SOC, ориентированный на реальный мониторинг и на compliance #socforum

В последнее время наши регуляторы в лице ФСТЭК, ФСБ и Банка России выпустили целый ряд нормативных документов, которые вводят обязанность для попадающих под их действие организаций, заниматься мониторингом ИБ, реагированием на инциденты и управлением событиями безопасности. Это и 17/21/31-й приказы ФСТЭК, и новый ГОСТа ЦБ по базовому уровню защищенности финансовых организаций, и пока еще не опубликованные требования ГосСОПКА. А если еще наложить сюда действующие и планируемые требования по обязательному уведомлению об инцидентах, то складывается картина, что тема собственного или внешнего центра мониторинга кибербезопасности (SOC) как никогда лучше позволит выполнить действующие и будущие требования регуляторов.

Более того, наблюдая за тем, кто и как подходит к теме SOC, предположу, что соблазн скатиться к compliance-ориентированному SOC сейчас как никогда высок у наибольшей доли российских предприятий. Почему о SOCах заговорили именно сейчас? Что, раньше не было такой потребности? Была. Так почему сейчас? И почему все начинают строить SOCи, даже не имея нормального процесса управления журналами регистрации?

Попробовал для себя сформулировать признаки двух типов SOC - ориентированных на выполнение требований законодательства и на реальный мониторинг происходящего на предприятии в контексте кибербезопасности. У SOC в первом случае могут быть следующие признаки:

• Фокусировка на мониторинге средств предотвращения угроз (МСЭ, AV, IPS, антиспам, контроль доступа и т.п.). Практически полное отсутствие поддержки систем настоящего мониторинга - NTA, CASB, EDR, UEBA и т.п.
• Инструментарий SOC живет по принципу “заблокировал и забыл” - никакого расследования инцидентов нет и в помине (тем более выстроенных процессов реагирования инцидентов). Также нет и аналитиков третьей линии, занимающихся threat hunting, и инструментария для обеспечения их работы (да того же YARA).
• Отсутствие playbook и написание правил корреляции по мере возникновения задачи, а не путем анализа use case (сценариев), которые должны лечь в основу ТЗ на построение SOC. 
• Попытка охватить мониторингом все, что есть в организации, приводящая к перегрузке SIEM, наличии на первых порах сотен и тысяч тикетов в день.
• Ориентация на решения, подключенные к SOC, и технологии, обеспечивающие его работу. Полная забывчивость в отношении выстраивания процессов и их документирования (да-да, опять playbook/runbook), а также в отношении людей, составляющих ядро нормального SOC.
• Ориентация и следование стандартам и нормативным требованиям ("а как нам выполнить вот этт пункт приказа №17?").
• Никак не интегрированное с ИТ управление. Этот критерий поставил на последнее место, так как бывают такие ситуации, когда ИТ и ИБ живут как кошка с собакой и не дружат совсем. Но все-таки жить друг без друга они не могут и для достижения лучших результатов должны дружить, обмениваться данными и интегрировать свои решения по мониторингу (а то и вовсем иметь единую базу событий с разными процессами их анализа, расследования и реагирования).

SOC ориентированный на реальный мониторинг и решение проблем ИБ может быть охарактеризован следующими признаками:

• Ориентация не на события ИБ, а на инциденты, включая обработку единиц тикетов в день, проведения расследований, выстраивание процессов реагирования, наличие команды threat hunting (или контакты с внешними людьми) и т.п. Наличие нормального решения класса IRP (Incident Response Platform) или SOAR тоже является признаком хорошего SOC.
• Защита критичных активов, а не всего, что требует предварительного анализа и понимания существующего ландшафта используемых технологий, решений, процессов, узлов, пользователей, информации и т.п. Мы это все знаем?
• Ориентация на людей в SOC, а не на продукты. Игнорировать последние, конечно, не стоит, но и сильно уж полагаться на них тоже.
• Знание не только ЧТО [написано в стандартах и требованиях], но и КАК [это надо реализовать наиболее эффективно]. Это проверка/аудит/инспекция/аттестация будет проходить по принципу "есть/нет", а в реальной работе надо понимать, зачем вам та или иная функция и как ее можно решить наиболее оптимальным образом.
• Тесная интеграция с ИТ.

Чтобы выстроить "правильный" SOC вам может помочь модифицированный метод "пяти почему", который я бы назвал "пять зачем", и который позволяет изучить причинно-следственные связи, лежащие в основе той или иной проблемы или задачи. Суть метода заключается в том, что вы, последовательно задавая пять раз вопрос "зачем" пытаетесь докопаться до первопричины своих решений. Каждый последующий вопрос задается к ответу на предыдущий. Например, это может выглядеть так:

• Зачем нам SOC?
• Потому мы уже не справляемся с хаосом средств защиты и нам нужна упорядоченность.
• Зачем нам упорядоченность?
• Потому что нам нужно систематизировать все события безопасности, получаемые от средств защиты и приоритезировать их.
• Зачем нам систематизация и приоритезация?
• Потому что нам нужно реагировать в первую очередь только на самые важные инциденты.
• Зачем нам нужно реагировать сначала на важные инциденты?
• Потому что нам надо предотвратить ущерб для критичных активов предприятия.

В данной цепочке мы, честно ответит себе пять раз "зачем", приходим к идее SOC, ориентированного на реальный мониторинг ИБ. А может быть и другая цепочка:

• Зачем нам SOC?
• Потому что нам надо будет отправлять данные об инцидентах в ГосСОПКУ.
• Зачем нам туда направлять данные об инцидентах?
• Потому что скоро вступят в силу требования 187-ФЗ.
• Зачем нам выполнять требования 187-ФЗ?
• Потому что мы субъекты критической информационной инфраструктуры.
• Зачем нам выполнять требования, предъявляемые к субъектам КИИ?
• Потому что за их невыполнение грядет уголовная ответственность.
• Зачем нам выполнять эти требования?
• Потому что мы не хотим сесть в тюрьму на 6-10 лет лишения свободы.

Тут, при том же исходном вопросе, мы видим совершенно иную цепочку рассждений, которая нас приводит к SOC, ориентированному на compliance. И строиться он будет именно исходя из этого (не как надо, а как написано в нормативке).

Понятно, что это условное деление и реальный SOC может быть вообще гибридным - рассчитанным и на работу с регуляторами, и на реальный мониторинг ИБ. И фактор времени надо тоже учитывать. Сначала может быть вы строили SOC для compliance, а с течением времени перестроили его в нечто более эффективное для решения насущных задач (обратное движение тоже возможно, но реже). Просто обратите внимание, каких признаков у вас больше, примените метод "пяти зачем" (хотя у него тоже есть свои ограничения) и извлеките уроки.