JSOC: опыт молодого российского MSSP

в 13:10, , рубрики: информационная безопасность

В рамках корпоративного блога хотелось бы запустить цикл статей о нашем молодом (но, тем не менее, очень ярком) начинании в сфере информационной безопасности – JSOC (Jet Security Operation Center) − коммерческом центре по мониторингу и реагированию на инциденты. В статьях я постараюсь поменьше заниматься саморекламой и большее внимание уделить практике: нашему опыту и принципами построения услуги. Тем не менее, это мой первый «хабро-опыт», и потому не судите строго.

SOC − предпосылки

Рассказывать, зачем вообще крупной российской компании нужен SOC, не очень хочется (уж слишком много различных статей и исследований по этому поводу написано). А вот статистика – совсем другое дело, и о ней грех не вспомнить. Так, например:

  • в компании численностью от 1 до 5 тыс. человек в течение года фиксируется:
    • 90 млн. событий ИБ;
    • 16 865 событий с подозрением на инцидент;
    • 109 реальных инцидентов ИБ ;
  • общий объем потерь от инцидентов ИБ в 2013 году составил $ 25 млрд. ;
  • в крупной компании используется не менее 15 разнородных средств защиты, не более чем в 7 из них проводится активный анализ журналов для выявления инцидентов .

Если же добавить к этому еще 3−4 новостных заголовка по соответствующей теме, то абсолютно логичной и понятной становится идея о том, что за безопасностью необходимо следить, а инциденты ИБ − выявлять и анализировать.

Что советуют по этому вопросу эксперты безопасности? Конечно же сделать SIEM-решение ядром существующего или строящегося SOC. Это позволит решить сразу несколько задач:

  • замкнуть инциденты, фиксируемые другими системами самостоятельно, в рамках одного единого ядра инцидент-менеджмента;
  • получить удобный инструмент для поиска необходимых событий, расследования инцидентов, хранения собранных данных;
  • выявлять статистические отклонения и медленно развивающиеся инциденты за счет анализа больших интервалов и объемов информации с конкретных средств защиты;
  • сопоставлять и коррелировать данные из разных систем, и, как следствие, строить сложные цепочки сценариев по обнаружению инцидентов, «обогащать» информацию в логах одних систем данными из других.

Немного общей методологии

Существует несколько уровней зрелости SOC − SOMM (Security Operations Maturity Model):

Уровни SOMM

Рис. 1 – Уровни SOMM

К сожалению, большинство компаний, сделав первый шаг на пути к собственному центру мониторинга инцидентов, на нем и останавливаются. По оценкам HP, 24 % SOC в мире не дотягивают до 1 уровня, и только 30 % SOC соответствуют базовому (2) уровню. Статистика распределения уровней SOMM в зависимости от сферы бизнеса компаний, собранная в 13 странах мира (включая Канаду, США, Китай, Великобританию, Германию, ЮАР и др.) такова:

Распределение уровней SOMM по сферам бизнеса

Рис. 2 – Распределение уровней SOMM по сферам бизнеса

SOC in-house: проблематика

При этом по пути внедрения масштабного SIEM-решения прошли практически все крупные российские компании. Удалось ли им построить эффективные SOC`и? К сожалению, чаще всего нет: на сегодняшний день нам известен опыт всего четырех успешных запусков SOC в России.

И, как правило, приступая к построению собственного SOC, все сталкиваются с тремя гранями одной проблемы.

Во-первых, с количественной нехваткой персонала по самым различным причинам: от кадрового голода и отсутствия профильных вузов до сложности обретения требуемых компетенций. Де-факто в рамках подразделения it-security сегодня работает по 4−5 человек, осуществляющих весь цикл работ по обеспечению безопасности компании (от администрирования средств защиты до регулярного анализа рисков и разработки стратегии развития тематики в компании). Естественно, при такой загрузке уделить должное время задачам SOC практически невозможно.

Второй момент связан с невозможностью построения эффективного процесса мониторинга с внутренними SLA. Помимо необходимости выделения персонала запуск SOC, обычно, влечет за собой создание в подразделении it-security полноценной дежурной смены, работающей в рамках расширенного рабочего дня или круглосуточно. А это − от 2 до 5 новых штатных единиц. При этом выделение персонала напрямую связано с необходимостью постоянного контроля кадровой текучки (крайне редко ИБ-специалисты готовы работать в ночной смене), выстраивания процессов и внутренних контролей качества выполняемых работ.

Ну и третьим пунктом нельзя не упомянуть необходимость не только обрабатывать возникающие инциденты, но и постоянно «тюнить» и подстраивать систему под изменяющуюся инфраструктуру или возникающие угрозы безопасности. А это, вне зависимости от выбранного инструмента, весьма трудоемкая задача для аналитика, требующая постоянно держать руку на пульсе. А наличие в штате человека, занимающегося чистой аналитикой и развитием SOC – большая роскошь (даже для крупной компании).

Оценка существующей на рынке потребности в создании SOC`ов вкупе с описанными нюансами привели нас сначала к идее, а потом и к фактическому построению собственного коммерческого SOC.

