История создания ASoar: от идеи до реализации системы кибербезопасности
Предыстория: личный опыт и первые шаги
Я описал свой путь в предыдущей статье https://habr.com/ru/articles/813239/, но если коротко, то моя карьера в сфере информационной безопасности началась, как и у многих, с работы в ИТ-инфраструктуре. Поначалу моя компания занималась тем, что поддерживала стабильность сетей и систем для различных компаний, и регулярно сталкиваясь с типичными проблемами, связанными с кибератаками. Однажды в компании, где штат ИБ был минимален, мы внедрили SIEM — решение, которое, как считалось, должно было кардинально улучшить безопасность. Однако это был дорогостоящий и трудоёмкий процесс. SIEM не только не оправдал ожиданий, но и породил кучу инцидентов, большинство из которых не представляли реальной угрозы. Специалисты тратили время на анализ множества событий, которые, по сути, были незначительными. С каждым новым ложным срабатыванием доверие к системе падало. В конце концов, люди просто начали игнорировать предупреждения, считая, что система безопасна, хотя это было далеко не так.
Так я сформулировал ключевую проблему SIEM:
В обычных организациях, где число специалистов по ИБ ограничено, использование SIEM часто не приводит к ожидаемым результатам. И именно это открыло мне глаза на необходимость поиска нового подхода. Я начал думать о том, как можно было бы автоматизировать процессы безопасности, не нагружая команду ложными тревогами и сложными настройками.
Почему автоматизация на базе SIEM не работает из коробки
На практике оказалось, что настройка SIEM — это ещё одна большая головная боль. Каждый инцидент нужно классифицировать, понять, что является важным, а что — просто шум. Выстраивание правил корреляции для инцидентов — дело сложное и требует времени. Когда я начал работать с SOAR-системами, которые должны были автоматизировать обработку инцидентов, стало ясно, что они работают только в связке с SIEM, а это значит, что прежде чем добиться технологической зрелости SOAR внутри компании, необходимо пройти сложный путь настройки и обучения SIEM с сотрудниками и инфраструктурой. На этом этапе большинство организаций сталкиваются с огромными трудностями, и системы либо не настраиваются до конца, либо начинают перегружать команду ложными инцидентами. Когда мы столкнулись с реальными проблемами внедрения SIEM, стало ясно: существующие решения перегружены инцидентами и требуют слишком больших ресурсов для настройки.
На одной из рабочих встреч я поделился этими мыслями с коллегами, и мы начали думать о том, как можно было бы построить решение, которое бы обходило эти проблемы. Мы вспомнили старый и хорошо известный принцип fail2ban — если кто-то делает подозрительные действия, блокируем его, есть даже набор библиотек с аналогичным названием. Конечно же, это решение показалось нам слишком жёстким и однобоким, но так родилась идея новой системы, основанной на похожем подходе, но дополнительно нам были нужны: гибкость, обучаемость, положительная обратная связь.
Практика: разработка скоринговой системы
Вместо того чтобы блокировать всех подряд при первом подозрении, мы решили использовать систему скоринга в реальном времени. Мы взяли за основу концепцию двух индексов: индекса полезности и индекса опасности. Мы начали строить гибкую систему, которая могла бы различать реальные угрозы и случайные, неопасные действия.
Индекс полезности: этот параметр показывает, насколько агент (пользователь или устройство) выполняет полезные действия в сети. Конечно, его настройка сложна, так как полезность зависит от конкретных задач и часто параметры индекса придется настраивать в конечной системе.
Индекс опасности: здесь всё гораздо проще. Большинство систем автоматически фиксируют подозрительные действия агентов, такие как попытки входа на несуществующие страницы, сканирование сетевых ресурсов и т. д. Индекс опасности накапливается за такие действия.
Наша ключевая идея заключалась в том, что если индекс полезности низкий, а индекс опасности растёт, то нужно временно ограничить доступ такому агенту. Это бы позволило минимизировать риск проникновения злоумышленников, одновременно избегая ложных срабатываний.
Быстро стало понятно, что нам нужен механизм «остывания», ведь мы не можем забанить навечно всех. Мы внедрили систему TTL (Time To Live) для обоих индексов. Это значит, что опасность и полезность со временем «остывает» — в частности, если агент перестаёт совершать подозрительные действия, его индекс опасности снижается. Например, если пользователь случайно зашёл куда-то с неверным паролем, то его не заблокируют сразу — индекс опасности повысится всего на единицу на несколько часов, но в случае повторных и множественных действий он продолжит расти.
Так сначала теоретически, а затем и практически мы разработали систему с детальной и динамической оценкой действий агентов. Введение двух индексов — полезности и опасности — позволяет гибко управлять доступом, минимизируя ложные срабатывания и сохраняя высокую точность реагирования. Это решает главную проблему SIEM и SOAR — чрезмерное количество событий и сложность настройки правил. Такая система, по сути, не только реагирует на инциденты, но и учится на реальной активности и получается, что чем больше защищаемый периметр, тем более защищен каждый элемент сети, т.к. его защита основана на общей статистике…
Пример из практики
Один из ярких случаев внедрения нашей скоринговой системы произошел в проекте для крупного e-commerce клиента. В системе защиты веб-сайта мы начали отслеживать действия пользователей, пытавшихся попасть в административные зоны через запросы к страницам, таким как /wp-admin, /phpMyAdmin, /bitrix и так далее (вот пример regex: hpMyAdmin|wp-admin|admin|administrator|phpmyadmin|bitrix|typo3).
Мы настроили все так: когда агент отправляет такие запросы и получает 404 от сервера, то мы понимаем что он ищет админку, это практически не опасное действие само по себе, и мы индекс опасности для этого агента немного увеличим. Это позволило нашей системе гибко управлять доступом: если пользователь случайно «натыкался» на админ-зоны, то мы его не блокировали, но если это было целенаправленное сканирование, то индекс опасности накапливался, и доступ ограничивался.
А дальше все пошло как по накатанной: оказалось, что все системы так или иначе отчитываются о том, как работают с пользователем, и сами даже выставляют уровни критичности для своих сообщений, это позволило нам быстро накопить большую базу для источников сигналов. Системы с одной стороны умные, а с другой стороны напрочь лишены возможности обмениваться инфой друг с другом и у них нет памяти. Вот эти две задачи мы и стали решать: сейчас мы накапливаем скоринг по всей сети, глубоко во времени и дифференцированно по степеням угроз.
Мы протестировали и реализовали все эти идеи в собственном продукте, долго проверяли его в нашей инфраструктуре и у партнёров. Менее года назад мы вышли на рынок с ASoar — системой класса TDR (Threat Detection and Response). Название Active SOAR подчёркивает нашу философию: SOAR автоматизирует оркестрацию безопасности, а Active в названии указывает на нашу приверженность к проактивному выявлению и немедленному реагированию на угрозы. Таким образом, мы находимся на стыке систем TDR и SOAR, совмещая лучшее из них.
Еще один прорыв — GHostHost
Концепция HoneyPot давно известна в мире кибербезопасности, но на практике её редко используют, особенно в корпоративных сегментах. Многие считают, что установка ловушек для злоумышленников — это скорее академический интерес, чем реальная защита. Мы решили развить эту идею и сделать её более прикладной.
Вместо того, чтобы в конце правил файрвола было что-то утилизирующее запросы, по типу «deny all», мы внутри ASoar создали подсистему, которую назвали GHostHost — виртуальную машину с множеством ловушек HoneyPot. Все запросы, не нашедшие своего адресата, перенаправляются на эту машину. В результате мы получаем логи всех попыток атак и передаем их в ASoar для анализа. Этот подход не только помогает нам выявлять злоумышленников на стадии рекогносцировки, но и сбивает их с толку. Злоумышленники видят ложные цели, что делает их работу менее эффективной.
Как это работает
Допустим, злоумышленник пытается провести сканирование нашей сети, отправляя запросы на различные порты и IP-адреса. Вместо того, чтобы эти запросы блокировались на уровне файрвола, они перенаправляются на GHostHost — виртуальный сервер с набором ловушек HoneyPot. Этот сервер ведет логи всех действий злоумышленника: какие порты он сканировал, какими протоколами, какие попытки входа делал, и т.д. Затем эти логи передаются в ASoar, где система автоматически оценивает действия агента и дает оценку их уровню угрозы.
Что самое важное, благодаря этому подходу злоумышленник не может провести рекогносцировку нашей реальной инфраструктуры ни внутри периметра, ни снаружи. Он попадает на ложные цели, которые кажутся ему реальными, и, следовательно, теряет время, тогда как наша система успевает отреагировать и заблокировать его.
Пример из практики
На одном из объектов наши специалисты внедрили GHostHost для защиты внутренней сети. В первый же день работы мы зафиксировали множество попыток сканирования со стороны одной из машин, где нерадивый администратор поставил «бесплатный антивирус». Благодаря тому, что все запросы на несуществующие адреса перенаправлялись на GHostHost, система успела вовремя обнаружить источник сканирования и изолировать его.
Отчётность
Одним из ключевых элементов успешной системы кибербезопасности является доступная и понятная отчётность. Я даже не буду в очередной раз распространяться о том, что в киббезе все очень любят показывать свою важность пустыми отчетами и делать «бумажную безопасность» взамен реальной. ASoar предоставляет возможности не только для глубокого анализа следа каждого агента и его действий, но и инструменты для визуализации данных, которые позволяют оперативно оценивать ситуацию. Например, администратор может легко увидеть, как индекс опасности рос или снижался для конкретного агента, какие события происходили, и как они влияли на оценку его активности.
Отчётность ASoar помогает отвечать на ключевые вопросы:
Сколько агентов было заблокировано за последнюю минуту, час или сутки?
Сколько логов поступает с каждой системы?
Какие правила корреляции срабатывали чаще всего?
Для удобства анализа все данные представлены на временных диаграммах, что упрощает мониторинг инфраструктуры и своевременное выявление проблем, таких как потеря логов или сбои в работе источников данных. Система также позволяет автоматически генерировать отчёты для регулярного представления их менеджерам или клиентам, что повышает прозрачность и контролируемость процессов безопасности.
В целом там работы еще очень много, поэтому система отчетов ASoar самая динамично развивающаяся часть и постоянно дорабатывается, там появляются постоянно новые идеи и фишки.
Реалии рынка
В современных условиях компании сталкиваются с серьёзной нехваткой квалифицированных специалистов по кибербезопасности. Ежегодно их дефицит растет, а их услуги становятся всё дороже. Это связано с тем, что киберугрозы развиваются быстрее, чем компании успевают обучать новых специалистов. И как сказал мой друг: «Период затишья заканчивается и Мир перестает более быть безопасным местом». По мере роста сложности атак и сетей, нагрузка на специалистов по ИБ увеличивается, а требования к их квалификации становятся всё выше.
Такие реалии рынка кибербезопасности создают повышенный спрос на решения, которые способны автоматизировать защиту и свести к минимуму участие человека в обработке инцидентов. ASoar в этом плане оказывается оптимальным выбором для компаний, которые не хотят содержать большие ИБ-команды. Он заменяет десятки часов ручной работы автоматической обработкой данных и анализом угроз в реальном времени, позволяя существенно снизить затраты на безопасность.
Потребительские свойства ASoar
ASoar создавался с учетом реальных потребностей компаний, стремящихся к оптимизации затрат на безопасность и минимизации человеческого фактора. Система обладает следующими потребительскими свойствами:
Автоматизация: Большинство процессов, которые требуют участия специалистов в традиционных SIEM-системах, в ASoar автоматизированы. Это позволяет значительно уменьшить нагрузку на команду безопасности и оперативно реагировать на угрозы, а администраторам дают возможность спокойно спать по ночам.
Гибкость и адаптивность: ASoar легко интегрируется с существующими системами безопасности, собирая логи с различных источников и предоставляя универсальные решения для компаний различной стадии технологической зрелости.
Эффективность: Даже компании с небольшими ресурсами могут получать высокий уровень защиты без необходимости содержания больших команд специалистов. Благодаря модели скоринга агентов, система позволяет точно выявлять и блокировать угрозы, не перегружая персонал ложными срабатываниями.
Низкий уровень false positive: важным преимуществом ASoar перед конкурентами является низкий уровень ложных срабатываний (false positive). Система использует интеллектуальные алгоритмы для анализа действий агентов в реальном времени, взвешивая индекс полезности и индекс опасности. Это позволяет более точно оценивать подозрительные действия и минимизировать количество ложных тревог. В результате администраторы не тратят время на ненужную проверку инцидентов и могут сосредоточиться на реальных угрозах. Это особенно важно для компаний с ограниченными ресурсами в сфере ИБ.
Таким образом, ASoar позволяет не только сократить затраты на ИБ, но и повысить её уровень за счёт автоматизации процессов и использования современных технологий, таких как GHostHost и системы скоринга агентов в реальном времени, основанной на общей статистики использования сети.
ASoar сейчас и планы на будущее
На данный момент ASoar предоставляет мощные инструменты для автоматизации и оркестрации процессов кибербезопасности. Сигнальная подсистема GHostHost позволяет дополнительно повысить чувствительность ASoar, выявлять и останавливать проникновения на разных уровнях. Наша система отчетности позволяет администраторам видеть, как и за что рос индекс опасности у агентов, какие действия они выполняли, а также мониторить статистику по заблокированным агентам и правилам безопасности. Мы предоставляем временные диаграммы для мониторинга логов и их источников, что позволяет быстро выявить проблемы в инфраструктуре.
Тем не менее, мы понимаем, что развитие системы не должно останавливаться на достигнутом. Мы уже планируем дальнейшее развитие интерфейсов и расширяем возможности по интеграции с внешними системами безопасности и управления, планируем внедрение искусственного интеллекта для выявления сложных корреляций и алгоритмов, основанных на подсчете энтропии, для выявления аномалий (планируется реализация anomaly detection index).
Заключение
История создания ASoar — это история поиска новых подходов в кибербезопасности. Мы осознали, что традиционные системы, такие как SIEM и SOAR, не всегда могут обеспечить достаточную защиту. Именно поэтому мы создали систему, которая работает в реальном времени, фокусируется на автоматизации и гибкости, позволяя администраторам сосредоточиться на реальных угрозах, а не на ложных инцидентах.
Сегодня ASoar — это не просто система защиты, это реализация комплексного подхода к безопасности, который помогает компаниям улучшить их кибербезопасность и снизить затраты на её поддержание. ASoar не только эффективно фильтрует агентов на основе их поведения, но и предоставляет необходимую информацию для мониторинга и улучшения процессов безопасности. Это делает систему привлекательной как для технических специалистов, так и для управленцев, отвечающих за безопасность в организации.
И важно в текущих реалиях указать, что ASoar разработан в России и включен в реестр отечественного софта.
Благодарности
Во всей этой истории я представляю не только себя, но и весь наш коллектив и я хочу выразить большую благодарность людям, которые внесли огромный вклад в создание ASoar. Прежде всего это мои коллеги, наша штатная и нештатная команда разработки воплотила в жизнь идеи, протестировала и довела проект до коммерческого запуска. И я хочу поблагодарить всех своих друзей и коллег из смежных компаний, которых я приглашал на консультации и мозговые штурмы, которые делились своим опытом и болели за наш продукт, помогали его отлаживать, соглашались быть первыми пользователями и давали конструктивную обратную связь!
Habrahabr.ru прочитано 877 раз
