Привет, Хабр! Меня зовут Кирилл Рупасов. Я руковожу группой инженеров SOC (Security Operations Center) в «К2 Кибербезопасность». Я не понаслышке знаю, как порой непросто создавать контент для Центра мониторинга кибербезопасности. Написать одно правило обычно несложно, а вот разработать их связанный комплекс — задача достаточно трудная, особенно для молодых команд.
Под катом я собрал всю полезную информацию о грамотном создании контента: виды правил и их нюансы, workflow и возможные проблемы, сценарии обработки инцидентов. А также рассказал, как мы организовали процесс разработки и поддержки актуальности контента в своем коммерческом SOC.
Виды и назначение контента для SOC
Итак, с какими же видами контента работает SOC и для чего нужен каждый:
Правила нормализации преобразуют исходные события в структуру для хранения в СУБД по регулярным выражениям с заданными полями и значениями.
Правила корреляции определяют, какие события считать инцидентами. Это ключевой вид контента.
Правила агрегации объединяют несколько событий в одно, снижая нагрузку на оборудование и требования к лицензии SIEM-системы.
Правила обогащения предоставляют аналитикам дополнительную информацию о событии/инциденте.
Скрипты связывают компоненты SOC и выполняют вспомогательные функции: от сбора статистики до обслуживания инфраструктуры.
Возможные проблемы с контентом
И вендор, и интегратор внедряют в SOC настроенную SIEM-систему с развитой документацией и готовым контентом. Кажется, что она умеет все «из коробки», нужно только прочесть инструкцию и все заработает. Однако в реальности внедрение SIEM-системы часто оборачивается разочарованием. Какие же могут возникнуть проблемы:
Поставляемый контент не оптимизирован под вашу инфраструктуру
Для реализации правил необходимы такие детали, как, например, списки ролей серверов (в частности, расположение контроллеров домена или почтовых серверов), пользователей и групп, специализированного ПО. Вендор физически не может этого знать. Поэтому он вынужден оставлять заглушки-переменные для заполнения. Интегратор тоже не знает нюансов инфраструктуры клиента, к тому же еще и ограничен сроками.
По контенту практически нет документации
Пример кейса — контент состоит из осмысленного заголовка и некоего информационного сообщения о нюансах инцидента, но детали правила в сообщении не раскрыты. Насколько качественно оно внедрено — тоже не совсем понятно. В результате аналитику сложно быстро определить суть инцидента.
Ситуация усугубляется и тем, что в моделях данных SIEM, оставшихся на рынке, поля данных выглядят как datafield1 или customstring1. Часто к ним нет никаких пояснений. Конечно, можно найти необходимую информацию прямо в коде, но это требует времени, а в момент инцидента его остро не хватает.
Изменения в одном элементе контента могут нарушить общую логику работы
Например, изменение категории события в нормализаторе может сломать завязанные на нее правила корреляции. Если нет документации на контент, не всегда понятно, могу ли я отредактировать ошибку и ничего не сломать. Например, перенести значение в более подходящее поле или уточнить его нормализацию.
Даже хорошо отлаженные правила могут требовать доработки
То, что характерно для одной системы, не характерно для другой. Даже достаточно простое и хорошо отлаженное правило может требовать доработки под конкретную инфраструктуру. Например, правило на lolbin. Оно составляется так, чтобы выявить не характерное использование легальных утилит. Однако бывают случаи, когда они используются немного странно. Приходится вносить исключения и подстраиваться под новые реалии.
Вендорские обновления порой вызывают сбои
Обновление правил, нормализаторов или режимов сбора в конфигурации может повлечь непредсказуемые последствия. Этот тезис перекликается с третьим пунктом. Но если там мы сами осознанно вносим изменения и можем проконтролировать их последствия, то вендорские обновления не всегда заметны. Более того, не все вендоры ведут историю изменений своего контента.
В результате их обновления иногда приводят к false positive срабатываниям или даже к тому, что срабатывания прекращаются вовсе. В моей практике такое происходило неоднократно, например, в компании IBM с их продуктом Qradar.
Подходы к самостоятельной разработке контента
Существуют два основных способа разработки контента для SIEM-системы в условиях корпоративного SOC.
Первый способ — попытаться доработать существующий «коробочный» контент, обычно предоставляемый вендором. Преимущество такого подхода — возможность быстрого старта SIEM-системы. Однако у него есть существенные минусы:
Высокие трудозатраты на исправление ошибок. Каждый, кто работал с legacy-кодом, понимает все сложности сопровождения такого решения.
Привязка к чужой логике и идеям, на которые зачастую отсутствует документация. Более того, от таких идей будет проблематично отказаться вне зависимости от их качества.
Трудности с обновлениями. Как писал выше, контент может ломаться при выходе новых версий продукта, что вынуждает переписывать его заново.
Второй способ — написать весь контент самостоятельно с нуля. Этот путь выбирают самые импульсивные команды. Преимущества — отсутствуют минусы первого подхода. Однако здесь тоже есть существенные недостатки:
SOC не сможет работать, пока не будет создана значимая часть контента для выявления инцидентов хоть на каком-то уровне. А для качественной работы необходимо как минимум создать нормализатор на несколько ОС (это порядка 300 событий для каждой из них), СЗИ и инфраструктурных средств, а также набор правил корреляции. Разработка подобного объема потребует не менее года.
Для создания контента с нуля нужны высококвалифицированные специалисты, которые стоят дорого.
В своей практике мы решили комбинировать оба подхода — по возможности поддерживаем и используем «коробочный» контент, но постепенно заменяем его собственным. В результате мы практически сразу можем запускать SOC в каком-то минимальном состоянии. Однако такой гибридный подход требует привлечения в два раза больше экспертов, так как трек разработки разделяется на два независимых потока.
Где взять идеи для контента
Существует три основных источника идей для создания правил или контента в целом, но каждый из них имеет свои ограничения:
Идеи от клиента, базирующиеся на специфике его бизнес-процессов. Как правило, они не связаны с типичными тактиками и техниками по MITRE ATT&CK, а ближе к задачам антифрода. Однако заказчик обычно не знаком со спецификой работы инструментов SOC, например, не понимает разницу между SIEM и Zabbix.
Идеи от сотрудников первой линии. Находясь на передовых позициях, они часто предлагают ценные идеи по улучшению работоспособности и оптимизации правил. Команда предоставляет статистику верных и ложных срабатываний, ошибок нормализатора, получает обратную связь от заказчика. Вместе с тем не всегда способна квалифицированно определить задачу. Так, например, однажды мы получили предложение исключить исполнение команд от легального пользователя www_data. С одной стороны это верно, он используется для работы web-серверов. При этом некоторые действия под этим пользователем могут свидетельствовать о, например, атаке типа command injection, используемой для первичного проникновения (T1059).
Идеи от команды экспертов. Мы работаем над целым рядом проектов из различных отраслей и можем сами генерировать задачи по контенту. Однако такие идеи могут быть не самыми приоритетными, требовать существенных вычислительных ресурсов или большого объема EPS (Events Per Seconds).
Наш workflow создания контента
Как видите, идеального источника идей для контента не существует. Решение этой проблемы достаточно простое — мы принимаем все идеи из всех источников, но они обязательно проходят через этап гипотезы. Так мы определяем реализуемость идеи.
Гипотезу может высказать любой сотрудник SOC. Не только инженеры, но и смежные специалисты. Например, сервис-менеджеры, ведь они — связующее звено между исполнителями и бизнесом. Причем под гипотезой мы понимаем сформированную идею с проработанным описанием, обоснованием и референсами.
Гипотезы рассматривает тимлид и драйвер — так мы называем эксперта, который взялся за данный проект, обладает достаточным опытом в разработке и принимает активное участие в создании контента. Он не является тимлидом, не руководит командой, но в то же время по своей инициативе двигает направление и рассматривает гипотезы.
Если тимлид или драйвер одобряют гипотезу, то аналитики первой линии могут начинать выполнять по ней простые задачи на исключения, а сотрудники второй линии — основную работу по разработке контента.
Важно мотивировать команду участвовать в разработке гипотез и предлагать свои собственные идеи. Материально и не только. Например, привлечение сотрудников первой линии поможет им глубже изучить контент и откроет перспективы карьерного роста.
На всех этапах создания контента необходим тщательный контроль. На стадии гипотезы важно четкое описание идеи и рисков. Для принятой в работу задачи устанавливаются цели и сроки. На выходе требуется документирование правила и примеры его срабатываний.
Общая схема разработки контента выглядит у нас следующим образом:
Самый первый этап — предварительный анализ или проверка гипотезы. Как говорилось выше, выдвинуть ее может любой сотрудник SOC. Этот шаг проходят даже самые очевидные идеи, так как в ходе рассмотрения мы можем выйти на неявные проблемы в реализации. Например, с потоком данных или их извлечением.
После гипотезы идея попадает в бэклог с определенным приоритетом. Он зависит от позиции в пирамиде Дэвида Бьянко, покрытия существующими правилами, маркетинга и других факторов.
Далее идет стандартный процесс разработки, который заканчивается передачей на оценку с обязательным ревью кода и документации опытными специалистами. В рамках ревью обращаем внимание, насколько эффективно работает правило, на корректность регулярных выражений и на возможность ложно-положительных срабатываний.
Зачем нужна группировка правил
Одиночные правила трудно поддерживать и модифицировать, поэтому мы их группируем. Во многих SOC используется группировка по MITRE ATT&CK или базам данных угроз (БДУ). Однако этот подход не всегда удобен, так как эти методологии «живые» — развиваются и часто меняются, из-за чего возникают разночтения и приходится пересматривать все правила. Кроме того, одно правило может относиться к нескольким тактикам и техникам. Поэтому его трудно классифицировать. Или может возникнуть другая ситуация: с практической точки зрения проще сделать одно правило, которое покрывает 4-5 техник, но ни к одной из них напрямую не относится. Куда его определить — непонятно.
Поэтому мы используем небольшие группы по 10-15 правил со схожей смысловой нагрузкой. Такая стратегия удобна и при организации спринтов. При этом связь с методологиями можно отражать в виде тегов или отдельных полей в документации.
Как работаем над документацией
В документации обязательно должно быть описание юзкейса (UseCase), включающее общее описание правила и примерное направление реагирования. Об этих группах правил я писал выше.
В самом правиле, помимо общего описания, рекомендуется указывать следующую информацию:
Описание общей логики правила, которое должно разъяснять, с какими данными оно работает, что ищет, какие исключительные ситуации могут возникнуть.
Описание реагирования, дополняющее раздел из UseCase. Это не playbook, а то, что разработчик вкладывает в идею правила. Playbook, исходя из опыта, не может появиться сразу. Его написание — достаточно длительный процесс. Он может затягивать внедрение правила, особенно в небольших командах. Необходима отправная точка для дальнейшего анализа и понимание, какую дополнительную информацию следует искать в контексте правила. Кроме того, на основании этих данных можно оценить корректность его работы и уже потом сформировать полноценный playbook.
Описание действий при внедрении правила. Очень важен отдельный трекинг с контролем сроков. Здесь может быть отражено, как именно внедряется правило и что для этого требуется. Например, перевод на самообучение, запрос информации у заказчика, заполнение переменных и т. д.
Работа с правилами агрегации
Агрегация событий позволяет экономить вычислительные ресурсы и лицензии. Она коварна и при неправильной настройке может лишить вас критически важной информации. Потому при формировании правил агрегации следует объединять события, где важно количество, а не состав. Не рекомендуется агрегировать такие события, как запуск процессов, так как это приведет к потере значимых данных. Даже если сохранить информацию о самом процессе. В то же время агрегация событий от межсетевых экранов или маршрутизаторов может сократить нагрузку в 3-5 раз.
Работа с обогащением событий
При обогащении событий значимой информацией и расшифровкой кодов важно добавлять сведения о том, что именно передано в IRP (Incident Response Platform). Эти данные должны полностью соответствовать принятой в SOC базе знаний. Поэтому лучше брать их прямо оттуда.
Рекомендую заранее заполнять большие или длинные поля. Оба подхода существенно сэкономят время аналитиков, за что они будут вам благодарны. Полезной может стать информация из описаний реагирования в юзкейсах и правилах.
Для обогащения можно использовать систему плагинов. В момент передачи события в IRP после его обработки запускается набор скриптов, которые:
Переносят необходимую информацию из базы знаний.
Выполняют рутинные запросы в SIEM.
Получают дополнительные данные из смежных систем.
Такие функции можно реализовать как в SOAR, так и самостоятельно. В нашей практике применяется динамический запуск модулей.
Соблюдение рекомендаций по агрегации и обогащению событий позволит оптимизировать нагрузку на SIEM и уменьшить затраты ресурсов, при этом сохранив критически важную информацию для эффективного реагирования аналитиков.
Заключение
Работа с контентом SOC гораздо сложнее, чем кажется. Она требует пристального внимания как со стороны аналитиков, так и со стороны создателей контента.
Процесс должен быть понятным и прозрачным для всех участников. Необходимо тщательно документировать все компоненты контента и осуществлять контроль на всех этапах его жизненного цикла.
Это непрерывный процесс, требующий постоянного развития и совершенствования. Только при соблюдении высоких стандартов разработки, тестирования и внедрения контента можно добиться эффективной работы систем мониторинга и реагирования на угрозы.