Выбор платформы

Естественно, запуская SOC, мы в первую очередь столкнулись с вопросом: «Какое SIEM-решение сделать ядром своей системы»? Отвечая на него, мы сформировали список требований к создаваемой системе. В частности она должна:

  • позволять физически и логически разделять аккумулируемые данные по разным resource pool (в нашим случае − по разным заказчикам) с возможностью разделения полномочий по доступу;
  • позволять строить максимально сложные цепочки и взаимосвязи между событиями, использовать различные справочники и события для дополнения инцидента важной информацией. При этом нам скорее был нужен framework для построения своей логики выявления инцидентов, чем уже написанные правила и сценарии;
  • иметь возможность написания и разработки интеграционных шин как в сторону систем-источников (и здесь ключевое значение приобретает максимальная гибкость в написании коннекторов к целевым системамсправочникам), так и api для связки с внешними инцидент-менеджментами, системами отчетности и визуализации;
  • позволять кастомизировать внутренние ресурсы под меняющиеся задачи SOC. В частности, создание внутреннего профиля мониторинга источников, ведение и кастомизация своего инцидент-менеджмента и т.д. (кстати, данные изыскания станут предметом отдельной статьи).

Свой выбор мы остановили на флагманском продукте в классе SIEM – HP ArcSight (и, несмотря на различные сложности в жизни системы, о своем выборе мы ни разу не пожалели). Технологически JSOC − уже давно не только HP ArcSight. SIEM`овское ядро постепенно обрастало различными полезными фичами: мониторинг трафика, ipsids, vulnerability assessment и т.д. Одновременно с этим мы накопили большое количество скриптов, аддонов и собственных разработок, интегрировались с собственным Security Intelligence решением (JiVS), которое является:

  • инструментом высокоуровневого поиска аномалий у клиента и отслеживания общих трендов в активностях и инцидентах;
  • системой контроля и визуализации нашего выполнения SLA перед заказчиком;
  • эффективным визуальным dashboard и системой отчетности для бизнес-руководства заказчика.

В итоге мы сформировали такие профили защиты/направления выявления инцидентов у компаний-заказчиков, как:

  • атаки на внешние веб-ресурсы компании;
  • несанкционированный доступ к системам и приложениям;
  • комплексное обеспечение безопасности бизнес-приложений;
  • активности вирусного и вредоносного ПО в сети компании, включая эвристическое выявление zero-day вирусов;
  • нарушение политик использования удаленного доступа в сеть компании;
  • нелегитимные действия пользователей при обращении в интернет и работе с внешними устройствами;
  • аномалии в аутентификации и использовании учетных записей;
  • и другие категории инцидентов в зависимости от инфраструктуры компании, ее внутренних политик ИБ и используемых средств защиты.

Инфраструктура

Инфраструктура сервиса JSOC

Рис. 3 – Инфраструктура сервиса JSOC

После выбора основной технологической платформы необходимо было решить задачи по созданию инфраструктуры и определить площадку размещения. Опыт наших западных коллег показывает, что целевая доступность архитектуры должна составлять не менее 99,5 % (причем с максимальной катаклизмоустойчивостью). При этом принципиальным оставался и вопрос географии: collocation возможен только в границах РФ, что исключило для нас возможность использования популярных западных провайдеров. Сюда же наложились естественные вопросы обеспечения ИБ инфраструктуры на всех уровнях доступа, и выбора у нас, по большому счету, не осталось: мы обратились к команде нашего ВЦОДа. В рамках большого колокейшена для нашего JSOC специально выделили фрагмент, где мы смогли развернуть свою архитектуру, одновременно ужесточив уже существующие в рамках ВЦОД профили безопасности. ИТ-инфраструктура развернута в Tier 3 дата-центре нашей компании, и ее показатели доступности составляют 99,8%. В результате мы смогли выйти на целевые показатели доступности нашего сервиса и получили существенную свободу действий в работе и адаптации системы под себя.

Команда

На начальном этапе запуска услуги команда JSOC состояла из 3 человек: двух инженеров мониторинга, закрывающих временной интервал с 8 до 22 часов, и одного аналитика/администратора, который занимался развитием правил. SLA по услуге, обозначенный клиентам, тоже был достаточно мягким: время реакции на обнаруженный инцидент – до 30 минут, время на разбор, подготовку аналитической справки и информирование клиента – до 2 часов. Но, по прошествии первых месяцев работы, мы сделали несколько очень существенных выводов:

  1. Смена мониторинга должна обязательно работать в режиме 24*7. Несмотря на существенно меньший объем инцидентов в вечерние и ночные часы, самые важные и критичные события (старт DDoS-атак, завершающие фазы медленных атак на проникновение через внешний периметр, злонамеренные действия контрагентов и т.п.) происходят все же именно в ночное время и к моменту старта утренней смены уже теряют свою актуальность.
  2. Время разбора критичного инцидента не должно превышать 30 минут. В противном случае шансы на его предотвращение или существенную минимизацию ущерба катастрофически падают.
  3. Для обеспечения требуемого времени разбора под каждый инцидент должен быть подготовлен полноценный инструментарий для его расследования: active channels с отфильтрованными целевыми событиями для разбора, тренды, демонстрирующие статистические изменения в подозрительных активностях и целевые аналитические отчеты, позволяющие быстро анализировать активности и принимать оперативные решения.
  4. Команда администрирования средств защиты наших клиентов должна быть отделена от группы мониторинга и выявления инцидентов. В противном случае риск влияния человеческого фактора в цепочке «выполнил изменения конфигурации – зафиксировал по факту инцидент – отметил ложным срабатыванием» мог существенно сказаться на качестве нашей услуги.

На практике все эти выводы вылились в создание в рамках Центра информационной безопасности компании «Инфосистемы Джет» отдельного структурного подразделения, ориентированного на трехуровневую модель обеспечения каждой из задач: как мониторинга и разбора инцидентов, так и администрирования средств защиты. Сейчас подразделение насчитывает уже более 30 человек, имеет сформировавшуюся структуру (см. Рис. 4) и включает в себя:

  • 2 дежурные смены, которые работают 24*7: одна занимается мониторингом и разбором инцидентов, другая – администрированием системы;
  • выделенную команду развития, отвлеченную от эксплуатационных активностей в рамках наших клиентов, и позволяющую нам сохранять актуальность услуги и профиля мониторинга угроз.

Организационная структура JSOC

Рис. 4 – Организационная структура JSOC

Данная организационная структура позволила нам выйти на следующие целевые показатели SLA:

Параметры Jet Security Operation Center Базовый Расширенный Премиум
Время обслуживания 8*5 24*7 24*7
Время обнаружения инцидента  (мин) Критичные инциденты 15-30 10-20 5-10
Прочие инциденты до 60 до 60 до 45
Время базовой диагностики и информирования заказчика (мин) Критичные инциденты 45 30 20
Прочие инциденты до 120 до 120 до 90
Время  выдачи рекомендаций по противодействию Критичные инциденты до 2 ч до 1,5 ч до 45 мин
Прочие инциденты до 8 ч до 6 ч до 4 ч

На текущий момент мы обслуживаем уже 12 клиентов и решаем стоящие перед нами задачи по обеспечению их информационной безопасности. Именно таковы итоги первых полутора лет работы JSOC.


Надеюсь, данный материал не показался вам излишне маркетинговым. В дальнейших статьях мы планируем осветить такие темы, как:

  • Доступность SOC: что это такое, из чего она складывается и как ее измерить;
  • Как далек путь от корреляционного правила в SIEM до работающего сценария выявления инцидента;
  • Организационные вопросы: чему учить и не учить специалистов SOC;
  • Немного практики по разбору инцидентов.


To be continued… ;) dryukov

Автор: jetinfosystems

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js