Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог

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: 117
 
Комментарии в Facebook
 

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

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

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

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

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

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

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

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

 

 

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