SOC, который работает: на что обратить внимание при реализации

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

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

SOC — это не проект, а процесс

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

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

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

Многие идут по самому распространенному и дорогостоящему пути, а именно, начинают с подготовки технического задания на закупку SIEM, SOAR, TIP и других решений. Компания проводит конкурс, внедряет инструменты, осваивает бюджет, потом выясняется, что работать с ними некому. На рынке нет готовых аналитиков, а те, кто есть, стоят дорого.

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

Таким образом, технологии — это последнее, о чем стоит думать, прежде всего, необходимо обратить внимание на потребности бизнеса.

Семь шагов, которые нельзя пропускать

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

Оценка потребностей бизнеса. Ответьте на вопросы: какие киберриски для нас критичны? Какие события недопустимы? Действительно ли нам нужен SOC или достаточно существующих средств защиты? Без вовлечения бизнес-владельцев этот шаг невозможен.
Разработка концепции и выбор модели. Определите, какой SOC нужен: собственный, внешний или гибридный. От этого зависят и CAPEX, и OPEX, и сроки, и требуемая численность команды. Модель должна решать именно ваши задачи, а не быть «красивой».
Формирование ТЗ на первую очередь. Оно базируется исключительно на результатах первых двух этапов. Не пытайтесь объять необъятное, так как внедрить все и сразу невозможно.
Проектирование и разработка организационно-распорядительной документации. Архитектура, персонал, процессы, регламенты, сценарии реагирования, инструкции взаимодействия с ИТ и бизнесом. Без этого технологии бесполезны.
Внедрение технических решений и запуск процессов. Только после того, как все вышеперечисленное готово. Заканчивается все обязательными испытаниями, приемкой и аттестацией в случае необходимости.
Обеспечение сопровождения. Есть ли вендорская поддержка? Хватает ли собственных сил? Нужны ли сервисные контракты?
Развитие. После внедрения первой очереди приступают к последующим или развитию центра. На этом этапе мы вступаем в итерационный процесс развития и улучшения, тем самым адаптируя SOC к постоянно изменяющимся требованиям и стремясь проактивно подходить к новым вызовам.

Если пропустить первый или второй шаг, то вероятность успеха стремится к нулю.

Три составляющие успеха

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

Технологии

Базовые решения, которые могут составлять основу стека технологий центра, включают:

AM (Asset Management)/CMDB (Configuration Management Database) — системы управления активами и конфигурацией
SIEM (Security Information and Event Management) — система сбора и корреляции событий
EDR (Endpoint Detection and Response) — система для обнаружения и реагирования на современные угрозы на конечных устройствах
SOAR (Security Orchestration, Automation and Response) — платформа оркестрации и автоматизации реагирования
TIP (Threat Intelligence Platform) — платформы управления Threat Intelligence
Подписки на Threat Intelligence (TI) — внешние источники данных об угрозах
VM (Vulnerability Management) — системы управления уязвимостями
Deseption — системы эмуляции ложной инфраструктуры
Sandboxes — песочницы для детонации подозрительных файлов
NTA (Network Traffic Analysis) — системы анализа сетевого трафика
UEBA (User and Entity Behavior Analytics) — системы поведенческого анализа пользователей и компонентов ИТ-среды

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

Подписывайтесь на наш Telegram Читать

Люди

Кадровый состав SOC зависит от задач, функций, режима работы (5/8 (рабочая неделя, дневные смены) или 24/7 (круглосуточно) и модели будущего SOC. Ответив на эти вопросы, можно сформировать линии аналитиков. Разделение по функциям не является догмой и всегда должно определяться в каждом конкретном случае для оптимального решения возложенных задач.

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

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

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

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

Процессы

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

стратегическое управление центром для возможности развития и адаптации к изменяющимся условиям;
управление персоналом — обучение, удержание, мотивация, подбор сотрудников;
обеспечение прозрачности функционирования и возможности однозначной оценки эффективности перед бизнесом.

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

Не начинайте с закупки SIEM, не пишите ТЗ на технологии. Начните с ответа на вопрос: «Какие бизнес-риски мы хотим закрыть с помощью SOC?». Вовлеките владельцев бизнес-процессов, оцените активы, определите недопустимые события, выберите модель, спроектируйте команду и процессы и только потом — технологии. Это единственный способ построить SOC, который не станет дорогой игрушкой, а действительно начнет защищать бизнес.

Какие модели реализации существуют и как выбрать

Собственный SOC

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

В итоге компания получает полную управляемость и высокую скорость взаимодействия с ИТ и ИБ. Минусами такой модели является высокая стоимость, сложность реализации, дефицит кадров, длительность запуска (от полугода).

Внешний SOC (MSSP)

Второй вариант модели реализации — покупка услуг внешнего SOC. В этом случае все технические средства и сотрудники находятся в сторонней организации, у которой приобретаются услуги мониторинга и реагирования.

Мы экономим CAPEX (оплата по факту — OPEX), получаем быстрый старт и масштабирование, имеем доступ к экспертам высокого уровня или узкопрофильным специалистам, но полностью зависим от провайдера, передаем чувствительные данные третьей стороне, появляются ограничения по кастомизации, возможности реагирования тоже чаще всего ограничены.

Гибридная модель

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

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

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

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