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

Рост популярности SOC обусловлен несколькими причинами:

• Технологии SOC стали понятны, а количество специалистов с теоретическими знаниями и практическим опытом выросло;
• ИБ-процессы в компаниях стали более зрелыми;
• Ужесточилось госрегулирование в части ИБ. Так, согласно указу президента №250 , в компаниях должны появиться ответственные за обеспечение ИБ из числа топ-менеджеров, что, естественно, повысило приоритет проектов по кибербезопасности;
• В поле зрение злоумышленников попали даже те компании, которые раньше им не были интересны. Атакам подвергаются как субъекты КИИ и государственные системы, так и остальные отрасли. Об этом говорит и статистика НКЦКИ , и данные отчетов «РТК-Солар» .

Решить задачу можно 2 путями: построить собственный SOC (on-premise) или воспользоваться услугами сервис-провайдера. Расчеты TCO (total cost of ownership, общая стоимость владения) показывают, что для средних и крупных компаний сервисная модель будет выгоднее. Экономия достигается, в частности, и за счет того, что нет траты на оборудование и зарплаты высокооплачиваемых экспертов. Впрочем, сервис можно реализовать и на собственной технической инфраструктуре – это гибридный вариант подключения, когда платформа (в частности, SIEM) принадлежит компании, а обрабатывают и анализируют все полученные с нее данные эксперты ИБ-провайдера.

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

Основные проблемы SOC

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

1. Отсутствие понимания целевого облика SOC и масштабов проекта в целом. Это техническая архитектура, карта процессов, зоны ответственности, необходимая экспертиза персонала, общий план-график проекта. Типичный подход: «давайте начнем, а по ходу дела разберемся» или «внедряем SIEM, потом посмотрим, что еще нужно».
2. Перекос при планировании работ в сторону технической части в ущерб процессной и методологической. Например, можно сразу купить SIEM на 30 000 eps (events per second или событий в секунду), не имея при этом людей на подключение и работу со всей инфраструктурой целиком. Или закупка связки SIEM + IRP при пока еще не отлаженной работе линий мониторинга и общем недостатке опыта у персонала. В результате компания тратит огромные бюджеты на те средства, которые не могут быть задействованы сразу;
3. Недостаточное внимание к рискам, связанным, например, с уходом части проектной команды или привлечением людей, основная работа которых связана с другой операционной деятельностью. Например, если команду покидает технический архитектор, то весь проект может затормозится на год или даже дольше.

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

Все это в итоге приводит к следующему: затраты значительные, а ощутимого результата нет (часто, проводимые нами пентесты оказываются незамеченными корпоративными SOC).

Что поможет?

Конечно, можно решать эти сложности самостоятельно методом проб и ошибок. А можно привлечь внешнего эксперта для консалтинга, от которого требуется:

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

Центр экспертизы при таком подходе станет основной движущей силой проекта в среднесрочной перспективе. Такая команда должна состоять как минимум из:

• Архитектора – технического эксперта с широким кругозором в области ИБ, ИТ и Security Operations;
• Методолога – специалиста по методическому обеспечению работы как внутри SOC, так и со смежными подразделениями;
• Опытного руководителя проектов;
• Бизнес-лидера проекта.

По ходу реализации проекта потребуется еще сама команда SOC, состоящая из разных линий мониторинга, а также команды поддержки инфраструктуры и СЗИ.

Важно, чтобы проектная команда занималась SOC в режиме full-time и не использовалась для параллельных задач.

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

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

• Анализ киберрисков;
• Анализ зрелости SOC;
• Разработка программы и плана развития или модернизации SOC;
• Разработка процессов, регламентов и других методологических документов;
• Проектирование и внедрение различных систем SOC (SIEM, EDR, NTA, IRP и т.д.), фактически интеграционная деятельность;
• Разработка и автоматизация плейбуков по реагированию на инциденты;
• Разработка метрик и KPI работы SOC;
• Разработка и передача контента для различных систем SOC;
• Проведение тренингов для специалистов SOC и команд реагирования;
• Киберучения и Red Teaming.

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

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

Три практических примера

Вернемся к практическим моментам, с которыми любой SOC рано или поздно столкнется. Я бы хотел поделиться тремя небольшими, но типовыми примерами:

1. Правила корреляции или контент SIEM

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

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

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

2. Реагирование на инциденты

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

3. Общее взаимодействие внутри команд

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

Выводы

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

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

Реклама. ООО "СОЛАР СЕКЬЮРИТИ", ОГРН 1157746204230