RRakhmetov 29 сен 2023 в 10:34

Обзор публикации MITRE «11 стратегий SOC-центра мирового уровня». Часть 3

Средний

53 мин

1.9K

Обзор

Коллеги, в двух предыдущих публикациях были рассмотрены стратегии 0-3 и 4-7 документа MITRE «11 стратегий SOC-центра мирового уровня». В сегодняшней публикации завершим рассмотрение данного документа финальным набором рекомендаций MITRE: Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC», Стратегия №9 «Общайтесь, взаимодействуйте, делитесь информацией», Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC», Стратегия №11 «Повышайте эффективность путем расширения функционала SOC». Приступим!

Оглавление:
Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC»

Стратегия №9 «Общайтесь, взаимодействуйте, делитесь информацией»

Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»

Стратегия №11 «Повышайте эффективность путем расширения функционала SOC»

Стратегия №8 «Используйте инструменты автоматизации для обеспечения работы аналитиков SOC»

При работе 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-центра.

Стратегия №9 «Общайтесь, взаимодействуйте, делитесь информацией»

Для повышения эффективности работы SOC-центра важно обеспечить взаимодействие внутри команды самого SOC, а также сотрудничество с работниками компании-заказчика и с внешними организациями. Авторы публикации уверены, что для SOC важно быть частью бизнес-экосистемы компании-заказчика, поэтому при работе SOC важно учитывать приоритеты бизнеса и взаимодействовать с представителями и стейкхолдерами компании-заказчика, предоставляя им ИБ-контекст. Для повышения внутренней ИБ-экспертизы и качества оказываемых услуг SOC-центру важно выстроить взаимодействие как внутри команды, так и с внешним ИБ-сообществом. Процессам выстраивания взаимодействия, сотрудничества, обмена информацией посвящена Стратегия №9.

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

1. Взаимодействие внутри SOC

Прежде всего, требуется выстроить формы коммуникации, взаимодействия, обмена информацией внутри самого SOC. Несмотря на то, что руководители и менеджеры SOC традиционно считаются ответственными за данное направление, важно дать возможность участвовать в данных активностях всем членам команды SOC для наиболее эффективного использования человеческого потенциала внутри SOC. Указанные активности преследуют следующие цели:

Обучение всех сотрудников SOC выполнению должностных обязанностей путем информирования и обмена знаниями;
Передача операционной информации между членами команды SOC;
Создание, планирование и обмен информацией о деятельности SOC;
Совместное решение проблем и задач;
Улучшение обработки обратной связи по работе с инструментами, технологиями, данными, аналитикой SOC для повышения их эффективности.

1.1. Обучение всех сотрудников SOC выполнению должностных обязанностей

Утверждённые процессы и документация помогут обеспечить понятное и логически связанное взаимодействие между членами команды SOC, в частности, такие документы, как сценарии реагирования и стандартизированные операционные процедуры (SOP, standard operating procedure).

1.2. Передача операционной информации между членами команды SOC:

Передача информации между коллегами внутри SOC может осуществляться следующими способами:

Трекинг инцидентов ИБ;
Трекинг аналитики киберугроз, IOC, атакующих;
Статус работы по выявлению киберугроз и их аналитике;
Работы по внедрению и разработке;
Планирование и проведение мероприятий по проактивному поиску киберугроз;
Планирование спринтов, исполнение задач;
Обновление по статусу важных инцидентов и кейсов;
Ежедневные планерки и передачи смены (в больших SOC-центрах могут проводиться общие собрания и отдельные собрания по каждому направлению деятельности SOC);
Ежемесячные или ежеквартальные общие большие встречи, прямое взаимодействие между членами различных команд, тим-билдинги.

1.3. Создание, планирование и обмен информацией о деятельности SOC

Следует соблюдать открытость в предоставлении информации о текущем и планируемом расходовании ресурсов SOC-центром. Для повышения эффективности планирование должно быть открытым для всех членов SOC, добиться чего можно с помощью регулярного планирования, гибкого scrum-планирования, учета и контроля функций SOC, например, с помощью системы показателей с отображением основных функций, возможностей, сервисов SOC и их текущего статуса.

1.4. Совместное решение проблем и задач

Коллективная работа аналитиков над сложными проблемами, совместное реагирование на инциденты и коллективные проактивные действия повышают качество оказываемых SOC услуг и уровень вовлеченности работников. Достигается это совместным анализом и применением инструментов совместной работы, таких как платформы обмена мгновенными сообщениями, решения для совместного использования экрана (screen sharing), системы кейс-менеджмента и управления данными киберразведки, базы знаний (например, Wiki-подобные), инструменты контроля и планирования (например, Jira, AzureDevOps и т.д.). Руководителям SOC-центра необходимо выстраивать благоприятную среду общения и взаимодействия между членами команды, обеспечивать возможность каждому высказывать свои идеи и предложения, получать и предоставлять поддержку от членов команды.

1.5. Улучшение обработки обратной связи по работе с инструментами, технологиями, данными, аналитикой SOC для повышения их эффективности

В случае разделения функций SOC или географической распределенности команд, качество взаимодействия и обмена информацией может снизиться. От руководителей SOC важно получать бизнес-контекст, координирование, поддержку, а отдавать технически точные данные, метрики, отчетность, идеи по улучшению. Внутри SOC следует обмениваться требованиями, идеями, решениями, получать поддержку, обеспечивать непрерывное получение и обработку обратной связи.

2. Взаимодействие со стейкхолдерами и заказчиками

Взаимодействие с заказчиками, включая топ-менеджмент и ИТ-руководителей, и возможность четко выразить задачи и потребности SOC позволят выстроить надежные взаимоотношения между SOC и потребителями его услуг. Взаимодействие на более низком уровне, с конкретными стейкхолдерами, позволит SOC-центру повысить понимание деятельности компании-заказчика и установить прочные взаимосвязи. В данном разделе авторы публикации приводят различные формы взаимодействия с заказчиками, такие как:

Предоставление заказчикам информации об услугах, оказываемых SOC-центром;
Понимание бизнес-процессов и информирование об изменениях;
Информирование о киберрисках в терминах ведения бизнеса и достижения целей;
Получение и предоставление ответов на отчеты об инцидентах;
Предоставление сведений об архитектуре, инструментах, данных, процессах SOC;
Совместное создание и настройка методов обнаружения и аналитики, мониторинг и реагирование на инциденты;
Получение и обработка обратной связи для улучшения работы;
Обучение представителей заказчика.

2.1. Предоставление заказчикам информации об услугах, оказываемых SOC-центром

SOC-центру следует озаботиться созданием информационного ресурса, на котором заказчику будет предоставлена информация о том, что такое SOC и что он делает. С ростом уровня зрелости предоставляемые материалы могут охватывать специфику конкретных функций, описывать уже обработанные SOC-центром масштабные инциденты для повышения значимости SOC в глазах заказчиков. На информационном ресурсе (это может быть внутренний веб-портал, Wiki-страница или SharePoint-сайт) следует указать информацию о том, как и почему SOC защищает заказчиков, как заказчики обеспечивают работу SOC, как обратиться в SOC в случае подозрений на киберинцидент, какие услуги предоставляет SOC, как SOC обеспечивает осведомленность и обучение заказчиков, также рекомендуется привести перечень ВНД, обеспечивающих и санкционирующих деятельность SOC.

