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

Аватар пользователя alukatsk
Автор: Лукацкий Алексей,
(3)
()
В последнее время наши регуляторы в лице ФСТЭК, ФСБ и Банка России выпустили целый ряд нормативных документов, которые вводят обязанность для попадающих под их действие организаций, заниматься мониторингом ИБ, реагированием на инциденты и управлением событиями безопасности. Это и 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, а с течением времени перестроили его в нечто более эффективное для решения насущных задач (обратное движение тоже возможно, но реже). Просто обратите внимание, каких признаков у вас больше, примените метод "пяти зачем" (хотя у него тоже есть свои ограничения) и извлеките уроки.
Оцените материал:
Total votes: 61
 
Комментарии в Facebook
 

Комментарии на сайте

Аватар пользователя riskmn

Забавно, как эти "пугалки" будут реализовываться (про посадки). Кончится тем, что все отключатся от интернета)))))

up
1 user has voted.
Аватар пользователя alukatsk

Стоит подождать правоприменения

up
0 users have voted.
Аватар пользователя riskmn

Отчего не подождать - это легко. Только надо развиваться темпами, которые соответствуют текущему уровню ...... Может не стоит бороться с проблемами при эксплуатации "сырых" решений, а изначально довести эти решения до ума (решить проблемы с дырами)? И многое чего и современных перспектив отпадет даже не родившись. Стоимость владения стоит считать, а не перспективность хотелок....

А уные люди решения найдут "несимметричные":-)))))

 

 

up
1 user has voted.
Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.