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

Мы начинаем серию постов "Чего хотят клиенты". В них мы собрали самые популярные запросы, с которыми к нам, как к сервис-провайдеру ИБ, приходят различные компании, желающие подключить свою инфраструктуру к Security Operations Center (SOC). С какой бы стороны баррикад вы ни стояли (строитель SOC или заказчик), надеемся, наш опыт будет вам полезен.

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

1) «У нас есть SOC, но нужно поднять его уровень или оптимизировать работу»

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

А чтобы сократить нагрузку на штатных специалистов и оптимизировать расходы, мы, как подрядчик, берем на себя часть экспертных функций (высококвалифицированная форензика, OSINT (киберразведка), RedTeaming, Threat Intelligence). И вот старый SOC готов работать по-новому.

2) «Нам нужно построить свой SOC с нуля»

Здесь все начинается с создания концепции SOC: определяются зоны ответственности, функции, штатная структура, задачи, SLA, OLA.

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

3) «Хотим SOC как сервис»

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

…А как в реальности?

Выше я описал идеальную схему взаимодействия с клиентами, но на деле, как водится, возникают «нюансы». Начнем с первого запроса.

…А как в реальности?

Иногда проще сломать и построить заново

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

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

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

Процессы и технологии нужно постоянно обновлять

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

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

Нужен практический опыт у исполнителя

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

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

При этом важно, чтобы в команде подрядчика были специалисты, знакомые с профилем и отраслью, в которой работает их заказчик, а в портфеле сервисов – комплементарные построенному SOC технологии.  Согласитесь: SOC в банковской сфере и промышленности сильно отличаются друг от друга. Иные процессы, роли вовлекаемых специалистов, защищаемые активы и бизнес-процессы. Могут иметь свою специфику и используемые в компании SIEM, IRP, EDR, NTA и другие компоненты. Поэтому подрядчику будет намного проще учесть все нюансы, если он сам оказывает сервисы на базе данных технологий.

Надо построить SOC с нуля

Казалось бы, все просто: бери и строй новый SOC без каких-либо «призраков прошлого». Но и здесь тоже достаточно подводных камней.

Построить SOC за месяц невозможно

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

А для этого, как минимум, нужно:

1. Настроить контент и внести исключения. Ни один SOC не будет сразу работать идеально. Первое время после запуска будут вычищаться Авгиевы конюшни исправляться нарушения существующей в организации политики ИБ. Чаще всего сразу начинает «падать» множество алертов об использовании различных RAT, TOR, не обновленных и отключенных антивирусах на хостах, избыточных связях между сегментами, открытых (и не документированных) сервисах на периметрах, хакерских утилитах на хостах, использовании сервисных «учеток» для работы администраторов. Стоит сразу определиться: что допустимо, а что – нет. И дальше начать пресекать нелегитимное использование сотрудниками запрещенного в компании ПО, а также добавлять исключения в SIEM. И если ИТ-служба компании будет работать совместно с экспертами SOC, количество ложных срабатываний сократится, а важные инциденты не останутся без внимания.

2. Скорректировать маршрутизацию тикетов и контроль их отработки смежными подразделениями в соответствии с принятым SLA. Здесь сильно облегчит жизнь система IRP/SOAR, но в любом случае нужны разделение зон ответственности и плейбуки. Пусть 1-2 безопасника будут кураторами в ликвидации инцидентов, а ИТ-специалисты – исполнителями. Иначе ИБ-служба станет своеобразным бутылочным горлышком, где будут застревать тикеты.

3. Сформировать регулярные задачи SOC, не связанные с Incident Response: Threat Hunting, Threat Intelligence (в части получения, использования, приоритизации индикаторов, поиска информации в интернете/даркнете), обеспечение работоспособности по моделям здоровья компонентов SOC, расширение списка корреляционных правил и детектов, внутренний контроль линий SOC, повышение компетенций и шеринг знаний. Но приступать к этому более продвинутому этапу надо только после того, как сформируются базовые процессы.

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

Словом, ставьте реальные сроки и идите итерационно в построении SOC. В противном случае мы увидим деградацию процессов и выгорание персонала из-за чрезмерной нагрузки.

Нужна техническая база и люди

«Мы купили SIEM, а еще у нас есть целых 2 сотрудника отдела ИБ. Давайте начинать» – с таким подходом собственный SOC вряд ли построишь. В этом случае лучше выбрать вариант гибридных сервисов, когда компоненты покупает компания, а услуги оказываются подрядчиком. Это позволит сначала посмотреть, как работает внешний SOC, а потом вместе с подрядчиком начать трансфер экспертизы и процессов. Сперва переключить функционал первой линии, потом, постепенно наращивая собственный опыт и экспертизу, начать поэтапное масштабирование функций и процессов.

Не все стоит делать самим

<Дискрлеймер: рассуждения в данном пункте не относятся к Сбербанку, РЖД, Роснефти и аналогичным гигантам>

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

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

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

Полный аутсорсинг: SOC как сервис

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

·       защитить инфраструктуру;

·       подключить все филиалы и всех удаленных пользователей;

·       обеспечить мониторинг АСУ ТП;

·       реализовать выявление внутреннего фрода, подключив к мониторингу бизнес-системы.

Но слона надо есть по частям!

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

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

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

Нужно подключить ИТ и бизнес

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

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

Заключение

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

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

Автор: Алексей Павлов, директор по развитию бизнеса центра противодействия кибератакам Solar JSOC