19 августа 2014 в 17:10

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

В рамках корпоративного блога хотелось бы запустить цикл статей о нашем молодом (но, тем не менее, очень ярком) начинании в сфере информационной безопасности – 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`овское ядро постепенно обрастало различными полезными фичами: мониторинг трафика, ips\ids, 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

Комментарии (7)

  • 0
    Статья понравилась, спасибо :-)
    Небольшой вопрос — вы ранжируете инциденты только по 2-м уровням или это просто для примера?

    Жду следующих выпусков!
    • 0
      Спасибо за комментарий.

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

      Следующий выпуск планируем в течении двух недель, следите за нашим блогом :)
  • 0
    Спасибо за статью, ждем продолжения.
    Разрешите задать пару вопросов:
    1. На чей опыт опирались при построении SOC и формировании структуры команды или строили исходя из своего видения и практического понимания, что должно быть именно так?

    2. Каков уровень доверия со стороны клиентов аутсорсинговому SOC?

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

    4. Кто послужил драйвером появления коммерческого SOC в Jet? «Жирный» клиент, который захотел сервис и готов был платить или все же сначала строили, потом ходили по рынку? Расскажите об этом немного поподробнее.

    5. Сталкиваетесь с ситуациями, когда дежурный инженер работает 24x7, а клиент нет, при этом события происходят глубокой ночью? Как в таких случаях происходит реагирование на инциденты?
    • 0
      Отвечу по порядку.

      1. Я бы сказал, что оба ответа верны. Естественно, опыт западных SOC мы учитывали, но в итоге постарались построить нечто свое, адаптированное под российскую специфику. И «шлифовка» текущего сервиса не прекращается ни на секунду.

      2. Как ни банально, но очень разный. Одни клиенты готовы сотрудничать с нами в рамках кейсов инфраструктурной безопасности или задач compliance, с другими мы выстраиваем модель по контролю инцидентов в бизнес-системах и выявлении нарушений в бизнес-процессах и поиску внутреннего мошенничества. К тому же своим клиентам мы с радостью устраиваем экскурсии: как в ЦОД, так и в сам центр мониторинга и реагирования. Возможность лично увидеть команду, которая тебя обслуживает, снимает большой слой недоверия.

      3. Безусловно подписываются. Способы контроля можно применять разные, и я, к сожалению, не готов освещать эту тему в деталях. Вопрос подбора, обучения и контроля персонала очень тонкий и объемный, по объему тянет на отдельную статью. Возможно, через какое-то время буду готов об этом написать.

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

      Можно отметить, что западные MSS получили свой бурный рост примерно 4-5 лет назад. Теперь востребованность тематики дошла и до России.

      5. В этом и смысл нашего сервиса. Если у клиентов есть свой 24*7, его потребность в наших услугах существенно ниже.

      Для этого с клиентов на старте согласовывается профиль оповещения: какие инциденты готовы ждать до утра и по ним можно отправить почтовое уведомление, а по каким необходимо будить специалистов ASAP в не зависимости от дня недели и времени суток.

      Возможен и второй вариант — когда клиент доверяет нам управление своими активными средствами защиты и тогда предотвращение/блокирование инцидента мы можем провести в режиме единого окна — команда разбора инцидентов передает информацию команде администрирования.
  • 0
    Не подскажете, где можно узнать поподробней о том, что должно выполняться при отнесении к тому или иному уровню SOMM именно в контекте SOC-ов? Т.е. чтобы были не общие формулировки «Level 2 = Выполнение нормативных и бизнес требований», а конкретные показатели — к чему стремиться; что такое ключевые составляющие SOC и т.п.
    • 0
      Добрый день.

      Задержался с ответом, извиняюсь. У HP есть сервис по оценке зрелости существующего SOC, в рамках него они проводят очень детальный аудит — www8.hp.com/h20195/v2/GetPDF.aspx%2F4AA4-4144ENN.pdf

      Полного перечня показателей SOMM и методологии/формул оценки я в открытом доступе не видел. Готов поделиться личными знаниями и подходами, но лучше за рамками общих комментариев.
  • 0
    А почему остановили свой выбор на Arcsight? Среди каких сием-систем выбирали? Расскажите, пожалуйста, что не понравилось (не хватало) в той же QRadar или сием от макафи? Вопрос стоимости был не во главе (или арксайт по совокупности не намного дороже других сием)?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.