2.2. Понимание бизнес-процессов и информирование об изменениях

Как указывалось в Стратегии №1, SOC-центру важно знать, что и почему он защищает - эти знания приобретаются при совместной работе с заказчиками и в дальнейшем дадут возможность согласовать инвестиции SOC-центра и задачи бизнеса, получить ресурсы и поддержку, снизить уровень риска. Вместе с ИБ-специалистами заказчика SOC-центр должен регулярно взаимодействовать с работниками-респондентами (руководителями, менеджерами, линейным персоналом) для обсуждения вопросов инвестиций в ИБ и требований кибербезопасности, текущих и завершенных ИБ-проектов, успехов SOC и важных киберинцидентов в зоне ответственности респондентов, новых киберугроз и рисков ИБ. Члены команды SOC во время таких обсуждений также должны получать информацию об изменениях в бизнесе, которые могут повлиять на деятельность SOC (например, новые бизнес-услуги, реорганизация бизнес-структур), узнавать о восприятии вопросов ИБ и киберрисков респондентами, получать обратную связь о деятельности, планах, инвестициях SOC-центра, а также получать актуализированную информацию об изменениях в IT/OT-ландшафте, облачных и мобильных инфраструктурах для обновления инвентаризационных данных, которые использует SOC. Указанные встречи и обмен информацией должны дополнять, но не заменять регулярные процедуры актуализации данных в SOC. Такие встречи в больших компаниях могут проводиться отдельно с каждым направлением бизнеса, с частотой раз в месяц или раз в квартал.

2.3. Информирование о киберрисках в терминах ведения бизнеса и достижения целей

SOC-центр и Red Team-команды хорошо и глубоко понимают киберриски компании-заказчика с технической стороны, поэтому важно доносить эту информацию до заказчиков с точки зрения влияния рисков на бизнес и выполнения необходимых действий. SOC-центр может сообщать информацию о киберрисках и соответствующих возможных негативных последствиях в виде регулярных оповещениях через email, веб-сайт, на брифингах, с помощью системы метрик и отчетности, предоставляя информацию о киберинцидентах и необходимых пост-инцидентных действиях, с помощью экстренных уведомлений об уязвимостях и необходимости установки обновлений (если управление уязвимостями входит в зону ответственности SOC).

Авторы публикации дают следующие рекомендации по правилам информирования заказчиков, включая отправку уведомлений об уязвимостях:

Подготовьтесь к информированию заранее: разработайте шаблон рассылки и заранее планируйте способ уведомления, составьте корректный список получателей уведомлений (отправляйте информацию об уязвимостях конкретных систем не на всю компанию, а только владельцам систем), заранее свяжитесь с ответственными за системы и за установку обновлений для получения от них обратной связи, корректирования планов устранения уязвимостей и рассылки уведомлений, а также продумайте текст уведомления (он должен быть релевантным и содержать конкретный перечень действий);
Кратко и понятно изложите, что требуется от получателей рассылки: что именно и с какими активами требуется выполнить, в какой срок и почему, предоставьте подробную инструкцию (скачайте обновление с такой-то страницы, обновите такое-то ПО, отключите такой-то компонент/сервис), а также следите за тем, чтобы рассылки и инструкции получали те, кто действительно отвечает за уязвимую систему;
Обеспечьте качество уведомлений: задокументируйте процесс формирования и проверки теста уведомления и его рассылки, обеспечьте точность технических подробностей в рассылке (если в рассылке есть результаты аналитической оценки, укажите её уровень достоверности), а также внимательно отнеситесь к грамматике текста и форматированию уведомления.

2.4. Получение и предоставление ответов на отчеты об инцидентах

SOC-центру следует предоставить заказчикам несколько способов уведомления о вредоносных или подозрительных действиях, например, через форму на сайте, по email (следует выбрать простой и легко запоминающийся email), через техническую поддержку. Указанные способы должны быть известны работникам компании-заказчика, эту информацию можно доводить на awareness-тренингах. Также следует обеспечить отправку уведомления о получении сообщения от сотрудников компании-заказчика, чтобы они знали, что информация получена SOC-центром и принята к обработке. При реагировании SOC-центр будет задавать сотрудникам компании-заказчика уточняющие вопросы и прояснять детали инцидента, поэтому работники должны быть к этому готовы, а у SOC-центра должны быть полномочия для такой деятельности.

2.5. Предоставление сведений об архитектуре, инструментах, данных, процессах SOC

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

2.6. Совместное создание и настройка методов обнаружения и аналитики, мониторинг и реагирование на инциденты

В случае работы SOC-центра с высокотехнологичными компаниями-заказчиками можно рассмотреть вариант более тесного взаимодействия с представителями компании-заказчика, которые обладают достаточной квалификацией для решения совместных задач. Такое взаимодействие поможет лучше понимать контекст работы защищаемых систем, интегрировать системы и сети заказчика в процесс управления киберинцидентами в SOC, более корректно и быстро проводить расследование и реагирование на инциденты. Для обеспечения такой синергии в SOC должны быть ресурсы для взаимодействия с представителями компании-заказчика, технические возможности SOC должны поддерживать такое взаимодействие, представители компании-заказчика должны соблюдать правила работы с инструментами SOC и порядок работы с информацией SOC, цепочка эскалации и уведомления о киберинцидентах не должна меняться, порядок реагирования должен диктоваться SOC и неукоснительно соблюдаться, также следует обеспечить регулярную синхронизацию и обмен информацией между участниками, а ожидания от взаимодействия должны быть понятны обеим сторонам.

2.7. Получение и обработка обратной связи для улучшения работы

В дополнение к регулярному получению обратной связи по инцидентам и по результатам общения со стейкхолдерами заказчика, следует предусмотреть более структурированное и частое получение обратной связи. Это можно реализовать в виде формы обратной связи в тикете по инциденту («оцените, как выполнил свою работу SOC-центр»), а также в виде периодических опросов работников компании-заказчика. Также рекомендуется проводить неформальные встречи со стейкхолдерами для получения обратной связи и обсуждения способов улучшения работы SOC.

2.8. Обучение представителей заказчика

SOC-центр играет важную роль в повышении уровня культуры кибербезопасности в компании-заказчике. Совместно с представителями ИБ-подразделения заказчика, следует предоставлять информацию о вредоносных кампаниях, новых киберугрозах, результатах и «выученных уроков» киберинцидентов, опыте других компаний из того же сектора экономики. В тренингах по киберобучению следует доносить информацию о работе и рекомендациях SOC-центра работникам компании. Также можно приводить примеры успешного выполнения SOC-центром задач по реагированию на киберинциденты, выявлению злоумышленников, аналитике киберугроз, что поможет повысить репутацию SOC-центра.

3. Взаимодействие с ИБ-сообществом

Ни один ИБ-профессионал в мире не может знать абсолютно всего, поэтому для получения новых знаний, актуализации экспертизы, обмена мнениями о технологиях защиты и TTPs атакующих важно взаимодействовать, учиться, обмениваться информацией с представителями других ИБ-компаний, с исследователями и вендорами. При этом важно заранее выстроить отношения с представителями ИБ-сообщества, т.е. до того, как может потребоваться их помощь в критический момент крупного инцидента.

3.1. Обмен информацией и получение знаний

