5 мая, 2015, BIS Journal №1(16)/2015

На всю оставшуюся жизнь


Окулесский Василий

заместитель начальника службы ИБ, кандидат технических наук (ОАО "Возрождение")

Обеспечение безопасности полного жизненного цикла АБС — адекватный ответ на «новый вектор» информационных атак

Следует высоко оценить своевременность рекомендаций Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации. Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированных банковских систем» (РС БР ИББС-2.6–2014)». Сформулированные в них требования отвечают современному этапу развития информационных угроз, выполнение их позволяет минимизировать актуальные для банков риски.


СМЕНА ВЕКТОРА АТАКИ

Минувший 2014 год характеризовался изменением тактики злоумышленников, покушающихся на банковские средства. Прежде атаки производились на рабочее место клиента, с которого он распоряжается своим банковским счётом, и риску хищения подвергались его средства. Автоматизированные банковские системы (АБС) были злоумышленникам не по зубам, в лучшем случае они атаковали их внешний контур — сервисы, с помощью которых обслуживают клиентов. На защиту этого внешнего контура и были направлены усилия подразделений информационной безопасности банков.

В прошедшем 2014 году ситуация изменилась. Объектом атак злоумышленников стали автоматизированные банковские системы в целом. Этот новый вектор был выявлен в результате предотвращения попыток «взлома» АБС, по результатам анализа применённого инструментария и алгоритмов атак. Специалисты по информационной безопасности банков заинтересованно обсуждали новый феномен на специальных форумах и в ходе личного общения.

Конечно, в банке работают профессионалы информационной безопасности, чья квалификация намного выше познаний в этой сфере даже «продвинутого» клиента. В их распоряжении комплекс различных средств и обширный перечень мер для защиты банковских IT-ресурсов. Преодолеть профессиональную промышленную защиту информационных систем кредитно-финансовой организации неизмеримо сложнее, чем взломать рабочее место клиента. Но и «куш» в случае успешной информационной атаки на банк выше на порядки.

Размер возможного хищения с банковского счёта клиента в любом случае ограничен суммой, которая на нём находится. Средние размеры хищений с электронных счетов у клиентов — физических лиц можно условно оценивать десятками тысяч рублей, а у юридических лиц — в сотни тысяч и миллионы рублей. В случае успешной атаки на банк можно незаконно вывести куда как большие средства, эквивалентные сотням тысяч и миллионам долларов США.

Поэтому приобретают популярность атаки на корреспондентский счёт банка, чтобы, в случае успеха, похитить деньги. «Траектория» вывода средств может быть разной: если есть прямые отношения банков — то межбанковским переводом, если используется система обмена данными или система платежей Банка России — то через его территориальные подразделения, или же международным платежом путём атаки на S.W.I.F.T. Дальнейшая судьба похищенных у банка денег определяется той же схемой, которой пользуются для вывода украденных у клиентов сумм: как только средства поступают, их «распыляют» по нескольким счетам, выводят и обналичивают.

ОТ «МОДУЛЬНОГО» ПОДХОДА — К СИСТЕМНО-ПРОЦЕССНОМУ

«Продвинутые» злоумышленники демонстрируют неплохое знакомство с основными банковскими продуктами и технологиями, системами контроля, и, соответственно, знакомы с их уязвимостями. Осведомлены о нестыковках в нормативных документах. Кроме более высокой квалификации «исполнителей», атаки на АБС отличаются от атак на рабочее место клиента образом, которым они осуществляются.

Атаки на информационные ресурсы банка являются не «огнём по площадям» вроде фишинга или массовых рассылок спама, содержащего «банковские» вирусы. Атака на «внутренний контур» АБС — вроде «снайперского выстрела». Она является адресной, тщательно продуманной, основанной на предварительном «информационном шпионаже», анализе защитных механизмов, выявлении уязвимостей и, в итоге, определении «слабого звена» — мишени для атаки. Инструментарий информационной атаки может быть специально разработан под конкретный банк, применительно к особенностям его АБС.

Атаки на защищённый «внутренний контур» АБС могут осуществляться и через интернет, и по закрытым каналам связи – с использованием различных лазеек, брешей, оставленных возможностей. Вина за проникновение может лежать и на сотруднике банка, который способен как оказаться злоумышленником, так и допустить инцидент по неведению, в том числе из-за нарушений правил безопасности.

