Построение внутреннего SOC. Плюсы, минусы, подводные камни

Построение внутреннего SOC. Плюсы, минусы, подводные камни

7–8 декабря в Москве состоялось одно из главных событий года в сфере российской информационной безопасности – SOC-Форум 2021 «Практика противодействия кибератакам и построения центров мониторинга ИБ». Подробный отчёт о нём читайте в разделе «Инфраструктура/Деловые мероприятия». А тут, в качестве знакомства с интересным и, надеемся, полезным опытом, публикуем один из докладов, прозвучавших на Форуме [1].

НАЧАЛО

Мы приступили к построению внутреннего SOC в 2018 году, основной целью ставили перед собой создать такую систему мониторинга, чтобы мы первыми узнавали, какие события в рамках информационной безопасности происходят в инфраструктуре банка, и могли незамедлительно реагировать на инциденты.

У нас на тот момент была сформирована команда, которая умела строить IT-инфраструктуру и поддерживать её. Кроме того, у нас был SIRT с талантливыми специалистами.

ЦЕЛИ И ЗАДАЧИ

Далее мы сформулировали первоочередные задачи, которые перед нами стояли (рис. 1).

Рисунок 1. «Цели и задачи, которые мы перед собой поставили»

Не буду детально останавливаться на каждой задаче, думаю, аудитория понимает, о чём идёт речь, но хотел бы обратить внимание на то, что у нас есть пул дочерних компаний, которые тоже необходимо было включить в контур мониторинга, предложив им ту же сервисную модель, которая работает внутри МКБ.

ПОДГОТОВКА К ПРОЕКТУ

С чего мы начали подготовку к проекту? Во-первых, пригласили в команду высококлассного архитектора, его задачей было спроектировать SOC в части технологий и придать ему те контуры, которые он сейчас имеет. В рамках подготовки также был определён руководитель SOC, давно работающий в банке и понимающий многие происходящие процессы. Во-вторых, мы произвели тщательный расчёт серверных мощностей, затем создали архитектуру и достаточно кропотливо подобрали ПО, ставшее основой SOC. Надо сказать, нам даже удалось сэкономить на ПО, поскольку мы отказались от очень дорогой SIEM-системы, приобретённой банком ранее.

И самое главное – это грамотный расчёт HR, потому что все мы прекрасно знаем, что Security Operation Center – это люди, технологии и процессы. И люди – это наиболее важная часть.

ОБОСНОВАНИЕ ПРОЕКТА

В рамках подготовки к запуску своего SOC мы, естественно, сравнивали его предполагаемую эффективность с коммерческими SOC. Мы очень плотно поработали с «Ангарой», «Бизоном», «Джет» и другими компаниями. Работали честно, у нас не было намерения любой ценой сделать всё самостоятельно, мы были готовы привлечь и внешние SOC. В итоге в сравнении с самым бюджетным предложением у нас стоимость владения SOC за 4 года получилась ниже на 40 процентов.

Во-первых, мы оценили все риски, в том числе остаточные. Мы оценили их количественно, и это стало своеобразным экономическим базисом для утверждения проекта. Во-вторых, мы провели детальный анализ как рынка SOC, так и банковского рынка в части мониторинга и реагирования на инциденты: мы изучили, как коллеги из крупнейших банков подходят к решению проблемы. В-третьих, мы подготовили очень точный ТСО. Стоимость владения мы показали правлению, чтобы бизнес чётко понимал, что сколько стоит и что он получает за обозначенный бюджет.

ПЛАН РЕАЛИЗАЦИИ

Дальше мы создали план реализации проекта, его дорожную карту (рис. 2). Тут важно отметить, что работы по созданию инфраструктуры заняли достаточно большое количество времени. В план вошли не только работы по подключению всех инфраструктурных элементов, но и создание свода правил по реагированию на события. Например, применительно к операционным системам, правила для Windows мы сейчас переписываем, используя MITTRE и другие признанные ИБ-сообществом практики. У нас их получается порядка 130, это довольно много, все их нужно смотреть, имплементировать, выверять, тестировать. Поэтому если вам кто-то скажет, что справился за три месяца, то будьте уверены: либо речь идёт об очень маленькой и гомогенной инфраструктуре, либо это неправда.

