Чек-лист: проверьте, все ли «умеет» ваш SOC?

Что может делать ваш SOC

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

Пример возможностей SOC в соответствии с NIST Cybersecurity Framework

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

Перечень функций SOC согласно MITRE

«Персонал—процессы—технологии» — основные компоненты SOC

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

Целевая модель SOC помогает решить: какие процессы нужны; какие технологии требуются для автоматизации процессов; какой персонал необходим для реализации процессов и поддержки технологий.

Правильной формулы состава SOC не существует. У каждой компании свой путь и свой «обязательный» набор SOC. Состав очень сильно зависит от целевого набора функций SOC и объема решаемых им задач.

Наиболее часто реализуемые функции SOC в России, по данным компании «Инфосистемы Джет»

Компаниям с небольшой областью покрытия мониторинга будет достаточно централизованно собирать, фильтровать и нормализовать события с инфраструктуры c помощью систем управления логами (Log Management System) и выстроить процесс управления инцидентами ИБ, чтобы команда из 2–3 человек могла эффективно решать поставленные задачи.

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

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

«Персонал»: какая команда нужна для обеспечения работы SOC

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

Пример ролевой модели SOC

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

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

«Процессы»: какие процессы нужны для эффективной реализации функций SOC

Распространенной ошибкой при создании SOC является неправильное выстраивание процессов: нередко регламентирующая их документация оказывается нежизнеспособной и «уходит в стол». В результате вооруженные техническими средствами специалисты остаются без четкого понимания стоящих перед ними задач и без детальных инструкций по их выполнению. В таких условиях организовать продуктивное взаимодействие внутри SOC и со смежными подразделениями крайне сложно.

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

Типовая карта процессов SOC

Как избежать ошибок при выстраивании процессов SOC

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

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

«Технологии»: с помощью каких решений автоматизировать процессы SOC

Крупный SOC желательно оснастить инструментами для автоматизации выстроенных процессов.

SIEM-система помогает автоматизировать выявление инцидентов ИБ за счет сбора, корреляции и анализа событий ИБ с элементов ИТ-инфраструктуры и средств защиты информации.

IRP/SOAR-системы (Incident Response Platform / Resilient Security Orchestration, Automation and Response) повышают скорость реакции на инциденты за счет автоматизации рутинных задач по их обработке. Например, с их помощью удастся сэкономить время на регистрации, классификации (определении категории и уровня критичности), заполнении карточки инцидента, обогащении событиями для анализа, проверке на вредоносность индикаторов компрометации и выполнении действий по реагированию. В решениях этого класса можно настроить сценарии реагирования под каждую категорию инцидентов, что поможет автоматизировать весь жизненный цикл управления ими.

SOC может применять системы IRP/SOAR не только для управления инцидентами ИБ, но и для решения дополнительных задач.

Инвентаризация и контроль ИТ-инфраструктуры
При наличии в системе модуля управления активами можно реализовать контроль актуальности состава ИТ-инфраструктуры и решить проблему теневых ИТ (Shadow IT). Все это осуществляется в тесном взаимодействии с другими инфраструктурными системами: CMDB, корпоративный домен, системы управления ИТ-инфраструктурой. Управление уязвимостями в инфраструктуре
С помощью системы можно не только выявлять и регистрировать, но и приоритизировать уязвимости по уровням критичности информационных активов, автоматически назначать ответственных и сроки устранения.

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

Что должен выявлять SOC

При строительстве SOC часто возникают сложности с пониманием того, какие инциденты он должен выявлять. Эту задачу решает его технологическое ядро — SIEM-система — путем корреляции событий ИБ, собираемых с элементов ИТ-инфраструктуры и средств защиты. Вендоры поставляют SIEM с большим количеством разработанных правил корреляции, которые остается только адаптировать под реалии конкретной ИТ-инфраструктуры. Или же можно написать свои правила, ориентируясь на популярный фреймворк MITRE ATT&CK с практиками выявления известных техник атак.

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

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

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

