модель soc что это
Руслан Рахметов, Security Vision
Оглавление
Друзья, в предыдущей статье (https://www.securityvision.ru/blog/informatsionnaya-bezopasnost-chto-eto/) мы обсудили основные понятия информационной безопасности и дали определение некоторым терминам. Разумеется, сфера защиты информации не ограничивается описанными определениями, и по мере появления новых статей мы будем всё больше погружаться в данную область и объяснять специфические термины.
Сейчас же давайте представим, как выглядит практическая работа тех, кто профессионально занимается информационной безопасностью, т.е. специалистов по защите информации. Мы часто слышим, что многие значимые расследования хакерских атак ведутся в Ситуационных центрах информационной безопасности, или Центрах SOC (от англ. Security Operations Center). Что такое SOC? Кто там работает и что делает? Какие обязанности выполняют сотрудники SOC, с какими системами и средствами они работают? Правда ли, что без знаний языков программирования не удастся достичь высот в работе в составе команды SOC-Центра, а навыки администрирования информационных систем нужны специалисту по защите информации как воздух? Поговорим об этом ниже.
Пока же нам следует уяснить, из каких специалистов должен состоять Центр SOC? Какие компетенции важны для успешной и плодотворной работы в Ситуационных центрах информационной безопасности? Для начала мы подробнее расскажем, какие именно задачи решаются в SOC-Центрах, поговорим о классификации SOC и о моделях работы и предоставления сервисных услуг заказчикам Ситуационных центров информационной безопасности.
На практике подключение и использование услуг SOC-Центра выглядит следующим образом:
1. Заказчик услуг SOC-Центра, который видит необходимость в аутсорсинге оперативного реагирования на свои инциденты ИБ, обращается к менеджерам SOC с запросом о подключении к сервисам SOC.
2. Менеджеры Центра SOC согласовывают детали подключения информационных и защитных систем заказчика к инфраструктуре SOC-Центра для того, чтобы оперативно обрабатывать поступающие данные без выезда на площадку Заказчика.
4. На площадке Заказчика информационные системы и имеющиеся средства технической защиты настраиваются на пересылку всей значимой с точки зрения ИБ информации во внешний SOC.
5. Во внешнем SOC-Центре входящие данные непрерывно обрабатываются сотрудниками SOC (дежурной сменой), которая состоит, как правило, из следующих специалистов:
Специалист по настройке правил в системах SIEM, SOAR, IRP получает от Заказчика вводные данные о работе информационных систем и затем составляет правила выявления инцидентов и реагирования на них в используемых в SOC-Центре системах. Это могут быть правила корреляции в системах SIEM, которые отвечают за обработку входящих сообщений от систем безопасности заказчика и за выстраивание этих разнородных событий в логически целостную «историю» для поиска возможной атаки. Также настраиваются правила автоматического реагирования, локализации, восстановления информационных систем при помощи SOAR и IRP решений. В случае, если для защиты Заказчиков используются сигнатурные методы обнаружения угроз, например, антивирусы или системы обнаружения/предотвращения компьютерных вторжений, то данный специалист создает для них сигнатуры, т.е. описывает правила, по которым угроза должна быть обнаружена.
Что такое SOC и для чего он нужен компаниям
Определение и задачи SOC
SOC (Security Operations Center, или Центр обеспечения безопасности) – то, что объединяет людей, процессы и технологии в достижении глобальной цели: снижение рисков через повышение киберзащиты в организации. Но прежде всего SOC – это команда экспертов по безопасности, которые вооружены технологиями обнаружения, анализа, подготовки отчетов и предотвращения киберугроз.
SOC можно сравнить с работой команды пожарных или медиков на скорой помощи. Киберспециалисты в SOC, как и сотрудники экстренных служб, помогают в чрезвычайной ситуации: оперативно появляются в нужном месте, анализируют угрозы и принимают соответствующие меры. Еще их объединяет стремление не допустить подобные инциденты.
SOC – это непрерывные потоки информации, которые обрабатывают и компьютерные системы, и эксперты
Задачи SOC
Самое трудоемкое в работе SOC – постоянно анализировать большие объемы данных. Центр обеспечения безопасности собирает, хранит и анализирует от десятков до сотен миллионов событий безопасности ежедневно. Не забываем, что все это контролируют эксперты: они включаются в работу, когда нужно решить, что делать с найденной угрозой.
Зачем SOC нужен компаниям?
Непрерывный контроль за безопасностью организации. У киберугроз и киберпреступников, которые за ними стоят, нет рабочего времени, выходных и обеденных перерывов. Оперативно выявлять инциденты безопасности помогут только постоянный мониторинг и сканирование сетевой активности. Чем быстрее организация реагирует на кибератаки, тем меньше она рискует безопасностью.
Как внедрить SOC в организации
Создание современного Центра обеспечения безопасности требует намного большего, чем просто поиск подходящего оборудования и специалистов. Работа над SOC превратится в непрерывный процесс, он поможет организации оперативно реагировать на постоянно возникающие угрозы безопасности, идти в ногу с технологиями и создавать комфортную среду, в которой легко поддерживать безопасность и производительность. С чего начать?
Оцените потенциал организации
Перед тем, как строить собственный Центр обеспечения безопасности, оцените потенциал организации и составьте подробный план по рискам. Приготовьтесь к тому, что столкнетесь с непрерывным потоком предупреждений о безопасности, в том числе ложных. А команда экспертов будет перегружена данными об угрозах и не всегда сможет эффективно их нейтрализовать и предупреждать.
Чтобы оценить потенциальные угрозы, ответьте на три ключевых вопроса:
Какие угрозы опасны для бизнеса?
Как выглядит каждая из этих угроз?
Как SOC будет их обнаруживать и блокировать?
Организация должна быть заинтересована в том, чтобы определить источники данных, которые помогут оперативно обнаруживать, блокировать и в будущем предупреждать угрозы. Основная информация поступает через события безопасности и сетевую активность, средства анализа угроз, инструменты авторизации. Дальше они попадают на платформу разведки безопасности, которая консолидирует сведения об угрозах, сопоставляет, идентифицирует и предупреждает о них экспертов SOC. И на последнем этапе в работу включается система управления и регистрации тикетов.
Помните о том, что нет организаций с неограниченными ресурсами для постоянной поддержки SOC. Рабочая нагрузка на Центр будет расти, и вам придется разрабатывать свои инструменты, которые позволят как минимум различать реальные и ложные инциденты безопасности.
Приготовьтесь к тому, что информационная нагрузка на экспертов увеличится
Соберите команду экспертов
Работа команды экспертов по безопасности зависит от организации, ее целей и потребностей. Это может быть служба безопасности, постоянная команда внутри организации, внешняя команда ИТ-специалистов и специалистов по кибербезопасности или комбинированный вариант.
В Центр обеспечения безопасности следует нанимать квалифицированный и сертифицированный персонал. Так как проблемы и угрозы постоянно меняются, вам нужны люди, которые быстро учатся, легко адаптируются и могут мыслить нестандартно там, где нужно оперативно принимать решения. Лучше всего привлекать в SOC действующих сотрудников из IT-подразделения.
Будьте в курсе новых угроз
Следите за тенденциями в среде компьютерной безопасности и держите руку на пульсе актуальных отраслевых практик. Старайтесь в числе первых узнавать о новых угрозах и обеспечьте необходимыми знаниями и навыками команду Центра. Методы обнаружения и защиты, которые были эффективными два-три года назад, вероятно, потеряли актуальность и не соответствуют текущим угрозам.
Разработайте модель работы SOC
SOC может работать централизованно или децентрализованно. В первом случае в Глобальный центр обеспечения безопасности (GSOC) компании из отдельных офисов поступают оповещения, видео с камер наблюдения и другая разведывательная информация. В децентрализованной модели региональные SOC функционируют обособленно и передают в главный офис только важную информацию. В любом случае вам нужно установить тесные связи между командами экспертов по безопасности, сотрудниками IT и других подразделений.
Обеспечьте инфраструктуру для поддержки SOC
Оборудование для SOC включает системы контроля доступа, системы обнаружения вторжений, консоли и другое оборудование, а связующим звеном выступает специализированное программное обеспечение. Полностью укомплектованный Центр обеспечения безопасности должен работать в режиме 24/7, иначе в нем нет смысла.
Из инструментов для реализации SOC потребуются:
Удобно использовать их не по отдельности, а комплексно, предварительно интегрировав в бизнес-процессы организации.
Если вы серьезно настроены на внедрение SOC, рекомендуем ознакомиться с электронной книгой Ten Strategies of a World-Class Cybersecurity Operations Center Карсона Циммермана. Обратите внимание на Приложение В с тестом «Нужен ли вам SOC?». Уделите ему 20 минут, и вы поймете, чего стоит ожидать от Центра обеспечения безопасности и насколько вы готовы к его внедрению.
«ИТ Гильдия» предлагает внедрение услуги « Управление обеспечением безопасности » — приложение от ServiceNow поможет выявлять и оперативно реагировать на инциденты безопасности и уязвимости. Оформите заявку на сайте компании, и наши эксперты ответят на интересующие вопросы.
Разбегаются глаза. Какую модель функционирования SOC выбрать?
BIS Journal №4(43)/2021
Разбегаются глаза. Какую модель функционирования SOC выбрать?
На многих мероприятиях, связанных с центрами мониторинга и реагирования на инциденты, очень часто противопоставляются две модели организации SOC – целиком собственный и внешний, коммерческий, которому функция мониторинга передаётся на аутсорсинг.
У каждой из этих полярных позиций есть свои сторонники и противники. Сторонники коммерческих SOC, которые, как правило, в этих центрах и работают, ратуют за то, что они оказывают профессиональные услуги в режиме 24×7 и имеют в штате высококлассных аналитиков и специалистов. Сторонники противоположной позиции считают, что, строя собственный SOC, не будут утеряны компетенции сотрудников, а также не будет потерян контроль над достаточно чувствительной информацией. Кто же прав? Какой из двух вариантов построения SOC является правильным?
Участвуя в полутора десятках проектов по построению или аудиту центров мониторинга, а также имея доступ к базе данных по сотне коммерческих и такому же количеству построенных SOC, могу сказать, что неправы обе стороны. Да, это звучит парадоксально, но это так. Дело в том, что существует гораздо больше моделей построения SOC, чем названные две, и выбираются они с опорой на множество факторов, которые надо принимать в расчёт. Давайте попробуем в них разобраться и в итоге ответить на вопрос, какой из множества моделей отдать предпочтение. Но для начала я попрошу вас ответить на 5 вопросов:
МОДЕЛЬ «МОГУ И ХОЧУ»
Это та модель, когда мы имеем и возможности, и ресурсы для построения собственного центра мониторинга. В этом случае мы закупаем нужные инструменты или создаём их своими руками, нанимаем высококлассных аналитиков и разрабатываем для них как план обучения, так и карьерный путь развития (а иначе они уйдут от нас, когда поднаберутся опыта), мы покупаем подписку на сервисы Threat Intelligence. При этом мы готовы к достаточно небольшой скорости развёртывания собственного центра – обычно этот срок занимает от года и выше, и это ещё оптимистичная оценка. SOC постоянно развивается, и на достаточно зрелый уровень он выходит только через 2–3 года эксплуатации.
Считается, и это неслучайно, что основные затраты при построении собственного SOC приходятся на закупку решений, составляющих технологический стек будущего центра мониторинга – SIEM для сбора сигналов тревоги, SOAR/IRP для управления инцидентами и автоматизации реагирования, TIP для обработки данных об угрозах, платформу для взаимодействия аналитиков и членов команды реагирования, платформу для хранения и обмена знаниями. SOC нового поколения также включает, помимо SIEM, ещё и решение по анализу сетевого трафика (NTA или NDR), решение по мониторингу активности на оконечных устройствах (EDR), а также при необходимости решение по мониторингу облачных сред (CASB). Если добавить сюда различные утилиты для проведения форензики (анализа памяти, реверс-инжиниринга), хранилище данных, сервера и персональные компьютеры, то сумма выходит достаточно кругленькая.
Отчасти поэтому, чтобы снизить риски санкций (как американских, мешающих использованию некоторых отечественных решений, так и российских, называющихся «импортозамещением»), а также для получения большей гибкости в решаемых задачах, многие компании строят свои SOC на компонентах opensource (например, связка ELK + MISP + TheHive), а также используют иные способы экономии (рис. 1).
Рисунок 1. Экономические аспекты оценки модели построения SOC
А ведь в собственном SOC нам надо ещё посчитать фонд оплаты труда для недешёвых аналитиков, работающих в 2–3 смены, их обучение, мебель, помещение и даже шредеры для уничтожения бумаг. В целом собственный SOC – это удовольствие недешёвое.
МОДЕЛЬ «ХОЧУ, НО НЕ МОГУ»
На противоположной стороне у нас находится аутсорсинговый SOC, услугами которого мы пользуемся, чтобы снять с себя все хлопоты по мониторингу и реагированию на инциденты. В этом случае все описанные ранее затраты у нас ложатся на выбранного партнёра, а мы уходим от модели капитальных затрат к операционным, которые выплачиваются небольшими частями ежегодно или ежеквартально; последний вариант, однако, у нас в регионе не очень развит. Учитывая полную противоположность этой модели, можно даже привести таблицу их сравнения, которая покажет плюсы и минусы обоих вариантов (рис. 2).
Рисунок 2. Сравнение двух основных подходов к построению SOC
Вроде бы кажется, что аутсорсинговый SOC обладает всеми преимуществами и не имеет недостатков, но это не так. Во-первых, в этом варианте построения центра мониторинга мы со временем теряем собственные компетенции и, если нам придётся по каким-то причинам расстаться с выбранным партнёром, мы останемся у разбитого корыта – никто нам уже не поможет оперативно разобраться с нашими инцидентами ИБ. Во-вторых, аутсорсинговый SOC всё равно требует контроля со стороны заказчика, что также требует и определённого инструментария, и персонала, который будет как минимум проводить анализ защищённости SOC (пентестеры или red team), а также оценивать результаты работы внешнего SOC и быть посредником между ним и внутренней ИТ-службой, которая должна будет реализовывать рекомендации по реагированию на инциденты и устранению причин, к ним приведших. В-третьих, любая внешняя организация гораздо хуже разбирается в вашей внутренней инфраструктуре, бизнес- и иных процессах, и поэтому реакция на некоторые инциденты может быть не всегда той, которую вы ждёте или которая лучше всего подходит к вашей ситуации. В-четвёртых, любая внешняя компания предлагает обычно типизированные сервисы, которые подходят большинству заказчиков. Если вы захотите чего-то особенного и выходящего за рамки привычных услуг SOC или их наполнения, то вам придётся раскошелиться – на коннекторы к вашим бизнес-системам, на особые условия реагирования (например, для изолированных систем), на написание собственных правил обнаружения и т. п. Ну и, наконец, не забывайте, что канал связи с вашим аутсорсинговым SOC может вдруг выйти из строя, снизится его пропускная способность или качество обслуживания, что тоже повлияет на оказываемые вам услуги SOC.
По опыту могу сказать, что аутсорсинг часто является промежуточным этапом при построении собственного SOC. Пользуясь услугами внешнего провайдера, мы изучаем процессы мониторинга и реагирования, обращаем внимания на сильные и слабые стороны этих процессов, перенимаем опыт и формируем собственный экспертный опыт, чтобы через несколько лет уже целиком строить свой центр мониторинга.
МОДЕЛЬ «ЕСТЬ ЧЕМ, НО НЕ С КЕМ»
Но существуют и иные модели организации центров мониторинга. Например, нередка ситуация, когда в организации есть весь необходимый инструментарий для сбора сигналов тревоги и расследования инцидентов, но нет людей для этого. Причём причиной может быть как нехватка денег на квалифицированные кадры, так и внутренняя политика компании, которая имеет чётко определённую численность разных подразделений и не может увеличивать её по своему желанию. В этом случае у нас получается SOC по модели «Managed SIEM» (условное название), в котором мы берём от внешнего SOC только персонал (аутстаффинг), который либо располагается на нашей территории, либо подключается к нашим техническим решениям удалённо.
В этой модели промежуточного SOC основной головной болью будет контроль персонала, получившего доступ к нашей инфраструктуре гораздо более глубокий, чем в случае с аутсорсингом, при котором аналитики и специалисты по реагированию работают с инструментарием, расположенным на своей территории. Кроме того, придётся открывать большее число каналов для доступа к SIEM, IRP, TIP и т. п., что может быть небезопасно, особенно если злоумышленники сначала атакуют провайдера услуг SOC, а через него уже и самих его заказчиков. По данным SOC Секретной службы США, начиная с 2019 года число атак на провайдеров услуг многократно возросло (только в 2019-м их было более 60). Размещение внешнего персонала на своей территории в этом случае выглядит предпочтительнее, но тогда придётся задуматься о выделении отдельного помещения, а то и не одного, для этих людей.
МОДЕЛЬ «ЕСТЬ С КЕМ, НО НЕЧЕМ»
Четвёртая распространённая модель построения SOCзаключается в том, что у компании могут быть квалифицированные специалисты, но нет ресурсов на закупку дорогостоящих коммерческих SIEM, SOAR, TIP и т. п. В этом случае нам остаётся либо осваивать opensource (в таком случае эта модель превращается в первую), либо обращаться к услугам инструментов, развёрнутых в облаке (условно эту модель можно назвать SIEM-as-a-Service). Последний вариант, кстати, является достаточно неплохой альтернативой в случаях, когда вы редко сталкиваетесь с продвинутыми злоумышленниками, а про государственных хакеров слышали только по ТВ или читали в Интернете. В этом случае вам необязательно строить дорогостоящий SOC, но функции мониторинга и анализа событий безопасности вам всё равно нужны.
Эта модель позволяет быстро проверять новые возможности и гипотезы без установки нового ПО (достаточно просто «на время» арендовать услугу из облака). Отсутствие необходимости установки ПО (а по статистике 45% компаний тратит только на внедрение SIEM более 3 месяцев) также снимает с нас головную боль по его масштабированию, обновлению, устранению уязвимостей и т. п. Также в зависимости от выбранной платформы в неё уже могут быть встроены различные плейбуки (дежурные процедуры реагирования), представлен каталог сценариев (usecase), применяться инструментарии обогащения событий и т. п.
ЧЕТЫРЕ МОДЕЛИ
Рисунок 3. Четыре основных модели построения технологического стека SOC
В итоге у нас получается четыре основных модели построения центра мониторинга и реагирования на инциденты ИБ, из которых Managed SIEM является наиболее редкой. И у каждой из этих моделей есть свои преимущества и недостатки, которые не дают однозначного выбора в пользу одной из них (рис. 3, 4).
Рисунок 4. Экспресс-сравнение основных моделей построения технологического стека SOC
МОДЕЛЬ «ВСЕГО ПОНЕМНОГУ»
Но не стоит думать, что этими четырьмя моделями всё ограничивается. На самом деле существуют и различные промежуточные варианты, которые находятся где-то между всеми этими моделями. Например, мало кто содержит собственных специалистов по реверс-инжинирингу вредоносного ПО. Эта функция отдаётся обычно на аутсорсинг, и то не на постоянной основе, а эпизодически, по мере появления ранее неизвестного ПО, которое вызывает подозрения, но на которое никак не реагирует имеющаяся песочница.
Другой пример. Согласно статистике некоторых российских коммерческих SOC число их заказчиков, выбравших не только мониторинг, но ещё и реагирование на выявленные инциденты, невелико – всего около 15%. Иными словами, 85% пользователей аутсорсинговых SOC отдают только мониторинг, но реагирование оставляют за собой, что требует не только соответствующих инструментов, но и специалистов.
Третий вариант гибридной модели заключается в том, что на стороне внешнего SOC реализуется только первая линия анализа событий безопасности, которые после обработки, классификации, приоритизации и объединения в инциденты, попадают на вторую и третью линию, расположенную уже на стороне заказчика. Кстати, возможен и противоположный вариант – первичный анализ осуществляется на стороне заказчика, а анализ со стороны более квалифицированных аналитиков требует привлечения внешнего SOC. А анализ в нерабочее время, выходные и праздничные дни? Кто его осуществлять будет, если у вас нет возможности обеспечить работу центра в режиме 7×24, а только в режиме 5×8?
А ведь мы рассмотрели только основные услуги, которые оказывает SOC, –мониторинг и реагирование на инциденты. А redteam’инг или фишинговые симуляции, которые тоже могут входить в сервисный каталог центра мониторинга?
ЧТО ВЫБРАТЬ?
Какую же тогда модель центра мониторинга и реагирования на инциденты выбрать? Какая из них будет более правильной? Может показаться, что ответа нет, но это не так. Он есть, и называется он «сервисная стратегия SOC». В ней определяются все исходные данные, которые влияют на выбор модели, – имеющиеся ресурсы, ожидания, желаемые результаты и сроки их достижения, распределённость компании и функционирование в разных часовых поясах и юрисдикциях, наличие инсорсинговой компании в холдинге, временные параметры, модель нарушителя, требования законодательства, квалификация персонала, возможности ИТ-службы, зависимость бизнеса от информационных технологий, культура компании. И это только часть вопросов, которые повлияют на решение о том, какой модели SOC надо придерживаться (рис. 5).
Рисунок 5. Компоненты сервисной стратегии SOC
Главное, задать эти вопросы в самом начале пути под названием «центр мониторинга и реагирования на инциденты ИБ». Именно ответы на них позволят не только определить модель функционирования SOC, но и оказываемые им сервисы, ключевые процессы, необходимые для их реализации, оргштатную структуру и режим работы аналитиков SOC, программу их обучения и т. п. И только в самом конце мы подойдём к вопросу архитектуры SOC и технологического стека, лежащего в её основе. И только в таком порядке. Удачи вам на этом непростом пути!
Чек-лист: проверьте, все ли «умеет» ваш SOC?
Какие задачи должен решать SOC? С ответа на этот вопрос целесообразно начинать проект создания ситуационного центра управления информационной безопасностью (Security Operation Center, SOC). Ринат Сагиров, ведущий консультант Центра информационной безопасности компании «Инфосистемы Джет», помог разобраться, что должен «уметь» современный SOC, и составить список по этой теме для чек-листа – нового формата TAdviser, в котором эксперты делятся полезной прикладной информацией, советами и инструкциями по применению различных технологий.
Содержание
Что может делать ваш SOC
SOC решает не только задачи по мониторингу и реагированию на инциденты информационной безопасности, но и в принципе любые другие операционные задачи в области ИБ (secops).
Многие компании при организации SOC ошибочно фокусируются на его техническом оснащении и только потом приступают к выстраиванию процессов и определению необходимого персонала. Между тем, целесообразно начинать с ответа на вопросы: для чего компании нужен SOC, и какие задачи он должен решать. Это поможет сформировать целевую модель планируемого SOC, исходя из целевого набора его функций или сервисов (если в компании внедрена сервисно-ориентированная модель). Например, MITRE выделяет порядка 40 функций SOC.
«Персонал—процессы—технологии» — основные компоненты SOC
После выбора целевого набора функций SOC эксперты рекомендуют переходить к разработке целевой модели, определяющей его основные компоненты в разрезе классической триады «персонал—процессы—технологии».
Целевая модель SOC помогает решить: какие процессы нужны; какие технологии требуются для автоматизации процессов; какой персонал необходим для реализации процессов и поддержки технологий.
Правильной формулы состава SOC не существует. У каждой компании свой путь и свой «обязательный» набор SOC. Состав очень сильно зависит от целевого набора функций SOC и объема решаемых им задач.
Компаниям с небольшой областью покрытия мониторинга будет достаточно централизованно собирать, фильтровать и нормализовать события с инфраструктуры c помощью систем управления логами (Log Management System) и выстроить процесс управления инцидентами ИБ, чтобы команда из 2–3 человек могла эффективно решать поставленные задачи.
Компаниям с разнообразным стеком технологий, распределенной ИТ-инфраструктурой и большим парком ИТ-средств для решения задач мониторинга и реагирования требуется большая команда SOC, которая способна использовать процессы в связке с технологиями, осуществлять их поддержку и развитие.
Остановимся подробно на отдельных составляющих SOC, исходя из базовой функциональности, включающей обнаружение и анализ нарушений ИБ в режиме реального времени, реагирование на инциденты и информирование всех заинтересованных сторон в компании о текущем уровне защищенности.
«Персонал»: какая команда нужна для обеспечения работы SOC
Организационная структура SOC зависит от его функций, поэтому четких критериев, которые бы определили точную численность персонала, нет. Для реализации базового функционала в команду SOC нужно включать специалистов, которые будут решать следующие задачи: мониторинг событий ИБ; регистрация и классификация подозрений на инцидент ИБ; сбор необходимых данных для анализа подозрения на инцидент ИБ; анализ подозрений на инцидент ИБ с целью его идентификации; координация реагирования на инциденты ИБ; администрирование технических инструментов SOC; развитие инфраструктуры SOC.
Основной состав команды стоит сформировать как можно раньше, чтобы он участвовал во внедрении систем и отладке процессов. Хорошим бэкграундом для сотрудника SOC является опыт администрирования ИТ-систем и сетевой инфраструктуры, внедрения и администрирования СЗИ, а также навыки по проведению тестирования на проникновение.
«Процессы»: какие процессы нужны для эффективной реализации функций SOC
Распространенной ошибкой при создании SOC является неправильное выстраивание процессов: нередко регламентирующая их документация оказывается нежизнеспособной и «уходит в стол». В результате вооруженные техническими средствами специалисты остаются без четкого понимания стоящих перед ними задач и без детальных инструкций по их выполнению. В таких условиях организовать продуктивное взаимодействие внутри SOC и со смежными подразделениями крайне сложно.
Для эффективности SOC рекомендуется моделировать процессы уровня управления и операционного уровня. Первые помогут обеспечить его развитие и заданный уровень качества реализации основного функционала. Вторые подразумевают выстраивание основных (т.е. напрямую связанных с реализацией целевого функционала) и вспомогательных процессов. Последние служат для определения подходов к подключению источников событий, развитию корреляционной логики, решению задач траблшутинга и актуализации перечня информационных активов в области мониторинга и данных об этих активах.
Как избежать ошибок при выстраивании процессов SOC
Подключите все заинтересованные подразделения к моделированию процессов; Закрепите зоны ответственности специалистов и определите наиболее удобные каналы коммуникаций между ними; Проведите пилотное тестирование по итогам моделирования; Проведите обучение всех, кто будет задействован в реализации процессов, с разбором реальных кейсов; Разработайте набор метрик, чтобы оценить правильность функционирования процесса.
«Технологии»: с помощью каких решений автоматизировать процессы SOC
Крупный SOC желательно оснастить инструментами для автоматизации выстроенных процессов.
SIEM-система помогает автоматизировать выявление инцидентов ИБ за счет сбора, корреляции и анализа событий ИБ с элементов ИТ-инфраструктуры и средств защиты информации.
IRP/SOAR-системы (Incident Response Platform / Resilient Security Orchestration, Automation and Response) повышают скорость реакции на инциденты за счет автоматизации рутинных задач по их обработке. Например, с их помощью удастся сэкономить время на регистрации, классификации (определении категории и уровня критичности), заполнении карточки инцидента, обогащении событиями для анализа, проверке на вредоносность индикаторов компрометации и выполнении действий по реагированию. В решениях этого класса можно настроить сценарии реагирования под каждую категорию инцидентов, что поможет автоматизировать весь жизненный цикл управления ими.
SOC может применять системы IRP/SOAR не только для управления инцидентами ИБ, но и для решения дополнительных задач.
Инвентаризация и контроль ИТ-инфраструктуры
При наличии в системе модуля управления активами можно реализовать контроль актуальности состава ИТ-инфраструктуры и решить проблему теневых ИТ (Shadow IT). Все это осуществляется в тесном взаимодействии с другими инфраструктурными системами: CMDB, корпоративный домен, системы управления ИТ-инфраструктурой. Управление уязвимостями в инфраструктуре
С помощью системы можно не только выявлять и регистрировать, но и приоритизировать уязвимости по уровням критичности информационных активов, автоматически назначать ответственных и сроки устранения.
Threat Intelligence Platform помогают автоматизировать задачи, связанные с использованием данных киберразведки (Threat Intelligence). К таким задачам можно отнести сбор и обработку индикаторов компрометации с последующим ретроспективным анализом событий ИБ на наличие получаемых индикаторов компрометации.
Что должен выявлять SOC
При строительстве SOC часто возникают сложности с пониманием того, какие инциденты он должен выявлять. Эту задачу решает его технологическое ядро — SIEM-система — путем корреляции событий ИБ, собираемых с элементов ИТ-инфраструктуры и средств защиты. Вендоры поставляют SIEM с большим количеством разработанных правил корреляции, которые остается только адаптировать под реалии конкретной ИТ-инфраструктуры. Или же можно написать свои правила, ориентируясь на популярный фреймворк MITRE ATT&CK с практиками выявления известных техник атак.
Не стоит ожидать, что правило корреляции сможет обнаружить полный вектор реализации угрозы ИБ. Вероятность того, что из всего многообразия тактик и техник злоумышленник выберет именно поставленные на мониторинг, ничтожно мала. Поэтому лучше разрабатывать правила корреляции, направленные на выявление атомарных событий реализации конкретных техник актуальных угроз.
Как разработать сценарную базу Определите актуальные угрозы ИБ для подключаемой ИТ-инфраструктуры; Установите сценарии действий (тактики) для реализации каждой угрозы ИБ; Выявите уязвимости, которые могут быть использованы в рамках конкретной тактики; Обозначьте способы (техники) реализации уязвимостей; Определите способы выявления реализации техники — набор событий ИБ, который указывает на попытки исполнения или осуществление конкретной техники, таких как:
— события обнаружения индикаторов компрометации (IP-адрес, URL, хеши файлов и т.д.);
— события обнаружения ПО, позволяющих реализовать технику;
— события обнаружения действий, предпринимаемых в рамках реализации техник. Проведите тестирование на проникновение, чтобы убедиться, что выбранные техники реализации угроз ИБ действительно актуальны для компании.
Аналитика
Возникающие события ИБ в инфраструктуре В первую очередь SOC должен анализировать события ИБ в элементах ИТ-инфраструктуры и средствах защиты информации для выявления инцидентов ИБ. Это нужно делать не только в режиме реального времени, но и в ретроспективе за заданный промежуток времени. Так вы сможете обнаружить пропущенные инциденты ИБ.
Постинцидентный анализ Чтобы инцидент не повторялся, важно анализировать результаты реагирования. Нужно разобраться, почему инцидент произошел и насколько эффективными были принятые меры по его устранению. После этого можно приступать к разработке рекомендаций: скорректировать настройки средств защиты, внести изменения в правила выявления инцидентов, изменить планы по реагированию и т.д.
Контроль метрик SOC Отслеживание значений метрик позволяет вовремя выявить и устранить проблемы, которые можно обнаружить как в организации процесса, так и в реализующем его персонале. Для SOC могут быть полезны, например, следующие метрики: доля инцидентов с соблюдением сроков реагирования; среднее время идентификации инцидентов ИБ; среднее время реагирования на инцидент (по уровням критичности).
Визуализация отчетности Аналитика по деятельности SOC отображается на дашбордах в виде виджетов — всевозможных таблиц и диаграмм, сгруппированных по смыслу на одном экране. Системы, входящие в технологическое ядро SOC (SIEM, IRP/SOAR), способны формировать множество типов виджетов любого состава и конфигурации. Чаще всего разрабатываются дашборды операционного и тактического уровней. Первые демонстрируют срез по текущей картине состояния ИБ: новые и открытые инциденты, их приоритеты, загрузку персонала, соблюдение сроков и т.д. Вторые предоставляют статистику по деятельности за последний месяц: распределение по категориям инцидентов и объектам атак, среднее время выявления и реагирования на инцидент, метрики эффективности.
Другой способ визуализации отчетности — представление данных по инциденту ИБ в виде графов или интерактивных схем и карт сетей. Такой способ демонстрирует: источник инцидента ИБ; информационные активы в корпоративной сети, подверженные атаке; скомпрометированные учетные записи; возможную связность одних инцидентов ИБ с другими для выявления цепочки атаки.
Новые тенденции
Поиск предпосылок к проведению атак В последнее время фокус ИБ смещается с выявления уже совершенных негативных действий в инфраструктуре в сторону обнаружения предпосылок к проведению атак. Другими словами, специалисты стремятся выявлять атаки на более ранних стадиях в соответствии с цепочкой Kill Chain, описывающей универсальный сценарий действий злоумышленника.
Для реализации такой концепции SOC нужны инструменты, которые не только выявляют сигнатурную активность, но и фиксируют и анализируют аномальное поведение, тем самым позволяя детектировать целенаправленные атаки с использованием неизвестного вредоносного кода, скомпрометированных учетных записей, бесфайловых методов, легитимных приложений и действий, не несущих под собой ничего подозрительного. Компания Gartner позиционирует связку NTA (Network Traffic Analysis), EDR (Endpoint Detection and Response) и SIEM как набор необходимых технических средств для организации максимально полного мониторинга инфраструктуры и выявления угроз, нацеленных на обход традиционных средств защиты.
EDR Рабочие места остаются ключевой целью злоумышленников и самыми распространенными точками входа в инфраструктуру компании. Конечные точки подключают к SIEM в качестве событий для мониторинга инцидентов редко или частично — только самые критичные. Это обусловлено в первую очередь высокой стоимостью сбора и обработки журналов со всех конечных станций, а также генерацией огромного количества событий для разбора, что зачастую приводит к перегрузке персонала SOC. Для детектирования событий на конечных узлах в инфраструктуре можно использовать решение класса EDR, которое поможет выявлять аномальное поведение на конечных хостах.
NTA Сетевой трафик — один из важных источников событий для выявления инцидентов ИБ. Часто вместо его полноценного анализа ограничиваются сбором логов со стандартных сетевых средств защиты и сетевого оборудования. Автоматизировать сбор и анализ событий внутри трафика можно с помощью решений класса NTA. В отличие от стандартных инструментов выявления сетевых атак, они оперируют большими объемами трафика, что дает возможность выявлять цепочку атаки целиком, а не довольствоваться срабатыванием единичной сигнатуры. Система класса NTA может быть полезна в выявлении неизвестных угроз за счет поведенческого анализа трафика.
Deception Tool Исследователи Gartner называют Deception одной из наиболее важных новых технологий в ИБ. Решения этого класса выявляют в ИТ-инфраструктуре совершаемые при APT-атаке вредоносные действия, которые часто остаются незаметными для стандартных ИБ-средств. Системы Deception создают активные ловушки и фейковые ресурсы, в полной мере имитирующие постоянную работу реальных пользователей, программных и программно-технических комплексов, функционирующих в ИТ-инфраструктуре. Такие ловушки дают злоумышленнику возможность успешно их атаковать и добиваться мнимых результатов нападения, тем самым выигрывая для команды SOC время на реагирование.
Breach and Attack Simulation (BAS) Активно развиваются и системы класса BAS, которые позволяют частично автоматизировать функционал тестирования на проникновение. Также они могут быть полезны при проведении киберучений, когда нужно отработать практические навыки персонала SOC по оперативному выявлению и реагированию на атаки.
О чем еще важно не забыть
«Песочница» Вырвавшийся на свободу вредонос, который аналитик решил проанализировать на основной машине, может оказаться серьезной угрозой. Для анализа вредоносного кода следует не забыть заложить в проект SOC полностью изолированную «песочницу».
Киберполигон Для киберучений понадобится киберполигон — симулятор, с помощью которого специалисты смогут обучиться отражать атаки и расследовать инциденты в боевом режиме. Кроме того, он пригодится и для тестирования новых средств защиты. По сути, это тестовая инфраструктура, которая никак не взаимодействует с основным ИТ-ландшафтом компании. В ней нужно обеспечить возможность имитации различных сценариев кибератак (DDoS, атак на ОС, Web, телеком-оборудование и Wi-Fi) и развернуть систему защиты, позволяющую выявлять и противодействовать им.
Защита самого SOC Для SOC нужно разработать отдельные, более строгие, стандарты обеспечения ИБ, чем для всей остальной компании. Инфраструктура SOC должна быть максимально разделена с корпоративной, сетевой сегмент отделен межсетевыми экранами и построен на отдельном сетевом оборудовании. Проще говоря, стоит исходить из того, что вся ИТ-инфраструктура компании уже скомпрометирована. При построении SOC нужно помнить, что его глаза и уши — это сетевые сенсоры, различные средства защиты информации, раскиданные по всей компании. Безопасный доступ к ним и их защита должны быть тщательно проработаны.
Вместо заключения
Строительство SOC — это длительный и ресурсозатратный проект. Классический подход к таким проектам можно сформулировать так: «Ешьте слона по частям».