Что такое Security Operation Center. Создавать или нет?

После одного из самых разрекламированных мероприятий этого года выложили презентации http://soc-forum.ib-bank.ru/materials_2016

По структуре мероприятия я ожидал, что будет два типа слушателей:

1. Кто не определился строить им SOC или нет, поскольку не знает что это такое и зачем это надо.
2. Кто уже понял зачем нужен SOC и им нужны примеры создания и эксплуатации SOC. Заодно узнать разницу в стоимости создания собственного SOC или стоимости эксплуатации виртуального SOC.

Те презентации, которые отвечали на эти два вопроса, я сейчас и порекомендую.

Что такое SOC. Создавать или нет?

1. SOC автоматизирует процессы, которые уже есть в компании. Соответственно, если никаких процессов нет, то и автоматизировать нечего, и SOC не нужен.
2. Если процессы есть, то должен быть сотрудник в компании, который бы хотел, чтобы эти процессы ускорились или улучшились. Он обычно и инициирует создание SOC.

Типовая ошибка: купить SIEM и ждать "вдруг" появления процессов. А они почему-то не появляются. Нет, ребята, создание процессов в SOC, это труд, причем многолетний! Хорошая аналогия: купить топор и ждать когда дом "сам" построится.

Первое, что ждут от SIEM, в отличие от обычного LogManager - это приоритезации событий. Ведь в журналах они просто свалены, а SIEM своими правилами может автоматически дать разный приоритет в зависимости от критичности ресурса с которым связано событие. И это лишь один пример автоматизации.

Второе, что ждут от SIEM, это корреляции событий из разных журналов друг с другом. Например, известно, что если сравнить два журнала: VIN всех автомобилей с завода и с зарегистрированными VIN в ГИБДД, то сразу же появятся расхождения, поскольку часть VIN "перебита". Почем так никто не делает?

Сравнить два и более журнала - простейшая операция для автоматизированной системы, но не для человека. Например, можно заставить SIEM сравнивать журнал СКУД, что человек зашел в здание и лишь затем залогинился в AD. И если он лишь залогинился (реализации угрозы "дал свой пароль коллеге"), то сразу генерируется инцидент.

Такой слайд даже рассказывал Андрей Страшнов (Банк России):

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

Идея создавать анализаторы журналов витала уже давно (с 1998 года). Раньше мы называли этот механизм "активный аудит". Но всегда страдало реагирование - не было времени, чтобы смотреть в журналы и разбирать инциденты. Да и психологию тоже надо знать: через месяц непрестанного анализа журналов, ты понимаешь что в жизни есть более интересные занятия.

Проще говоря, задачи службы ИБ у которой есть SOC и у которой нет SOC ничем не отличаются. Но те, у кого есть SOC - делают то же самое эффективнее. Вот например так:

А вот пример от Эльмана Бейбутова (JSOC):

Мне понравилось какие функции у SOC выделил Алексей Плешков (Газпромбанк)

И, на мой взгляд, самую суть "зачем SOC" донес Максим Степченков (IT-Task)

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

Ну и, если просто упомянуть все процессы и процедуры SOC, то впечатляет:

Вот как описывает старт проекта SOC Константин Смирнов (Accenture) Это был самый зрелый доклад в номинации "от интегратора":

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

Меня заинтересова картинка Дмитрия Березина(КРОК) про людей в SOC (только надпись SOC надо поменять на LogManager или SIEM, потому что SOC - это вся картинка). Они делят людей на инженеров и аналитиков.

Вот моя версия оргструктуры, которую я показывал когда работал в HP. Инженерами я называю тех кто все настраивает, аналитиками - тех кто реально думает над событиями. Нужно от 10 человек:

Интересный вопрос про разделение обязанностей команды SOC поднял Андрей Янкин(Jet): Если вы набрали в штат людей в свой SOC, то заставлять ли его сотрудников одновременно администрировать сами СЗИ? Лучше всего это сразу исключить! Мало того, в SOC буду еще идти и события от средств ИТ и других, например от HR базы, там ведь тоже есть уже администраторы:

По вопросам технологий, которые должны поставлять события, вообще по-хорошему все что у вас есть должно собираться в единый Log Manager и на основе этих событий SIEM принимает еще дополнительные решения и опять генерирует уже более глобальные события и создает инциденты. Вот, например, как показывает анализ атак в современном мире Дмитрий Березин(КРОК)

