Информационные системы – сердце и основа организаций финансового сектора. Сложно представить современный банк, обрабатывающий все запросы в бумажном виде.
Алексей Бабенко, руководитель направления, ЗАО НИП «Информзащита»
При этом именно долгое время «бескомпьютерной» обработки данных выработало четкую установку о первоочередной необходимости обеспечения физической безопасности. Поэтому сегодня никому не надо лишний раз доказывать, что стены должны быть крепкими, а замки на дверях – надежными.
Однако физическая безопасность является лишь одной из многих контрмер, которая закрывает далеко не самый большой перечень угроз, присущих информационным системам.
Любые информационные системы, в том числе и финансовых организаций, имеют три ключевые характеристики безопасности: конфиденциальность, целостность и доступность. Конфиденциальность позволяет быть уверенным, что данные обо всех ваших счетах и движении денежных средств не станут общедоступны (в обратной ситуации вряд ли кто-то станет хранить деньги в таком банке).
Целостность – что цифры на ваших счетах не будут никак изменены без вашего вмешательства (как в меньшую, так и в большую сторону). Доступность – что вы всегда сможете провести необходимую операцию при, допустим, срочной сделке.
В итоге в рамках рассмотренных характеристик безопасности для информационных систем возникает множество угроз. Сделать систему абсолютно безопасной – недостижимая задача, но избежать большинства угроз можно, и, более того, в современных условиях – обязательно нужно.
Безопасность – это процесс, и ее обеспечение должно быть постоянным в течение всего жизненного цикла системы.
Первый этап: планирование и прием в эксплуатацию
Представьте, что вы строите дом – добротный особняк с запасом площади для растущего поколения. Сомнительно, что вы допустите ситуацию, когда проект дома делает человек, который всегда занимался строительством заборов, и совершенно не знаком с технологиями жилого строительства.
Anna Egoyan _ \
Поэтому первым этапом по проектированию подсистемы безопасности еще только запланированной информационной системы должен быть подбор квалифицированных кадров, обучение сотрудников, либо привлечение опытных подрядчиков.
Второй распространенной ошибкой становится формирование требований к информационной безопасности на этапе разработки информационной системы. Если продолжить параллель со строительством дома, то получится, что об армировании основания жилища вы задумались только в тот момент, когда фундамент уже залит, а стены начали возводиться.
Важно понимать, что исправлять архитектурные ошибки так же непросто, как пытаться менять основание у построенного дома. А наличие неучтенных требований относится именно к таким ошибкам.
При разработке информационной системы должны учитываться практики безопасного программирования. Если же речь идет о подрядной организации, которая разрабатывает систему, то важно проследить, чтобы договор содержал пункт об обеспечении информационной безопасности.
При этом, чем точнее будет прописано то, что вы ожидаете получить, тем более предсказуемый результат получится на выходе. То же касается и приобретения уже готового продукта – одним из критериев выбора должен стать уровень защитных мер, заложенный производителем.
Наконец, до ввода информационной системы в эксплуатацию, вне зависимости от того, кто разрабатывал ее, необходимо провести тестирование. И если функциональное тестирование – повсеместная практика, то тестирование безопасности часто не проводится вовсе или же является небольшой частью общих тестов.
Между тем тестирование корректной работы подсистемы безопасности, а также защищенности программного обеспечения является обязательной стадией при принятии решения о вводе системы в эксплуатацию. Рекомендуется произвести выборочный анализ исходного кода, чтобы убедиться в том, что разработчики не на словах, а на деле используют методы безопасного программирования, учитывают защиту от известных угроз и не допустили логических ошибок.
Анализ тогда даст дополнительную уверенность в том, что программисты, писавшие код, «чисты на руку» и не оставили в коде недекларированного функционала. При этом сканер исходного кода – не панацея, но эффективный инструмент в руках умелого мастера, который может определить, безопасен ли код или нет.
Продолжение следует.
