Привет! Меня зовут Лев Палей, и я собаку съел на всяких сравнениях, технико-экономических обоснованиях и всей этой истории с выбором каких-либо решений. Теперь я работаю по другую сторону сделки. Поэтому, после некоторого времени, проведенного в компании-производителе, решил рассказать о тяготах выбора WAF, как историю из тех времен, когда сам был заказчиком и с учетом всякого нового, что начал понимать теперь. Раньше я не мог много об этом рассказывать (не было времени), а сейчас готов поделиться своим двусторонним опытом. Если перед вами стоит задача ........ велком под кат за подробностями.
Часть 3. Как внедрить WAF революционно и эволюционно?
Начать бы надо с основных моделей работы WAF, по которым сейчас развиваются решения этого класса:
Позитивная модель, когда предполагается что весь трафик небезопасный, если не доказано иное. Доверенным является лишь тот трафик, который определен администратором как легальный. Весь остальной сетевой поток считается небезопасным и блокируется. Для реализации подобного подхода требуется хорошее знание механизмов публикуемых приложений. Очевидным плюсом этой модели является четкое определение легитимного трафика и веб-запросов, минусы – зависимость процесса публикации от WAF, трудозатраты на администрирование. Кроме того, при подобной модели сложно выстроить защиту от эксплойтов нулевого дня, а также модифицированных атак. Связано это с тем, что при позитивной модели, обучение системы проводится с отсечением любого трафика, который не проходит под описание профиля приложения – а это, в свою очередь приводит к снижению точность в определении атак.
Негативная модель безопасности, когда предполагается что весь анализируемый трафик опасен за исключением того, который определен как легитимный. Это значит, что каждый запрос проверяется досконально с задействованием большого количества парсеров, если заблокирован легитимный трафик, нужно внести исключение. Именно так и производится подстройка СЗИ под трафик приложения. Подобная модель безопасности легче в сопровождении, более точна в определении атак, но при реализации в формате On-Premise потребует больше мощностей, чем при использовании решения на основе позитивной модели.
Инструменты и подходы к оценке эффективности WAF мы рассматривали в этой статье.
Функциональная база WAF
С учетом тех тенденций, по развитию инфраструктуры, о которых говорили в статье у текущего WAF должны быть реализованы такие группы функций:
Противодействие атакам из OWASP TOP-10. Рейтинг OWASP TOP-10 формирует сообщество OWASP (Open Web Application Security Project) исходя из текущих тенденций в выборе векторов атак со стороны хакеров и наиболее критичные уязвимости, встречающиеся в веб-приложениях.
Анализировать приложения в режиме DAST. Это позволяет выявить уязвимости в опубликованных на WAF приложениях до того, как их найдет кто-то внешний.
Проверять периметр компании на предмет уязвимостей. Обеспечивается путем сканирования опубликованных IP-адресов и открытых сетевых портов, сопровождаемых поиском типовых уязвимостей или обнаружением уязвимостей в трафике приложений.
Уметь закрывать выявленные уязвимости (виртуальный патчинг). Используется в случаях, когда нет возможности установки обновлений ПО (остановка сервиса критична, либо патч отсутствует).
Обеспечивать защиту микросервисов и API. Выполняется путем составления карты API, отслеживания изменений в структуре API и фильтрации запросов к API. Защита микросервисов осуществляется за счет контроля запросов между микросервисами и выявления нелегитимных запросов. Тут важно упомянуть, что есть и OWASP API TOP 10.
Возможность настройки детектирования нужных вам событий. Такая функция помогает выявлять специфичные для ваших приложений отклонения и правильно встраивать их в процесс мониторинга.
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, то необходимо также провести аналитическую работу, изучить рынок и получить референсы от клиентов, т.к. сторонней организации будет предоставлена огромная ответственность по защите ваших ресурсов. Кроме того, необходимо определить процедуру возмещения ущерба провайдером в случае, если ущерб был возник по его вине.
Пятый шаг – проведение пилотного проекта с выбранным СЗИ. Это поможет попробовать в деле функциональных возможностей, которым был присвоен статус «критичный», оценить техническую поддержку вендора и интегратора, возможно – определить требуемый тип лицензий, либо потребляемых ресурсов.
Рассмотрим теперь эту методику на примере, для наглядности:
Для компании N, деятельность которой связана с торговлей через интернет-магазин. Это значит, что приложения важны и можно посчитать стоимость ущерба;
Произведя расчет, пришли к выводу, что потенциальный ущерб от атаки может составить 10 млн рублей в год и согласовали выделение бюджета в размере 8 млн. руб в год. В который, кроме стоимости WAF, вошли также стоимость его интеграции и ФОТ для FTE, который будет его сопровождать.
После этого, сотрудники ИБ определяют необходимые критерии для выбора WAF: противодействие атакам из OWASP TOP-10, OWASP API TOP-10, возможность отправки логов по syslog (в компании планируется внедрение SOC) и возможность подтверждения входа с помощью многофакторной аутентификации, виртуальный патчинг, возможность сканирования периметра на предмет открытых портов и уязвимостей и оно должно быть отечественным.
По итогу под эти требования подошли только три WAF представленные на российском рынке: W, X, R. В соответствии с бюджетными ограничениями, была возможность выбора либо вендора W, либо любого из трех вендоров, но по формуле MSSP с ежегодной платой 4 млн. рублей.
Взвесив все риски MSSP и перспективы проблем при сопровождении WAF своими силами, руководством компании был выбран путь инвестиций в свою инфраструктуру и покупку WAF вендора W.
Заключение
Вот такая мини-инструкция по составлению технико-экономического обоснования получилась. Надеюсь будет полезно. Это абсолютно не та область, которую можно назвать увлекательной или очень точной, но для того чтобы сделать правильный выбор всегда нужно от чего-то отстроиться, следовать простой и понятной всем сторонам логике. В больших компаниях зачастую существует своя методология, но основной принцип – повешать, все что важное, выбросить, то что не важно, остается неизменным.
Выводы
Основная мысль, которую хотелось донести: оценка решения – это не оценка функций, как самостоятельных объектов. Каждый заказчик покупает себе решение задачи, а если не считать, все, что связано с ИБ, темным лесом и мистической энергией, то самое честное – относиться к любому средству защиты, как к средству автоматизации. Если у вас есть осознанная потребность в сокращении нагрузки, повышению качества детектирования, быстрому внедрению в существующей инфраструктуре, то именно это и нужно выставлять в качестве фильтров, при поиске своего решения задачи. Чем-то напоминает поиск обуви или электроники в маркетплейсах, не находите?
Удачных вам исследований и качественных решений! А если найдете, что улучшить, дописать или исправить – пишите. Сделаю еще один подход и постараюсь учесть.
Все об API Security, Web Security. Еще немного про уязвимости и технические изыскания команды Вебмониторэкс. Никакой рекламы. Только полезные материалы. https://t.me/WMXWAS