Участие в обсуждениях и обмене опытом на разнообразных площадках поможет SOC-центру быть более информированным и гибким, лучше понимать TTPs атакующих, аналитику киберугроз, способы работы с технологиями. Если на таких площадках SOC получает информацию, которую невозможно получить другим способом, то это говорит об успешно выстроенной модели взаимодействия с сообществом. При этом в крупных SOC-центрах для информирования сообщества может быть выделены соответствующие ресурсы, а само информирование - быть регулярным; небольшие же SOC-центры также могут обладать интересной информацией и должны иметь возможность поделиться ей с сообществом. Для корректного предоставления информации за пределы SOC-центра или компании-заказчика, следует разработать политику распространения информации, которая будет соответствовать юридическим и PR-стандартам и внутренним правилам компании-заказчика. Также следует убедиться, что созданы правила для членов команды SOC по публичному обсуждению деятельности SOC, существует политика проверки контента перед публикацией, юридическая служба, PR-служба и ИБ-руководители компании контролируют процесс, а у членов команды SOC есть возможность и согласование на ведение публичной деятельности.

Взаимодействие возможно и между SOC-центрами напрямую, включая прямые контакты аналитиков разных SOC между собой. Такое общение может начаться при совместном реагировании на общий инцидент или при работе с заказчиками в одном секторе экономики. В дальнейшем, такое взаимодействие может быть формализовано или оставаться неформальным - оба варианта будут полезны для обмена опытом, знаниями, повышения лояльности и чувства сопричастности сотрудников. Взаимодействовать можно также и на базе специально созданных площадок - форумов, объединений, рабочих групп, в том числе сформированных при государственном участии, объединенных по какому-либо признаку (географическое положение, обслуживаемый сектор экономики, используемые типы технологий).

3.2. Совместная работа организаций при реагировании на инциденты

Зачастую некоторые типы крупных киберинцидентов могут быть эффективно решены только при взаимодействии SOC-центров, обслуживающих несколько компаний, затронутых этим инцидентом. Например, при кибератаке на поставщика ПО/оборудования есть риск распространения угрозы на клиентов, поэтому SOC-центру такого вендора будет лучше работать совместно с SOC-центрами его клиентов. При подготовке к отражению инцидентов, которые могут выйти за границы инфраструктуры компании-заказчика, SOC-центру следует актуализировать контактные данные своих контрагентов, партнеров, поставщиков услуг, оборудования, ПО и СЗИ, а также контактную информацию правоохранительных органов и SOC-центров, с которыми налажено взаимодействие.

Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»

Измерение эффективности работы SOC поможет компании-заказчику понять, насколько хорошо SOC-центр выполняет свои задачи, а также выявить сильные и слабые стороны, определить направления для совершенствования. Несмотря на важность выявления приоритетных направлений и измерения эффективности работы в них, по данным авторов публикации, только половина SOC-центров (среди опрошенных институтом SANS) применяют формализованные метрики эффективности, поэтому рекомендации данной стратегии могут быть полезны и новым, и уже зрелым SOC-центрам.

В рамках описания данной стратегии авторы используют следующие термины:

Показатель/метрика: показатель является единичной величиной (например, количество инцидентов в месяц), а метрика может быть комплексной величиной (например, изменение количества инцидентов год к году в процентах);
КПЭ, ключевые показатели эффективности (англ. KPI, Key Performance Indicator): показатели/метрики, которые демонстрируют достижение ключевых бизнес-целей;
Оценка: подход, процесс или способ оценки, в результате чего формируются показатели/метрики.

1. Элементы программы метрик SOC-центра

SOC-центр может оценивать собственную эффективность с помощью программы внутренних метрик SOC, которая позволяет определить, измерить, сформировать отчет о выполнении КПЭ операционных процессов SOC-центра, результатах работы, а также о ситуационной осведомленности компании-заказчика, которую предоставляет SOC. В программе внутренних метрик SOC следует учесть следующие элементы:

Бизнес-цели: причина проведения измерений эффективности работы SOC;
Источники данных и сбор информации: сведения о работе SOC, которые можно использовать для формирования показателей/метрик;
Синтез, анализ данных: формирование метрик на основании полученной информации;
Отчетность: представление метрик стейкхолдерам;
Принятие решений и действия: дальнейшее использование сформированных метрик.

1.1. Бизнес-цели

Бизнес-цели включают в себя обоснование и ожидаемые результаты сбора, анализа данных, формирования отчетности и выполнения дальнейших действий на основании сформированных метрик. Бизнес-цели могут быть внутренними (для внутреннего измерения эффективности SOC), внешними (для предоставления информации об эффективности SOC заказчикам и заинтересованным лицам), для использования вне SOC (оценка киберрисков и состояния ИБ компании-заказчика в целом на основании данных SOC).

1.1.1. Внутренние бизнес-цели

Аудиторией для результатов оценки достижения внутренних бизнес-целей будут аналитики SOC, руководители отдельных SOC-команд и всего SOC в целом. Данные метрики оценивают скорость и качество работы SOC, они достаточно низкоуровневые. Внутренние способы оценки могут использоваться для:

Улучшения эффективности и качества действий аналитиков (мониторинга, выявления, расследований и т.д.);
Контроля качества и стабильности функционирования систем и инструментов SOC-Центра;
Непрерывного улучшения и оптимизации процессов SOC;
Оценки и устранения недостатков в выявлении и предотвращении TTPs атакующих (например, оценивая TTPs в соответствии с матрицей MITRE ATT&CK);
Понимания и оценки готовности SOC-центра к новым целям, функционалу, инструментам, которые планируются к внедрению (например, готов ли SOC-центр к проактивному поиску киберугроз, анализу ВПО, внедрению deception-решения).

1.1.2. Внешние бизнес-цели

Аудиторией для результатов оценки достижения внешних бизнес-целей будут заказчики услуг SOC: руководители, стоящие «над» SOC, управляющий комитет SOC-центра, руководители ИТ-блока, владельцы ИТ-сервисов, а также те, кто оплачивает услуги, предоставляемые SOC-центром. При оценке эффективности также часто используют такие метрики, как SLA и SLO: SLA (Service Level Agreement, соглашение об уровне оказываемых услуг) - это обязательные и утвержденные контрактами и соглашениями показатели, за несоответствие которым могут налагаться штрафы; SLO (Service Level Objective, цель уровня обслуживания) - это показатели, характеризующие работу SOC, обязанность соответствия которым не утверждено юридически. Внешние способы оценки могут использоваться для:

Отражения состояния и уровня готовности SOC-центра к выполнению своих функций в разрезе персонала, процессов, технологий;
Контроля соответствия SLA и SLO ожиданиям потребителей услуг SOC-центра;
Контроля соответствия инфраструктуры заказчиков требованиям по кибербезопасности;
Демонстрации окупаемости затрат в кибербезопасность.

1.1.3. Бизнес-цели для использования вне SOC

Аудиторией для результатов оценки достижения бизнес-целей вне SOC будут различные работники компании-заказчика, в частности, владельцы ИТ-сервисов и руководители компании. Способы оценки достижения бизнес-целей вне SOC могут использоваться для:

