SOC 2.0. 12 шагов, ведущих к пропасти. И 12 советов, как их избежать

SOC 2.0. 12 шагов, ведущих к пропасти. И 12 советов, как их избежать

Тема центров мониторинга ИБ (Security Operations Center, SOC) в России известна давно, и обычно её представляют в радужных тонах – там успех, здесь победа. Но не всё так красиво, как обычно это выглядит на презентациях SOC Forum.

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

ЧТО ТАКОЕ SOC?

Одна из классических ошибок, которая возникает почти в любом проекте, — отсутствие согласия в терминологии, а именно в понимании того, что должен делать SOC. И вроде на пальцах все понимают, о чём идёт речь, но копни глубже, и всё, начинается рассинхронизация. Для кого-то SOC – это только центр мониторинга, кто-то добавляет в него и реагирование, третьи наделяют SOC ещё и возможностями по управлению всеми средствами защиты, а четвёртые, говоря «SOC», имеют ввиду вообще всю службу ИБ. Но это ещё полбеды. Даже если сфокусироваться только на мониторинге, то включать ли борьбу с DDoS в сферу внимания SOC? А поиск уязвимостей? А контроль утечек? А мониторинг репутации и Darknet? А мониторинг мошенничества в банках? У каждого специалиста по ИБ своё восприятие термина Security Operations Center, и каждый из них считает, что это восприятие настолько очевидно, что и тратить время на разъяснение не нужно.

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

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

МАСШТАБИРУЕМОСТЬ

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

В другом проекте была схожая проблема, но там она возникла по другим причинам. Компания решила следовать «линии партии», взявшей курс на импортозамещение, и стояла задача построить SOC целиком на отечественных решениях. В процессе проектирования выяснилось, что один из отечественных SIEM не способен «переварить» больше определённого количества событий в секунду (event per second, EPS) и надо использовать кластер из SIEM, между которыми распределялась нагрузка. Вместо одного условного Splunk, который в России больше не работает, использовалось три копии одного российского SIEM, обрабатывающего тот же поток данных (и ещё один «мастер-SIEM» для управления ими). А так как проектируемый SOC был иерархическим и в разных странах присутствия компании строились свои региональные SOC, то число копий российского SIEM достигло двух десятков.

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

Правда, был в этом и положительный момент. Российский разработчик SIEM получил задание по доработке своего решения под разработанный проект, чтобы в будущем улучшить свои показатели масштабирования. А пока потребитель использует вместо одного SIEM двадцать и поддерживает тем самым отечественного производителя. 

Совет № 2. Проектируя SOC, учитывайте его не только текущую, но и планируемую архитектуру.

ПОКРЫТИЕ И ТЕЛЕМЕТРИЯ

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

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

Совет № 3. Чем больше источников телеметрии с разных участков инфраструктуры попадает в SOC, тем оперативнее он может выявлять инциденты. Составьте план расширения уровня покрытия SOC от периметра внутрь кампусной сети, а также наружу – в облака и мобильные устройства.

УРОВНИ L1-L3

Ох уж эти три уровня аналитиков SOC, обсуждение которых идёт уже не первый год. Кто-то считает, что наличие этих уровней говорит о зрелости SOC, и по-другому и быть не может. Первая линия отсекает явные ложные срабатывания и проводит вторичную обработку событий (после SIEM) и заводит соответствующие тикеты в IRP или SOAR системе (вот тоже больная тема для дискуссии – чем отличается IRP от SOAR и SGRC?). Вторая линия разбирается с более сложными случаями, а третья – это такая швейцарская гвардия, которая призывается только в особых случаях и самых сложных инцидентах, требующих, например, реверс-инжиниринга вредоносного кода.

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

Совет № 4. Не гонитесь за модой и не стройте SOC по принципу «все так делают». Возможно, в вашем случае аналитики могут работать и без чёткого деления на уровни L1-L3.

ИНТЕГРАЦИЯ С ИТ

Ещё одна боль многих SOC – их неумение выстраивать работу с другими подразделениями и, в частности, с ИТ. Например, на одном из серверов выявлена критическая уязвимость, и SOC, недолго думая, открывает соответствующий тикет и отправляет заявку на устранение уязвимости в ИТ-службу. И… А дальше всё – никакого контроля исполнения заявки внешними подразделениями. Через месяц выясняется, что… Да много может быть причин. Ложное срабатывание сканера уязвимостей, уязвимость не может быть проэксплуатирована в конкретной инфраструктуре, сервер некритичный, вендор не выпустил патч… Центр мониторинга эскалирует проблему вышестоящему руководству, где и выясняется, что SOC– это скорее вещь в себе, чем интегрированное в компанию подразделение. Так ещё и конфликтная ситуация возникла, которая ни к чему хорошему не приведёт, так SOCне может эффективно работать без поддержки со стороны ИТ. Та же реконфигурация средств защиты, которые могут находиться в эксплуатации у ИТ…

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

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

СЦЕНАРИИ ИЛИ USE CASE

