WAF‑защита: FAQ для бизнеса

После прочтения статьи вы узнаете, в каких ситуациях вам пригодится решение класса Web Application Firewall, какие варианты сервиса WAF есть на рынке, какие атаки он блокирует, а для каких понадобятся дополнительные ИБ‑решения. Кроме того, вы узнаете, как внедрить WAF у себя и как понять, что вы все сделали правильно и система реально работает.

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

Поэтому сегодня мы расскажем про WAF не только и не столько с технической точки зрения, сколько с точки зрения бизнеса.

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

В какой ситуации вы уже могли оказаться

Кейс №1. Другой онлайн‑магазин недавно атаковали. Боюсь, что мой следующий. «Веб‑сайт моего онлайн‑магазина в зоне риска. Нужно срочно развернуть WAF. Растет число ИБ‑инцидентов, и если вдруг сайт зависнет у пользователей, то, боюсь, что они уйдут к конкурентам, и тогда ситуация станет безвыходной».

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

Кейс №2. Нужны гарантии сохранности клиентских данных. «Я работаю в e‑commerce и в свете все новых ИБ‑угроз сильно переживаю за сохранность персональных и платежных данных моих клиентов. Не хочется попасть на штрафы или в новостную ленту в качестве жертвы хакеров, не говоря уже о возможных репутационных потерях, оттоке клиентов и общем падении конверсии из‑за того, что сайт недостаточно защищен».

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

Кейс №3. Нужно подготовиться к проверке со стороны регуляторов. «Растет давление со стороны регуляторов, и я понимаю, что ко мне могут прийти с проверкой. Поэтому мне крайне важно обеспечить соблюдение требований стандарта PCI DSS и законов о защите данных. Нужны технические меры, которые можно будет продемонстрировать аудиторам».

Внедренная WAF поможет соблюсти требования регуляторов и предоставить аудиторам достаточные доказательства того, что деятельность компании соответствует всем нормативным актам (PCI DSS 6.6 Option 2, ЦБ ГОСТ Р 57580.1‑2017, ФСТЭК России).

Кейс №4. Нужна WAF‑защита, но я не знаю, с чего начать. «У меня онлайн‑магазин. В основном клиенты покупают через сайт и мобильное приложение. Постоянно вижу новости, как кого‑то взломали, и понимаю, что мне нужна более серьезная защита, в том числе межсетевой экран уровня приложений. Однако штат компании небольшой, и раздувать его не хочется. Своих экспертов по ИБ у нас нет, поэтому думаю про аутсорсинг. Опять‑таки не такой уж большой у меня бизнес, чтобы разворачивать защиту веб‑приложений WAF в локальной инфраструктуре. Кроме того, ее потом еще придется как‑то обновлять и поддерживать. Поэтому защита нужна, но пока не знаю, с чего начать».

Малому и среднему бизнесу часто нет смысла развертывать on‑premise решение класса Web Application Firewall — это требует значительных капитальных затрат на оборудование и лицензии, а также постоянных ресурсов на поддержку. Альтернативой служит WAF как облачный сервис: он не требует собственной инфраструктуры, подключается быстрее и, как правило, предполагает техническую поддержку в рамках тарифа.

Кейс №5. Уже внедряли WAF. Получилось не очень, но защищать веб‑приложения все равно надо. «Знаю, как работает WAF. Точнее, как в теории он должен работать. Уже был опыт развертывания в локальной инфраструктуре. Не понравилось. Долго выбирали on premise решение, еще дольше внедряли. Возникли проблемы с настройкой, все оказалось очень нетривиально. По итогам много денег ушло на “железо” и лицензии, и, несмотря на внушительные капитальные затраты, боль бизнеса так и осталась болью»

Последний WAF‑пример немного похож на предыдущий. В обоих случаях есть запрос на защиту, но явно не хватает ресурсов либо внутри компании (кейс №4), либо у подрядчика (кейс №5). Решением такой ситуации становится переход на облачный WAF, где операционная ответственность за настройку и мониторинг лежит на интеграторе.

Какой вариант сервиса WAF подойдет вам

Самостоятельное управление WAF

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

В этом сценарии настройка правил и обработка событий ИБ — это зона ответственности не подрядчика, а ваша.

WAF как управляемый сервис

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

Как работает WAF

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

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

WAF умеет эффективно отражать все известные атаки на уровне приложений, в частности:

• атаки на механизмы аутентификации и авторизации при вводе пользовательских данных;
• вредоносные запросы к БД приложений (SQL‑инъекции);
• межсайтовый скриптинг (Cross‑Site Scripting или XSS);
• подделку межсайтовых запросов (Cross‑Site Request Forgery, CSRF);
• DoS‑атаки, направленные на использование логики веб‑приложения, например много частых запросов на “тяжелую” страницу, генерирующую отчет и подтягивающую большой объем данных.

