По структуре мероприятия я ожидал, что будет два типа слушателей:
- Кто не определился строить им SOC или нет, поскольку не знает что это такое и зачем это надо.
- Кто уже понял зачем нужен SOC и им нужны примеры создания и эксплуатации SOC. Заодно узнать разницу в стоимости создания собственного SOC или стоимости эксплуатации виртуального SOC.
Те презентации, которые отвечали на эти два вопроса, я сейчас и порекомендую.
Что такое SOC. Создавать или нет?
- SOC автоматизирует процессы, которые уже есть в компании. Соответственно, если никаких процессов нет, то и автоматизировать нечего, и SOC не нужен.
- Если процессы есть, то должен быть сотрудник в компании, который бы хотел, чтобы эти процессы ускорились или улучшились. Он обычно и инициирует создание 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"
Как правильно сделать SOC на базе SIEM from
Denis Batrankov, CISSP
В заключение
На SOC Forum я не ходил как вендор. Из имеющихся у меня презентаций я мог бы рассказать про средство для расследования инцидентов Autofocus. Ну и еще возможно про Threat Intelligence и IoC, про которые иногда лишь упоминалось на этом форуме. Но это оставлю для какого-нибудь Anti-APT форума.