В уже функционирующих SOC такого уже не встречается, но для тех, кто только подступается к теме, это неоправданное ожидание звучит постоянно. На вопрос «Какие сценарии мониторинга для вашего SOC являются приоритетными?» ответ часто звучит так: «Мы хотим мониторить всё!». Это как с системами обнаружения вторжений, в которых нередко включают абсолютно все сигнатуры, которые есть в системе, в надежде на то, что это позволит увидеть больше атак. Не позволит. Только ухудшит ситуацию, так как система будет либо жутко «фолсить» (то есть генерить ложные срабатывания), либо излишне нагружать себя обработкой событий, которые никогда не встретятся в месте установки системы мониторинга. Так и с SOC – они не мониторят всё и вся – у них есть вполне конкретный набор сценариев, которые наиболее актуальны для предприятия, в котором функционирует SOC. Эти сценарии зависят от модели угроз, ожиданий руководства, требований законодательства, ИТ-ландшафта и ряда других параметров, но список их всё равно конечен. У кого-то их несколько десятков; у кого-то 2–3 сотни. Но уж точно не тысячи возможных сценариев (use case). Безусловно, есть набор стандартных для многих сценариев (типа контроля привилегированного доступа, неудачные попытки аутентификации, аномалии доступа, утечки данных, использование уязвимостей, отказ средств защиты и сервисов и т. п.), но их не так уж и много.

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

АВТОМАТИЗАЦИЯ И ОРКЕСТРАЦИЯ

Это интересная история. Во многих SOC есть SIEM, есть TIP-платформы, есть системы тикетинга. На бумаге или в форматевики хранятся сборники дежурных процедур (playbook). То есть мониторинг худо-бедно, но выстроен. Проблемы начинаются, когда мы фиксируем инцидент и необходимо на него среагировать. Вроде как эту задачу решают системы класса SOAR (Security Orchestration, Automation and Response), которые давно уже стали неотъемлемой частью современного SOC. И не так важно, речь идёт о платном решении типа Splunk Phantom, бесплатном Cisco Secure X или решении open source The Hive.

Проблема в том, что каждая из трёх букв O, A и R работают не очень хорошо. Во-первых, далеко не у всех компаний есть чёткое понимание термина «инцидент», иначе как можно объяснить, что многие компании заявляют о том, что они сталкиваются ежедневно с тысячами (!) инцидентов (даже не атак). К слову, служба ИБ Cisco, ежедневно получая с инфраструктуры около 1,2 триллиона событий безопасности, трансформирует их всего в 22 инцидента. Говоря о тысячах инцидентов, надо понимать, что управлять ими будет некому. Даже после внедрения SOAR время локализации инцидента может составлять от полутора десятков минут до нескольких часов (зависит от инцидента). Даже при 12-часовой смене аналитика SOC отработать ему более 50 инцидентов не получится (и то в идеальной ситуации). Откуда берутся тысячи инцидентов, непонятно.

Во-вторых, у трети компаний вообще отсутствует формализованный процесс реагирования на инциденты, без которого SOAR не работает.

В-третьих, оркестрация подразумевает возможность подключаться к управляемым средствам защиты. Но если они не имеют API (например, отечественные решения, насквозь сертифицированные и обвешанные печатями регуляторов) или к ним запрещён формуляром на средство защиты удалённый доступ, то полностью задачу оркестрации решить невозможно. А тут ещё и неочевидная ситуация с вмешательством SOAR своими скриптами в регламенты работы средств защиты. Кто будет нести ответственность, если реагирование пойдёт не так и что-то важное будет заблокировано?

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

Совет № 7. Попробуйте начать с SOAR-функциональности в вашем SIEM (если она там есть) или с бесплатного или open-source-решения, пилотирование которого позволит не только понять зрелость вашего процесса реагирования, но и сформулировать требования к SOAR-решению. Также можно начать работу с SOAR с реализации каких-то типовых playbook’ов, попутно не только готовя новые сборники дежурных процедур, но и создавая варианты сопряжения SOAR с имеющимися средствами защиты; если не напрямую, то через промежуточный шлюз.

ОТСУТСТВИЕ ПРОДВИНУТЫХ СРЕДСТВ АНАЛИТИКИ

Несмотря на то что в России тема SOC активно продвигается уже лет пять, для многих технологическим ядром SOC по-прежнему является SIEM, оперирующий одними логами, получаемыми от средств защиты, сетевого оборудования, прикладного и системного ПО. А что с Netflow или поведенческими характеристиками пользователей? А что с мониторингом DNS-активности? А применяется ли машинное обучение или хотя бы цепочки правил для SIEM, позволяющие выявлять достаточно сложные события безопасности? Нередко бывает так, что даже купленное и достаточно дорогостоящее решение по мониторингу используется от силы на треть своих возможностей, а технологии, которые, по версии Gartner, составляют ядро SOC следующего поколения (речь идёт о NTA, мониторинге сетевых аномалий, EDR, мониторинге персональных и мобильных устройств, а также CASB, мониторинге SaaS-платформ), не используются вовсе, оставляя немалое количество инцидентов за пределами внимания аналитиков SOC.

Совет № 8. Начиная с мониторинга логов, не забудьте и про другие источники телеметрии, а также продвинутые методы анализа этих источников.

