Размещено на http://www.allbest.ru/

1

Размещено на http://www.allbest.ru/

ОГЛАВЛЕНИЕ

• защита экран веб приложение
• ВВЕДЕНИЕ
• ГЛАВА 1. ПОДХОДЫ К РЕШЕНИЮ ЗАДАЧИ ЗАЩИТЫ ВЕБ-ПРИЛОЖЕНИЙ
• 1.1 Организация цикла безопасной разработки и анализ кода
• 1.2 Применение экрана веб-приложений
• 1.3 Комплексный подход к защите веб-приложений
• ГЛАВА 2. РАЗРАБОТКА КРИТЕРИЕВ ОЦЕНКИ ЭКРАНА ВЕБ-ПРИЛОЖЕНИЙ
• 2.1 Анализ Российских нормативных документов
• 2.2 Анализ зарубежных практик
• 2.3 Требования к механизмам защиты экрана веб-приложений
• ГЛАВА 3. РАЗВИТИЕ ЭКРАНОВ ВЕБ-ПРИЛОЖЕНИЙ В БУДУЩЕМ
• 3.1 Объединение процессов безопасной разработки и технологий экранирования
• 3.2 Развитие интеллектуального поведенческого анализа пользователей веб-приложений
• Список используемой литературы
• Приложение № 1. Критерии оценки экранов веб-приложений

ВВЕДЕНИЕ

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

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

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

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

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

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

ГЛАВА 1. ПОДХОДЫ К РЕШЕНИЮ ЗАДАЧИ ЗАЩИТЫ ВЕБ-ПРИЛОЖЕНИЙ

1.1 Организация цикла безопасной разработки и анализ кода

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

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

· Microsoft Security Development Lifecycle

· Cisco Secure Development Lifecycle

· PCI Security Standards

· Обеспечение информационной безопасности на стадиях жизненного цикла автоматизированный банковской системы (РС БР ИББС-2.6-2014)

Стандарты так или иначе помогают создать цикл безопасной разработки программного обеспечения, указывают на основные стадии разработки, и меры, которые необходимы применять в контексте каждого этапа с целью уменьшения вероятности возникновения ошибок в разрабатываемом продукте. Так, например, Microsoft Security Development Lifecycle определяет этапы и меры, представленные в таблице 1.

Таблица 1 - Этапы разработки по Microsoft Development Lifecycle

№	Этап	Меры
1	Обучение	· Повышение знаний, умений и общей квалификации сотрудников, задействованных в цикле безопасной разработке · Осведомление о цикле безопасной разработке, передача необходимых знаний о его процессах
2	Определение требований	· Определение требований безопасности · Определение требований к качеству · Оценка рисков
3	Проектирование	· Архитектурные требование · Анализ ландшафта атак · Моделирование угроз
4	Внедрение / разработка	· Использование доверенных средств разработки · Использование практик безопасного программирования · Статический анализ кода
5	Верификация	· Динамический анализ · Фаззинг · Проверка векторов атак
6	Релиз	· Выработка планов по реагированию на инциденты · Финальный анализ безопасности · Доверенный выпуск
7	Реагирование	· Сбор информации и возникающих проблемах, и инцидентах · Выполнение планов реагирования на инцидент

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

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

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.1 Анализ Российских нормативных документов

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

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

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

2.2 Анализ зарубежных практик

Первым значимым драйвером рынка экранов веб-приложений стало обновление стандарта безопасности индустрии платежных карт PCI DSS в части требования 6.6 в 2008 году. В результате обновления у сертифицирующихся организаций появилась альтернатива при обеспечении информационной безопасности своих веб-приложений: организация может сама выбирать -- либо поддерживать бизнес-процессы по анализу защищенности веб-приложений (внедрению процессов цикла безопасной разработки), либо внедрять и обслуживать экран веб-приложений. Новый вариант стандарта и определил первые ключевые требования для систем экранирования веб-приложений. Выполнение данных требований до сих пор актуально для многих разработчиков, так как стандарт особенно важен в финансовой и банковских сферах.

Общие требования к экрану веб-приложений по версии PCI DSS:

· системные компоненты экрана веб-приложений должны соответствовать требованиям PCI DSS;

· возможность реагирования на угрозы, описанные в OWASP Top Ten;

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

· предотвращение утечки данных -- инспекция ответов сервера на наличие критичных данных;

· применение как позитивной, так и негативной модели безопасности;

· инспектирование всего содержимого веб-страниц, включая HTML, DHTML и CSS, а также нижележащих протоколов доставки содержимого (HTTP/HTTPS);