У SIEM как правило есть уже готовые правила корреляции (называются use cases), но их нужно внедрять последовательно, мы в ArcSight внедряли по 30 правил корреляции в неделю, потому что нужно было их все анализировать и удалять ложные срабатывания, доделав их до того, что все новые события - это 100% инцидент.

Виртуальный SOC

Чаще всего, глядя в список требуемых от службы ИБ задач, в численность своих сотрудников, хочется отдать все на внешнее управление. И такие сервисы есть. Я тоже за внешние сервисы. Здесь есть одна проблема - недоверие, но когда она решится, то почти все компании будут отдавать свои события профессионалам на анализ.

Главная, на мой взгляд, причина перехода на аутсорсинг ИБ: часто нет квалифицированных сотрудников и одновременно нужен контроль 24/7.

Это отражено в презентации Сергея Романова (Энергобанк):

И получится чудесный результат как у телекомпании СТС. Это самая лучшая презентация в номинации "от заказчика" у Максима Наумова (СТС Медиа) про результаты перехода на аутсорсинг ИБ:

Очень много практических примеров привел Андрей Безверхий (SOC Prime) о том, почему содержать свой собственный SIEM - головная боль:

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

Вот что думает про SLA Анатолий Скородумов(банк Санкт-Петербург):

Очень понравилась статистика уже работающих коммерческих SOC (на ноябрь 2016)

Коммерческий SOC компания Информзащита:

Коммерческий SOC компания Solar:

Компания SOC Prime - настраивает вам SOC:

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

Но этот же факт является плюсом: внешние сотрудники не будут скрывать инциденты, как это могут делать собственные сотрудники.

Оценка эффективности SOC

Методики оценки эффективности SOC годятся для тех, кто строит свой SOC и кто хочет подключиться к уже существующему SOC. На конференции еще упомянули подраздел - оценка зрелости процессов. Я знаю метод CMMI (Capability Maturity Model Integration), который использует для оценки команда ArcSight и этот метод был представлен Андрей Тамойкин (Информзащита). Он состоит в оценке многих параметров заключенных в триаду: Люди+Процессы+Технологии:

SOC нужен в первую очередь службе информационной безопасности и современная парадигма безопасности состоит в том, что взломы происходят какие бы дорогие средства защиты мы не купили и задача безопасника сегодня в том, чтобы узнать что произошел взлом и среагировать как можно быстрее. Поэтому одним из важных параметров оценки работы SOC является - как быстро мы узнаем о том что мы еще не знаем - о неизвестных атаках. Здесь очень хорошо проявляют себя песочницы, системы анализа аномалий пользователей и базы Threat Intelligence c различными индикаторами компрометации.

Алексей Лукацкий(Cisco) привел картинку про kill chain: атака проходит несколько этапов и чем быстрее мы заметим взлом на первых этапах, тем проще будет потом защититься:

Мне больше импонирует версия оценки эффективности: число инцидентов на одного аналитика. Проблема простая: на начальном этапе правила корреляции еще дают ложные срабатывания и аналитик должен вводить туда уточняющие параметры, чтобы снизить число ложных срабатываний. В итоге повышается число событий которые обрабатывается автоматические и снижается число событий которые должен посмотреть аналитик своими глазами, вот как на графиках ниже:

Внешние источники SOC

Я хочу добавить, что в правильном SOC собирается информация со всего мира и также от всех сотрудников компании. И Владимир Дрюков (Solar) подчеркнул как важно обмениваться информацией со всем миром. Это называется международными терминами Threat Intelligence и Indicator of Compromise (IoC): Кто владеет информацией, тот владеет миром!

Вот статистика от Владимира по Threat Intelligence

Глядя на презентацию Алексея Павлова и то, как Solar ищет угрозы APT, я решил, что они лучше всех понимают текущие способы взлома и как найти инцидент очень быстро:

И о себе

В принципе все вышеизложенное есть в моей презентации "Как сократить путь от SIEM к SOC"

Презентация «Как сократить путь от SIEM к SOC» — на SlideShare. Слайды перенесу на сайт отдельно.

Как правильно сделать SOC на базе SIEM from Denis Batrankov, CISSP

В заключение

На SOC Forum я не ходил как вендор. Из имеющихся у меня презентаций я мог бы рассказать про средство для расследования инцидентов Autofocus. Ну и еще возможно про Threat Intelligence и IoC, про которые иногда лишь упоминалось на этом форуме. Но это оставлю для какого-нибудь Anti-APT форума.