Web application firewall архитектура

Эволюция Web Application Firewall: от сетевых экранов до облачных систем защиты с машинным обучением

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

Что такое WAF

Более 75% атак хакеров направлены на уязвимости веб-приложений и сайтов: такие атаки, как правило, незаметны для ИБ-инфраструктуры и ИБ-служб. Уязвимости веб-приложений несут в себе, в свою очередь, риски компрометации и фрода учетных записей и персональных данных пользователей, паролей, номеров кредитных карт. Кроме того, уязвимости в веб-сайте служат точкой входа злоумышленников в корпоративную сеть.

Web Application Firewall (WAF) представляет собой защитный экран, который блокирует атаки на веб-приложения: SQL-инъекции, межсайтовый скриптинг, удаленное выполнение кода, брутфорс и обход авторизации (auth bypass). В том числе атаки, использующие zero-day уязвимости. Файрволы приложений обеспечивают защиту, выполняя мониторинг содержимого веб-страниц, включая HTML, DHTML и CSS, и фильтруя потенциально вредоносные запросы по HTTP/HTTPS.

Какими были первые решения?

Первые попытки создать Web Application Firewall предпринимались еще в начале 90-х годов. Известно как минимум о трех инженерах, работавших в этой области. Первый — профессор компьютерных наук Джин Спаффорд из Университета Пердью. Он описал архитектуру файрвола приложений с прокси и в 1991 году опубликовал её в книге «Безопасность UNIX на практике».

Вторым и третьим — были ИБ-специалисты Уильям Чесвик и Маркус Ранум из Bell Labs. Они разработали один из первых прототипов файрволов приложений. Его распространением занималась компания DEC — продукт выпустили под названием SEAL (Secure External Access Link).

Но SEAL не являлся полноценным WAF-решением. Он представлял собой классический сетевой файрвол с расширенной функциональностью — возможностью блокировать атаки на FTP и RSH. По этой причине первым WAF-решением сегодня считается продукт компании Perfecto Technologies (позже Sanctum). В 1999 году она представила систему AppShield. В то время Perfecto Technologies занимались разработкой ИБ-решений для e-commerce, и целевой аудиторией их нового продукта стали онлайн-магазины. AppShield умел анализировать HTTP-запросы и блокировал атаки на основе динамических ИБ-политик.

Примерно в одно время с AppShield (в 2002 году) появился первый WAF с открытым исходным кодом. Им стал ModSecurity. Он создавался с целью популяризации WAF-технологий и поддерживается IT-сообществом до сих пор (вот его репозиторий на GitHub). ModSecurity блокирует атаки на приложения, основываясь на стандартном наборе регулярных выражений (сигнатур) — инструментов для проверки запросов по шаблону — OWASP Core Rule Set.

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

Три поколения — уже история

Принято выделять три поколения WAF-систем, эволюционировавших по мере развития технологий.

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

Примером обнаружения на основе регулярных выражений является уже упомянутый проект Core Rule Set с открытым исходным кодом. Еще пример — Naxsi, который также является опенсорсным. Системы с регулярными выражениями имеют ряд недостатков, в частности, при обнаружении новой уязвимости администратору приходится создавать дополнительные правила вручную. В случае с масштабной IT-инфраструктурой правил может быть несколько тысяч. Управлять таким количеством регулярных выражений довольно сложно, не говоря о том, что их проверка может снижать производительность сети.

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

Второе поколение. Чтобы обойти проблемы, связанные с производительностью и точностью WAF, были разработаны файрволы приложений второго поколения. В них появились парсеры, которые отвечают за выявление строго определенных типов атак (на HTML, JS и т. д.). Эти парсеры работают со специальными токенами, описывающими запросы (например, variable, string, unknown, number). Потенциально вредоносные последовательности токенов выносятся в отдельный список, с которым регулярно сверяется WAF-система. Впервые этот подход показали на конференции Black Hat 2012 в виде C/C++ библиотеки libinjection, которая позволяет выявлять SQL-инъекции.

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

Третье поколение. Эволюция в логике обнаружения третьего поколения заключается в применении методов машинного обучения, позволяющих максимально приблизить грамматику обнаружения к реальной грамматике SQL/HTML/JS защищаемых систем. Данная логика обнаружения в состоянии адаптировать машину Тьюринга для охвата рекурсивно перечисляемых грамматик. Причем ранее задача создания адаптируемой машины Тьюринга была неразрешимой, пока не были опубликованы первые исследования нейронных машин Тьюринга.