· инспектирование сообщений веб-сервиса (SOAP, XML);

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

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

· поддержка SSL\TLS-терминации соединения;

· предотвращение или обнаружение подделки идентификатора сессии;

· автоматическое скачивание обновлений сигнатур атак и применение их;

· возможность установки режима отказоустойчивости;

· поддержка устройством клиентских SSL-сертификатов;

· поддержка аппаратного хранения ключей.

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

Более серьезно к формированию критериев для экранов веб-приложений сделал проект Web Application Firewall Evaluation Criteria (WAFEC), который поддерживался сразу двумя профильными организациями, это, Open Web Application Security Project (OWASP) и Web Application Security Consortium (WAFEC). Данный проект преследовал две основные цели, это помочь в общем понимании роли экрана веб-приложений в защите их, и предоставить инструмент для обоснованного выбора соответствующего продукта класса экран веб-приложений. Первая версия выпущенного документы появилась на свет в 2006 году и была широко распространена в области защиты веб-приложений. В 2013 году команда вновь собралась, для того, чтобы выпустить вторую версию документа, но до сих пор так и не получилось сформировать новые требования для экранов веб-приложений, в то время как критерии из первой версии документа успели устареть и во многом уже не отражают эффективность экранов веб-приложений, так как не учитывают новые угрозы, уязвимости и появившееся технологии защиты с 2006 года. Однако несмотря на эти проблемы, изданный документ WAFEC представляет собой хорошо организованный документ, с четкой и понятной структурой на основе которой можно продолжить трансформацию документа, убрать устаревшие критерии и добавить актуальные. Переработка критериев с учетом результатов исследования представленной в данной магистерской диссертации представлены в Приложении 1.

2.3 Описание общих требований к экрану веб-приложений

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

· Imperva Web Application Firewall;

· F5 Application Security Manager;

· Positive Technologies Application Firewall.

Проанализировав основные лидирующие продукты на мировом рынке, можно сформировать список защитных механизмов, которые обычно присущи WAF:

· проверка протокола;

· машинное обучение эталонной модели;

· сигнатурный анализ;

· специализированные механизмы;

· пользовательские правила выявления нелегитимных запросов;

· защита от атак типа «Отказ в обслуживании»;

· интеграция со сторонними решениями.

2.3.1 Проверка протокола

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

· требования RFC;

· длина и количество заголовков, параметров;

· временные рамки;

· проверка JSON, XML сущностей;

· отсутствие недопустимых значений.

2.3.2 Машинное обучение

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

· данным на входе алгоритма;

· алгоритму обучения;

· способу принятия решения;

· оптимизационной технологии;

· возможности настройки;

· формату эталонных моделей.

Примеры описывающие характеристики машинного обучения приведены в таблице 3.

Таблица 3 - Характеристики машинного обучения.

Характеристика машинного обучения	Примеры
Данные на входе алгоритма обучения	Помимо идентификаторов доступа из запроса пользователя, различные реализации позволяют вносить дополнительные сведения, которые повышают эффективность обучения. Например, могут учитываться следующие данные: · запросы от доверенных узлов (зона тестирования); · тип параметра: dynamic, static, hidden, read-only; · ответы веб-приложения.
Характеристика машинного обучения	Примеры
Алгоритм обучения	Сердце машинного обучения, математический аппарат, нацеленный на обнаружение аномалий в самом глубоком понимании прикладного обеспечения. Например, · метод опорных векторов (Support Vector Machine); · случайный лес (Random forest); · нейронные сети (Neural Networks); · скрытая модель Маркова (Hidden Markov Model).
Способ принятия решения	Во избежание рекурсивного обучения в машинном обучении должны применяться понятные критерии готовности элемента к внесению его в эталонную модель. Например, это могут быть следующие критерии: · время обучения; · количество запросов, содержащих обучаемый элемент; · пороги энтропии элемента.
Техника оптимизации модели	В ходе цикла разработки защищаемое веб-приложение постоянно меняет свою модель поведения. Несоответствие выученной эталонной модели с реальной приводит к блокировке клиентских запросов. Для того чтобы этого не случалось, каждый механизм машинного обучения снабжается техникой по оптимизации эталонной модели. Могут использоваться следующие техники: · интерфейс ручной корректировки модели; · привлечение “учителя” для машинного обучения; · эвристический анализ запросов нарушающих текущую модель, с последующей её оптимизацией.
Возможности настройки	Машинное обучение -- это сложный совокупный процесс, необходимость в конфигурировании которого может зависеть как от количественных показателей трафика, так и от качественных характеристик веб-приложения. Например, может возникнуть потребность в конфигурировании: · максимального времени обучения; · порогов срабатывания; · способа принятия решения; · математических параметров алгоритма обучения.
Характеристика машинного обучения	Примеры
Формат эталонных моделей	Машинное обучение может быть разработано для построения модели: · позитивной; · негативной. Так же, в зависимости от обучения, модель может содержать различные объекты, в типичной реализации оптимально считается содержать: · идентификатор ресурса (URI/URL); · параметры прикладных сущностей (HTTP, XML/JSON entity); · идентификатор сессии (Cookie).

