Как оценить эффективность WAF и зачем вообще это все нужно? Часть 3

2f0eb450fc5766493e613b03268bd6cc.jpg

Привет! Меня зовут Лев Палей, и я собаку съел на всяких сравнениях, технико-экономических обоснованиях и всей этой истории с выбором каких-либо решений. Теперь я работаю по другую сторону сделки. Поэтому, после некоторого времени, проведенного в компании-производителе, решил рассказать о тяготах выбора WAF, как историю из тех времен, когда сам был заказчиком и с учетом всякого нового, что начал понимать теперь. Раньше я не мог много об этом рассказывать (не было времени), а сейчас готов поделиться своим двусторонним опытом. Если перед вами стоит задача … велком под кат за подробностями.  

Часть 3. Как внедрить WAF революционно и эволюционно?

Начать бы надо с основных моделей работы WAF, по которым сейчас развиваются решения этого класса:

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

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

Инструменты и подходы к оценке эффективности WAF мы рассматривали в этой статье.

Функциональная база WAF

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

1. Противодействие атакам из OWASP TOP-10. Рейтинг OWASP TOP-10 формирует сообщество OWASP (Open Web Application Security Project) исходя из текущих тенденций в выборе векторов атак со стороны хакеров и наиболее критичные уязвимости, встречающиеся в веб-приложениях.

2. Анализировать приложения в режиме DAST. Это позволяет выявить уязвимости в опубликованных на WAF приложениях до того, как их найдет кто-то внешний.

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

4. Уметь закрывать выявленные уязвимости (виртуальный патчинг). Используется в случаях, когда нет возможности установки обновлений ПО (остановка сервиса критична, либо патч отсутствует).

5. Обеспечивать защиту микросервисов и API. Выполняется путем составления карты API, отслеживания изменений в структуре API и фильтрации запросов к API. Защита микросервисов осуществляется за счет контроля запросов между микросервисами и выявления нелегитимных запросов. Тут важно упомянуть, что есть и OWASP API TOP 10.

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

WAF — это неотъемлемая часть цикла PDCA для опубликованных приложений в части управления уязвимостями, которая позволяет закрыть GAP между исправлением на бэке или фронте, встроиться в цикл безопасной разработки доставляя данные об уязвимостях в CI\CD.

Метрики оценки эффективности WAF

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

Вот они (в техническом плане):

  • доля false positive (FP) и false negative (FN) сработок по отношению к общему количеству сработок. Эта метрика позволяет оценить точность настройки WAF, а управление им — снизить трудозатраты специалистов, администрирующих его. Например, если общая доля FP и FN составляет около 50%, это значит, что СЗИ настроено некорректно, ложные срабатывания создают отдельный «шум», среди которого можно пропустить реальную атаку на веб-ресурсы. Необходимо стремиться к доле FP и FN на уровне 10% от общего количества срабатываний. Чем меньше FP и FN — тем меньше часов вы проведете в личном кабинете WAF.

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

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

  • доля отраженных атак при тестировании специализированными инструментами. Для тестирования WAF есть целый ряд инструментов, например, GoTestWAF, обладающий несколькими тысячами тестов, в том числе для следующих типов атак: SQLi, RCE, XSS, PTRAV, RFI, LFI, XXE, LDAPi, mail-injection, NoSQLi, SSI, SSTI, GraphQL, SSRF, OpenRedirect. Регулярное использование инструментов тестирования позволит выявить потенциальные проблемы безопасности и вектора атак, которые не закрываются внедренным в организации WAF. Дальнейшим действием может быть обращение к вендора с требованием по совершенствованию функционала, либо смена существующего решения. Вопрос точности для решений WAF очень важен, потому как это основная польза, которая может быть доставлена решением. У этого параметра должен быть максимальный коэффициент.