Машинное обучение предоставляет уникальную возможность адаптировать любую грамматику для охвата любого типа атак без создания списков сигнатур вручную, как это требовалось при обнаружении первого поколения, и без разработки новых токенизаторов/парсеров для новых типов атак, таких как внедрения Memcached, Redis, Cassandra, SSRF, как того требовала методология второго поколения.

Объединяя все три поколения логики обнаружения, мы можем нарисовать новую диаграмму, на которой красным контуром представлено третье поколение обнаружения (рис. 3). К этому поколению относится одно из решений, которое мы реализуем в облаке совместно с «Онсек», разработчиком платформы адаптивной защиты веб-приложений и API Валарм.

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

• Анализ поведения ответа приложения (пассивное)
• Сканирование/фаззер (активное)
• Файлы отчетов/процедуры-перехватчики/ловушки (пост фактум)
• Ручное (определяется супервизором)

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

Далее рассмотрим технологические возможности различных вариантов реализации WAF.

Железо, ПО или облако — что выбрать?

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

Другой вариант развертывания WAF — программная реализация. Решение устанавливается в качестве дополнения для какого-либо ПО (например, ModSecurity настраивается поверх Apache) и работает на одном сервере с ним. Как правило, подобные решения можно развернуть как на физическом сервере, так и в облаке. Их минус — это ограниченные возможности масштабируемости и поддержки со стороны вендора.

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

Почему сейчас все чаще смотрят в сторону облачного WAF, расскажем далее.

Что может WAF в облаке

С точки зрения технологических возможностей:

• За обновления отвечает провайдер. WAF предоставляется по подписке, поэтому за актуальностью обновлений и лицензий следит поставщик сервиса. Обновления касаются не только программного, но и аппаратного обеспечения. Провайдер апгрейдит серверный парк и занимается его обслуживанием. Он также отвечает за балансировку нагрузки и резервирование. Если происходит отказ в работе сервера WAF, трафик немедленно перенаправляется на другую машину. Рациональное распределение трафика позволяет избежать ситуаций, когда файрвол входит в режим fail open — не справляется с нагрузкой и перестает фильтровать запросы.
• Виртуальный патчинг. Виртуальные патчи ограничивают доступ к скомпрометированным частям приложения до закрытия уязвимости разработчиком. В результате заказчик облачного провайдера получает возможность спокойно дождаться пока поставщик того или иного программного обеспечения опубликует официальные «заплатки». Сделать это максимально оперативно — приоритет для поставщика ПО. К примеру, в платформе «Валарм» за виртуальный патчинг отвечает отдельный программный модуль. Администратор может добавлять кастомные регулярные выражения для блокировки вредоносных запросов. Система дает возможность отмечать некоторые запросы флагом «Конфиденциальные данные». Тогда их параметры маскируются, а сами они ни при каких условиях не передаются за пределы рабочей зоны файрвола.
• Встроенный сканер периметра и уязвимостей. Это позволяет самостоятельно определять сетевые границы ИТ-инфраструктуры, используя данные DNS-запросов и протокола WHOIS. После WAF автоматически анализирует работающие внутри периметра службы и сервисы (выполняет сканирование портов). Файрвол способен обнаруживать все распространённые типы уязвимостей — SQLi, XSS, XXE и др. — и выявлять ошибки в конфигурации ПО, например, несанкционированный доступ к репозиториям Git и BitBucket и анонимные обращения к Elasticsearch, Redis, MongoDB.
• Атаки мониторятся ресурсами облака. Как правило, облачные провайдеры обладают большими объемами вычислительных мощностей. Это позволяет производить анализ угроз с высокой точностью и скоростью. В облаке развертывается кластер из фильтрующих узлов, через которые проходит весь трафик. Эти узлы блокируют атаки на веб-приложения и отправляют статистику в Центр аналитики. Он использует алгоритмы машинного обучения, чтобы обновить правила блокировки для всех защищаемых приложений. Реализация подобной схемы указана на рис. 4. Подобные адаптированные правила безопасности минимизируют число ложных срабатываний файрвола.

Теперь немного об особенностях облачных WAF с точки зрения организационных моментов и управления:

• Переход к OpEx. В случае с облачными WAF стоимость внедрения будет равняться нулю, так как все железо и лицензии уже оплатил провайдер, оплата сервиса производится по подписке.
• Разные тарифные планы. Пользователь облачного сервиса может оперативно подключить или отключить дополнительные опции. Управление функциями реализуется из единой панели управления, которая также защищена. Доступ к ней осуществляется по HTTPS, плюс имеется механизм двухфакторной аутентификации на базе протокола TOTP (Time-based One-Time Password Algorithm).
• Подключение по DNS. Можно самостоятельно изменить DNS и настроить маршрутизацию в сети. Для решения этих задач не нужно набирать и обучать отдельных специалистов. Как правило, с настройкой может помочь техническая поддержка провайдера.

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

Текст подготовил Александр Карпузиков, менеджер по развитию продуктов ИБ облачного провайдера #CloudMTS.

Источник

Web Application Firewall: проблемы выбора и перспективы развития

Являются ли системы класса WAF обязательным стандартом для обеспечения безопасности веб-ресурсов или же остаются важной, но дополнительной опцией? Как выбрать и внедрить Web Application Firewall и что ждёт рынок в будущем? Об этом рассуждают представители вендоров, сервис-провайдеров и крупных заказчиков в рамках онлайн-конференции AM Live.

Введение

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

В дискуссии приняли участие:

• Михаил Кондрашин, технический директор компании Trend Micro в СНГ, Грузии и Монголии.
• Виктор Рыжков, менеджер по продуктовому маркетингу направления Application Security компании Positive Technologies.
• Вячеслав Гордеев, системный инженер компании Fortinet.
• Вячеслав Алешин, руководитель направления разработки облачных продуктов кибербезопасности компании BI.ZONE.
• Александр Баринов, руководитель направления сервисов Solar MSS компании «Ростелеком-Солар».
• Иван Новиков, CEO компании «Валарм».

Ведущий и модератор дискуссии — Андрей Дугин, начальник отдела обеспечения информационной безопасности компании МТС.

Для чего нужен Web Application Firewall

В первую очередь мы спросили у наших экспертов, кому и зачем нужен WAF. Модератор дискуссии предложил поговорить о том, чем этот класс средств защиты отличается от обычных файрволов, в том числе — нового поколения (Next Generation Firewall, NGFW). Не проще ли вместо использования WAF банально поддерживать безопасность сайта — устанавливать актуальные патчи, устраивать пентесты и т. д.?

Виктор Рыжков:

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

Вячеслав Алешин:

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

Иван Новиков:

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

Вячеслав Гордеев:

— Существуют два принципиальных отличия WAF от других межсетевых экранов: функциональное и архитектурное. К функциональным особенностям можно отнести возможность разбора специализированных форматов внутри HTTP (например, JSON), чего не делают NGFW и другие системы. Архитектурные особенности — это способ внедрения и установки в сеть. Web Application Firewall работает в первую очередь как реверс-прокси, публикуя только те приложения, которые находятся внутри компании.

Михаил Кондрашин:

— Если говорить образно, WAF — это продукт, который позволяет эксплуатировать уязвимый веб-сайт так, чтобы его не взломали. Что касается размещения, то NGFW устанавливается на шлюзе, а WAF — там, где находится веб-сайт.

Александр Баринов:

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

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

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

Ещё одна тема, которую затронули гости студии, — варианты размещения Web Application Firewall. Имеет ли смысл использовать локальный (on-premise) вариант или лучше подписаться на облачный сервис? Как отметили эксперты AM Live, в данном случае это — вопрос доверия к облачному провайдеру, поставщику услуги. Сейчас рынок безопасности веб-приложений активно мигрирует в облако, а значит, всё больше и больше заказчиков считают риски таких сервисов приемлемыми для себя.

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

Рисунок 1. Используете ли вы WAF в своей организации?

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

Технические особенности WAF

Базовую структуру «типового» решения класса Web Application Firewall обрисовал Вячеслав Гордеев. Как сказал эксперт, у каждого WAF есть набор модулей защиты, по которым проходит весь трафик. Обычно всё начинается с базовых уровней — модулей защиты от DDoS-атак и блоков сигнатурного анализа. Уровнем выше стоит возможность разработки своих собственных политик безопасности, а также подсистема математического обучения. На одном из последних этапов обычно появляется блок интеграции со сторонними системами.

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

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

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

Отвечая на вопрос «Что, на ваш взгляд, наиболее важно при выборе WAF?», большинство зрителей прямого эфира AM Live отметили в качестве ключевого фактора технологии обнаружения атак. За этот вариант проголосовали 63 % респондентов. Интеграцию с другими средствами защиты считают наиболее важной функцией WAF 12 % опрошенных, а стоимость — 9 %. За варианты «Модель поставки» и «Сертификация» высказались 2 % и 3 % соответственно. Другие факторы считают наиболее важными 11 % участников опроса.