Контроля прогресса внедрения мер защиты информации;
Эффективность результатов применения мер защиты информации;
Влияние работы SOC на бизнес компании-заказчика, включая отчетность по инцидентам, отработанным в SOC;
Вклад SOC в общие показатели кибербезопасности и киберрисков компании-заказчика.

1.2. Источники данных и сбор информации

При реализации программы метрик SOC-центр может использовать данные, которые уже либо обрабатываться в системах самого SOC, либо приходят от других подразделений компании. Источниками данных могут быть:

Системы Log Management и SIEM, аналитические платформы;
Тикетинг-системы, системы кейс-менеджмента, SOAR-платформы;
Репозитории SOC-центра, системы управления задачами для DevOps;
Системы контроля за расходованием бюджета SOC-центра;
Системы управления активами;
Системы управления уязвимостями и сканированиями на наличие уязвимостей;
Платформы эмуляции кибератак.

Для оценки эффективности SOC можно также использовать следующие способы формирования данных для анализа:

Результаты проведения учений и эмуляций кибератак: тренировки, учения, эмуляция реагирования на критичные инциденты помогут оценить, как SOC будет вести себя в «боевых» условиях и оценить качество процессов, коммуникации, действий по реагированию;
Фокусные технические оценки эффективности: проведение мероприятий Red/Purple Team, использование специальных платформ эмуляции кибератак помогут оценить опасность актуальных киберугроз и проверить реагирование на них;
Использование фреймворков для оценки зрелости SOC: комплексная оценка персонала, процессов и технологий SOC-центра поможет составить более целостную картину состояния SOC; такую оценку можно проводить с применением открытых фреймворков (например, с помощью NIST Cybersecurity Framework или SOC-CMM).

1.3. Синтез, анализ данных

Для формирования отчетности на основании собираемых данных авторы публикации рекомендуют использовать повторяемый и автоматизируемый процесс, при этом результаты анализа данных должны формироваться как регулярно, в соответствии с заданным расписанием, так и по запросу. Следует максимально автоматизировать и упростить анализ данных, основываясь на агрегированной и предварительно обработанной информации. Результатом анализа должны стать понятные и действенные сведения.

1.4. Отчетность

Следует определить формат и целевую аудиторию для формируемой отчетности. Авторы рекомендуют:

Учитывать аудиторию и время: в результате получения отчетов об эффективности работы SOC могут быть приняты политические, финансовые или технические решения, поэтому для каждой группы получателей можно формировать максимально понятный ей отчет, включая в него небольшое количество самых релевантных показателей, а не перегружать читателей обилием метрик;
Учитывайте возможность дальнейшей работы с отчетностью: метриками и отчетностью смогут обмениваться различные сотрудники компании, поэтому наряду с отчетом следует приводить и использовавшуюся методологию. Кроме того, следует быть готовым к необходимости предоставить доступ к «сырым» техническим данным, на основании которых отчетность была сформирована;
Используйте формат, принятый у заказчика: для построения отчетности рекомендуется использовать инструменты, с которыми работает компания-заказчик и которые позволяют автоматизировать обновление данных в отчете;
Используйте визуализацию: применение средств визуализации поможет лучше донести информацию до аудитории.

1.5. Принятие решений и действия

Результатом применения информации, собранной, проанализированной и сформированной на предыдущих этапах, должно стать принятие решений или выполнение некоторых действий. Результатом может стать как действие (изменение в работе SOC), так и бездействие (в случае, если метрики показывают, что SOC функционирует в соответствии с целевыми значениями). В случае внесения изменений в работу SOC-центра по результатам формирования метрик эффективности, следует предусмотреть также дальнейший анализ показателей, которые продемонстрируют результативность вносимых изменений.

2. Использование услуг сторонней организации для оценки работы SOC

Авторы публикации указывают, что для реализации некоторых элементов программы метрик SOC-центра может потребоваться помощь сторонней организации для оценки эффективности. Независимая внешняя экспертиза оценит состояние SOC-центра свежим взглядом, поможет выявить незамеченные ранее сложности, сможет привлечь для оценки дефицитных специалистов, а также позволит удовлетворить нормативные требования. Самым логичным вариантом будет привлечение другого SOC-центра для проведения независимой экспертизы эффективности: это может быть SOC, с которым установлены партнерские отношения, координирующий SOC или национальный SOC; такие SOC-центры часто предлагают подобные услуги, у них может быть уже разработана методология оценки эффективности и присутствовать понимание контекста деятельности SOC. Кроме того, можно обратиться к специализированным консалтинговым компаниям, у которых есть соответствующий опыт и фреймворки для проведения оценки. В случае проведения независимой оценки деятельности SOC-центра со стороны сторонней организации, следует обеспечить корректную передачу запрашиваемой информации, наладить сотрудничество работников SOC и представителей оценивающей организации, а также обеспечить защиту передаваемой вовне информации и обеспечить юридическое обеспечение проведения оценки, например, с помощью подписания соглашения о неразглашении.

3. Примеры метрик оценки эффективности SOC

В публикации приводятся следующие советы и рекомендации по применению метрик оценки эффективности SOC:

Не все метрики применимы ко всем SOC-центрам и во всех ситуациях: следует ориентироваться на размер и задачи SOC для выбора применимых метрик оценки эффективности;
Некоторые метрики могут быть технически невыполнимы в определенных случаях и в определенных SOC;
Адаптируйте используемые метрики для целевой аудитории: разные лица могут быть заинтересованы в получении различных метрик, при этом могут возникнуть сложности в случае использования метрик, которые будут непонятны тому, кто не работает непосредственно в SOC-центре;
Следует использовать компенсирующие меры контроля для метрик, с которыми могут производиться манипуляции («читинг») со стороны сотрудников SOC-центра;
Используйте расчет медианных значений и процентилей: такой расчет поможет снизить влияние редких событий, выбивающихся из общего ряда, что позволит получить более объективные сведения;
Применяйте градацию метрик: целевые значения метрик могут быть строже для высокоприоритетных заказчиков в зависимости от уровня риска, критичности и нормативных требований.

3.1. Примеры метрик для оценки достижения внутренних бизнес-целей

Состояние «здоровья» инструментов и технологий SOC;
Состояние «здоровья» источников данных;
Задержка данных при обработке инструментами SOC;
Охват матрицы MITRE ATT&CK средствами обнаружения;
Соотношение ложноположительных и истинноположительных предупреждений / инцидентов;
Скорость разработки правил обнаружения и их количество;
Соотношение инцидентов, обработанных аналитиком по сценариям с помощью средств автоматизации, к инцидентам, обработанных аналитиком вручную;
Объем предупреждений / инцидентов, эскалированных в результате триажа на следующий уровень, которые были затем закрыты как истинноположительные инциденты;
Объем предупреждений / инцидентов, по которым не проводилось дальнейшее реагирование;
Время, затраченное аналитиками на рутинные операции;
Время, затраченное аналитиками на работу с программой метрик.

3.2. Примеры метрик для оценки достижения внешних бизнес-целей

