Лучшие практики по организации работы SOC и VOC

Лучшие практики по организации работы SOC и VOC

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

Цели и особенности процессов

В то время как основная функция SOC — ​это обнаружение, локализация и расследование активных компьютерных атак и инцидентов, VOC занимается непрерывным выявлением, оценкой критичности и координацией устранения уязвимостей и конфигурационных ошибок. Чтобы процесс объединения и разделения функций прошёл быстро и плавно, мы предлагаем выделить основные параметры и сравнить их между собой (таблица 1).

От разделённых процессов к общей системе

Сравнивая SOC и VOC, можно также подметить, что они скорее всего будут покрывать не только разные вектора работы и отличающиеся средства защиты информации (СЗИ), но скорее всего работать в разных горизонтах планирования: SOC сфокусируется на минутах и часах с момента события, а VOC — ​закроет среднесрочный и долгосрочный (планирование патчинга, архитектурные изменения) интервал. Но самое интересное проявляется на стыке их функций:

• VOC поставляет в SOC детализированные сценарии возможных атак на основе обнаруженных уязвимостей, что позволяет аналитикам SOC оптимизировать правила корреляции в SIEM-системах и отсекать ложноположительные алерты.
• SOC, в свою очередь, передаёт в VOC информацию об активных попытках эксплуатации уязвимостей на конкретных узлах сети, что позволяет мгновенно переопределять приоритеты устранения брешей, переводя номинально «средние» уязвимости в категорию критических, если они находятся под активным огнём в реальном времени.
• Формирование обоих центров (отдельно или в рамках общей платформы) позволяет также устранить «исполнительский разрыв» из-за институционального разделения обязанностей: подразделение ИБ выявляет уязвимости и формирует требования по безопасности, но непосредственные действия по патчингу, изменению конфигураций и администрированию систем выполняются ИТ-департаментом или командой DevSecOps.

Особенности архитектуры

Программные комплексы нового поколения, такие как Security Vision, спроектированы для максимальной автоматизации устранения человеческого фактора. Более того, если платформа даёт возможности для быстрой и самостоятельной интеграции систем, скорость внедрения и адаптации к любым изменениям больше не будет зависеть от вендоров и их собственных планов по развитию продуктов и их API.

В любом случае, даже если не использовать единую платформу, можно выделить три модели развёртывания и эксплуатации:

1. Собственный центр (in-house). Такой подход обеспечит полный контроль над данными, глубокое понимание специфики бизнеса, минимальные риски нарушения конфиденциальности. С другой стороны, затраты на инфраструктуру и лицензирование, сложности с удержанием редких экспертов, отсутствие круглосуточного покрытия в небольших командах ограничивают область применения (крупные корпорации, государственные структуры, финансовые организации, владельцы объектов критической информационной инфраструктуры (КИИ)).
2. Аутсорсинг (MSSP, SaaS). Самый быстрый старт (time-to-market), предсказуемая стоимость по сервисной модели (SLA), круглосуточный мониторинг 24/7/365, доступ к экспертизе провайдера. Но ограниченная кастомизация под нестандартные процессы, риски утечки данных, зависимость от каналов связи и SLA провайдера больше подходят для среднего бизнеса и организаций с жёсткими ограничениями по штатной численности ИБ-специалистов.
3. Гибридная модель. Оптимальный баланс: внутренняя команда сохраняет управление и контроль за критическими активами, внешняя — ​берёт на себя рутинную фильтрацию L1 и ночные смены. Сложность разграничения ответственности, необходимость построения прозрачных каналов интеграции между локальными и внешними системами подходят для компаний со зрелыми процессами, стремящихся оптимизировать затраты без потери контроля над ключевыми рисками.

Статистические исследования [1] фиксируют устойчивую динамику: доля организаций, предпочитающих полностью внутреннее управление процессами VOC (или аналогичных специализированных групп), выросла до 41% (по сравнению с 30% в предыдущих аналитических циклах). Бизнес начинает рассматривать координацию устранения уязвимостей как стратегическую функцию внутреннего управления рисками, которую невозможно полностью делегировать внешнему подрядчику. При этом общая доля компаний, внедривших или находящихся на этапе активного развёртывания моделей, эквивалентных VOC, достигла 65%.

Отраслевая специфика и рекомендации по построению интегрированного центра

В IT и разработке ПО критичны атаки через цепочки поставок и уязвимости в собственном продукте, поэтому контроль безопасности и мониторинг уязвимостей смещаются на ранние этапы разработки.

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

Финансовый сектор подвергается высокодинамичным атакам; поэтому в первые этапы часто выходит автоматизация реагирования на инциденты.

Ритейл чаще сталкивается с кражами платёжных данных и падением сервисов во время распродаж, поэтому интеграция SOC включает системы антифрода и WAF.

В государственном секторе мы встречаем обилие legacy-систем и APT-атаки, поэтому Threat Intelligence и архитектура нулевого доверия (Zero Trust) — ​основа подходов. Качественное взаимодействие SOC и VOC целесообразно выстраивать по плану, и мы предлагаем следующий подход:

1. Провести аудит систем инвентаризации и сформировать единую ресурсно-сервисную модель. Следует использовать инструменты непрерывного обнаружения активов, уделяя особое внимание выявлению Shadow IT и классификации активов по уровням бизнес-критичности.
2. Интегрировать платформы SOC и VOC на уровне данных. Настроить передачу информации проще всего на единой платформе (как, например, Security Vision). Это обеспечит дежурную смену контекстом в режиме «одного окна», чтобы при анализе алерта аналитик сразу видел актуальную экспозицию атакуемого узла.
3. Разработать совместные SLA и матрицы ответственности. Совместно с ИТ-департаментом и DevSecOps утвердить жёсткие временные рамки и автоматически следить за исполнением SLA, закрепить персональную ответственность за владельцами ИТ-систем.
4. Внедрить сквозную автоматизацию процессов. Разработать автоматические плейбуки для обогащения инцидентов, создания заявок в тикет-системах и контроля устранения уязвимостей посредством автоматического запуска повторных сканирований.
5. Обеспечить регулярное тестирование защищённости. Интегрировать в деятельность симуляторы атак (BAS), Red Teaming и программы Bug Bounty. Это позволит верифицировать эффективность настроенных правил детектирования.

Реализация этих принципов позволяет трансформировать информационную безопасность организации из фрагментарного реагирования на угрозы в управляемый, непрерывный и измеримый процесс снижения киберрисков.

[1] https://blog.checkpoint.com/exposure-management/the-case-for-a-vulnerability-operations-center/

Реклама. ООО «ИНТЕЛЛЕКТУАЛЬНАЯ БЕЗОПАНОСТЬ», ИНН: 7719435412, Erid: 2VfnxvrT4qy