Защита бизнес-приложений

18 августа 2008 Банковские технологии
Банковские технологии
#8, август 2008 г.
Владислав Ершов, Ведущий системный аналитик отдела информационной безопасности компании Открытые Технологии.

То, что бизнес зависит от IT, — очевидно. Особенно это актуально для финансовой отрасли, на сегодняшний день одной из самых развитых в отношении IT. В свете серьезного влияния информационных технологий на бизнес все компании в определенной степени уделяют внимание вопросам безопасности — будь то антивирус, установленный после очередной вирусной эпидемии, или зрелая система менеджмента информационной безопасности (ИБ), созданная в соответствии со стандартом ISO 27001. Однако если рассмотреть уже реализованные подходы к обеспечению безопасности, очевидно, что наиболее уязвимым местом остаются бизнес-приложения. Причем со временем их уязвимость лишь растет, как растет и связанный с этим ущерб для бизнеса. Ответ на вопрос, как защитить бизнес-приложения и, соответственно, бизнес, дан в предлагаемой статье.


Об особенностях

Говоря об информационной безопасности, необходимо рассматривать ее как комплексную и непрерывно управляемую систему. Проблемы безопасности рассматривают такие стандарты как серия ISO 2700х, различные национальные и отраслевые стандарты (стандарт Банка России по ИБ, стандарт безопасности платежных систем PCI DSS). К тому же существуют рекомендации по безопасной разработке приложений. Очевидно, что к безопасности бизнес-приложений имеют отношение и антивирусное средство, и межсетевой экран, и процедуры менеджмента ИБ. Но имеются и специфические особенности обеспечения безопасности бизнес-приложений, о которых пойдет речь дальше.

Для специалистов по ИБ уже очевидно, что бизнес-приложения (промышленные или собственные разработки) нельзя считать защищенными! Это определяется в первую очередь человеческим фактором:

  • ошибками при разработке;
  • ошибками при настройке;
  • ошибками при эксплуатации.

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

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


Традиционный подход

Традиционно при защите приложений применяется ряд типовых методов:

  • использование встроенных средств обеспечения ИБ;
  • использование сканеров защищенности для поиска уязвимостей или ошибок конфигурирования;
  • установка обновлений;
  • использование специализированных наложенных средств.

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

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

Кстати, о полномочиях. Очень часто под "защитой приложений" подразумеваются системы класса IAM (Identity and Access Management). Подобные системы можно уподобить межсетевому экрану, который разрешает доступ, например, только на 80 порт к веб-приложению. И это действительно необходимый элемент защиты. Но при этом межсетевой экран не способен обнаружить атаки на уровне приложения или зарегистрировать подозрительные действия пользователя в приложении. Аналогично и системы класса IAM являются важным элементом системы ИБ, но выполняют лишь ограниченную часть функций. К тому же возникает вопрос адекватности выданных пользователю полномочий и проблема использования им легальных и необходимых для работы полномочий в неслужебных целях.

Итак, традиционные средства обеспечения ИБ важны, но недостаточны. Основные их ограничения связаны с невозможностью контроля событий на уровне приложения. Данный тезис давно стал понятен западным специалистам по ИБ, и к настоящему моменту новые веяния обратили на себя внимание и в России.


Современный подход

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


Первый рубеж обороны: веб-приложения

Как известно, встречают по одежке. Для клиента "одежкой" банка, в который он идет, являются позиция на рынке, имидж, офис, приветливые и профессиональные сотрудники и... веб-сайт. Веб-сайт банка — это:

  • информационный источник для клиента и средство обратной связи,
  • средство дистанционного обслуживания (СДО).

Важно понимать, что оба аспекта одинаково важны. Различными будут только риски. Если для информационного источника важнее обеспечить доступность информации, то для СДО необходимо обеспечить еще и целостность информации. Веб-сайт, доступный из недоверенной среды Интернет, уязвим априори.

Чтобы подробнее рассмотреть имеющиеся риски, нужно ответить на ряд вопросов. Например, будет ли нанесен ущерб бизнесу, если:

  • потенциальный клиент получит недостоверную информацию об услугах и выберет другой банк;
  • клиент не сможет получить доступ к веб-сайту банка (к СДО);
  • злоумышленник, воспользовавшись уязвимостью СДО, осуществит перевод денег со счета клиента;
  • злоумышленник, воспользовавшись уязвимостью СДО, получит информацию об операциях клиента;
  • злоумышленник, воспользовавшись уязвимостью СДО, получит информацию о банковских карточках, персональную информацию клиентов и т. п.

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

Веб-приложения требуют особого подхода к защите, и для этой цели существуют специализированные продукты — Web Applications Firewall (WAF). Классический WAF анализирует трафик к приложению на всех уровнях сетевой модели OSI, начиная с третьего. При этом основной упор делается на верхние уровни, где осуществляется контроль взаимодействия пользователя с приложением. При настройке WAF осуществляется обучение легальной работе с приложением (это может быть сделано в ручном и автоматическом режиме), после чего весь нелегальный трафик блокируется. Таким образом, WAF функционирует на основе "белого списка", в отличие от традиционных средств IPS, использующих сигнатурный анализ. WAF обеспечивает контроль специфичных для веб-приложений протоколов (HTTP, HTTPS) и различных параметров:

  • cookies,
  • параметры запросов,
  • возвращаемые значения,
  • соответствие RFC,
  • ответы сервера и т. д.

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