Мы живём в быстро меняющемся мире, и указанное изменение вектора атаки требует от подразделений информационной безопасности и от руководства банков изменения методологии защиты своих информационных сис­тем. Кроме того, для защиты от нового типа атак потребуются и ресурсы: организационные, человеческие, технические и финансовые. Кто способен осознать новые тенденции, защитится заранее, кто промедлит — будет вынужден делать то же самое, но уже после громких инцидентов, наносящих ущерб деловой репутации.

Старый подход, посредством которого противодействовали информационным атакам злоумышленников на рабочее место и средства клиента, допускал фрагментарные действия, которые механически суммировались и упорядочивались. Защита «периметра» и каналов связи АБС строится, как правило, эшелонировано, по модульному принципу: устанавливаются системы обнаружения и предотвращения вторжений IPS/IDS, файерволы, на рабочие станции — антивирусные программы, антиспам-фильтры и другие технические и программные средства защиты информации.

Совершенно по-особому выстраивается защита самой АБС. Необходима уверенность, что в ней самой не содержатся логические бомбы, закладки, бэкдоры и прочие «сюрпризы». Под таким углом обеспечение информационной безопасности на всех стадиях жизненного цикла автоматизированных банковских систем — требование, абсолютно адекватное для противодействия новому вектору атак, мишенью которых является «внутренний контур» АБС, а целью — хищение денег банка. Чтобы защититься от «адресных» атак на «внутренний контур» АБС, нужно изменить методологию обеспечения информационной безопасности. Суть новизны — в качественно новом подходе, который носит целостный, системно-процессный характер.

ПОЛЬЗОВАТЕЛЬ ВКЛЮЧАЕТСЯ В РАЗРАБОТКУ

Давайте вспомним, что представляет собой программное обеспечение АБС, даже самой небольшой, — это миллионы строк программного кода. Как бы хороши ни были программисты, невозможно избежать ошибок проектирования и кодирования, если задача поставлена неточно или неполно. И чем больше объём кода, тем выше вероятность ошибок. Подразделения информационной безопасности банка получают уже готовый продукт, работая с его функционалом. Проверяют его работоспособность, не зная возможных внутренних ошибок. Для них АБС выступает своего рода «чёрным ящиком»: в ответ на такое-то внешнее действие получается такой-то результат, и всё. Выполняет АБС то, что от неё требуется для работы банка и обслуживания клиентов — и хорошо. 

Классика проверок учит: надо тестировать, как система выполняет положенное, не выполняет запрещённое и просто проверять защиту от дурака. Обычно проверяют только первую, реже вторую составляющую. Мало кто в банке раньше задумывался о том, чтобы проверить, не может ли АБС выполнять то, что формально не запрещено, но чего ни в коем случае нельзя делать.
Новый подход, требование обеспечения информационной безопасности АБС на всех стадиях их жизненного цикла, с самого начала, преодолевает разрыв между изготовителями и пользователями. Недостаточность такого взаимодействия прежде служила причиной возникновения многих брешей в программном обеспечении банковских информационных систем, включая отдельные приложения. Включение банковских представителей ИБ в процесс проектирования, разработки, их участие во всех дальнейших стадиях использования АБС позволяет минимизировать внутренние риски банка.

Нормативно-правовой базой нового подхода служат следующие документы:
  • Положение Банка России от 9 июня 2012 года № 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств» (далее — Положение Банка России № 382-П);
  • Постановление Правительства России от 1 ноября 2012 года № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» (далее — Постановление Правительства РФ № 1119);
  • Приказ Федеральной службы по техническому и экспортному контролю от 18 февраля 2013 года № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».
ПРОЕКТИРОВАНИЕ: РОЛЬ ТЕХНИЧЕСКОГО ЗАДАНИЯ

Типовыми этапами жизненного цикла автоматизированной системы банка являются проектирование, разработка, тестирование, эксплуатация (обновление выступает одним из элементов эксплуатации). Требования информационной безопасности должны быть сформулированы для каждого из этих этапов в соответствии с триединым принципом соблюдения целостности, доступности и конфиденциальности. Исходной и конечной точкой для информационной безопасности являются бизнес-процессы банка.