• массовые DDoS‑атаки (в случае массовой атаки понадобится отдельный сервис Anti‑DDoS);
• отдельные атаки ботов, эксплуатирующих бизнес‑логику приложения;
• неизвестные атаки или атаки нулевого дня (под которые еще нет правил и сигнатур) — хотя есть шанс, что они попадут под общие критерии вредоносных запросов (например, если есть RCE нулевого дня и злоумышленник сумел заставить веб‑приложение выполнить команду на сервере, и WAF не обнаружит саму эксплуатацию уязвимости, остается шанс что WAF увидит в запросе эту команду и заблокирует его);
• внутренние угрозы (для этого нужна система контроля доступа или система управления инцидентами SIEM) или угрозы в случае компрометации учетных данных;
• атаки вредоносного ПО в загружаемых на веб‑приложение файлах.

Чем можно дополнить WAF

Система закроет бреши на седьмом уровне модели OSI, но для комплексной защиты понадобится еще ряд решений, с которыми WAF будет интегрироваться:

• Anti‑DDoS для предотвращения массовых DDoS‑атак;
• межсетевые экраны с функционалом анализа трафика и обнаружения атак на уровне сети (NGFW);
• система управления событиями и информацией безопасности (SIEM) для дополнительного анализа событий безопасности и коррелирования инцидентов;
• система анализа сетевого трафика (NTA) для глубокого анализа трафика и выявления вредоносной активности;
• система управления уязвимостями (VM) для управления уязвимостями и создания виртуальных патчей на WAF.

Чек‑лист внедрения WAF

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

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

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

Настройте правила. Задайте правила и политики WAF для блокировки SQL‑инъекций, XSS и т.д. (можно ориентироваться на стандартные шаблоны, предоставляемые производителем) и затем при необходимости скорректируйте их, чтобы уменьшить количество ложных срабатываний и предотвратить блокировку легитимного трафика, например, данных в куки, которые похожи на межсайтовый скриптинг. Здесь нет задачи запретить всё. Наоборот, важно настроить систему точечно под ваши нужды. Наверняка у вас есть приложения, для корректной работы которых придётся добавить исключение в правила и политики. Вместо отключения сигнатуры целиком, что может быть просто небезопасно, гораздо эффективнее настроить «белые списки», то есть перечень по умолчанию разрешенных запросов, легитимность которых не нужно проверять.

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

Внедрение WAF — трудоёмкий процесс, который требует экспертизы в области сетевой безопасности и веб‑приложений. Если в штате нет специалистов с соответствующими компетенциями, разумно привлечь подрядчика: это сократит сроки внедрения и снизит риск ошибок в настройке. При наличии внутренней команды можно справиться самостоятельно, опираясь на документацию вендора и описанный выше чек‑лист.

Как понять, что все получилось

Наконец, проект внедрения завершен, и начинается сама эксплуатация WAF. Как же понять, что межсетевой экран уровня приложений реализован как надо и все действительно работает, причем работает не на бумаге, а на деле? Чтобы это проверить, обратите внимание на следующее:

1. Защищаемое приложение должно работать корректно, то есть как минимум не хуже, чем раньше. Важно, чтобы задержка ответа существенно не увеличилась и не было непонятных, внезапно возникающих ошибок.
2. Автоматизированные средства мониторинга, в том числе сканеры, показывают, что межсетевой экран блокирует нелегитимный трафик.
3. Аналогичную картину наблюдают ваши штатные SOC‑аналитики или пентестеры, которые в рамках отдельного проекта проводят аудит безопасности системы и ее тестирование на проникновение.
4. WAF не блокирует легитимный трафик, то есть степень ложноположительных срабатываний приемлемая и не мешает вашей компании нормально функционировать.

Заключение

Лавина угроз информационной безопасности, в том числе для API и веб‑приложений, только нарастает, и, судя по всему, злоумышленники останавливаться не собираются. Методы атак совершенствуются быстрее, чем обновляются регламенты и настройки защиты, и поэтому найти дыру в точечной обороне становится все легче. Как следствие, разрозненных мер защиты и реактивного подхода уже недостаточно для нормальной, безопасной работы. Нужен комплексный подход, который вряд ли получится реализовать с помощью одного all‑in‑one решения, а значит, разные системы придется увязывать между собой как в локальной, так и в облачной инфраструктуре и настраивать общую логику с внутренними бизнес‑системами.

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

Централизованное управление политиками и доступ к детальной статистике по событиям при этом остаются доступны вне зависимости от выбранной модели развертывания.