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

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

Наиболее распространенное заблуждение — отождествление SOC с набором технологических решений, когда компания полагает, что сейчас «купит большой SIEM за много денег и у нее будет SOC». Нередки случаи, когда заказчики начинают непосредственно с попытки подготовить техническое задание на реализацию, пойти в конкурс и поскорее освоить выделенный бюджет. В этом случае, как правило, идет фокусировка исключительно на технической составляющей. Планируются к закупке стандартные наборы решений: SIEM, SOAR, возможно, TIP и подписки на Threat Intelligence (TI) и т.д. Это дорогие продукты, особенно если подходить к их закупке опрометчиво, и они быстро могут съесть весь доступный бюджет.

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

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

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

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

Определение и базовые принципы построения SOC

SOC (Security Operations Center) — это синергия людей (сотрудников, аналитиков), процессов, и, только в последнюю очередь, технологий. Это принципиальный момент, который отличает эффективный центр кибербезопасности от простого набора дорогостоящего оборудования и программного обеспечения.

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

Применяемые на практике основные этапы создания SOC (в порядке их реализации) представлены на рисунке 1.

1. Оценка потребностей бизнеса в создании SOC на базе оценки рисков, понимания недопустимых событий и возможностей по их недопущению. Именно на этом шаге приходит понимание необходимости создания такой структуры и формируются требования к центру кибербезопасности.
2. Разработка концепции построения центра, включая оценку и выбор оптимальной модели его построения. На этом шаге также определяется вектор развития и основные шаги реализации его жизненного цикла (дорожная карта).
3. Лишь на третьем этапе формируется техническое задание на реализацию, основанное на глубокой проработке первых двух этапов. Как правило, техническое задание формируется на первую очередь построения центра. Очень сложно одномоментно спроектировать, внедрить и интегрировать тяжелые решения, такие как SIEM, SOAR, TIP, VM, ловушки (honeypots) и другие. Это связано не только с внедрением технических решений, но и с поиском и набором сотрудников, выстраиванием и отладкой процессов. Внедрение первой очереди, как показывает практика, занимает от полугода до года и более. Далее центр итерационно развивается в соответствии с дорожной картой и учетом необходимых корректировок по результатам его эксплуатации и возможного изменения факторов, влияющих на его развитие.

4-5. На четвертом и пятом этапах проводится проектирование и разработка всей организационно-распорядительной документации, которая будет поддерживать и сопровождать деятельность центра.

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

9. Важным моментом является обеспечение сопровождения центра. На все ли решения есть вендорская поддержка? Достаточно ли собственных сил и средств для сопровождения или необходимы сервисные контракты и т.д.?

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

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

Рис. 1. Основные этапы создания SOC

Три составляющие 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 для широкого набора задач, начиная от выявления атаки или уязвимости и заканчивая анализом и реагированием.

Люди

Кадровый состав SOC определяется ответами на следующие вопросы, которые возникают на этапе проектирования:

• Какие задачи поставлены перед центром?
• Какие функции будет выполнять SOC?
• Как SOC будет взаимодействовать с бизнесом?
• Какой режим работы предполагается: 5/8 (рабочая неделя, дневные смены) или 24/7 (круглосуточно)?
• Какая модель SOC предполагается?

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

Типовая структура линий аналитиков

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

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

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

Таким образом, SOC представляет собой комплексное и иерархическое кадровое подразделение. Однако на этом задачи обеспечения не заканчиваются.

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

Предварительный состав помещений

1. Кабинет руководителя
2. Помещение для переговоров и совещаний
3. Помещение дежурной смены (первая линия)
4. Помещение аналитиков (вторая-третья линии)
5. Помещения для администраторов и другого персонала
6. Помещение для отдыха и психологической разгрузки
7. Помещение для подогрева и приема пищи

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

Процессы

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

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

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

Модели реализации SOC

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

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

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

Рис. 2. Модель реализации. Собственный SOC

Преимущества

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

Недостатки

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

Внешний SOC

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

Рис. 3. Модель реализации. Внешний SOC

Преимущества

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

Недостатки

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

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

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

Рис. 4. Модель реализации. Гибридный SOC

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

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

Преимущества

• Частичная экономия, когда часть функций не реализуется капитальными затратами в компании, а покупается как сторонняя услуга
• Возможность быстрого старта
• Доступ к экспертам высокого уровня или узкопрофильным специалистам в зависимости от стоящей задачи

Недостатки

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

Эффективный SOC

Итак, мы определили, что SOC — это сложное комплексное решение. Как же сделать так, чтобы он работал эффективно и оправдывал вложенные в его создание силы и средства? Рассмотрим ключевые направления совершенствования.

Знание того, что мы защищаем и от чего

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

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

Совершенствование процессов

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

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

Совершенствование контентной базы

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

Также должна совершенствоваться работа с данными киберразведки, как внешними, так и внутренними:

• проводить оценку и измерение актуальности определенных фидов (источников TI);
• пересматривать поставщиков этой информации;
• пересматривать источники событий, в которых будет проводиться поиск индикаторов компрометации (IoC).

