Более того, наблюдая за тем, кто и как подходит к теме 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. И строиться он будет именно исходя из этого (не как надо, а как написано в нормативке).
