| Слушать на Google Podcasts | Слушать на Mave | Слушать на Яндекс Музыке |
Руслан Рахметов, Security Vision
При работе SOC с различными технологиями важно выстроить архитектуру, которая обеспечивает работу членов команды SOC-центра и объединяет данные, получаемые от различных источников (ИТ/ИБ-системы, системы мониторинга, аналитика киберугроз) для преобразования данных в информацию, а информации - в знания. Используемые в SOC технологии, такие как SIEM, TIP, EDR и т.д., предоставляют свой собственный интерфейс, и аналитики вынуждены постоянно переключаться между консолями различных решений. Авторы публикации указывают, что лучшей стратегией будут снижение количества консолей управления и взаимная интеграция между различными технологиями SOC, а также автоматизация и централизованное управление выполнением повторяющихся задач, процедур эскалации и обработки инцидентов. Стратегия №8 посвящена описанию технологий SOC, которые помогут достичь данных целей.
1. SIEM-системы.
Решения класса Security Information and Event Management (SIEM, системы управления информацией о безопасности и событиями ИБ) позволяют обрабатывать миллионы событий ИБ и извлекать из них пользу для работы SOC-центра. Как и при использовании любой технологии в SOC, важно не только приобрести дорогостоящее решение, но и инвестировать в его настройку, администрирование, поддержку. Решения SIEM позволяют собирать, агрегировать, фильтровать, сохранять, категорировать, коррелировать, отображать данные, релевантные для решения задач ИБ, а также проводить анализ в режиме реального времени и на основании накопленных данных. Системы SIEM позволяют выделить из потока данных от различных источников значимые события ИБ, что дает возможность нескольким аналитикам SOC оперативно обрабатывать сразу большое количество информации, имеющей отношение к кибербезопасности, в результате выявляя сложные кибератаки APT-группировок, проводя анализ ранее произошедших инцидентов, обрабатывая киберинциденты на всех этапах жизненного цикла, используя данные аналитики киберугроз, осуществляя проактивный поиск киберугроз, обеспечивая ситуационную осведомленность компании-заказчика и соответствие нормам применимого законодательства.
Применение SIEM-системы позволяет выявить (сбор данных, нормализация, корреляция), проверить (обогатить, исключить ложноположительные срабатывания, передать на дальнейший анализ) и отреагировать на инцидент ИБ. При этом использование SIEM-систем в SOC и в департаментах ИБ различных компаний может сопровождаться заблуждением, что эта технология позволит сократить затраты на персонал, однако, применение SIEM зачастую позволяет выявить инциденты, которые ранее были невидимы и проходили незамеченными, что может привести к повышению нагрузки на ИБ-аналитиков, и, соответственно, к росту штата. Аналогично, применение решений по автоматизации SOC, например, с помощью SIEM или SOAR-систем, может привести не к полному отказу от аналитиков уровня L1, а к повышению эффективности и результативности их деятельности в результате передачи им в работу уже очищенных, приоритизированных и обогащенных средствами автоматизации инцидентов.
Основными функциями и компонентами в современных SIEM-системах являются:
1.1. Сбор данных:
Сбор данных может осуществляться как с помощью компонента-коллектора (агента), который либо устанавливается локально на целевой системе, с которой требуется получать события аудита ИБ, либо подключается удаленно к целевой системе для получения данных, либо принимает данные, отправляемые ему целевой системой. Коллектор позволяет фильтровать, дедуплицировать, кэшировать, управлять потоком данных, приоритизировать обработку данных в оперативном режиме, без потерь, с использованием аутентификации соединений и шифрования трафика.
1.2. Нормализация и сохранение данных:
Во многих SIEM-решениях данные собираются в центральном хранилище, которое позволяет выполнять поисковые запросы по данным с быстрым получением результата. Ноды SIEM, которые обеспечивают корреляцию и хранение данных, ранее традиционно предлагались в виде ПАК или программных инсталляций, но в последнее время все чаще используются виртуализированные решения, облачные IaaS-образы, SaaS-решения. Нормализацию (т.е. парсинг поступающих данных, выделение значимых свойств событий, структурирование обработанной информации) можно проводить при чтении сохраненных событий (например, при выполнении поисковых запросов в SIEM, метод имеет название "schema on read") или при записи в SIEM сохраняемых событий (более традиционный вариант, метод имеет название "schema on write"). Коммерческие SIEM-решения при решении задачи нормализации и сохранении данных различаются количеством парсеров и интеграций «из коробки», а также моделями лицензирования потока входящих событий и поддержкой разных способов хранения информации (использование хранилищ для «горячих» и «холодных» данных). В больших инфраструктурах подсистема хранения и обработки данных в SIEM может представлять собой географически распределенную кластеризованную систему с множеством нод. В распределенных средах и больших компаниях может встать вопрос о необходимости выполнения поисковых запросов, корреляции, аналитики данных между всеми нодами одной масштабной SIEM-системы или даже между различными SIEM и Log Management системами.
1.3. Аналитика данных:
Анализ данных и выявление инцидентов может производиться с помощью следующих основных подходов:
- Корреляция и выявление инцидентов в режиме реального времени;
- Корреляция и выявление инцидентов в сохраненных ранее данных;
- Методы машинного обучения для выявления инцидентов.
Корреляционное и аналитическое ядро SIEM-системы выполняет категоризацию поступающих данных, приоритизацию поступающих событий в зависимости от настроенных правил корреляции и обогащенных данных (например, сравнивая с отчетами о сканировании на наличие уязвимостей или используя различные технологии машинного обучения), а также выполнение ограниченного набора действий по реагированию (например, отправка email-оповещения операторам SOC, создание кейса в SIEM-системе, запуск скрипта). Расширенные действия по реагированию выполняются уже в SOAR-системах.
1.4. Поисковые запросы, взаимодействие, работа аналитиков:
Работники SOC-центра выполняют поисковые запросы в консоли SIEM-системы, отслеживают появление предупреждений от SIEM, оценивают состояние киберзащищенности с помощью средств визуализации (на дашбордах, диаграммах, графиках). Используемые в SOC-центрах SIEM-решения должны предоставлять возможность автоматизации выполнения частых поисковых запросов и визуализации состояния ИБ компании-заказчика, что приводит к воспроизводимости результатов и к упрощению обмена информацией с коллегами. В SIEM-системе, как правило, одновременно работают сразу несколько пользователей, и она должна обслуживать все их поисковые запросы, а также предоставлять возможность создания уведомлений/тэгов, заведения кейсов/тикетов, отправки уведомлений, эскалации инцидентов.
1.5. Гибкая интеграция:
Следует заранее предусмотреть выполнение операций импорта/экспорта контента SIEM (правил корреляций и настроек), а также непосредственно событий ИБ, что может потребоваться, например, при сохранении данных о критичном инциденте или при запросе правоохранительных органов. Также SIEM-решения для больших инфраструктур должны поддерживать отказоустойчивость, кластеризацию, пересылку событий в другие SIEM (например, в родительскую организацию).
Авторы публикации указывают, что, поскольку SIEM-система является, вероятно, самым дорогим единоразовым приобретением SOC-центра, следует предварительно оценить целесообразность такой покупки, оценив потребность SOC-центра и ответив на вопросы:
- Превышают ли текущие потребности SOC-центра имеющиеся возможности применяемых технологий?
- Происходит ли в SOC анализ значительной доли информации в режиме, близком к реальному времени?
- Нужно ли в режиме, близком к реальному времени, обрабатывать информацию от различных устройств в сети?
- Готов ли SOC выделять ресурсы на администрирование и настройку SIEM-системы?
- Каковы будут сценарии использования SIEM-системы?
- Какие преимущества для функций SOC-центра принесет использование SIEM-системы?
- Соответствует ли функционал и архитектура SIEM-системы планам развития SOC на среднесрочную и долгосрочную перспективу?
Перед принятием решения о приобретении SIEM-системы важно не только провести качественное и детальное функциональное сравнение конкурентных решений, но и оценить модель лицензирования производителя SIEM-решения: лицензирование может производиться по количеству нод инсталляции, по объему обрабатываемых данных (в объеме входящего трафика или количестве обработанных событий в единицу времени), по количеству пользователей, по количеству/типу источников данных, по дополнительному функционалу. Важно учесть лицензионные ограничения, в которые можно "упереться" при резком всплеске событий (например, при серьезном инциденте) или в результате неверного первоначального расчета планируемой нагрузки на SIEM-систему. Также следует учесть и стоимость поддержки и обслуживания SIEM-системы, которые могут доходить до 20-30% от первоначальной стоимости SIEM ежегодно. Для «облачных» SIEM, предлагаемых по модели SaaS, ограничения и первоначальный расчет производительности могут не играть важную роль, поскольку сама SaaS-модель подразумевает гибкое масштабирование по требованию. Однако следует иметь ввиду возможность неконтролируемого увеличения расходов на «облачную» SIEM, вызванного скачкообразным ростом потребления ресурсов, например, из-за подключения избыточных «шумных» источников или отсутствия тонкой подстройки SIEM.
Авторы публикации подчеркивают важность донастройки SEM-системы, разработки use cases (сценариев выявления кибератак), создания контента и аналитики, кастомизированных под конкретную инфраструктуру, без чего инвестиции в дорогостоящую SIEM-систему могут оказаться неэффективными или даже бессмысленными. Кроме того, в публикации приводятся следующие рекомендации по использованию и настройке SIEM-систем в SOC-центрах:
- Поддерживайте «здоровье» источников данных и высокое качество передаваемой ими информации: рекомендуется регулярно контролировать перечень источников и выявлять те, которые перестали передавать события, а также выявлять причины изменений содержимого событий;
- Управляйте созданием контента в SIEM: максимальную пользу от применения SIEM-систем дают кастомизированные, тонко настроенные правила корреляции, аналитика, поисковые запросы, отчеты и дашборды, поэтому важно не только создавать такой контент, но и централизованно управлять им, для чего нескольким сотрудникам SOC можно назначить роль «менеджер контента SIEM»;
- Оптимизируйте поисковые запросы: неправильно составленные поисковые запросы могут приводить к избыточной нагрузке на SIEM, поэтому следует предупреждать о выполнении таких запросов и обучать пользователей SIEM;
- Ведите базу знаний: следует управлять базой знаний о защищаемой инфраструктуре (пользователях, устройствах, сервисах) для повышения качества работы SOC с SIEM-системой;
- Управляйте создаваемыми в SIEM предупреждениями и кейсами: следует назначить ответственного за контролем качества закрытия кейсов (инцидентов), создаваемых в SIEM, при этом для более глубокого управления инцидентами можно использовать системы класса SOAR и Case Management.
2. Системы Log Management.
Решения для управления событиями (Log Management, сокращенно LM) можно использовать как более простую и дешевую альтернативу SIEM-системам: такие продукты также позволяют проводить агрегацию и хранение событий, выполнять поиск, формировать отчеты. При этом SIEM-решения создавались для решения задач ИБ и для применения в SOC-центрах, поэтому «из коробки» поддерживают разнообразные методы выявления инцидентов и соответствующую аналитику, а LM-системы применяются в более общих ИТ-сценариях. Разница в функционале между решениями класса LM и SIEM постепенно размывается, поэтому важно анализировать реализацию конкретных функций, которые планируется применять в SOC-центре; при этом авторы публикации указывают на возможность построения SOC на базе LM-систем при условии использования других ИБ-технологий. Небольшие SOC-центры, по мнению авторов публикации, вполне могут обойтись связкой LM и EDR решений, а полноценные SIEM-системы будут слишком дороги в приобретении и обслуживании, так что экономическая целесообразность их применения в малых SOC остается под вопросом, однако, растущая популярность предложений "SIEM as a service" может повлиять на текущее положение дел.
3. Системы User and Entity Behavior Analytics.
Системы анализа поведения пользователей и сущностей (User and Entity Behavior Analytics, сокращенно UEBA) позволяют выявить отклонения в поведении пользователей, устройств и других сущностей в инфраструктуре от нормальной, шаблонизированной деятельности, что может свидетельствовать о вредоносной активности. Фокус UEBA-систем направлен на выявление внутренних угроз и действий нарушителей, которые уже проникли в инфраструктуру. Сами UEBA-решения могут быть отдельными решениями, а также могут дополнять функционал SIEM-систем или других СЗИ. Работа решений класса UEBA основывается на следующем функционале:
- Сценарии использования: выявление нестандартного поведения пользователей, инсайдеров и внешних нарушителей, работающих из-под скомпрометированных учетных записей или горизонтально передвигающихся по сети, выявление утечек и «эксфильтрации» (вывода, похищения) ценной информации, приоритизация и обогащение данных по инцидентам на основе скоринговых риск-баллов поведения пользователей и сущностей, выявление похожих паттернов поведения и взаимосвязей пользователей и сущностей;
- Источники данных: системы аутентификации и контроля доступа, системы управления конфигурациями, кадровые данные о сотрудниках, межсетевые экраны, IDS/IPS-системы, DPI-системы (англ. Deep Packet Inspection, системы глубокого анализа трафика), данные от систем защиты конечных точек (EDR-решения, антивирусы);
- Аналитика: использование методов машинного обучения (с учителем и без), выявление на основе правил.
Использование UEBA-систем даст наилучшие результаты при применении в инфраструктурах с большим количеством пользователей с четко определенными моделями поведения - в этом случае UEBA сможет выявить отклонения более точно. Перед принятием решения о необходимости приобретения UEBA-решения, в SOC-центре следует оценить готовность к применению данной технологии, определить источники данных для UEBA, оценить возможности UEBA по интеграции с имеющимися СЗИ, уточнить у вендора сроки обучения UEBA-модели и уровень ложноположительных и истинноположительных срабатываний, а также понять, насколько предоставляемые UEBA-системой заключения будут понятны аналитикам SOC.
4. Системы Case Management.
Системы управления кейсами/тикетами/инцидентами (англ. Case Management) помогают работникам SOC-центра вести контроль и учет обрабатываемых киберинцидентов. В более зрелых и крупных SOC такая потребность будет особенна высока, а процессы управления инцидентами - более комплексными и сложными. Системы Case Management должны позволять членам команды SOC-центра выполнять следующие действия:
- Вести полный учет информации по инциденту на всех этапах жизненного цикла (триаж, анализ, реагирование, закрытие, отчетность);
- Позволять записывать структурированную (тип, категория, время обнаружения инцидента) и неструктурированную (ручной ввод сотрудником) информацию в карточку инцидента с указанием временных меток;
- Предоставлять интерфейс для взаимодействия сотрудников SOC и представителей компании-заказчика, обеспечивать интеграцию с другими аналогичными системами учета в компании, предоставлять функционал отправки email-сообщений для уведомления, эскалации, назначения задач;
- Поддерживать сохранение артефактов инцидентов (файлов, сэмплов ВПО, событий);
- Обеспечивать связывание кейсов друг с другом, а также создание дочерних кейсов и передачу кейсов между сотрудниками;
- Обеспечивать возможность заведения кейсов сотрудниками компании-заказчика, например, через веб-форму или email;
- Поддерживать систему метрик, оценки трендов, обратную связь для подстройки детектирования и аналитики;
- Поддерживать ролевую модель разграничения доступа, защиту от несанкционированного доступа злоумышленников.
5. Системы Security Automation, Orchestration, and Response
Системы оркестрации, автоматизации и реагирования на киберинциденты позволяют аналитикам быстро и эффективно создавать и выполнять повторяемые процессы, типовые для SOC-центров. Несмотря на то, что в системах SIEM и Case Management могут встречаться похожие функции, целевое применение именно SOAR-решений позволит SOC-центру:
- Собирать инциденты из разнородных, разрозненных систем, представляя операторам единый интерфейс для работы с инцидентами;
- Обогащать и приоритизировать предупреждения и инциденты, дополнять их аналитикой киберугроз, обогащать знаниями о сущностях, затронутых инцидентом;
- Запускать автоматизированные действия для получения дополнительной информации по инциденту, например, запуская подозрительные файлы в "песочнице", получая результаты сканирования устройства на наличие уязвимостей, запрашивая информацию о пользователях из HR-систем;
- Выполнять поисковые запросы по сохраненным событиям;
- Взаимодействовать с работниками компании-заказчика, например, запрашивая подтверждение выполненных действий или получение объяснений;
- Выполнять автоматизированные активные действия по реагированию, например, разрывая сетевые соединения или блокируя учетные записи.
Есть множество различных причин применять SOAR-системы в SOC-центрах. Авторы публикации приводят некоторые из них:
- Слишком большое количество событий / предупреждений и недостаток времени на их ручной анализ;
- Необходимость повышения повторяемости и целостности при выполнении триажа и расследований;
- Возможность быстро обучать и привлекать к обработке инцидентов менее опытных сотрудников на основе наработанных практик и процедур реагирования в виде сценариев реагирования SOAR, составленных более опытными экспертами;
- Недостаточность ресурсов и опыта для ручного внедрения методов интеграции и автоматизации, которые предлагаются в SOAR «из коробки»;
- Повышение удовлетворенности аналитиков от работы из-за снижения количества рутинных ручных операций;
- Снижение времени триажа инцидентов (среднее/медианное время обнаружения и анализа);
- Снижение времени реагирования (среднее/медианное время сдерживания, реагирования, устранения);
- Синергия усилий всех функций SOC по анализу и выявлению инцидентов.
В общем случае, применение SOAR-решений в SOC-центре будет наиболее целесообразным и эффективным при достижении определенного уровня зрелости:
- Разработан и задокументирован процесс обработки инцидентов, по которому работают аналитики SOC-центра;
- Использующиеся в SOC возможности по автоматизации и применению скриптов не удовлетворяют всех потребностей, их сложно поддерживать в актуальном состоянии;
- Есть растущая потребность в упорядоченной передаче знаний и практик от старших сотрудников младшим, которые также не всегда соблюдают рекомендации по обработке типовых инцидентов;
- Есть растущая потребность в совместной разработке и обмене способами автоматизации рабочих процессов SOC;
- Аналитики уже в достаточной мере достигли повторяемости процессов реагирования на типовые инциденты и стремятся переключиться на более творческие задачи;
- Инструменты, которые SOC планирует интегрировать с выбранным SOAR-решением, имеют документированные или совместимые API-механизмы.
Для достижения успеха при внедрении SOAR-платформ авторы публикации дают следующие рекомендации:
- Инвестируйте в ИБ-инструменты (SIEM/LM, TIP, сетевые и хостовые сенсоры) с хорошо задокументированными API-механизмами;
- Используйте лучшие практики управления проектами, включая назначение SOAR-чемпионов из числа работников SOC-центра, определение критериев успеха проекта внедрения SOAR, выделение ресурсов и времени на разработку и тестирование сценариев использования SOAR;
- Начинайте с выявления легкореализуемых, но полезных и часто повторяющихся действий для автоматизации в SOAR (например, со сбора информации и обогащения инцидентов в SOAR);
- Для каждой интегрируемой с SOAR системой и задействованным бизнес-подразделением следует определить стейкхолдера, с которым стоит заранее начать взаимодействие, а также заранее определить поведение целевой интегрируемой с SOAR системы, в том числе в случае ошибок при выполнении автоматизированных действий;
- До окончания внедрения низкорискованных интеграций и повышения уровня зрелости процессов обработки инцидентов в SOC следует избегать высокорискованных рабочих процессов, которые обеспечивают взаимодействие с системами вне зоны контроля SOC, выполняют необратимые изменения, нарушают доступность сервисов, учетных записей или сетевого трафика, вносят изменения на большом количестве систем, могут нарушить работу пользователей, клиентов или привести к снижению выручки, а также воздействуют на системы, влияющие на жизнь и безопасность людей;
- При внедрении высокорискованных рабочих процессов следует избегать выполнения блокировок на межсетевых экранах, VPN-шлюзах и системах управления учетными записями (как минимум, в течение первых 3-6 месяцев эксплуатации SOAR-решения), также рекомендуется проводить контролируемое тестирование интеграций сначала на ограниченном наборе некритичных устройств в нерабочее время. Кроме того, необходимо удостовериться в возможности быстрого отката автоматически вносимых при реагировании изменений.
Несмотря на то, что в некоторых SIEM-системах также есть возможности по автоматизации реагирования, специализированные SOAR-решения имеют следующие отличительные особенности:
- Позволяют собирать кейсы, предупреждения и оповещения от разнообразных источников, включая входящие email-сообщения, инциденты из SIEM, сработки EDR-решений;
- При реагировании предлагают просмотреть похожие инциденты/кейсы, отображают аналитику возможные дальнейшие действия в зависимости от ранее закрытых кейсов, используют методы машинного обучения для связи инцидентов между собой;
- Предоставляют удобный графический редактор для создания сценариев реагирования и настройки автоматизированных действий, что снижает трудозатраты и упрощает работу, при этом в случае необходимости для действий по автоматизации доступна ручная правка;
- Предоставляют единый фреймворк и для разработки, и для использования сценариев реагирования;
- Предоставляют предустановленный набор API и способов интеграции с уже использующимися в компании ИТ/ИБ-системами;
- Предоставляют возможность API-интеграции с новыми или кастомизированными инструментами SOC;
- В отличие от SIEM-систем, платформы SOAR не предназначены для обработки большого потока событий ИБ и управления логами.
6. Защита данных и инструментов SOC.
Авторы публикации указывают, что знание атакующими перечня конкретных используемых технологий мониторинга SOC позволит им либо провести целевую атаку на эти технологии, либо настроить свои инструменты взлома для избежания обнаружения. Таким образом, SOC-центр должен быть, с одной стороны, изолирован от общей ЛВС компании, с другой - получать оттуда информацию, взаимодействовать с ИТ/ИБ-системами, предоставлять отчетность и ситуационную осведомленность сотрудникам компании. Сама по себе работа SOC-центра подразумевает, что рано или поздно в компании-заказчике произойдет кибератака, которая может затронуть в том числе и сам SOC, поэтому в SOC-центре следует руководствоваться принципом "assume breach" (т.е. «предполагайте, что вас взломают или уже взломали»). Одной из рекомендаций авторов публикации является создание отдельного Windows-домена для изоляции инфраструктуры SOC от общей инфраструктуры компании-заказчика, при этом события ИБ должны собираться сенсорам из систем, подключенных к общей инфраструктуре компании. При планировании защищенной архитектуры SOC следует учитывать состояние ландшафта киберугроз компании-заказчика, географическую распределенность его инфраструктуры, используемые методы логической сегментации сети. Также стоит определить, каковы встроенные функции безопасности в инструментах SOC и позволяют ли ресурсы SOC использовать только выделенное собственное оборудование и сетевую инфраструктуру. Авторы публикации подчеркивают, что защите инфраструктуры самого SOC следует уделять самое пристальное внимание, а также дают ряд советов по обеспечению внутренней информационной безопасности SOC-центра.