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

Можно ли запустить одну из ключевых платформ центра мониторинга информационной безопасности (Security Operations Center, SOC) за пару месяцев? Как именно реализовать концепцию быстрого запуска SOC?

1. Введение
2. Зачем мы придумали концепцию «быстроSOC»
3. Что собой представляет концепция «быстроSOC»
4. Выводы

Введение

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

Ранее на Anti-Malware.ru анализировали особенности применения SOC для мониторинга промышленных сетей АСУ ТП и сравнивали услуги коммерческих SOC (Security Operations Center).

Зачем мы придумали концепцию «быстроSOC»

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

Как следствие, только на создание и запуск центральной технологической платформы SOC на базе SIEM уходит минимум 6–8 месяцев, и при этом компания не получает SOC как таковой: нужно ещё смоделировать и отладить необходимые процессы, нанять и обучить персонал.

Запуск SOC — весьма продолжительный и трудоёмкий проект, в рамках которого недостаточно только внедрить SIEM-систему, а необходимо ещё как минимум: 

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

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

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

Рисунок 1. Вариант технической архитектуры SOC при гибридной модели

Что собой представляет концепция «быстроSOC»

При внедрении SIEM-системы самыми продолжительными этапами работ являются:

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

За последние пять лет мы успешно реализовали более 100 проектов по внедрению SIEM-систем. Поэтому у нас есть неплохой набор «заготовок»:

• Скорректированные парсеры «из коробки» и для нетиповых источников (уровень приложений, оборудование АСУ ТП и т. п.) для сбора и нормализации событий по ИБ, необходимых для настройки корреляционного контента. Охватываются ключевые инфраструктурные элементы, такие как ОС (Windows, *NIX-like), СУБД, ИТ-сервисы (корпоративный домен, корпоративная почта, телефония и т. п.), сетевое оборудование, а также средства защиты, в том числе и отечественные.
• Необходимые настройки политик журналирования событий по ИБ на инфраструктурных элементах.
• Правила корреляции, позволяющие выявлять более 70 % техник MITRE ATT&CK и исключающие выявление событий связанных с легитимными действиями процессов на инфраструктурных элементах и в инфраструктуре в целом.

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

1. Создание базовой конфигурации — 30 рабочих дней.
2. Развитие базовой конфигурации — 90 рабочих дней и более.

Рисунок 2. Этапность запуска SOC (источник: пресс-служба компании «Инфосистемы Джет»)

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

• настроить сбор событий с источников, которые являются необходимыми (must have) в проектах по внедрению SIEM-систем и используются у всех при построении системы ИБ, минимальный набор — корпоративный домен Microsoft Active Directory, антивирусное ПО и межсетевой экран;
• настроить и отладить корреляционный контент, который не требует длительной отладки и реализуется на ИБ-событиях от подключённых источников, позволяющих выявлять компрометацию учётных записей, злоупотребление административными привилегиями, активность вредоносных программ на конечных хостах и признаки заражения в сетевых взаимодействиях.

При этом мы активно включаем заказчика в работу, выдавая на старте проекта необходимые требования к сетевым взаимодействиям и к настраиваемым политикам журналирования. 

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

Выводы

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

Поэтому концепт «быстроSOC» применим в первую очередь для построения Security Operations Center с моделями при участии сервис-провайдера, в том числе и в облачном варианте.

Однако если у вас уже выстроены процессы, обучен персонал, но технологическое ядро SOC было построено на базе зарубежного SIEM с истекающей лицензией, то описанная концепция применима и в этом случае. Тогда начать проект можно за 30 рабочих дней до наступления «часа икс», развернув тестовую инсталляцию выбранного отечественного решения и настроив контент согласно концепции.

И, разумеется, если персонал заказчика не вовлечён в строительство SOC, то запустить «быстроSOC» нельзя будет не только за 30 дней, но и за полгода.