Рисунок 2. «Дальше мы создали план реализации проекта, его дорожную карту»

ИСПОЛЬЗУЕМЫЕ ТЕХНОЛОГИИ

Мы купили большой объём оборудования, в результате получили 336 ядер, 3 терабайта оперативной памяти и около 100 терабайт дисковой подсистемы. Но чтобы завершить задуманную архитектуру, нам предстоит расширить мощности, в первом полугодии 2022 года мы ожидаем очередную крупную поставку «железа». Важная часть работы SOC – предварительная обработка событий. Это позволяет снизить нагрузку на ядро SOC и сделать, насколько это возможно, распределённым прикладной функционал. Мы сделали очереди на базе Kafka, и, соответственно, те инциденты, которые возникают, обрабатываются с помощью Kafka, потом у нас происходит обогащение, затем сравнение и итоговое формирование инцидента. В основном мы сознательно используем opensource либо собственную разработку на Python. Это снимает с нас дополнительные экономические ограничения для перехода на более современные технологии.

Сырые события попадают из источников событий в файловую систему на ZFS, а те, которые нужны для активного использования, – на ELK-стек. Для операторов и менеджеров существует Jira, которая демонстрирует инциденты и, по сути, является единым окном для всего SOC (рис. 3).

Рисунок 3. Используемые технологии. «Мы купили большой объём оборудования, в результате получили 336 ядер, 3 терабайта оперативной памяти и около 100 терабайт дисковой подсистемы»

Теперь, что касается мониторинга и метрик. Тут важно понимать, что мы изначально делали акцент на том, чтобы SOC был доступен. И один из первых наборов правил, которые мы создаём, – это правила на случай, если события перестали поступать либо SOC прекратил функционировать. Это важно, иногда про это забывают. Соответственно, метрики того, как что работает, – это тоже неотъемлемый атрибут, чтобы осуществлять эффективную поддержку. Мы сразу заострили на этом внимание, потому что можно бесконечно двигаться в развитии, но, если ты построил одну стену дома, потом строишь другую, а предыдущая тем временем разваливается, это, согласитесь, не способствует завершению строительства в целом (рис. 4).

Рисунок 4. Мониторинг и метрики. «Метрики того, как что работает, – это тоже неотъемлемый атрибут, чтобы осуществлять эффективную поддержку»

ПРОМЕЖУТОЧНЫЕ РЕЗУЛЬТАТЫ

Что мы сейчас умеем? Мы умеем фильтровать 20–40 процентов потока в зависимости от коллекторов и платформ от входящих событий. Умеем обрабатывать объём событий – примерно 150 гигабайт в сутки. У нас средний среднесуточный поток данных – 4 тысячи событий в секунду, и соответственно, пиковый поток на источник – чуть больше 5 тысяч. Есть достаточно распространённые платформы, с которыми мы умеем дружить и получать события. Есть 117 готовых правил, есть 4 инфраструктуры, подключённые к МКБ (рис. 5).

Рисунок 5. Промежуточные результаты. Сбор событий и правила

Есть ещё и процедуры, связанные с реагированием. Вот статистика, сколько событий мы можем обработать в зависимости от режима работы. На режим 24/7 мы перешли совсем недавно, поэтому цифры по достаточно распространённому режиму 9/5 вполне актуальны (рис. 6).

Рисунок 6. Промежуточные результаты. Мониторинг и реагирование