Рисунок 2. Что, на ваш взгляд, наиболее важно при выборе WAF?

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

Как внедрять Web Application Firewall

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

По мнению модератора дискуссии, основные этапы внедрения файрвола — следующие:

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

Михаил Кондрашин отметил, что внедрение сервиса WAF в одно приложение занимает полторы минуты. Эксперт пояснил, что речь идёт только о мониторинге: настройка правил блокировок займёт дополнительное время. При этом другие спикеры онлайн-конференции указали, что подразумевается «чистое» время, которое не включает многие аспекты внедрения — согласования, обучение персонала и другие этапы. Иван Новиков подчеркнул, что время внедрения зависит от способа развёртывания, а также от конкретного приложения и от трафика, который необходимо контролировать.

Гости студии рассказали также о том, как правильно построенный процесс внедрения поможет уменьшить процент ложных срабатываний WAF. Виктор Рыжков отметил, что решить эту задачу поможет тестирование на подготовительном этапе (pre-production), а также после ввода системы в эксплуатацию. Эксперт отметил важность возможности «обучения» файрвола, когда на этапе теста часть вердиктов корректируется специалистом. Александр Баринов порекомендовал изучить статистику работы WAF за первый месяц работы, чтобы понять, не блокирует ли система легитимный трафик. Вячеслав Алешин подчеркнул, что не бывает WAF полностью исключающих ложные срабатывания.

Спикеры перечислили также основные направления интеграции Web Application Firewall с другими средствами безопасности. По мнению экспертов, это:

• SIEM-системы (WAF выступает поставщиком данных).
• Различные виды песочниц.
• Антивирусные ядра.
• DLP-системы.
• Сканеры уязвимостей.
• Средства безопасности внутри платформы Kubernetes.
• NGFW.

Зрители AM Live высказали свои мнения о том, что больше всего тормозит внедрение WAF. Почти треть опрошенных (32 %) отметила, что главным препятствием для успешного внедрения являются ложные срабатывания. Ещё 21 % указал на сложность администрирования, а 18 % — на высокую цену. Снижение производительности веб-сайта отметили 5 % респондентов, а 4 % пожаловались на недостаточную масштабируемость. Не видят препятствий для внедрения и используют WAF 20 % опрошенных.

Рисунок 3. Что, на ваш взгляд, тормозит внедрение WAF больше всего?

Тренды и прогнозы развития рынка WAF

В заключение беседы эксперты в студии поделились своим видением перспектив развития рынка Web Application Firewall. Спикеры отметили рост популярности различных открытых WebAPI и предсказали смещение фокуса защиты в их сторону; у Gartner даже есть определения для таких продуктов — Web Application & API Protection (WAAP). Из-за пандемии зависимость от онлайна выросла драматическим образом, поэтому важность WAF возрастёт, его наличие может стать обязательным условием безопасности веб-ресурса. Участники онлайн-конференции отметили, что WAF станет «ближе» к приложениям и будет встроен в процесс их разработки.

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

С точки зрения развёртывания продолжатся миграция WAF в облака и интеграция систем этого класса с другими облачными сервисами. Эксперты отметили тенденцию к открытости систем безопасности, которая затронет и WAF; это — ответ на запросы рынка, выгодный как покупателям, так и вендорам.

Финальный опрос зрителей онлайн-конференции был посвящён мнению нашей аудитории относительно WAF по итогам эфира. Почти треть опрошенных (29 %) после просмотра очередного выпуска AM Live убедились в правильности своего выбора WAF. Ещё 16 % респондентов заинтересовались и готовы тестировать эти средства безопасности. Считают WAF избыточным для себя 13 % участников опроса, а 3 % зрителей в результате решили сменить поставщика WAF.

Не поняли, о чём шла речь во время прямого эфира, 32 % наблюдавших за ним, а 7 % опрошенных считают, что участники не смогли доказать необходимость использования WAF.

Рисунок 4. Каково ваше мнение относительно WAF по итогам эфира?

Выводы

Дискуссия показала, что Web Application Firewall является ключевым элементом безопасности современных веб-ресурсов. Рост числа критически важных задач, выполняемых посредством веб-интерфейсов и открытых API, является драйвером рынка систем безопасности этого класса. Сегодня заказчик может выбирать: самостоятельно развёртывать WAF на собственной инфраструктуре, встраивать в неё готовые программно-аппаратные комплексы или же использовать облачные сервисы.

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

Источник