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

Никто не хочет покупать кота в мешке, особенно, когда речь идет о дорогостоящих ИБ-решениях. Поэтому сделке и интеграции часто предшествует пилотный проект. Казалось бы, что может быть проще: поставил СЗИ, посмотрел пару недель, как оно работает и принял решение о покупке (или не принял). На практике же после пилота иногда повисает «неловкая пауза»: заказчик не понимает, как ему оценить результаты теста, а вендор – как дальше защищать свой продукт, потому что вводных от заказчика было ничтожно мало. Итог может быть печальным для всех. Вендор уйдет без клиента, а потенциальный заказчик – без киберзащиты. Поэтому, чтобы недели (а иногда и месяцы) не прошли даром, к пилоту надо хорошо подготовиться. Особенно, если речь идет о сложных системах, таких как межсетевой экран веб-приложений (WAF). Поскольку WAF – это полноценный участник архитектуры, он требует правильной интеграции с защищаемыми приложениями, балансировщиками нагрузки и другими системами в инфраструктуре заказчика. Давайте посмотрим на каждый этап отдельно.

Первый список OWASP Top Ten был выпущен в 2004 году. И с того момента появилось 7 обновлений, последнее из которых представлено в ноябре 2025 (пока в статусе Release Candidate). Эксперты WMX проанализировали все выпуски, чтобы разобраться, как с каждым годом и даже десятилетием менялась оценка угроз.

Привет, Хабр! На связи команда маркетинга ИБ-вендора WMX (aka Вебмониторэкс). Обычно мы рассказываем о веб-угрозах, вредоносном трафике, особенностях WAF и API-firewall, и прочих тонкостях защиты веб-приложений. Но сегодняшний пост - исключение. Мы хотим поделиться опытом ребрендинга.

За последние пару лет имидж поменяли многие компании, но как известно - «существовать – значит, меняться». И вот мы тоже посмотрели на наш старый дизайн, лого, название и поняли, что пора нам все это освежить, сделать лаконичным и современным. Мы не планировали революцию, а только легкую модернизацию: обновиться, сохранив преемственность. «Operation Cannot Possibly Fail» - решили мы, но все, естественно, пошло не по плану и оказалось намного сложнее, чем нам казалось.

Через API проходит большой объем данных, в том числе конфиденциальных. Естественно, такое «богатство» интересует киберпреступников. Они могут с помощью уязвимостей API обойти авторизацию в приложения, получить ценные данные компании или клиентов и т. п. Для защиты программных интерфейсов может использоваться API‑Firewall, который работает, по позитивно модели безопасности: разрешены запросы, соответствующие заранее определённой спецификации API, а все остальное — запрещено. Но это теория, а как защита работает в жизни? В данном посте мы постарались описать кейсы использования API‑Firewall на примере нашего решения ПроAPI Защита.

От чего защищает WAF (Web application firewall)? Самый очевидный ответ – от взлома веб-приложения. Однако не все веб-атаки предполагают эксплуатацию уязвимостей - иногда злоумышленники совершают и легитимные технически корректные действия, которые могут навредить организации. Так один из наших клиентов столкнулся с проблемой SMS-бомбинга. Для массовой рассылки SMS киберпреступники использовали открытый API. Решить проблему удалось с помощью WAF. Какие настройки для этого потребовались – расскажем в этой статье.