Работа с данными киберразведки — это не статичная история (выбрал провайдера, подключил и забыл). Оценка и переоценка качества и применимости фидов для конкретной компании должна проводиться постоянно.

Пример подхода к развитию в этом направлении

1. Подключение открытых источников и работа с IoC
2. Выбор коммерческого поставщика, измерение качества и применимости, проведение дедупликации
3. «Подготовка» собственных IoC
4. Обмен IoC со смежными SOC (внутри отрасли или в рамках доверенных кругов)
5. Обработка тактик, техник и процедур (TTP) и т.д.

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

Проведение киберучений

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

• теоретические (штабные учения) — учения, направленные на обсуждение организационных задач и тренировку практики принятия управленческих решений;
• тренировки на киберполигоне — специальной инфраструктуре, предназначенной для отработки практических навыков путем моделирования компьютерных атак и отработки реакций на них;
• киберучения на собственной инфраструктуре — наиболее приближенная к реальной жизни тренировка, позволяющая оценить технические возможности выявления и реагирования на киберинциденты, а также протестировать эффективность процессов SOC;
• программа «bug bounty», предлагающая вознаграждение за найденные уязвимости в собственной инфраструктуре.

Оценка эффективности SOC. Метрики и KPI

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

Разработка комплекса метрик — нетривиальная задача, более того, она не шаблонная. Что хорошо для одного SOC, далеко не факт, что будет полезно для другого.

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

Примеры стратегических целей

• Задекларировать, что компания соответствует нормативным требованиям
• Добиться изменения поведения топ-менеджеров
• Обосновать или добиться принятия каких-то управленческих решений
• Обосновать покупку новых инструментов или найм нового персонала

Далее необходимо понять:

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

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

Рассмотрим два примера метрик для иллюстрации.

Пример 1: Количество инцидентов за сутки.

Попытаемся ответить на вопрос, что на самом деле метрика нам дает и для кого эта информация.

Возможные интерпретации

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

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

Более информативно, например, отслеживание количества инцидентов в динамике с разбивкой по категориям и с учетом времени обнаружения (Mean Time to Detect, MTTD) и времени реагирования (Mean Time to Respond, MTTR).

Пример 2: Стоимость клиентских данных в даркнете

О чем говорит эта метрика?

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

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

Важно понимать, что метрики являются не самоцелью, а инструментом управления и коммуникации с бизнесом. Именно поэтому метрики должны быть:

• целевыми — привязанными к стратегическим целям;
• измеримыми — с четким источником данных и периодичностью сбора;
• понятными заинтересованным сторонам;
• действенными — на их основе принимаются решения.

Нельзя вводить метрики «для галочки» или собирать все подряд без понимания, зачем это нужно.

Модели зрелости SOC как инструмент развития

В завершение остановимся на своего рода «шпаргалке», которая может подсказать вектор развития SOC и сделать его более сбалансированным — оценке по модели зрелости. Существуют разные методологии проведения таких оценок, например, SOC-CMM или Open CSIRT SIM3.

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

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

Для примера, только в базовом варианте методики SOC-CMM (Capability Maturity Model for Security Operations Centers) содержится более 900 вопросов по всем направлениям. Даже просто проведя самооценку по такой модели, можно явно определить направления развития и выявить места, на которые нужно обратить внимание.

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

Заключение

Подводя итог, можно сформулировать основные выводы и рекомендации.

1. SOC — это не набор технологий, а синергия людей, процессов и технологий. Попытки построить SOC, начиная с закупки SIEM и других решений без предварительной проработки требований и модели, в подавляющем большинстве случаев обречены на провал.
2. Создание SOC — это непрерывный процесс, а не проект с фиксированными сроками. Организация должна быть готова к постоянному развитию, адаптации и пересмотру требований.
3. Ключевой этап — предварительная проработка. Оценка потребностей бизнеса, разработка модели, определение вектора развития, учет требований к команде и процессам. Именно здесь закладывается фундамент успеха.
4. Выбор модели реализации (собственный, внешний, гибридный SOC) должен основываться на конкретных требованиях и возможностях организации, с четким пониманием плюсов и минусов каждой модели.
5. Эффективность SOC должна измеряться. Метрики должны разрабатываться по принципу «сверху вниз» — от стратегических целей к конкретным показателям, а не собираться бессистемно. Только так можно показать бизнесу ценность SOC.
6. Модели зрелости являются эффективным инструментом для самооценки и определения сбалансированных векторов развития. Они помогают увидеть «слепые зоны» и развивать SOC не только в техническом плане, но и в части взаимодействия с бизнесом и управления персоналом.
7. Непрерывное совершенствование — норма жизни для SOC. Это касается актуализации знаний об активах, развития контентной базы, работы с TI, правил выявления, проведения тренировок.

Только такой системный подход позволяет построить SOC, который действительно помогает бизнесу управлять киберрисками, проактивно противостоять угрозам и демонстрировать измеримые результаты своей работы.

Автор: Павел Корнилов, руководитель отдела систем мониторинга и автоматизации информационной безопасности STEP LOGIC