Измерение эффективности SOC. Зона покрытия

Как уже писал в предыдущей статье, во вторник 17.12.2019 я выступал на конференции "Ведомостей" с докладом на тему "Технологии настоящего и будущего в центрах мониторинга ИБ (SOC)". 

Выступление условно можно было поделить на 3 части: 

1. Вводная.
2. Реализация контроля безопасности бизнес-процессов с помощью SOC.
3. Измерение эффективности SOC.

Пункты 1 и 2 я описал в предыдущей статье, на которую ведет ссылка в списке. Здесь подробнее остановлюсь на том, как можно измерить зону покрытия SOC. 

Логично, что SOC должен покрывать все 100% защищаемой инфраструктуры, будь то IT-, OT- или иные технологии. Но как это проверить, особенно если нет уверенности в том, что IT/OT-подразделения сами владеют всей информацией? Одним из вариантов может быть проведение аудита защищенности либо тестирования на проникновение. Команды разделяются на Red Team и SOC. Задача первых - достучаться до каждого хоста в сети и попытаться скомпрометировать его, не скрываясь. Задача вторых - обнаружить и отразить атаку в соответствии с выстроенными процессами. 

Обе команды должны предоставить отчеты о проведенной работе. Сравнивая их, можно определить слабые места как в SOC, так и в Red Team. Для определения зоны покрытия при анализе результатов акцентируем внимание на задаче обнаружения атак. 

Как видим на рисунке, полученные результаты можно будет условно поделить на 4 группы:

• Зеленая. Полное совпадение в отчетах аудитора и SOC. Говорит о том, что SOC зафиксировал все атаки, которые провел аудитор. Значит, защищенность атакуемых объектов контролируется, события систем и СЗИ собираются, алгоритмы генерации инцидентов ИБ релевантны проводимым атакам. Все ОК, необходимо мониторить доступность источников событий, отсутствие пропусков и периодически актуализировать алгоритмы под обновления типов атак.
• Желтая. SOC зафиксировал атаку от аудитора, но аудитор не указал ее в отчете. Может говорить о невнимательности аудитора при заполнении отчета, о непонимании аудитором проведенных действий, либо намеренном умалчивании проведенной атаки. Также возможно, что зафиксированные SOC атаки не были связаны с проведением аудита, и являются настоящими инцидентами ИБ - в этом случае вопросы к SOC.
• Красная. Аудитор отчитался о проведенной атаке, а SOC не зафиксировал. Наиболее вероятные причины: отсутствие событий ИБ с источников и/или релевантных алгоритмов генерации инцидента. Также может быть связано с халатностью SOC при заполнении отчета, либо идентификацией инцидента, как не зависящего от аудита.
• Серая. В компании могут существовать такие узлы/сегменты, до которых не добрался аудитор в связи с отсутствием доступа: запрещающие правила на firewall, отсутствие маршрутизации, либо физическая изоляция сетей друг от друга. С одной стороны, можно считать, что защита таких сегментов выстроена успешно, но для более полной картины стоит пустить туда на некоторое время аудитора, чтобы определить, все ли уровни защиты так хороши, как сетевой, и контролирует ли SOC безопасность этих сегментов. 

И, как окончательная проверка зоны покрытия - сверить зафиксированные в обоих отчетах хосты с информацией в системах инвентаризации активов компании. Не исключено, что проведенная работа поможет ИТ-подразделениям найти shadow IT-ресурсы и устранить недочеты в процессе инвентаризации.

Вывод: если у вас есть SOC и Red Team, собственные либо наемные - попробуйте провести описанные упражнения. Лишним не будет.