2.3.3 Сигнатурный анализ

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

2.3.4 Специализированные механизмы

Специализированные механизмы защиты Эффективность фильтрующих средств защиты существенно зависит от степени перекрытия одних и тех же угроз различными механизмами. Объясняется это тем, что всегда существует некоторая вероятность, в пределах которой исследуемые атаки могут остаться незамеченными для конкретного алгоритма защиты. Вероятность обнаружения атаки, если ее исследуют множество различных алгоритмов, резко понижается. Это наглядно демонстрируется при попытках теоретически спроектировать обход механизмов защиты экрана веб-приложений. К примеру, рассмотрим упоминавшийся ранее механизм защиты «машинное обучение эталонной модели». Он не гарантирует защиты в том случае, если возможно произвести атаку, контекст которой лежит в заданных пределах отклонения от эталонной модели. Происходит это потому, что данный механизм защиты не имеет возможности определить тип воздействия на веб-приложение. Тип нелегитимного воздействия может определяться с помощью сигнатурного анализа, однако атака, использующая 0day-уязвимость, с легкостью преодолеет такой защитный механизм. Таким образом возможность появления ложно-негативных событий для каждого из механизма защиты вполне осязаема, тогда как вероятность угрозы проведения атаки, которая будет комбинировать несколько условий обхода различных механизмов защиты, становится на порядок меньше. К примеру, комбинированным условием обхода двух выше рассмотренных механизмов защиты является атака, эксплуатирующая 0day-уязвимость, контекст которой не нарушает отклонения от эталонной модели машинного обучения. Для снижения вероятности ложно-негативных событий современные экраны веб-приложений не ограничиваются комбинированием двух вышерассмотренных механизмов защиты. Их количество может достигать нескольких десятков, но в отличие от механизма машинного обучения задача исследования этих алгоритмов существенно более узка; зачастую она сводится к обнаружению конкретного типа атак. Такие механизмы защиты носят названия по типу атаки на веб-приложение, которую они обнаруживают. В зависимости от реализации WAF они могут быть как-либо сгруппированы в общей политике безопасности или разнесены в отдельные ее части. Рассмотрим специализированные механизмы защиты, используемые современными экрана веб-приложений, для обнаружения наиболее распространенных атак на веб-приложения.

Внедрение кода

Возможность инъекции возникает, когда веб-приложение посылает недостаточно проверенные данные из запроса клиента на вход интерпретатору команд смежной функциональной системы, в общей информационной. Целью атаки могут быть следующие смежные системы: СУБД, операционная система, LDAP-сервер, XPath-интерпретатор и прочие. Это позволяет злоумышленникам манипулировать смежными функциональными системами. Обнаружение инъекции производится с помощью нескольких техник:

1. Токенизация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. Если валидные для синтаксиса целевой системы токены найдены, запрос клиента признается потенциально опасным.

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

3. Создается группа сигнатур, характеризующих попытки манипуляции с целевой системой. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным

Некорректная аутентификация и управление сеансами

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

1. Определение допустимых идентификаторов сессии. Если в запросе найдены ранее неизвестные идентификаторы сессий или значение этих идентификаторов отличается от допустимого значения, запрос признается нелегитимным.

2. Фиксация read-only идентификаторов сессии. При нахождении в запросе измененного идентификатора сессии, который по логике веб-приложения не может изменяться на стороне клиента, запрос признается нелегитимным.

3. Контроль клиентов на предмет подмены идентификаторов сессии. При нахождении в запросе идентификатора сессии, принадлежащего другому клиенту, запрос признается нелегитимным.

4. Определение попыток перебора идентификаторов сессии. При превышении объективно возможного порога запросов в секунду с разными идентификаторами сессий от одного клиента запросы признаются нелегитимными.

Также существуют техники проактивной защиты:

1. криптографическая подпись идентификаторов сессии;

2. шифрование идентификаторов сессии.

Межсайтовое выполнение сценариев

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

1. Токенезация - нахождение токенов для всех лексем запроса на основе использования конечного автомата. При нахождении валидных для синтаксиса языка программирования токенов запрос клиента признается потенциально опасным.