Аналитика

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

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

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

Визуализация отчетности Аналитика по деятельности SOC отображается на дашбордах в виде виджетов — всевозможных таблиц и диаграмм, сгруппированных по смыслу на одном экране. Системы, входящие в технологическое ядро SOC (SIEM, IRP/SOAR), способны формировать множество типов виджетов любого состава и конфигурации. Чаще всего разрабатываются дашборды операционного и тактического уровней. Первые демонстрируют срез по текущей картине состояния ИБ: новые и открытые инциденты, их приоритеты, загрузку персонала, соблюдение сроков и т.д. Вторые предоставляют статистику по деятельности за последний месяц: распределение по категориям инцидентов и объектам атак, среднее время выявления и реагирования на инцидент, метрики эффективности.

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

Новые тенденции

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

Смещение фокуса ИБ при выявлении киберинцидентов

Для реализации такой концепции SOC нужны инструменты, которые не только выявляют сигнатурную активность, но и фиксируют и анализируют аномальное поведение, тем самым позволяя детектировать целенаправленные атаки с использованием неизвестного вредоносного кода, скомпрометированных учетных записей, бесфайловых методов, легитимных приложений и действий, не несущих под собой ничего подозрительного. Компания Gartner позиционирует связку NTA (Network Traffic Analysis), EDR (Endpoint Detection and Response) и SIEM как набор необходимых технических средств для организации максимально полного мониторинга инфраструктуры и выявления угроз, нацеленных на обход традиционных средств защиты.

EDRРабочие места остаются ключевой целью злоумышленников и самыми распространенными точками входа в инфраструктуру компании. Конечные точки подключают к SIEM в качестве событий для мониторинга инцидентов редко или частично — только самые критичные. Это обусловлено в первую очередь высокой стоимостью сбора и обработки журналов со всех конечных станций, а также генерацией огромного количества событий для разбора, что зачастую приводит к перегрузке персонала SOC. Для детектирования событий на конечных узлах в инфраструктуре можно использовать решение класса EDR, которое поможет выявлять аномальное поведение на конечных хостах.

NTAСетевой трафик — один из важных источников событий для выявления инцидентов ИБ. Часто вместо его полноценного анализа ограничиваются сбором логов со стандартных сетевых средств защиты и сетевого оборудования. Автоматизировать сбор и анализ событий внутри трафика можно с помощью решений класса NTA. В отличие от стандартных инструментов выявления сетевых атак, они оперируют большими объемами трафика, что дает возможность выявлять цепочку атаки целиком, а не довольствоваться срабатыванием единичной сигнатуры. Система класса NTA может быть полезна в выявлении неизвестных угроз за счет поведенческого анализа трафика.

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

Breach and Attack Simulation (BAS) Активно развиваются и системы класса BAS, которые позволяют частично автоматизировать функционал тестирования на проникновение. Также они могут быть полезны при проведении киберучений, когда нужно отработать практические навыки персонала SOC по оперативному выявлению и реагированию на атаки.

О чем еще важно не забыть

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

Киберполигон Для киберучений понадобится киберполигон — симулятор, с помощью которого специалисты смогут обучиться отражать атаки и расследовать инциденты в боевом режиме. Кроме того, он пригодится и для тестирования новых средств защиты. По сути, это тестовая инфраструктура, которая никак не взаимодействует с основным ИТ-ландшафтом компании. В ней нужно обеспечить возможность имитации различных сценариев кибератак (DDoS, атак на ОС, Web, телеком-оборудование и Wi-Fi) и развернуть систему защиты, позволяющую выявлять и противодействовать им.

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

Вместо заключения

Строительство SOC — это длительный и ресурсозатратный проект. Классический подход к таким проектам можно сформулировать так: «Ешьте слона по частям».

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

Подробнее о нюансах организации SOC можно узнать у экспертов компании «Инфосистемы Джет».

Смотрите также

• Ситуационные центры
• Ситуационные центры (определение, основные задачи)
• Ситуационный центр губернатора