Уровень готовности SOC к выполнению своих задач;
Медианное/среднее время выявления инцидента (от момента первичного проникновения атакующих в инфраструктуру до момента их выявления);
Медианное/среднее время реакции SOC на обращение заказчика (с помощью заявки, звонка, email о подозрении на инцидент);
Медианное/среднее время реагирования на инцидент (от момента выявления кибератаки до выполнения действий по активному реагированию);
Медианное/среднее время сдерживания угрозы (оценка масштаба атаки и блокирование дальнейшего распространения; с помощью технологий автоматизации реагирования можно добиться значительного снижения данного показателя);
Медианное/среднее время устранения угрозы (очистка инфраструктуры от присутствия атакующих);
Назначение владельцев для активов (следует стремиться к 100% охвату для всех типов активов и используемых инфраструктур);
Управление активами (следует стремиться к 100% охвату процессом управления активами, включая управление конфигурациями и патч-менеджментом, для всех типов активов и используемых инфраструктур);
Охват сканирования (следует стремиться к 100% процентному охвату активов процессом сканирования на наличие уязвимостей);
Охват мониторинга (следует стремиться к 100% процентному охвату активов процессом ИБ-мониторинга);
Глубина мониторинга (процент охвата мониторингом активов на аппаратном, системном, прикладном уровне, учитывая также полноту мониторинга по матрице MITRE ATT&CK);
Распределение количества инцидентов по заказчикам;
Распределение количества инцидентов по атакующим (если они были установлены).

3.3. Примеры метрик для оценки достижения бизнес-целей для использования вне SOC:

Установка обновлений безопасности (целевым значением может быть 90% активов, пропатченных в течение 7 дней для стандартной процедуры);
Неустановленные обновления безопасности (обновления доступны, но не установлены по разным причинам; целевым значением должно быть отсутствие таких явлений, если только этот риск не был корректно обработан);
Присутствие ПО с истекшим (end-of-life) сроком эксплуатации (целевым значением должно быть отсутствие таких явлений, если только этот риск не был корректно обработан);
Утилизация ИТ-ресурсов (загрузка аппаратных мощностей, использование ПО);
Выполнение тренингов по ИБ;
Результаты учебных фишинговых рассылок (процент пользователей, перешедших по ссылке в учебной фишинговой рассылке (цель - менее 5%), и сообщивших о полученной рассылке (цель - более 50%));
Использование и корректность работы СЗИ (например, охват инфраструктуры установленными и обновленными антивирусами, средствами проверки подписи исполняемого кода, с целевым значением 100%);
Использование высокорисковых сервисов (использование в инфраструктуре сервисов с известными уязвимостями или доступными из интернет);
Использование высокорисковых учетных записей (использование постоянных учетных записей с административными привилегиями).

В заключении авторы публикации указывают, что зачастую важно измерять не абсолютные значения метрик, а обращать внимание на тенденции и изменения (например, изменения месяц к месяцу, год к году) - это позволит не только контролировать и своевременно корректировать процессы на операционном и тактическом уровнях, но и оценивать эффективность SOC и состояние кибербезопасности компании на стратегическом уровне. Кроме того, применение метрик оценки эффективности SOC может привести к негативным результатам, например, к погоне аналитиков SOC-центра за выполнением KPI, к формализации работы ради хороших показателей, к боязни ошибок и отсутствию творческой составляющей, к недостаточно глубокому рассмотрению сложных кейсов. Для предупреждения таких последствий следует обсуждать с командой SOC-центра внедрение каких-либо метрик, избегать «читерства» с метриками, не перегружать команду большим количеством показателей, а также использовать метрики не для наказания, а для выявления слабых сторон и улучшения работы SOC-центра.

Стратегия №11 «Повышайте эффективность путем расширения функционала SOC»

Злоумышленники непрерывно совершенствуют свои TTPs, скрывают свою присутствие и разрабатывают новые инструменты, и для эффективного мониторинга и реагирования на киберинциденты SOC-центры должны непрерывно совершенствоваться. Базовые функции по выявлению кибератак, реагированию, аналитике киберугроз могут быть в некоторых случаях недостаточны, поэтому SOC-центр может принять решение о расширении своего функционала, который будет соответствовать актуальным киберугрозам и потребностям заказчика. Таким расширенным функционалом может быть проактивный поиск киберугроз (англ. threat hunting), проведение тестирований Red/Purple Team, использование платформ эмуляции кибератак (BAS-системы) и Deception-решений («ловушки»), использование форензики, проведение штабных киберучений.

1. Поиск киберугроз (Threat Hunting)

Проактивный поиск киберугроз является одной из главных дополнительных функций SOC, которую можно начать развивать, достигнув зрелости в процессах реагирования на инциденты и в аналитике киберугроз (Cyber Threat Intelligence). Поиск киберугроз фокусируется на поиске новых или ранее невыявленных атакующих, которые уже скрытно присутствуют в инфраструктуре. Иными словами, поиск киберугроз - это проактивный поиск вредоносных или подозрительных действий в сетях, системах, данных, которые не удалось выявить существующими стандартными ИБ-инструментами и способами. При поиске киберугроз аналитики руководствуются принципом "Assumed Breach", который означает буквально: «Считайте, что вас уже взломали». Это подразумевает создание и проверку определенных гипотез о действиях атакующих, которые уже могли ранее незаметно проникнуть в инфраструктуру, на основании опыта аналитиков и известных TTPs киберпреступников, в том числе с применением форензики. Для работы аналитикам по поиску киберугроз потребуется работать с ИБ-данными, которые обрабатывает SOC-центр, контролировать сработки СЗИ и обрабатываемые инциденты ИБ, работать с аналитикой киберугроз, а также понимать контекст и бизнес-процессы заказчика и знать, что является отклонением от штатной работы инфраструктуры и нормальных бизнес-операций.

Для эффективной реализации функции поиска киберугроз SOC-центр должен обладать определенным уровнем зрелости: корректно и оперативно обрабатывать киберинциденты, получать полные и точные данные от сетевых и хостовых устройств, «видеть» всю инфраструктуру. Причинами, по которым SOC-центр может решить начать вести поиск киберугроз, могут быть недостаточность имеющихся средств и способов выявления атак, данные киберразведки об интересе киберпреступников к компании-заказчику, необходимость расширить текущие процедуры реагирования с помощью дополнительной аналитики. Целесообразность инвестиций в поиск киберугроз можно оценить с точки зрения затрат на возможное восстановление «с нуля» всей инфраструктуры компании, если атакующие глубоко закрепились в ней и не были выявлены на более ранних этапах. При этом нужно осознавать, что поиск киберугроз не должен быть бесконечным блужданием по ИБ-данным в надежде обнаружить что-то важное: должны быть обозначены конкретные цели, определена гипотеза, а также разработан план выполнения, включающий в себя подготовку, выполнение, завершение операции по поиску киберугрозы. Кроме того, поиск киберугроз может только дополнить, но не заменить обычное реагирование на киберинцидент.

1.1. Подготовка к поиску киберугроз

Подготовка должна включать в себя разработку документа - программы поиска киберугроз, в котором будут указаны ожидаемые результаты, ресурсное обеспечение, правила проведения, полномочия и согласование от руководителей SOC-центра. Нужно также определить, в каких случаях допустимо вести наблюдение за атакующими в инфраструктуре, без выполнения действий по активному реагированию. При подготовке к проведению операций по поиску киберугроз следует:

Разработать гипотезу поиска киберугроз на основе идей и обратной связи от членов команды SOC, используя матрицу MITRE ATT&CK и составляя предположения о целях, TTPs и возможных действиях атакующих;
Распланировать и приоритизировать активности в зависимости от вероятности реализации киберугроз и задач SOC;
Определить доступные ресурсы, включая сотрудников, системы, инструменты, а также рассмотреть возможное привлечение партнеров.