МЕТРИКИ

С показателями эффективности ситуация обстоит хуже всего, так как это последнее, до чего доходят руки у руководства SOC. Инциденты обнаруживаются? Да. Чего ещё надо? Наверх, на стол руководству компании, уходят цифры отражённых ежемесячно атак и локализованных инцидентов, а на уровне SOC к этим метрикам добавляются более привычное время реагирования или локализации инцидента, загрузка аналитиков SOC, число незакрытых тикетов и инцидентов. А что насчёт других, не менее показательных метрик — уровень автоматизации SOC, число инцидентов, обнаруженных с помощью данных Threat Intelligence, процент эскалации инцидентов на уровень L2, число ложных срабатываний, уровень прохождения аналитиками тренингов и курсов повышения квалификации, число инцидентов, не имеющих use case, уровень покрытия SOC, число инцидентов из-за известных уязвимостей и др.? Не измеряя ключевые и не очень показатели деятельности SOC, включая и время перехода от одного элемента дежурной процедуры (playbook) в SOAR к другому (это позволяет оценивать не просто время расследования и локализации конкретного инцидента, но и выявлять конкретные шаги рабочей процедуры, из-за которых инцидент расследуется слишком долго и неэффективно), мы не в состоянии улучшать процессы мониторинга и реагирования. Без этого нельзя также и руководству компании донести эффективность инвестиций в центр мониторинга ИБ и показать результаты его деятельности, понятные именно на бизнес-уровне.

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

ОТСУТСТВИЕ ПЛАНОВ РАЗВИТИЯ

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

Совет № 10. Имея в голове некую идеальную картину своего SOC (может, вы хотите построить не Security Operations, а уже Fusion Center), попробуйте выплеснуть её на бумаги и зафиксировать ключевые атрибуты будущего центра. Затем, опираясь на имеющиеся ресурсы и временные рамки, можно выстроить стратегию достижения идеального SOC, стартуя с текущей точки.

НИЗКИЙ КОНТРОЛЬ КАЧЕСТВА

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

Совет № 11. Выделите сотрудника (как минимум), который был бы наделён полномочиями и был достаточно подкованным во всех вопросах построения и эксплуатации SOC, чтобы он мог выступать в качестве «ревизора» и готовить предложения по улучшению. Тем же, кому сложно добиться создания ещё одной штатной единицы, а свободных людей в SOC нет, стоит задуматься о внешнем аудите своего центра мониторинга.

ОТЧЁТЫ И ДАШБОРДЫ

Думаю, что завершить дюжину наблюдений по SOC стоит ещё одним, неразрывно связанным с уже описанной проблемой под номером 9, а именно речь пойдёт о дашбордах и отчётах, демонстрирующих работу центра мониторинга. При этом я не говорю о видеостенах, на которых показывают экраны SIEM, UEBA, NTA или SOAR/IRP. Речь идёт о способе визуализации, который позволяет, увидев ключевые показатели эффективности, добиться инсайта или озарения и увидеть что-то, что нельзя увидеть в обычном отчёте или панели средств мониторинга. Для этого, правда, необходимо понимать, не только что делает SOC, но и зачем он это делает, и как это соотносится с требованиями всего бизнеса или его отдельных направлений. А это, увы, большая редкость. Для многих задача SOC – это снижение числа инцидентов и не более. А так как «продать» это бизнесу достаточно сложно (в отличие от, например, снижения объёма мошенничества или ущерба от инцидентов или снижения стоимости клиентской записи в Darknet), то рождаются многостраничные отчёты, размалёванные всеми цветами радуги, или такие же статические, но дашборды во всю стену, которые что-то показывают, но насколько это важно, никто не понимает (даже их авторы). Руководство тоже не понимает, но по количеству страниц или частоте мигания дашборда делает вывод, что «да, люди работают, значит,всё хорошо».

Совет № 12. Отчёт или дашборд– это способ визуализации наиболее важной для целевой аудитории информации, сгруппированной по смыслу так, чтобы её было легко понять и принять какие-то управленческие решения (получить деньги, полномочия, людей, одобрение…). Просто показать число инцидентов – это не цель, и ни к какому решению это число не приведёт. Поэтому важно уделять внимание не только «понятным» вещам, таким как количество EPS/FPS у SIEM или выбор способа анализа журналов регистрации Windows, но и тому, как воспринимается информация людьми и как правильно доносить до них имеющиеся показатели деятельности.

Мы плавно подошли к финалу нашего движения к SOC 2.0. Кто-то успешно сделал все 12 шагов и смог пересечь пропасть, запустив SOC нового поколения, в котором все его элементы – и люди, и процессы, и технологии, и сервисная стратегия – подчинены единому замыслу и увязаны с бизнес-потребностями компании, которая раскошелилась на этот центр. Кто-то ещё только делает эти шаги в надежде построить SOC 2.0. Главное, не ошибиться и для описанных в статье 12 наблюдений (а на самом деле у меня их больше) реализовать приведённые советы, чтобы движение к центру мониторинга будущего не превратилось в падение в пропасть. Удачи вам на этом пути!