На этапе проектирования отправной точкой служит рабочий функционал и обеспечение его безопасности, которая описывается рядом нормативных требований. Это безопасность работы через интернет, электронной почты, ведение журналов событий, управление правами доступа и т. д. Информационные ресурсы АБС, которые должны быть защищены, следует подразделять по соответствующим функциональным принципам. Требования к обеспечению безопасности тех или иных рабочих функций должны учитываться разработчиками ещё на этапе проектирования системы, для чего их следует включить в техническое задание.

Можно привести примеры целесообразности такого порядка. Допустим, возникает потребность расследовать инцидент, обстоятельства которого отражены в журнале проводок платежей. Для этого в системе заранее должна быть предусмотрена возможность протоколировать действия по созданию модификаций структуры журналов. Если этого изначально не было, то для придания такой возможности придётся переписывать код.

Далее, если в АБС используются специальные средства криптозащиты, то они должны быть учтены ещё при её проектировании. Для чего требования по их правильному встраиванию нужно указать в техническом задании. Иначе в дальнейшем возможны нарушения процедур их использования. Точно так же в техническом задании следует сформулировать требования к рабочим местам. Требования к безопасности определяются и тем, используется для работы информационной системы только внутренняя сеть или также интернет, но в любом случае эти параметры должны быть учтены при проектировании.
Необходимость доработки АБС может быть вызвана добавлением функций, предусматривающих новые роли участников бизнес-процесса. Новая роль может быть включена и как элемент доступа к уже существующей функции, предусматривая изменение прав доступа к информации и её обновления. Перспективы подобных доработок, дополнения многообразными возможностями также должны учитываться ещё на стадии проектирования.

Новые функции могут не соответствовать прежним технологиям, выходить за рамки их функционала. Дополнение каналов информирования  клиентов электронной почтой или SMS-оповещением заново ставит вопрос о целостности передаваемых данных. Но если задача безопасного использования новых технологий заранее не будет поставлена перед проектировщиками в техническом задании, то такие возможности, скорее всего, не будут заложены в АБС. Кроме формулировки требований в техническом задании, сотрудники банка должны анализировать, в какой степени представляемые исполнителем программные разработки соответствуют заданным рабочим функциям и насколько надёжно при этом осуществляется их защита.

Может даже сложиться впечатление, что в проектировании АБС сотрудников подразделения информационной безопасности банка должно участвовать не меньше, чем самих разработчиков. Чтобы сократить объёмы контроля, не снижая его качества, бизнес-процессы и рабочие функции АБС должны быть формализованы с чёткими критериями, где и какие средства обеспечения информационной безопасности должны быть задействованы. Например, использование интернета должно сопровождаться конкретикой, в частности, в отношении «демилитаризованной зоны» — промежуточного буфера, отделяющего внешнюю среду от внутренней. Формализация указанных требований завершает постановку задач и разработку технического задания.

ТЕСТИРОВАНИЕ: СООТНОШЕНИЕ IT И БЕЗОПАСНОСТИ

Насколько разработчики выполнили формализованные требования безопасности, выясняется на следующем этапе — тестирования, проверки. В зависимости от результатов тестирования система либо запускается в эксплуатацию, либо возвращается для доработки. В тестировании АБС могут участвовать специалисты банков как собственно по IT-системам, так и по информационной безопасности. В зависимости от ситуации ведущая роль может принадлежать одним или другим.

Потому что в ходе тестирования исходного кода приходится сталкиваться с проблемой грани между IT-технологиями и информационной безопасностью, которая бывает зыбкой. Так, с точки зрения промышленных информационных технологий, использование для отладки режимов программ-дебаггеров является нарушением стандартов разработки, которое отменяет гарантию качества. Но, с точки зрения информационной безопасности, из-за возможных типовых ошибок исходного кода атака может оказаться успешной, привести к модификации данных, перехвату управления.

Тестирование исходного кода подразумевает, в первую очередь, проверку выполнения стандартов программирования. В том числе на отсутствие «логических дыр», различных ошибок и неувязок — семантических, синтаксических, при использовании переменных, так называемых бэкдоров. Вторая задача тестирования — поиск «логических бомб» в исходном коде. Использование программистами различных функций дебаггеров в режиме отладки является чисто технологическим моментом. Но если следы таких воздействий не до конца ликвидируются, то ими могут воспользоваться хакеры и мошенники.

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