1.2. Выполнение операций по поиску киберугроз

Каждая операция по поиску киберугроз должна быть структурирована примерно следующим образом:

План операции, включая разработанную гипотезу, цели, границы, время проведения операции, а также необходимые для проведения операции источники ИБ-данных;
Получить доступ к данным и собрать необходимую информацию;
Провести анализ собранной информации, выполнив несколько итераций, записывая полученные результаты в структурированном формате, пригодном для совместной работы;
Запланировать и проводить периодический анализ данных для обеспечения непрерывного поиска киберугроз с помощью доступного инструментария SOC-центра (например, в SIEM, SOAR, платформе обработки Big Data);
Произвести реагирование на выявленную киберугрозу или передать данный кейс команде реагирования;
Регулярно сообщать результаты операций руководителям SOC-центра и синхронизировать действия между собой (внутри команды аналитиков по поиску киберугроз).

Авторы публикации приводят несколько рекомендаций для успешного выполнения операций по поиску киберугроз:

Сфокусируйтесь на определенной гипотезе;
Будьте любопытными и любознательными, обращайте внимание на мелочи;
Инвестируйте в людей, выделяйте им ресурсы и время на поиск киберугроз;
Старайтесь воспринимать каждую новую операцию по поиску киберугроз «с чистого листа», не полагаясь только лишь на предыдущий опыт;
Выстраивайте доверительные отношения с работниками компании-заказчика для получения от них информации и знайте, что является нехарактерным в поведении систем и бизнес-процессов;
Разрабатывайте гипотезы и сценарии вероятных атак с учетом ранее происходивших инцидентов, данных киберразведки, TTPs из матрицы MITRE ATT&CK, предупреждений и трендов SOC-центра, информации из внешних источников (блоги, социальные сети), а также на основании предположений о потенциальном интересе злоумышленников к определенным активам и данным компании.

1.3. Завершение операций по поиску киберугроз (пост-поисковые действия, англ. Post-Hunt Activities)

При завершении операции по поиску киберугрозы, вне зависимости от того, были ли найдены атакующие или нет, следует сообщить результаты операции и выводы заинтересованным лицам (другим аналитикам, руководителям SOC-центра, сотрудникам ИБ-департамента, заинтересованным стейкхолдерам). Следует сообщить информацию о выявленных недостатках в системе обеспечения ИБ и предложить пути улучшения состояния киберзащищенности, включая общую кибергигиену, процессы управления уязвимостями и реагирования на киберинциденты в SOC (включая перенастройку источников ИБ-данных, правил корреляции, сценариев реагирования).

2. Red Team тестирования

Еще одним способом проактивного тестирования и улучшения мер защиты в SOC является проведение Red Team тестирований, которые представляют из себя выполнение действий, характерных для атакующих, с использованием соответствующих TTPs, которые применяются в реальных кибератаках, для проверки корректности и эффективности реагирования персонала, процессов, технологий SOC. Отличие Red Team тестирований от тестирований на проникновение в том, что пен-тесты проводятся в отношении какой-либо технологии с применением определенного шаблона, а Red Team тестирования, как правило, более комплексные и ресурсоемкие, поскольку они могут включать в себя отработку нескольких сценариев атак и разные векторы (включая социальную инженерию и проникновение на территорию компании-заказчика). Кроме того, зачастую SOC-центры не оповещаются о проведении Red Team тестирований для соблюдения «чистоты эксперимента», а сами тестирования подразумевают имитацию действий атакующих (включая TTPs APT-группировок) и реальной кибератаки для проверки выявления, анализа, реагирования на неё. Преимущества проведения Red Team тестирований следующие:

Повышение качества защиты и мониторинга в результате тестирований, и, как следствие, повышение затрат реальных атакующих на преодоление улучшившейся защиты;
Повышение точности и сокращение времени выявления угрозы как следствие анализа выявленных в результате тестирования ложноположительных и ложноотрицательных срабатываний;
Выявление слабых мест в обнаружении возможного повышения привилегий и горизонтального перемещения атакующих и, как следствие, улучшение защитных механизмов;
Выявление и демонстрация недостатков в обеспечении кибербезопасности.

При проведении Red Team тестирований можно либо привлекать экспертов SOC-центра, либо воспользоваться услугами сторонней компании. Оба варианта имеют свои преимущества: члены команды SOC-центра смогут по-новому взглянуть на защищаемую инфраструктуру и СЗИ, которые постараются обойти, эмулируя действия продвинутого атакующего, а сотрудники сторонней компании не будут иметь знаний об инфраструктуре и смогут пойти нестандартным путем при проведении тестовой кибератаки. В обоих вариантах, важно будет учесть следующее:

Планирование: выделение ресурсов и времени на проведение Red Team тестирований с учетом возможностей Red Team и SOC-центра, а также с учетом оценки риска причинения реального ущерба инфраструктуре компании в результате тестирования;
Устранение конфликтов: определение способа отнесения события к настоящему инциденту или к действиям Red Team;
Эскалация: определение того, как и когда Red Team-инцидент может быть эскалирован на руководителей для управления и выделения ресурсов;
Выделение ресурсов: выделение достаточных ресурсов для Red Team и для SOC-центра и определение соотношения между ними.

Для повышения эффективности проведения Red Team тестирований, авторы публикации приводят следующие советы:

Определите доверенное лицо, которое будет знать о проведении Red Team тестирования: это может быть руководитель SOC-центра или директор по ИТ, который сможет остановить тестирование в случае нанесения ущерба компании или при необходимости перенаправить ресурсы SOC-центра на реагирование на реальный инцидент;
Выбирайте реалистичные сценарии тестовых кибератак, учитывая бизнес-процессы и инфраструктуру компании-заказчика, а также ранее случавшиеся реальные кибератаки;
При развитии функционала Red Team тестирований, начинайте с простых сценариев, постепенно переходя к более сложным;
Определяйте заранее границы и критерии успеха тестирования, не допускайте размытия границ проекта тестирования, старайтесь формулировать критерии успеха тестирования так, чтобы для демонстрации результата не требовалось выполнять деструктивных действий и наносить реальный ущерб;
После проведения Red Team тестирования следует устранить его последствия (откатить изменения, удалить артефакты и установленное Red Team-командой ПО и т.д.);
Выделяйте время на анализ выученных уроков, полученных в результате тестирования, делайте выводы, улучшайте меры защиты.

3. Purple Team тестирования

При проведении тестирований защищенности компании-заказчика команда Red Team выступает в роли «нападающих», выполняя действия, характерные для TTPs атакующих, а команда Blue Team «защищается», стремясь выявить и предотвратить атаку Red Team. При этом в случае совместной работы членов команд Red Team и Blue Team такое тестирование называется Purple Team, при котором одновременно проводятся мероприятия и по нападению, и по защите, а в результате такой коллаборации и защитники, и нападающие вместе учатся и повышают свои навыки.