Все современные WAF могут работать в режиме кластера (active/active или active/standby), обеспечивая высокую доступность, а ряд продуктов WAF помимо функций защиты выполняют и задачи по балансировке и оптимизации трафика. Опыт использования подобных продуктов показывает, что для каждой конкретной ситуации может быть выбрано оптимальное решение из представленных на рынке продуктов, исходя из поставленных задач.

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


Второй рубеж обороны: внутренние бизнес-приложения

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

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

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

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

  • работа в режиме сетевого сниффера для полного и независимого контроля взаимодействия пользователей с приложением;
  • возможность анализа различных распространенных прикладных протоколов (HTTP(S), SQL*Net, Swift, TN3270, TN5250, MQ Series, MSMQ и др.) и протоколов собственной разработки;
  • разбор трафика взаимодействия пользователей с приложением и выявление интересующих событий (аутентификация, доступ к определенным разделам приложения, просмотр счетов, перевод денег и др.);
  • формирование бизнес-правил, определяющих возможные мошеннические действия (доступ к большому количеству счетов в течение дня, изменение определенных данных, доступ в нерабочее время и др.);
  • надежное хранение зарегистрированных событий и контроль их нелегального изменения в хранилище;
  • анализ исторических данных для расследования инцидентов;
  • средство автоматизации расследования инцидентов;
  • возможность просмотра сеансов работы пользователей вплоть до восстановления интерфейса пользователя для ряда протоколов (например, HTTP(S), TN5250).

Средство, обладающее подобным функционалом, является отличным инструментом автоматизации деятельности по обеспечению экономической безопасности организации (включая организацию внутреннего контроля и борьбу с мошенничеством).


Третий рубеж обороны: интеграционные платформы

С развитием IT зачастую приходится решать вопросы интеграции различных приложений внутри организации, а также обеспечивать взаимодействие с внешними организациями. Особенно это актуально для крупных банков, развивающихся за счет слияний и поглощений. В этом случае интеграция на уровне IT может идти путем перехода на единую банковскую систему, что зачастую слишком дорого и трудоемко. Чаще осуществляется интеграция существующих приложений. В настоящее время большое распространение получила идеология сервисно-ориентированной архитектуры (SOA), когда для интеграции используются открытые и стандартизованные протоколы на базе XML. Интеграция может происходить также с использованием других технологий.

При интеграции приложений помимо преодоления технических сложностей необходимо решать и вопросы информационной безопасности. Основные риски связаны с возможностью внесения неверно сформированных или заведомо ложных данных, отправкой сообщений от неавторизованного источника, реализацией различных специфических атак (например, XML Flood или XPath injection).

Для решения задачи обеспечения безопасности при интеграции приложений могут быть использованы специализированные продукты класса XML Gateway. Данные продукты обеспечивают защиту от атак прикладного уровня, специфичных для используемых при интеграции протоколов (по аналогии с WAF для протокола HTTP), контроль целостности передаваемых сообщений, интеграцию с внешними системами управления доступом.


Четвертый рубеж обороны: базы данных

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

  • клиент-серверных приложений,
  • многозвенных приложений,
  • инструментария для разработки ПО или администрирования СУБД,
  • локальных средств управления сервисами СУБД.

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

Для решения задачи защиты СУБД необходимо:

  • осуществлять мониторинг взаимодействия с СУБД;
  • контролировать доступ к наиболее критичным данным, выполнение операций над структурой БД и осуществление административных задач (создание дампа данных, изменение полномочий доступа, создание пользователей и т. д.);
  • обнаруживать атаки в сетевом трафике, направленные на СУБД;
  • при необходимости блокировать неразрешенные взаимодействия.

Данный функционал реализуется продуктами класса Database Activity Monitors (DAM). DAM функционируют в режиме сниффера, а некоторые продукты и в inline-режиме при потребности в функционале блокирования. Кроме этого, DAM зачастую содержат сканеры уязви-мостей СУБД для комплексной оценки защищенности. Выводы

Риски при автоматизации бизнеса за счет бизнес-приложений зачастую неприемлемо высоки из-за возникающих угроз. К тому же появляется все больше требований со стороны законодательства и различных стандартов, которые касаются обеспечения безопасности данных и контроля доступа к ним. Актуальность проблемы подтверждается и крупнейшими аналитическими агентствами (например, Gartner рассматривает этот вопрос в своем материале Hype Cycle For Data and Application Security). Но в настоящее время существуют продукты, способные обеспечить безопасное использование бизнес-приложений:

  • Web Application Firewall (F5 Networks BIG-IP Application Security Manager, Imperva SecureSphere Web Application Firewall);
  • продукты для контроля действий пользователей и обнаружения мошенничества (Intellinx);
  • XML Gateway (IBM DataPower XML Security Gateway XS40, Imperva SecureSphere Web Application Firewall);
  • Database Activity Monitors (Imperva SecureSphere Database Monitoring/Security Gateway).

Подобные средства как обеспечивают обнаружение нарушений в режиме реального времени, так и позволяют расследовать инциденты ИБ. Поскольку все эти классы средств обеспечивают защиту данных и приложений, то зачастую в одном продукте можно встретить широкий набор функциональных возможностей (например, WAF и DAM или WAF и XML Gateway). Из данного конструктора можно построить прочную стену, используя накопленный опыт и знания, обеспечив тем самым защиту вашего бизнеса.




Предыдущая новость:
Решения IronPort для защиты от вирусов и спама
Следующая новость:
Бизнес-приложения как объект защиты системой ИБ