SOC: Технологическая основа

SOC: Технологическая основа
Многие годы, обсуждая технологическую составляющую Центров операционной безопасности (Security Operations Center, SOC), речь заходить о решениях класса Security Information and Event Management (SIEM), системах учета заявок, визуализации данных и т.п.
На мой взгляд, необходимо понять роль и место всех технологических составляющих в рамках SOC.

Я приводил разные схемы на этот счёт:
3e1a1439931cd85e95e999bf22a5c626.png  
но если упростить, то получается пирамида:
90b456c037c2871348211ca5f88d2ba1.png  
И в её основе лежат совсем ни SIEM-решения, ticketing и reporting tools, а источники событий.
И если этого основополагающего «слоя» нет, или он не качественный, то практически нет смысл обсуждать вышележащие «слои».
Есть ещё один важный момент, точнее ошибочное ощущение у организаций, реализующих свой SOC или потребляющие сторонние SOC-услуги, что этот «слой» у них по умолчанию есть и всё хорошо. Но есть один нюанс, заключающийся в том, что в реальности «слой» есть, а вот данных от него нет на вышележащие «слои» нет.
Об этом я и рассказывал на мероприятии ЦБИ ( ссылка ).
574d3bd048dc475776c34c5021936ffa.png
Более 5 лет назад я определил 2 необходимых условия для создания не формального, а работающего нижнего «слоя»:
1. Возможность зарегистрировать информацию источником событий.
2. Возможность предоставить доступ к зарегистрированной информации SIEM-системе.

Если этого нет, то на «слои» выше ничего не попадёт, и разговорить будет не о чем.

Но практика показала, что данные условия не являются достаточными, и я начал пополнять этот список следующими тезисами:
1. Читаемость информации, а именно возможность воспринять информацию человеком или SIEM-системой. Дело в том, что в ряде случаев информация представляется в закодированном виде и работать с ней нельзя (точнее работать конечно можно, но результата нет).
2. Наличие необходимых данных. К сожалению, объём зарегистрированной информации ограничен, и есть опасность, что нужных данных там просто не будет.
3. Гарантированная доставка информации. Здесь можно провести простую аналогию «TCP vs UDP», т.е. требуется выбирать наиболее предпочтительный для вас вариант.
4. Наличие мощностей у источника событий. На практике аудит событий не всегда используется, т.к. это негативно сказывается на производительности самого источника событий, и здесь встаёт непростой выбор между регистрацией необходимой вам информации и возможностями самого источника событий (в своё время я экспериментально доказал полное исчерпание ресурсов центрального процессора источника событий в следствии регистрации событий).
5. Корректный приём SIEM-системой:
- корректная фильтрация событий – не отбросить нужное;
- корректный парсинг событий – выделить нужное;
- обработка пиковых потоков событий – не потерять нужное.
 
Хотел бы обратить внимание, что список является открытым и будет пополнятся с течением времени.

Успехов в формировании вашего основополагающего технологического слоя в SOC-е!
Alt text

Александр Кузнецов

Заметки про управление в области информационной безопасности и не только