Задачей Purple Team тестирования является улучшение защиты компании-заказчика от действий атакующих, включая повышение качества выявления, реагирования, предотвращения киберугроз с помощью обработки обратной связи об эффективности сценариев реагирования и конфигураций средств защиты. При этом следует руководствоваться подходом, обеспечивающим непрерывное проведение Purple Team тестирований, постоянное взаимодействие и обработку обратной связи. В отличие от Red Team, при проведении Purple Team тестирований осуществляется непрерывное взаимодействие членов команд атакующих и защитников (Red и Blue Team), в рамках которого Blue Team точно знает, что, где и как выполняет команда Red Team. При этом авторы публикации рекомендуют при каждом тестировании проверять только один или несколько наборов TTPs атакующих для более точной оценки корректности защитных мер и их донастройки.

Команды Purple Team могут работать следующим образом:

Тестирование Red Team одной системы или некоторого сегмента инфраструктуры под наблюдением членов Blue Team для оценки эффективности мер защиты (инструментов, сенсоров, аналитики);
Члены Blue Team в интерактивном режиме наблюдают за каждым действием, выполняемым членами команды Red Team;
Открытое проведение оценки наличия уязвимостей и эмуляция действий атакующих, при которых Red Team останавливается на каждом этапе тестирования, а Blue Team анализирует выполненные действия;
Тестирование систем, находящихся в промышленной эксплуатации, с эмуляцией действий определенной киберпреступной группировки;
Использование платформ эмуляции кибератак для совместной работы Red Team и Blue Team.

4. Платформы эмуляции кибератак

Проведение пен-тестов, тестирований Purple Team и Red Team, оценок уязвимостей достаточно ресурсозатратно, при этом многие TTPs атакующих бывает сложно точно воспроизвести. Для проведения регулярных автоматизированных оценок защищенности компании можно использовать решения класса BAS (англ. Breach and Attack Simulation, платформы эмуляции кибератак), обеспечивающие повторяемый, измеримый, масштабируемый процесс тестирования корректности работы мер защиты. Выполнение BAS-тестирований производится в отношении определенных хостов, сетей, систем компании, при этом BAS-платформы должны поддерживать тестирование различных TTPs атакующих в соответствии с матрицей MITRE ATT&CK. Причинами внедрения платформ эмуляции кибератак могут быть отсутствие или недостаточное ресурсное обеспечение Red Team, потребность в автоматизации действий по проведению регулярных тестирований действий атакующих, необходимость оценки охвата матрицы MITRE ATT&CK текущими силами и средствами SOC-центра, необходимость оценки эффективности реализации мер защиты вне SOC (например, ИБ-департаментом).

Платформы эмуляции кибератак могут обладать следующими характеристиками:

Охват TTPs атакующих в BAS-системе, например, на основе охвата матрицы MITRE ATT&CK;
Релевантность, функционал тестирования, частота обновлений: TTPs, заложенные в BAS-решении, должны регулярно обновляться, соответствовать типам активов и систем, которые используются в компании, а сами BAS-платформы должны обладать функционалом тестирования различных типов систем (базы данных, веб-сервера, приложения, облачные сервисы и т.д.);
Предустановленные сценарии тестирования: BAS-решения должны позволять объединять различные вектора атак и TTPs для более полной проверки, а также позволять эмулировать действия конкретных релевантных APT-групп;
Прозрачность работы и расширяемость: BAS-решения должны предоставлять полную информацию о выполняемых действиях и применяемых TTPs при эмуляции атак, эти TTPs должны быть кастомизируемыми и должны соответствовать потребностям SOC (например, эмулировать только отдельные действия атакующих или всю цепочки атаки полностью);
Снижение рисков: должно быть предусмотрено логирование выполняемых BAS-платформой действий, "откат" всех внесенных в рамках атаки изменений в инфраструктуре (например, восстановление настроек систем, учетных записей в исходное состояние), возможность экстренной мгновенной остановки BAS-тестирования, а также должна быть обеспечена надежная защита самой BAS-платформы.

Авторы публикации приводят следующие рекомендации для успешного внедрения BAS-решения:

Совместное использование BAS-платформы SOC-центром, командами Red / Blue Team, пен-тестерами;
Постепенное начало эксплуатации: следует начинать применять BAS-решение с небольшого количества некритичных активов в тестовой среде для проверки надежности и безопасности работы решения;
Обеспечение безопасности тестирования: следует разработать и утвердить правила проведения и завершения BAS-тестирований, а также порядок обработки нештатных ситуаций;
Обеспечение релевантности тестовых атак инфраструктуре и актуальным для компании-заказчика киберугрозам: следует выбрать реалистичные сценарии тестирования, подходящие для компании-заказчика, которые обеспечивают проверку реально используемых мер защиты;
Выбирайте тестовые устройства для проверки средств выявления и предотвращения на них: BAS-решения могут помочь командам SOC-центра, Red Team, Purple Team в настройке средств защиты для реагирования на тестовые атаки, проведенные с помощью BAS;
Оценивайте применимость полученных результатов ко всей инфраструктуре: проведя BAS-тестирование на ограниченном наборе устройств, следует сделать обоснованные выводы о том, репрезентативны ли данные результаты для всех устройств в инфраструктуре компании-заказчика;
Продолжайте использовать сканеры уязвимостей: BAS-решения не могут заменить сканеры уязвимостей, т.к. сканеры тестируют значительно большее количество уязвимостей и конфигураций, чем BAS-платформы;
Согласуйте с юристами использование BAS-инструментов для обеспечения соответствия законодательству: следует знать, можно ли использовать выбранное BAS-решение для проведения внутренних аудитов и тестирований в целях подтверждения соответствия законодательству;
BAS-платформы не заменяют членов команд Red Team: некоторые проверки могут быть выполнены только вручную, а BAS-решения лишь автоматизируют определенные действия, не замещая экспертизу сотрудников.

5. Deception-решения («ловушки»)

Deception-решения («ловушки») применяются для сокрытия реальных объектов инфраструктуры компании, запутывания атакующих и направления их «по ложному следу». Кроме того, можно использовать Deception-платформы для проактивного поиска киберугроз, заманивая атакующих в контролируемую среду и позволяя им «украсть» поддельные данные (приманки), движение которых можно будет затем отследить: например, позволив атакующим «украсть» специально созданные тестовые учетные данные, можно будет затем отследить попытки их применения или публикации и сделать соответствующие выводы. Таким образом, Deception-платформы могут дополнять другие методы обнаружения атак (сигнатурные и на основании выявления аномалий) и предоставлять SOC-центрам ценную информацию для выявления скрытой вредоносной активности. Deception-решения позволяют автоматизированно «раскидать» приманки по инфраструктуре компании, анализировать действия, выполняемые атакующими, контролировать их перемещение между приманками. В отличие от классических Honeypot/Honeynet-технологий, Deception-системы позволяют автоматизировать создание и контроль приманок, направлять по ложному следу атакующих, обеспечивать проактивный поиск и анализ киберугроз. Приманки могут представлять их себя:

Поддельные учетные записи, документы, файловые «шары», размещенные на определенном устройстве;
Поддельные системы, сервисы, серверы, которые на первый взгляд неотличимы от настоящих, но оснащены технологиями «песочниц» для контроля и анализа действий атакующих;
Поддельные объекты Active Directory, которые могут заинтересовать атакующих;
Периметровые приманки, похожие на настоящие веб-сервисы, для отвлечения атакующих путем наведения их на ложные цели.

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

