Привет! Меня зовут Михаил Климов, я руководитель команды SOC в компании RED Security. Хочу поговорить про выбор SOC (Security Operation Center) — центра реагирования на инциденты информационной безопасности (ИБ). Вопрос актуален как никогда: в последнее время половина ленты Хабра посвящена кибератакам на бизнес, приняты законы, ужесточающие ответственность компаний за утечку персональных данных. Из-за этого многие директора по информационной безопасности обращаются к вопросу о создании процессов мониторинга событий ИБ в инфраструктуре и максимально быстрого реагирования на возможные кибератаки.
Но как выбрать тот самый SOC и определиться с моделью поставок — отдельный вопрос. Я часто сталкиваюсь с тем, что компании начинают строить внутренний центр мониторинга, тратят около года на проект, и все это время защищенность остается на прежнем неудовлетворительном уровне. Затем они понимают, что самостоятельно его реализовать сейчас не могут, и в итоге обращаются к аутсорсингу. И напротив, поработав несколько лет с внешними поставщиками сервисов SOC, переходят к созданию внутреннего центра мониторинга. Как же понять оптимальный вариант поставки для конкретной компании на определенном этапе, чтобы не потратить время и ресурсы впустую, двигаясь методом проб и ошибок? Что правильнее: строить собственный центр реагирования или выбрать одно из готовых решений от многочисленных аутсорсинговых сервис-провайдеров?
В этом посте я и мой коллега Ильназ Гатауллин, технический руководитель RED Security SOC, разобрали варианты организации SOC исходя из потребностей и ресурсов бизнеса.
Без чего не будет работать SOC
Чтобы обеспечить качественную защиту, SOC должен иметь доступ к информации со всех конечных точек сети (эндпоинтов), сетевому трафику и данным о сканировании внешнего периметра.
Это значит, что SOC обязан собирать информацию со всех внутренних серверов, принтеров, любого сетевого оборудования и устройств в периметре. Он также должен получать данные от киберразведки (Threat Intelligence), чтобы быстро и вовремя реагировать на подготовительные операции со стороны хакеров.
Самый продвинутый уровень — мониторинг процессов в реальном мире, например, доступ сотрудников к оборудованию. Это могут делать центры кризисного реагирования, которые есть только у очень больших компаний.
Если центр мониторинга SOC не имеет полной картины покрытия инфраструктуры и источников событий, то компания остается уязвимой. Чтобы SOC действительно приносил пользу, перед его запуском нужно подготовиться: понять, что именно будет защищать центр, описать инфраструктуру и подключить к SOC максимальное количество устройств по всему периметру.
Обычно у компании три варианта: построить свой SOC, обратиться к поставщику соответствующих сервисов за сторонним MSSP-решением или реализовать гибридную модель. Рассмотрим каждый из них подробнее.
In-house SOC: собственная команда из 10–15 человек
Как правило, это развлечение для крупного бизнеса из сфер, которые постоянно находятся под угрозой атак. У этих компаний есть достаточный объем ресурсов: вычислительных, финансовых, человеческих.
Особенно важна экспертиза и реальный опыт тех, кто будет обеспечивать работу SOC. Сотрудники должны знать ту SIEM-систему, которую компания планирует использовать в качестве технологического ядра SOC: уметь не только разбирать данные о событиях, но и наполнять ее новыми правилами корреляции для выявления инцидентов. Кроме того, они обязаны быстро — хотя бы в течение часа — на основе информации о инцидентах давать грамотные рекомендации по защите и митигации угрозы. Сотрудники SOC также должны узнавать почерк хакерских группировок, следить за информацией о новых техниках и тактиках атак, в идеале — проводить расследования и разрабатывать рекомендации по повышению общего уровня защищенности компании.
Что понадобится сделать
SOC не ограничивается только SIEM. В него входит целый набор различных программных решений, плюс он подразумевает постоянный штат ИБ-специалистов и аналитиков. Подготовку к созданию своего SOC можно разбить на такие шаги:
1. Создание SOC начинается с запуска процессов, необходимых для работы аналитиков, и внедрения SIEM: open-source или коммерческой.
2. К SIEM подключаются источники событий, и настраивается расширенный аудит. Для этого применяются такие утилиты, как Sysmon или auditd. Они позволяют получать больше информации о действиях в системе.
3. Включается фильтрация неинформативных событий. Пропускная способность SIEM может быть ограничена условиями лицензирования или объемом дискового пространства. Для фильтрации требуются аналитики, способные дать компетентное заключение, нужна ли SOC информация о том или ином событии.
4. Для поступающих в систему событий необходима обработка: нормализация, парсинг и выделение ключевой информации. Правила обычно приходится создавать самостоятельно ил как минимум дорабатывать те, которые поставщик SIEM-системы предлагает «из коробки».
5. Для кейс-менеджмента к SOC можно использовать ServiceDesk. Есть и более продвинутый вариант — IRP-система. Конечно, можно настроить для ответственных лиц оповещение по инцидентам напрямую из SIEM. Но это, как правило, неудобно: в SIEM нет карточек со статусами, возможностью эскалации и контроля ответственного.
6. Уже после введения SOC в эксплуатацию его по-прежнему нужно дорабатывать: оптимизировать процессы, уменьшать количество ложноположительных срабатываний, добавлять исключающие условия в корреляционные правила и так далее.
А развивать собственный SOC можно практически бесконечно — расширять направления работы, нанимать специалистов на более узкие задачи и углублять аналитику.
Какие требуются сотрудники
SOC — это постоянный мониторинг, для которого нужны люди. Минимальный набор для организации первой линии — пять человек. То есть по одному для каждой смены плюс сотрудник на замену, если кто-то заболеет или уйдет в отпуск.
В обязанности специалистов второй и третьей линий входит разработка корреляционных правил и корректировка существующих, улучшение детектирующей логики. Минимальное количество сотрудников для этих линий — два человека. Кроме того, могут понадобиться дополнительные специалисты:
можно нанять отдельного SIEM-администратора на поддержку SIEM и IRP, их интеграцию и автоматизацию;
расследованием инцидентов ИБ могут заниматься либо аналитики SOC второй и третьей линий, либо отдельные сотрудники — эксперты по реагированию на инциденты;
за добавление новых источников событий и поддержку существующих подключений отвечают SIEM-администраторы или SOC-инженеры — в зависимости от компании;
центру мониторинга нужен руководитель — глава SOC, который будет отвечать за организацию рабочих процессов, административные вопросы, координацию и управление других сотрудников.
Минимальное количество сотрудников для работы SOC — 8–10 человек. Но надо понимать, что речь идет о высококвалифицированных ИБ-специалистах, труд которых стоит недешево. Людей с нужным опытом, умеющих обрабатывать информацию, отделять ложное событие от истинного, не так много. Их тяжело найти и удержать в компании, ведь на них всегда есть спрос.
Все перечисленное может занимать годы работы и требовать больших вложений. Поэтому строить SOC самостоятельно имеет смысл, только если эта компания:
достаточно крупная, чтобы содержать дежурную смену и вторую-третью линии аналитиков и инженеров;
имеет мощности для хранения сотен терабайт логов о событиях безопасности;
на нее проводят целевые атаки, к которым злоумышленники готовятся месяцами и учитывают ее конкретные особенности.
Гибридная модель: сочетание своих и сторонних ресурсов
Это самый популярный сейчас вариант: одну часть инцидентов компания обрабатывает сама, а другую — силами стороннего SOC. SIEM обычно находится во внутреннем периметре заказчика. Поставщику предоставляют к ней административный доступ, а заказчику ограничивают. Так делают, чтобы избежать конфликтов и некорректной настройки системы.
Данные для оперативной обработки, доступ к которым нужен быстро, как правило, находятся на собственных мощностях. То есть информация об инцидентах не уходит в стороннюю компанию, а остается в контуре заказчика.
Распределяются роли по-разному: в зависимости от договоренностей то или иное действие может выполнять и заказчик, и поставщик. Приведем пример, как делают чаще всего, но в каждой конкретной ситуации условия сотрудничества различаются.
Чем занимается поставщик
Задачи мониторинга, как правило, передаются сервис-провайдеру. На аутсорс отдают действия, которые нужно выполнять максимально быстро и осуществлять круглосуточно. Поставщик проводит анализ подозрений на поступившие в SIEM инциденты. После этого:
выделяет «боевые» инциденты и сообщает о них заказчику;
дает рекомендации по устранению уязвимостей и дальнейшим действиям.
Кроме того, поставщик занимается поддержкой и обновлением SIEM, разработкой и дополнением корреляционных правил, правил нормализации, агрегации событий, исключением ложноположительных срабатываний. Если на стороне заказчика нет собственной IRP-системы или ServiceDesk, провайдер может предоставить свою — и вести карточки инцидентов в ней.
По законодательству информацию о киберинцидентах нужно передавать в НКЦКИ — Национальный координационный центр по компьютерным инцидентам. Этим также занимается провайдер, если он аккредитован как центр ГосСОПКА.
НКЦКИ анализирует инциденты, выдает рекомендации по защите и содействует реагированию на них
Что делает заказчик
Собственные специалисты обычно отвечают за чуть менее срочные, но масштабные задачи, например, за внедрение изменений и устранение уязвимостей. А еще заказчик сам подключает к SIEM-системе нужные источники по инструкции от сервис-провайдера.
Также заказчик может самостоятельно нанять в штат специалистов для поддержки SOC и реагирования на инциденты. Например, распределить задачи можно по такой схеме:
первая и вторая линии работают 24/7 и принадлежат подрядчику;
третья линия, которая обычно отвечает за детальный анализ артефактов инцидентов, находится на стороне компании и работает по графику 8/5.
Если закон требует соблюдать определенные условия по организации ИБ — за их выполнение также отвечает сам заказчик. Например, если компания обязана использовать отечественное ПО, то он сам должен контролировать, какие именно сервисы у него установлены.
Что отдавать подрядчику, а что реализовывать самостоятельно — в основном вопрос ресурсов заказчика. Например, у небольшого бизнеса может не быть компетенций или персонала, чтобы заниматься мониторингом, а у крупной компании проблем с этим скорее не возникнет.
MSSP-решение: сторонний SOC и как его выбрать
MSSP (Managed Security Service Provider) — компания, которая предоставляет фактически полный аутсорсинг SOC. Он пригодится, если у заказчика нет ресурсов для самостоятельной реализации даже отдельных элементов центра мониторинга. Кроме того, если компания хочет создать внутренний SOC, она часто подключает аутсорсинговый SOC на время подготовки проекта, чтобы получить целевой уровень защиты здесь и сейчас и постепенно налаживать внутри процессы и растить компетенции.
Как я говорил выше, для создания внутреннего SOC у компании должны быть определенные наработки по информационной безопасности. Как минимум:
SIEM-, IRP-системы;
процессы, обеспечивающие мониторинг и реагирование на инциденты ИБ;
документация и инструкции;
обученные сотрудники.
Если у компании ничего из этого нет, она обычно отдает весь мониторинг внешнему поставщику сервиса SOC. В рамках MSSP-решения поставщик берет на себя все задачи по установке и настройке компонентов SIEM, разработки правил корреляции, нормализации и агрегации. Он также занимается поддержкой SIEM и предоставляет IRP-решение для ведения кейс-менеджмента. Сервис-провайдер анализирует инциденты и хранит данные о них и о событиях на своих мощностях, поэтому заказчику нет необходимости искать значительный объем вычислительных ресурсов.
В чем удобство для клиента
По сравнению с гибридной моделью у MSSP есть несколько особенностей. Они связаны с тем, что инфраструктура SOC настроена на стороне провайдера и уже развернута. Часто это становится преимуществом для клиента. Вот почему:
скорость подключения MSSP-решения намного выше, чем гибридного или собственного, в среднем на него уходит 1–2 месяца;
заказчику не приходится самостоятельно поддерживать инфраструктуру SOC — этим занимается поставщик;
заказчику не нужно самому искать и онбордить специалистов;
у провайдера уже есть наработанный опыт в решении актуальных задач, он знает, чего ожидать, и лучше разбирается в сфере.
Поэтому MSSP-решение подойдет компаниям, у которых нет профильных ИБ-экспертов для мониторинга инцидентов.
На что обратить внимание
Даже при выборе в пользу MSSP нужно понимать, что вовлеченность заказчика в процесс мониторинга необходима. Он должен как минимум активно взаимодействовать с поставщиком, соблюдать его рекомендации, получать и давать обратную связь. Контроль за процессами также находится на его стороне.
MSSP подразумевает определенную зависимость от поставщика. Тем, кому это не подходит, лучше выбрать гибридную модель. Например, если компания не готова отдавать данные о своих инцидентах на сторонние сервера или имеет очень большую инфраструктуру с сотнями тысяч событий в секунду.
Выбор поставщика — тоже ответственность заказчика. Можно опираться на производительность, репутацию компании и другие факты. Например, стоит оценить:
наличие и разнообразие дополнительных услуг — подключение нестандартных источников данных;
ограничения по EDR-агентам — количество, возможность и стоимость установки дополнительных;
полноту обратной связи — скорость и детализацию отчетов о событиях, реагирование на комментарии.
Как правило, MSSP-провайдеры дают возможность провести пилотный проект, чтобы заказчик мог лично проверить уровень и качество сервисов. Для проверки эффективности работы SOC заказчик может провести пентест — собственными силами или с привлечением внешних экспертов по анализу защищенности. Это покажет, насколько SOC хорош в условиях, «приближенных к боевым».
Важно учитывать, что во время пилотного проекта действуют ограничения по количеству подключаемых к мониторингу источников и правил корреляции по сравнению с сервисом, оказываемым в проде.
Какое бы решение вы ни выбрали, помните, что SOC — это процесс. Чтобы он работал эффективно, нужна системность и всесторонний подход. Поэтому не пренебрегайте обучением сотрудников, построением архитектуры ИБ и регламентами. Начните с них, а задуматься о центре мониторинга можно уже после этого.
Если вы присматриваетесь к SOC и у вас есть вопросы, пишите их в комментариях, постараюсь помочь.