В организационном плане:

  • доля опубликованных сервисов, находящихся под защитой WAF. Естественно, что приобретение WAF предназначено в первую очередь для защиты важных с точки зрения бизнеса активов. Например, в компании 100 ресурсов, опубликованных наружу, 10 из которых являются высокоприоритетными, 40 — среднего приоритета и 50 низкоприоритетных. После интеграции WAF, за защиту заведены только высокоприоритетные активы, при том, что свободных мощностей (и вычислительных и лицензионных) хватает для заведения оставшихся ресурсов. В этом случае, было бы разумно защитить и их. Если мы посчитали границу бюджета, этот параметр можно считать корректировочным.

  • утилизация лицензий WAF. Тут скорее, про методу учета лицензий производителем. Многие лицензируются по устоявшейся модели RPS — это пиковая нагрузка на приложение, кол-во запросов в секунду. Но есть и вариант расчета по RPM, который в этом плане более щадящий. Суть в том, что учитывается не максимальный пик кол-ва запросов. По практике такой пик достигается 1–2 раза в месяц в среднем. А общая нагрузка за месяц. Платишь за то что действительно используешь. Эта величина — по сути стоимость лицензий и возможность рассчитать корректный объем их потребления.

Для ТОП-менеджмента компании будут нужны другие показатели, более близкие к эффективности:

  • стоимость простоя веб-приложений и бизнес-процессов, по причинам связанным с WAF (пропустили атаку, неработоспособность WAF и тд). Тут мы уже считали в статье

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

Эти метрики можно сравнивать с тем, что было до внедрения WAF и вызванными в ранние периоды простоями (конечно если такие были).

Ну, а тут уже и базовая методология вырисовывается, давайте ее разберем по шагам:

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

Второй шаг — исходя из данных, полученных по итогам первого шага, необходимо определить границы бюджетов на покупку и интеграцию WAF. Необходимо помнить о том, что стоимость средств для защиты ресурсов не должна превышать ущерб от потенциального простоя этих ресурсов. Другими словами, если риск атаки на веб-ресурсы составляет 2 млн в год, нет смысла ставить СЗИ, стоимость которого (вместе с расходами на ФОТ и тд) составит 3 млн в год. В этом случае, целесообразнее принять риски потенциальной атаки. Если только репутационные риски не вносят свою корректировку в этот параметр. 

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

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

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

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

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

Рассмотрим теперь эту методику на примере, для наглядности:

  1. Для компании N, деятельность которой связана с торговлей через интернет-магазин. Это значит, что приложения важны и можно посчитать стоимость ущерба;

  2. Произведя расчет, пришли к выводу, что потенциальный ущерб от атаки может составить 10 млн рублей в год и согласовали выделение бюджета в размере 8 млн. руб в год. В который, кроме стоимости WAF, вошли также стоимость его интеграции и ФОТ для FTE, который будет его сопровождать.

  3. После этого, сотрудники ИБ определяют необходимые критерии для выбора WAF: противодействие атакам из OWASP TOP-10,  OWASP API TOP-10, возможность отправки логов по syslog (в компании планируется внедрение SOC) и возможность подтверждения входа с помощью многофакторной аутентификации, виртуальный патчинг, возможность сканирования периметра на предмет открытых портов и уязвимостей и оно должно быть отечественным.

  4. По итогу под эти требования подошли только три WAF представленные на российском рынке: W, X, R.  В соответствии с бюджетными ограничениями, была возможность выбора либо вендора W, либо любого из трех вендоров, но по формуле MSSP с ежегодной платой 4 млн. рублей.

  5. Взвесив все риски MSSP и перспективы проблем при сопровождении WAF своими силами, руководством компании был выбран путь инвестиций в свою инфраструктуру и покупку WAF вендора W.

Заключение

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

Выводы:

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

Удачных вам исследований и качественных решений! А если найдете, что улучшить, дописать или исправить — пишите. Сделаю еще один подход и постараюсь учесть.

Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы. https://t.me/WMXWAS

© Habrahabr.ru