2. Внедрение Content Security Policy (CSP). CSP-заголовок -- относительно новый способ обеспечения безопасности HTTP-коммуникаций. Данный заголовок для каждого ответа определяет возможные источники ресурсов, из которых может состоять веб-страница, отображаемая браузером клиента. Некоторые WAF обладают техникой автоформирований правил CSP.

3. Анализ ответов. Содержание ответа сравнивается с принятыми из запроса данными. При обнаружении однозначных данных в паре запрос-ответ транзакция признается нелегитимной.

4. Внедрение в ответы веб-приложения специального JavaScript-кода, контролирующего отображение страницы в браузере клиента, особенно эффективно при определении DOM-based XSS.

5. Создается группа сигнатур, характеризующих попытки межсайтового исполнения сценариев. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.

Небезопасные прямые ссылки на объекты

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

1. Определение попыток перебора объектов. При превышении объективно возможного порога запросов объектов в секунду от одного клиента запросы признаются нелегитимными.

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

3. Создается группа сигнатур, характеризующих попытки прямого обращения к объектам. При нахождении запросов, соответствующих сигнатурам атаки, сигнатурный анализ признает запрос нелегитимным.

Небезопасная конфигурация

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

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

Утечка критичных данных

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

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

Отсутствие контроля доступа к функциональному уровню

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

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

Подделка межсайтовых запросов

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

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

Использование компонентов с известными уязвимостями

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

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

Непроверенные перенаправления и переходы

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

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

2.3.5 Пользовательские правила выявления нелегитимных запросов

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

· расшифрование;

· инспектирование;

· парсинг;

· нормализация и хранение;

· управление сессиями;

· проверка по политикам безопасности.

Результаты работы этих процессов должны находить применение не только в установленных механизмах защиты, но и предоставляться администраторам ИБ для формирования собственных правил безопасности.

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

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

Примеры реализации:

· набор критериев в контексте единого правила;

· встроенный язык программирования с фреймворком по работе с трафиком;

· интерфейс корреляции пользовательских сигнатур.

2.3.6 Защита от атак типа отказ в обслуживании

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

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

Первый уровень защиты от атак типа «Отказа в обслуживании» в WAF -- это механизм определения инфицированных клиентов. Он частично заимствован из решений ориентированных на предотвращение мошенничества, где проверка клиентов является одной из ключевых функций. Проверка осуществляется путем внедрения в ответы веб-приложения специального JavaScript-кода, который сканирует окружение клиентского браузера на предмет возможных вредоносных программ. Если JavaScript обнаруживает такие программы на стороне клиента, такие клиенты попадают в отдельный список пользователей, которые будут блокироваться при обнаружении DoS-атаки. Тем самым снижается возможность проведения атаки типа «Распределенный отказ в обслуживании» с помощью бот-сетей.

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

Третий уровень защиты -- использование капчи. Некоторые WAF, детектируя DoS-атаки, могут внедрить в ответы веб-приложения капчу. Сессии клиентов, которые прошли испытание, признаются «человеческими» и продолжают работу в обычном режиме. Сессии, не прошедшие такое испытание, блокируются.

2.3.7 Интегрированность в ландшафт ИБ

Эффективность средства защиты информации в общем ландшафте информационной безопасности предприятия может многократно усилиться, если эти средства защиты будут связаны друг с другом. Поэтому важно, чтобы такие продукты как Web Application Firewall имели широкие интеграционные возможности с другими системами информационной безопасности. На сегодняшний день WAF могут быть интегрированы со следующими классами систем и сервисов:

· «сканеры уязвимостей» («Vulnerabilities scanners»);

· «система контроля инцидентов» («SIEM»);

· «репутационные сервисы» («Reputation service»);

· «сервисы противодействия мошенничеству» («Fraud Prevention service»);

Наиболее полезной является интеграция со сканерами уязвимостей --таким образом реализуется функция «Виртуального обновления» («Virtual Patching»), позволяющая автоматизировать контроль над безопасностью веб-приложения. Сканер будет находить уязвимости, формировать отчет, а WAF на его основе сформирует соответствующие правила безопасности.

Ключевым аспектом информационной безопасности многих крупных компаний служат системы контроля инцидентов. В контексте интеграции с WAF это дает возможность коррелировать события безопасности веб-приложений с событиями других систем.

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

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

ГЛАВА 3. РАЗВИТИЕ ЭКРАНОВ ВЕБ-ПРИЛОЖЕНИЙ В БУДУЩЕМ

3.1 Объединение процессов безопасной разработки и технологий экранирования

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

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

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

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