Локальная защита от ботов — реальность или утопия? Кое-что что работает эффективней привычной коробки

Локальная защита от ботов — реальность или утопия? Кое-что что работает эффективней привычной коробки

Много раз слышал от CISO и CIO крупных компаний, в особенности финансовых организаций, что для защиты от DDoS-атак на уровне приложений, а также от ботовых атак на бизнес-логику сайтов нужно исключительно локальное решение (on-premise). Только оно обеспечит полный контроль над трафиком и позволит соблюсти регуляторные требования. И до 2022 года иностранные коробочные решения активно использовались в большинстве кредитных организаций с этой целью.

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

Главным аргументом организаций в пользу on-premise является выполнение требований PCI DSS (международный стандарт безопасной обработки платёжных данных). И сложности в связи с этим документом заключаются в передаче SSL-сертификатов. Стандарт PCI-DSS (Payment Card Industry Data Security Standard) не запрещает напрямую передачу SSL-сертификатов [1] сторонним компаниям. Однако он устанавливает строгие требования к защите данных, включая конфиденциальность и целостность информации, связанной с обработкой платежных карт.

Если SSL-сертификат используется для безопасной обработки данных, соответствующей требованиям PCI-DSS (например, данных карт), то передача сертификата третьей стороне должна осуществляться с учетом следующих принципов:

1. Конфиденциальность. SSL-сертификаты содержат закрытые ключи, которые должны храниться в секрете. Передача закрытого ключа третьей стороне может создать риски утечки данных, если не обеспечены должные меры безопасности.
2. Минимизация данных. PCI-DSS требует минимизировать объем передаваемых данных, особенно если они связаны с платежными картами. Если передача SSL-сертификата не связана с обработкой данных карт, это не нарушает стандарт, но все равно требует осторожности.
3. Контроль доступа. Если третья сторона получает доступ к SSL-сертификату, необходимо убедиться, что у нее есть соответствующие меры безопасности для защиты данных.
4. Соглашения с третьими сторонами. Если вы передаете SSL-сертификат или связанные данные третьей стороне, необходимо заключить соглашение, которое обязывает их соблюдать требования PCI-DSS и обеспечивать защиту данных.
5. Аудит и мониторинг. Передача SSL-сертификата должна быть задокументирована, а действия третьей стороны должны контролироваться для обеспечения соответствия стандарту.

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

И есть устойчивое заблуждение на рынке, что только on-premise решения по защите от атак на уровне приложений, то есть, по сути, стоящие во внутреннем контуре под полным контролем штатных сотрудников, как раз и могут обеспечить защиту без раскрытия SSL-сертификатов. Но только ли они?

Давайте вспомним одного из крупнейших вендоров решений по защите от различных веб-угроз — американскую компанию Cloudflare. У него нет решений on-premise, однако этот вендор предоставляет защиту от DDoS-атак как на сетевом уровне (L3–L4), так и на уровне приложений (L7), а также от ботов. И облачные продукты Cloudflare имеют сертификацию согласно стандарту PCI-DSS. Это означает, что не только on-premise позволяет выполнить требования стандарта, но и сервисная модель вполне может это обеспечить. Иностранцы с облачной моделью защиты и сертифицированными по стандарту решениями также ушли с рынка. Российские провайдеры же в большинстве своем могут защищать от тех же DDoS-атак без раскрытия SSL-сертификатов, но не от ботов. В большинстве, но не все.

Есть и другие причины, побуждающие отечественные банки выбирать on-premise. Одна из них — внутренние протоколы безопасности, которые писались еще во времена присутствия на российском рынке F5, Imperva, Radware, Fortinet и других иностранцев. В то время и с той сложностью атак на прикладном уровне казалось, что стоящая в инфраструктуре «железка» — это оптимальное решение. Выбор формы поставки решения также зависит от того — удобнее ли относить затраты на приобретение решений защиты к капитальным или же к операционным расходам. И расходы на покупку on-premise часто именно CAPEX (хотя и бывают разные варианты). Ну и, наконец, для многих специалистов по информационной безопасности важен максимальный контроль за всеми процессами в ИТ и ИБ при обеспечении подхода Zero Trust в компании, что также  возможно с on-premise.

В идеальной картине мира банки хотели бы иметь on-premise решение для защиты от DDoS-атак как на сетевом уровне, так и на уровне приложений, включая защиту от ботов. С сетевыми DDoS-атакам (L3–L4) и атаками на уровне приложений (L7) все относительно просто — на рынке есть необходимые решения от разных вендоров. Мы также активно внедряем свою on-premise защиту в банках. А вот с защитой от атак продвинутых ботов все иначе. Допускаю, что еще несколько лет назад можно было реально поставить внутрь инфраструктуры иностранное коробочное решение и быть уверенным, что боты не пройдут. Сейчас же мы видим, что все чаще в ход идут фулстек-боты, которые умеют имитировать человеческие действия, адаптироваться под профиль трафика, эмулировать действия браузера, менять IP-адреса и идентификаторы устройств. Чтобы эффективно бороться с такими веб-угрозами, антибот-решения должны обладать мощными алгоритмами машинного обучения, анализировать десятки параметров поведения пользователей, собирать информацию о глобальных базах ботнетов. И даже если организация наймет лучших на рынке аналитиков, которые будут обучать алгоритмы локального решения бороться с новыми ботами, то обучение это будет происходить все равно на данных трафика лишь одной организации. Вендор же имеет возможность обучать свой продукт на основании анализа трафика сразу пула веб-ресурсов своих клиентов или даже целых отраслей и выявлять закономерности для повышения точности алгоритмов фильтрации. Такое решение будет априори эффективнее.

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

Есть ли такие решения на рынке? Есть и уже активно пилотируются в российских банках. Для повышения эффективности защиты они встраиваются в эшелонированную архитектуру ИБ, состоящую из защищенных каналов связи, различных firewall, ПАК по защите от сетевых и сессионных атак, и передают данные об инцидентах в SIEM/SOC (а где-то интегрируются с антифрод-системами).

Так что можно упорно хранить заветную иностранную «железку», надеясь на полный контроль над трафиком и отсутствие атак интеллектуальных фулстек-ботов в обозримом будущем. А можно оглянуться вокруг, изучить внимательно предложения отечественных вендоров и найти свой идеальный on-premise, получающий с регулярным обновлением сигнатуры и модели угроз от вендора. И работающий эффективнее привычной коробки.

[1] Цифровой сертификат, который удостоверяет подлинность веб-сайта и позволяет использовать зашифрованное соединение, содержит цифровую подпись издателя, ключ и имя владельца сертификата, название центра сертификации (прим. ред.).

Реклама. ООО «СЕРВИСПАЙП», ИНН: 7708257951, Erid: 2VfnxxkCnRv