Критерии оценки экрана веб-приложений (стр. 2 )

1.2.  Применение экрана веб-приложений

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

Зачем же потребовалось выводить экран веб-приложений в отдельный класс устройств? Ведь по сути решение может вписаться в класс продуктов межсетевых экранов прикладного уровня. Тут же появляется вопрос: почему именно веб-приложений, которая так все поменяла, хотя и до этого средства экранирования поддерживали протоколы HTTP/HTTPs? Ответ на эти вопросы кроется в модели OSI, которая группирует закономерности, протоколы и механизмы для каждого из семи уровней по типу межсетевого взаимодействия. Традиционно считается, что прикладной уровень — это последний уровень модели и выше него располагаются только данные конечных приложений, которые не могут быть формализованы и сгруппированы. Однако с развитием стандартов представления информации прикладными сервисами уже можно говорить о том, что, частично, данные, которыми оперируют определенные группы приложений, хорошо формализуются, и правила их представления, по сути, являются некими проприетарными протоколами или, упрощенно говоря, закономерностями. Таким образом, можно говорить о появлении нового уровня межсетевого взаимодействия, который скрыт для классических межсетевых экранов прикладного уровня. Новый класс устройств — экран веб-приложений — характеризуется способностью понимать группы протоколов и зависимостей, свойственных для веб-приложений, которые строятся над прикладными протоколами http/https.

Классическое размещение экрана веб-приложений в сети — в режиме обратного прокси-сервера, перед защищаемыми веб-cерверами. В зависимости от производителя могут поддерживаться и другие режимы работы — например, прозрачный прокси-сервер, мост или даже пассивный режим, когда продукт работает с репликацией трафика. После установки экрана веб-приложений и пуска продуктивного трафика сразу же начинает работу основной компонент защиты — машинное обучение, в ходе которого составляется эталонная модель коммуникации с объектом защиты, и таким образом формируется «белый» список допустимых идентификаторов доступа. На данный момент в веб-приложениях используются три типа идентификатора доступа: HTTP-параметры (в представлениях типа: Raw, XML, JSON), идентификатор ресурса (URL, URN), идентификатор сессии (cookie). Задача экрана веб-приложений состоит в определении допустимых значений идентификаторов для веб-приложения. Из определенных значений впоследствии будет состоять эталонная (позитивная) модель. Включение конкретных значений идентификатора в модель осуществляется на основе применения математико-статистического алгоритма, который с помощью выборки продуктивного трафика оценивает эти значения как допустимые. Когда все ресурсы веб-приложения добавлены в позитивную модель, администратор системы должен убедиться в отсутствии значимого количества ложно-позитивных срабатываний и переключить систему в режим блокировки. Помимо машинного обучения в набор функций экрана веб-приложений обычно входят следующие типовые механизмы защиты: валидация протокола; сигнатурный анализ; защита от инъекций и XSS (зачастую проприетарная); возможность создания собственных правил защиты; DDoS-защита; интеграция с репутационными и фрод-сервисами; интеграция с прочими устройствами в ландшафте ИБ компании. Приоритетом для производителя экрана веб-приложений является фокус на собственных исследовательских центрах, которые генерируют обновления политик безопасности с учетом актуальных угроз веб-приложениям. Так появляются, например, сигнатуры атак, присущие для конкретных веб-фреймворков и систем контроля контента или проприетарные механизмы защиты от XSS и SQL-инъекций

1.3.  Комплексный подход к защите веб-приложений

В итоге получается, что для защиты информации в приложениях у служб защиты информации на предприятии есть три возможных подхода:

·  внедрить процессы цикла безопасной разработки;

·  частично внедрить процессы безопасной разработки, сделав упор на стадиях тестирования;

·  внедрить и администрировать экран веб-приложений.

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

Таблица 2 – Задачи и решения безопасности приложений.

Задача	Экран веб-приложений	Тестирование на безопасность
Противодействие известным и неизвестным уязвимостям	Да	Да
Проверка большого количества приложений	Да	Да
Фильтрация запросов по белым и черным спискам	Да	Нет
Защита клиента	Да	Нет
Обнаружение реальных уязвимостей	Нет	Да
Обнаружение программных закладок	Нет	Да
Проверка качества приложения	Нет	Да
Атематическое закрытие обнаруженных уязвимостей	Только совместно

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

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

Безопасность веб-приложений на предприятии, может гарантироваться только в случае, если:

·  продуктивные веб-приложения созданы и живут в цикле безопасной разработки;

·  установлен экран веб-приложений, который закрывает веб-приложение от известных, но еще не закрытых в цикле разработке уязвимостей, сдерживает эксплуатацию неизвестных;

·  Функционирует центр безопасности. Производится постоянный мониторинг и тюнинг WAF. Сочлененные правильным образом технологии, процессы и люди, готовы начать реализацию дополнительных контрмер.

ГЛАВА 2. РАЗРАБОТКА КРИТЕРИЕВ ОЦЕНКИ ЭКРАНА ВЕБ-ПРИЛОЖЕНИЙ

2. 

2.1.  Анализ Российских нормативных документов.

Экраны веб-приложений — это относительно новое средство защиты информации, и до недавнего времени никаких упоминаний о его применении в Российских нормативной базе не было. В связи с этим производители таких устройств могли получить сертификат от Федеральной службы по техническому и экспертному контролю только на соответствие техническим условия и на не декларированные возможности. Однако, Федеральная служба по техническому и экспертному контролю выпустила информационное сообщение об утверждении требований к межсетевым экранам от 28 апреля 2016г. N 240/24/1986. В которым, были определены требования для новых типов межсетевых экранов, среди которых и требования для экранов веб-приложений, классифицированного как межсетевой экран уровня веб-сервера.