Чтобы показать промежуточные результаты, продемонстрирую консоль оператора (рис. 7). Тут происходит качественное обогащение: к каждому инциденту мы стараемся прикрепить не просто учётную запись, но ещё и пользователя и описание хоста из CMDB, чтобы понимать, с кем общаться, когда из-под учётной записи выходят какие-то негативные события, и оценивать критичность инцидента. Плюс там есть различные ссылки, чтобы можно было быстро смотреть связанные с инцидентом события.

Рисунок 7. Промежуточные результаты. Консоль оператора

ПЛЮСЫ, МИНУСЫ, ПОДВОДНЫЕ КАМНИ

Теперь, собственно, про плюсы-минусы и подводные камни (рис. 8). Какие плюсы?

Стоимость – это очевидно, потому что 40 процентов стоимости владения по сравнению с коммерческими SOC – впечатляющий показатель.

Скорость реагирования. Мы точно реагируем быстрее, потому что скорость реагирования тесно взаимосвязана с другим свойством – управляемостью. А управляемость у нас, понятно, намного выше. Я всегда могу прийти и сказать: «Ребят, давайте ту или иную процедуру поправим и сделаем лучше». В сторонний SOC я, наверное, тоже могу внести правки и усовершенствования, но в рамках соответствующего договора, и совершенно точно речь пойдёт о месяцах или годах и о модификации дорожной карты организации. С учётом того, что у стороннего SOC клиентов много, индивидуальные процедуры могут иметь место, но не думаю, что на постоянной основе.

Рисунок 8. Плюсы, минусы, подводные камни

Какие минусы? Скорость реализации. В общем-то, мы сразу настраивались на то, что этот проект займёт несколько лет. Сейчас мы создали базис, который умеет всё. Этот год мы посвятили очень важным вещам, я бы сказал, основным: написанию ядра, подключению ключевой инфраструктуры, созданию и отладке коллекторов и т. д. То, что в ходе работы возникло 117 правил, не было запланированным, потому что акцент на правила у нас выпадал на 2022 год. Безусловно, скорость реализации в коммерческом SOC была бы выше, даже несмотря на договорные процедуры и на то, что инфраструктуру так же нужно было бы подключать.

Огромный минус – это поиск персонала. У нас есть несколько классных специалистов, которые двигают процесс. Но хантинг на рынке таких единичных специалистов – это на самом деле стоп-фактор. Их на рынке практически и нет. Нужно владеть ситуацией, знать людей, контакты, чтобы находить тех, кто умеет и может. Но и этого недостаточно. Чтобы людей привлечь, нужны всяческие плюшки, и не только материальные. Ведь эти специалисты, по-своему звёзды, должны захотеть к вам прийти, сказать: «О! Да тут прикольно будет работать!» И вот эти ключевые фигуры являются главным подводным камнем, так как в один прекрасный момент такой человек может встать и пойти своим светлым путём. Соответственно, надо заранее создавать кадровый резерв, готовить аналогичных по уровню специалистов.

Другой подводный камень – понимание ответственными лицами, зачем и какой нужен SOC. CISO должен отчётливо представлять, что он получит в результате и в каком виде. Если такого представления нет, то и полноценного результата не будет, независимо от того, идёт речь о внутреннем или коммерческом SOC. Если у руководителя нет картинки в голове, то, скорее всего, системообразующий договор получится нежизнеспособным как минимум в первый год работы.

Кроме того, безопасник обязан быть толмачом, переводчиком. Это значит, что я должен постоянно переводить с нашего технического уругвайского на бизнесовый парагвайский. Когда такой перевод происходит, бизнес начинает понимать, о чём идёт речь, становится адекватным и выделяет деньги на то, что, как оказывается, для него полезно.

Ну, и вера в свои силы. Да, это тоже важно, потому что где-то на полпути случается, что какие-то процессы идут медленно, что-то перестаёт получаться, или снова приходится переписывать ядро и т. п. Это демотивирует, и всегда нужно находить какие-то положительные моменты в том, что реализуется. Вот на этом пожелании каждому и всем верить в свои силы я и закончу.

[1] Доклад также опубликован на портале НКЦКИ