Банкам приходится тестировать программные продукты внешних производителей, в том числе отдельных модулей к собственным разработкам. Чтобы можно было проверить не только функциональность, но и отсутствие не декларированных возможностей, добросовестные поставщики предоставляют исходный код, даже если такого требования нет в техническом задании. Банк должен быть уверен, что приобретаемый продукт не будет содержать уязвимостей, которыми смогут воспользоваться мошенники для успешной атаки на АБС.

ЭКСПЛУАТАЦИЯ: НЕПРЕРЫВНАЯ ПРОВЕРКА

В процессе эксплуатации банк обязан в первую очередь обеспечить работоспособность всех сервисов, доступность всем участникам бизнес-процессов в соответствии с их ролями и полномочиями. Если заблокировать права доступа сотруднику офиса, он не сможет выполнять свои функции, обслужить клиента; системный администратор будет лишён возможности возобновить работоспособность «зависшей» системы. Но предоставить сотруднику более широкие права доступа, чем предусмотрены его служебными обязанностями, означает подвергнуть его риску случайно обслужить мошенника.

Система управления правами доступа должна функционировать чётко как швейцарские часы, в соответствии с системой распределения ролей участников бизнес-процессов. Ролям каждого участника — владельца, привилегированного и простого пользователей информационного ресурса — должны соответствовать свои формы электронных документов, процедуры, связанные с занесением в логи критически важных действий.

На стадии эксплуатации важны сбор и анализ событий доступа и поддержки работы системы. Для этапа эксплуатации важно создание резервных и архивных копий, эти функции должны присутствовать, быть оттестированными и практически отработанными. Это необходимо, поскольку АБС непрерывно работает, развивается, совершенствуется. Меняются не только данные, но и сама система, причем с большой частотой обновления. У архивных копий — свой, достаточно длинный жизненный цикл. В случае повреждения, уничтожения данных система должна быть немедленно восстановлена из резервной копии, иногда — из более ранних версий.

Кроме того, развитие банка — живой процесс: чтобы выжить в конкурентной борьбе, постоянно разрабатываются и создаются новые продукты, модифицируются или удаляются прежние. Оптимизируется структура: не только открываются новые офисы и точки обслуживания в разных регионах, но и ликвидируются старые, иногда — переводятся в другое место. Выводятся из эксплуатации целые фрагменты АБС, серверы и рабочие места пользователей. Информационные массивы закрываемых подразделений также должны храниться в доступном для работы с ними виде.
Если в архивных копиях хранятся только данные, а не СУБД, есть опасность, что ими нельзя будет воспользоваться: меняются сами данные, их структура, системы визуализации. Поэтому неправильно хранить отдельные группы данных и копии системы управления базами данных: на стадии проектирования должны быть предусмотрены службы копирования СУБД в каждый конкретный момент времени. Такие возможности должны тестироваться постоянно и непрерывно. При этом резервное копирование в режиме реального времени не должно мешать выполнению основных сервисов.

ЗАВЕРШЕНИЕ ЖИЗНЕННОГО ЦИКЛА АБС

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

Например, информация о персонале должна храниться 75 лет, бухгалтерская информация в действующем банке — не менее 7 лет с момента ввода в систему. По-разному может решаться вопрос о степени важности, «сроках хранения»  и дальнейшей судьбе сведений о структуре информационной сети, слаботочных систем — что уничтожить, а что передать на хранение в централизованный архив.

Если каждое подразделение уникально, имеет смысл информацию хранить минимум год, для проведения расследований в случае возникновения непредвиденных ситуаций. Но в любом случае эти вопросы должны быть решены заранее, до того, как закрывается отделение банка. Иначе информация о сети организации может стать доступной случайным людям, в том числе мошенникам.

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

Переход к новому системно-процессному принципу обеспечения информационной безопасности на всех этапах жизненного цикла АБС является адекватной мерой противодействия «новому вектору» атак злоумышленников — на «внутренний контур» банковских IT-систем. Чтобы требования безопасности могли соблюдаться на всех этапах жизненного цикла АБС, они должны быть представлены разработчикам ещё до стадии проектирования, в техническом задании. Благодаря этому технические возможности выполнения требований безопасности могут быть заложены в архитектуру информационных систем.


 

 

Смотрите также

Подпишись на новости!
Подписаться