Четко определить конечные цели применения решения, например, воспользовавшись фреймворком MITRE Engage;
Выбрать подходящее Deception-решение: авторы публикации рекомендуют использовать коммерческие продукты в целях упрощения создания Deception-инфраструктуры и "приманок", особенно если SOC-центр только начала вести работу в Deception-направлении;
Стараться воспроизводить близкие к реальным элементы инфраструктуры в рамках Deception-проекта: «приманки» и Deception-объекты должны меняться со временем и создавать видимость работы пользователей с ними, как если бы они были настоящими;
Обеспечивать контроль и мониторинг созданной Deception-инфраструктуры для предотвращения «побега» атакующих из контролируемой среды.

6. Анализ ВПО

В своей работе SOC-центры регулярно сталкиваются с подозрительными файлами, которые требуется проанализировать для понимания возможных вредоносных действий и последствий. С ростом зрелости SOC-центра функционал локальных и облачных антивирусов становится недостаточным, поэтому появляется потребность в развитии внутренней функции по анализу ВПО. Целями анализа ВПО могут быть:

Исследование образцов ВПО для понимания вектора атаки и вероятных целей, что может привести аналитиков к уже известным семействам ВПО или киберпреступным группам;
Исследование функционала ВПО и его поведения, включая методы закрепления и обеспечения скрытности, а также способы связи с командным центром атакующих (сервером "Command and Control", сокращенно C&C или C2-сервером);
Обогащение информацией о ВПО данных по текущему инциденту и накопление базы знаний о киберугрозах, вредоносных кампаниях и кибергруппах для дальнейшего улучшения качества реагирования и проактивного поиска киберугроз.

Анализ ВПО, проводимый силами SOC-центра, повышает вероятность выявления и противодействия атакующим, поскольку результаты анализа специфичны для компании-заказчика. Кроме того, SOC-центр, обладающий хорошими компетенциями по анализу ВПО, может оказывать неоценимую помощь ИБ-сообществу и предоставлять более качественные услуги по расследованию киберинцидентов. Глубокий анализ ВПО собственными силами поможет SOC-центру понять следующее:

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

Для успешной реализации внутренней функции SOC-центра по анализу ВПО, авторы публикации рекомендуют следующее:

Оцените потребность SOC-центра во внутреннем анализе ВПО, оцените, насколько часто SOC сталкивается с неизвестными и сложными образцами ВПО;
Оцените уровень возврата инвестиций во внутреннюю функцию анализа ВПО, являющуюся достаточно ресурсоемкой для SOC-центра;
Наладьте взаимодействие вирусных аналитиков с членами команды реагирования на инциденты, с аналитиками киберугроз и аналитиками Threat Hunting в SOC-центре, а также с другими SOC-центрами и ИБ-сообществом;
Поддерживайте инициативы по публикации аналитиками статей о результатах исследования ВПО - это поможет не только повысить репутацию SOC-центра среди сообщества и клиентов, но и удержать персонал и привлечь новые таланты;
Создайте выделенную инфраструктуру для анализа ВПО, обеспечьте ее защиту, а также предоставьте вирусным аналитикам свободу в выборе инструментов и способов анализа;
Задокументируйте полномочия, общие процедуры и правила анализа ВПО в SOC-центре.

7. Форензика

Применение форензики (компьютерной криминалистики) в SOC-центре может быть востребовано для проведения расследований киберинцидентов, а также для привлечения нарушителей к ответственности по нормам законодательства. В случае серьезного инцидента следует привлечь юридический отдел для определения необходимости сбора юридически значимых доказательств с использованием строго определенных методов и инструментов. Форензика может производиться с оперативной памятью, жестким диском (анализ операционной системы и файлов), сетевым трафиком, мобильными устройствами, облачными хранилищами, а также данными различного формата. Факторами успеха в создании внутренней функции компьютерных криминалистических исследований в SOC-центре, по мнению авторов публикации, являются:

Оцените цели проведения форензики: будет ли форензика использоваться только для поддержки расследования киберинцидентов внутри SOC-центра или рассматриваются варианты использования собираемых данных в суде;
Получите необходимые полномочия для проведения форензик-анализа, задокументируйте процессы проведения форензик-анализа;
Учтите, что исследуемые данные могут содержать нелегальный или травмирующий контент, поэтому минимизируйте возможное негативное влияние полученной информации на аналитика;
Учтите, что форензика - это нишевый раздел ИБ-экспертизы, поэтому не допускайте формирования точки отказа в виде одного-единственного форензик-аналитика в SOC-центре;
Приготовьтесь к резкому росту нагрузки на форензик-функцию в случае крупного инцидента: назначьте ответственного за приоритизацию и контроль форензик-анализа, установите разумные границы окончания проведения форензик-анализа, наладьте взаимодействие со сторонними партнерами (MSS-провайдером, другим SOC-центром, интегратором) для возможности быстрого их привлечения.

8. Проведение штабных киберучений

В условиях ограниченных временных и человеческих ресурсов для проверки готовности к реагированию на киберинциденты можно проводить штабные киберучения (англ. tabletop exercises), на которых присутствующие ответственные члены ИБ-команды пошагово проходят по документам (политикам, сценариям, процедурам реагирования) и проверяют понимание своих действий и готовность к их выполнению. Во время проведения штабных киберучений не проводится полный технический анализ тестового инцидента, проводится умозрительная оценка готовности членов команды к выполнению своих действий (например, к поиску контактов ответственных, к использованию инструментов и средств защиты). Проведение штабных киберучений будет полезным для достижения следующих целей:

Понимание всеми участниками процесса реагирования своих действий, оповещение участников о возможных инцидентах и требованиях по взаимодействию с ИБ-командой;
Повышение и актуализация знаний ответственных лиц о своих ролях и обязанностях;
Выявление недостатков в процессах реагирования и ресурсном обеспечении (сотрудники, информация, инструменты);
Выявление возможных сложностей, которые могут возникнуть у участников при реагировании на реальные инциденты.

Для успешного проведения штабных киберучений следует разработать реалистичные сценарии тестовых кибератак, заранее подготовить план проведения учений, пригласить всех вовлеченных в процесс реагирования сотрудников, а также сделать процесс киберучений интересным и максимально приближенным к боевому реагированию. Проведение штабных киберучений полезно тем, что такие упражнения позволяют всем участникам процесса реагирования, даже тем, кто не погружен в ИБ глубоко (например, юристы, PR, руководители), проверить свои знания и повысить уровень готовности к выполнению действий в случае реальной кибератаки. Кроме того, авторы приводят следующие рекомендации для успешного проведения штабных киберучений:

Следует выбрать ответственного за организацию штабных киберучений (выбор сценариев, приглашенных лиц, выбор места и времени, логистика);
Следует выбрать ответственного за проведение штабных киберучений (взаимодействие со всеми участниками, запуск сценариев, модерация);
Давайте участникам штабных киберучений новые вводные по ходу проведения занятия для большей динамичности сценария;
Определите объем и границы штабных киберучений в зависимости от аудитории, которая будет на них присутствовать, а также контролируйте действия, выполняемые участниками;
Следует вести протокол и документировать выявленные недостатки и вопросы;
Выберите временные рамки для проведения штабных киберучений, держите выбранный темп, но при необходимости вносите гибкость в расписание занятия.

Теги:

Хабы:

Информационная безопасность