Учитывая сложность, разнообразие и взаимную увязку банковских автоматизированных систем, их тестирование требует большого опыта и серьезных ресурсов. Сбои происходят даже при переносе уже проверенного ПО с тестовой площадки на «боевую». При этом далеко не все можно отдать на аутсорсинг.

Самое пристальное внимание необходимо уделять «самописному» ПО. Если коммерческие системы тестирует на безопасность разработчик, то относительно несерийного ПО часто ограничиваются заверениями. Это крайне опасный подход. Приходится также учитывать, что сами тесты бывают небезопасны для банковских систем — особенно тесты на проникновение. Для любого тестирования важен подбор инструментов. Результаты не должны заканчиваться констатацией факта «пройдено или не пройдено» — за тестами должна следовать работа риск-менеджмента по выработке решений на обработку рисков и т.д. Хороший пример — организация работ по PCIDSS и СТО БР ИББС. Во многих случаях лучше проводить независимое тестирование — доверие к независимому арбитру выше, но начинать следует самостоятельно — очевидные вещи можно протестировать и своими силами. Тестированию следует подвергать и часть АБС, работающую на стороне клиента.

Характерный пример, говорящий косвенным образом о сложности задачи и отсутствии встроенных средств защиты в АБС: в реестре ФСТЭК России нет ни одной АБС, сертифицированной хотя бы на отсутствие недекларированных возможностей, только межсетевые экраны и несколько экземпляров Oracle Database 10g. Лучше строить систему защищенной, чем защищать построенную. Технологии давно созрели. Люди перестают верить в логин-парольную защиту доступа в интернет-банк, что более чем оправдано.

Резюмирую: аудит это не деяние, а процесс. Его, как ремонт, нельзя закончить (и не надо) — можно только остановить.

Реклама