Фокус на реагирование: CSIRT как новый подход к аутсорсингу SOC

Несмотря на то, что рынок услуг аутсорсинга Security Operations Centers на сегодняшний день в большей степени сформирован, многие заказчики предпочитают выстраивать процессы мониторинга и реагирования на инциденты ИБ собственными силами. Почему компании не используют аутсорсинг SOC в полной мере, в чем недостатки существующих типовых коммерческих операционных центров безопасности, и как изменить ситуацию — ответы на эти вопросы в нашей статье. 

 

 

 

1. Введение
2. Три проблемы существующих подходов в аутсорсинге SOC
1. 2.1. Сервисы не учитывают потребности рынка
2. 2.2. Процессы реагирования — слабое звено Incident Response
3. 2.3. Трудности взаимодействия всех участников процессов Incident Response
3. Jet CSIRT: больше, чем SOC
4. Выводы

 

Введение

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

Компания «Инфосистемы Джет» стояла у истоков развития экспертного аутсорсинга в России. В 2012 году наши специалисты хорошо изучили направление, сформировали технологическую базу и вскоре разработали первый коммерческий сервис, в значительной мере давший импульс всему российскому рынку ИБ.

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

Отвечая на запросы рынка, мы создали новую услугу — специализированный центр реагирования на инциденты ИБ  Jet CSIRT (Jet Computer Security Incident Team).  Данный сервис стал для нас не революцией, не кардинальной сменой парадигмы, а скорее эволюционным шагом развития подхода, разработанного нами же ранее.

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

 

Три проблемы существующих подходов в аутсорсинге SOC

Сервисы не учитывают потребности рынка

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

А что в результате? Клиенты не получают полностью удовлетворяющие их услуги аутсорсинга процессов мониторинга и реагирования на инциденты ИБ. Статистика SANS за 2017 год показывает, что владельцы информационных систем пока предпочитают поддерживать и развивать процессы самостоятельно и не используют аутсорсинг в полной мере.

 

Рисунок 1. Процессы ИБ (в среднем по миру), реализуемые клиентами самостоятельно и посредством аутсорсинга (статистика SANS за 2017 г.)

 

Стоит отметить, что в ряде отраслей аутсорсинг скорее всего так и останется невостребованным в силу их закрытости. Тем не менее широкое распространение сервиса, отвечающего запросам типового заказчика, могло бы существенно изменить картину на рынке.

Добавим, что ситуация усугубляется маркетинговым «бумом» всевозможных направлений, практик и технологий. Стремление поставщиков услуг и решений переиграть конкурентов иногда приводит к комичным ситуациям, когда под одинаковыми названиями предлагаются абсолютно разные продукты либо, наоборот, разные названия подразумевают одно и то же. Яркий пример – всевозможные решения класса Security Intelligence или Anti-APT. Аналогичная картина наблюдается и в аутсорсинге Incident Response, где распространено большое количество схожих названий, за которыми фактически может скрываться любой ИБ-продукт. Для начала разберемся с определениями:

• CSIRT— Computer Security Incident Response Team
• CERT — Computer Emergency Incident Response Team
• SOC — Security Operation Center
• MDR — Managed Detection and Response Services 
• MSSP — Managed Security Service Provider

Теперь обратимся к лучшим мировым практикам по управлению инцидентами ИБ. Так, стандарт NIST SP 800-61 Rev. 2 (Computer Security Incident Handling) содержит следующие этапы, процессы и подпроцессы:

• Preparation (аудит, проектирование, настройка, war rooms, методики, playbooks).
• Detection (обнаружение, аналитика, расследование, уведомление).
• Containment, Eradiation & Recovery (сдерживание, нейтрализация, подавление, восстановление).
• Post-Incident Activity (документирование, улучшение процессов, закрытие).

Отметим, что схожий подход представлен в стандарте ISO/IEC 27035:2016.

Как же соотносятся популярные аббревиатуры с процессами управления ИБ на практике? Зачастую традиционный коммерческий SOC фокусируется на процессе детектирования, CERT нацелен на глобальную и региональную кибераналитику и иногда на ограничение распространения массовых угроз. Под MSSP часто понимают аутсорсинг функций средств защиты информации. Например, это может быть MSSP WAF — WAF из облака или WAF как услуга.

Лучшие практики FIRST CSIRT Framework и NIST SP 800-61 показывают, что CSIRT широко покрывает большинство процессов Incident Response. Помимо этого, продукт охватывает проектирование систем информационной безопасности, аудит и консалтинг, пентесты и разработку СЗИ. Что важно, CSIRT лучше всего подходит для предоставления услуг по сервисной модели среди рассматриваемых концепций аутсорсинга Incident Response.

Наш опыт взаимодействия с клиентами и результаты исследования уровней зрелости SOC в мире компании Micro Focus демонстрируют, что большинству заказчиков нужна комплексная помощь и поддержка по всем процессам Incident Response, а не только в части мониторинга, предоставления им «SIEM в облаке» или в расследовании инцидентов ИБ. Клиентам требуется помощь в аналитике, реагировании, формировании playbooks по реагированию, оптимизации настроек и эксплуатации СЗИ, периодической проверке уровня защищенности и т.д.

Процессы реагирования — слабое звено Incident Response

Вторая проблема, на наш взгляд, связана с нередким отсутствием понимания сервис-провайдерами сути и глубины процессов Incident Response. Зачастую основной фокус делается на детектировании атак, что находит свое отражение в регламентах коммерческих SOC. Действительно, задача детектирования крайне важна и является одним из самых сложных элементов Incident Response. В то же время, как было показано выше, процесс реагирования на инциденты ИБ представляет собой цепочку взаимосвязанных процессов, а именно: Preparation, Detection, Containment/Eradiation/Recovery, Post-Incident Activity.

 

Рисунок 2. Этапы Incident Response (NIST 800-61)

 

Зрелость глобального процесса Incident Response определяется самым слабым звеном. Что это значит? Если представлена слабая система безопасности, недостаточно проработаны процессы, не детализированы регламенты, неграмотно осуществлено разделение труда и отсутствуют узкопрофильные специалисты, то даже самая сильная экспертиза в детектировании не станет панацеей от угроз. При этом на практике, как это ни парадоксально, мы часто наблюдаем случаи, когда в рамках служб SOC основной фокус делается на детектировании и почти полностью игнорируются процессы реагирования. В итоге это приводит к написанию крайне упрощенных регламентов, в которых процесс реагирования изначально имеет размытые зоны ответственности и упрощенную структуру, что, безусловно, снижает эффективность множества процессов Incident Response в целом. Приведем аналогию из жизни: важно не только вовремя правильно диагностировать заболевание, но и оперативно назначить пациенту эффективное квалифицированное лечение.

Кроме того, существуют важнейшие перманентные процессы, такие как Threat Hunting — проактивный поиск угроз, которые не обнаруживаются традиционными средствами детектирования. Важно понимать, что Threat Hunting требует хорошей координации между командами, в том числе с ИТ-специалистами и владельцами активов, а также глубокого погружения в инфраструктуру.

 

Рисунок 3. Процесс Threat Hunting (подход Carbon Black)

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

Вот и получается, что без таких процессов как Threat Hunting и выстроенных процессов Incident Response типовой коммерческий SOC представляет собой просто SIEM как сервис (SIEM в облаке). Это достаточно важный момент, ведь многие сервис-провайдеры выстраивают конвейер, минимизируя свое погружение в процессы и инфраструктуру клиента. В итоге через один-два года клиенты выражают недовольство и разочарование, а иногда и вовсе прекращают пользоваться услугами экспертного аутсорсинга, переходя к идее собственного SOC с учетом значительных издержек на его создание.

Трудности взаимодействия всех участников процессов Incident Response

Третья, не менее важная проблема может возникнуть при реализации мониторинга и реагирования в зрелом формате, когда необходимо выстроить эффективное взаимодействие между профильными группами и определить роль каждого участника. Сложность здесь заключается в том, что крайне трудно наладить продуктивную координацию между командами Incident Response, если они представляют разные стороны. С этим мы нередко сталкиваемся даже на CTF-соревнованиях, в которых компания «Инфосистемы Джет» часто принимает участие: команды SOC и команды реагирования находятся в считанных метрах друг от друга и при этом почти всегда испытывают сложности взаимодействия. Что уж говорить о реальных контрактах, где у разных команд могут быть разные KPI, приоритеты, интересы или квалификация. В итоге из-за отсутствия слаженности действий очень сильно страдает не только эффективность процессов, но и драматически увеличивается время их выполнения.

 

Рисунок 4. Среднее время отработки процессов Incident Response (статистика SANS за 2017 г.)

 

Мы уверены, что лучшее решение данной проблемы — привлечение сработанных команд и минимизация количества участвующих в процессе сторон.

Резюмируя вышесказанное, можно сделать вывод, что для повышения эффективности и востребованности сервисов аутсорсинга мониторинга и реагирования на угрозы ИБ необходимо учитывать следующие факторы:

• Клиентам зачастую нужна поддержка по всему перечню процессов Incident Response
• Важно разделять в регламентах разные типы реагирования, требующие различных специализаций и реализующиеся на разных этапах
• Детектирование (мониторинг) без выстроенных процессов реагирования теряет смысл
• Эффективность процессов Incident Response достигается налаживанием тесной координации между группами и распределением ролей между участниками, лучше всего концентрировать все роли в одной экспертной команде

Именно эти требования стали для нас ориентиром при пересмотре подхода к аутсорсингу информационной безопасности.

 

Jet CSIRT: больше, чем SOC

Убедившись в преимуществах концепции CSIRT, более широко охватывающей блок Incident Response и связанные с ним процессы, мы решили взять ее за основу обновленного подхода к аутсорсингу SOC.

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

Обладая одной из крупнейших в стране команд в сфере информационной безопасности и располагая десятками действующих сервисных контрактов экспертного аутсорсинга ИБ, компания запустила разработку сервисного продукта Jet CSIRT. Наличие большого количества специалистов ИБ различных профилей позволило нам реализовать гибкий подход и большой охват процессов Incident Response.

Безусловно, помимо собственного опыта создания коммерческого SOC, при создании Jet CSIRT использовался опыт и наработки других экспертных команд, а также учитывались требования законодательства и регуляторов. В частности, при построении Jet CSIRT мы руководствовались:

• Выстраивание процессов: NIST 800-61, FIRST Framework.
• Выстраивание команд, регламенты взаимодействия, определение ролей: практики SANS, РС БР ИББС-2.5-2015.
• Технологии и архитектура: практики MITRE, SANS.
• Используемые метрики и оценки зрелости: подходы Carnegie Mellon University, Rhodes University.
• Требования: №187-ФЗ, ПП-79, ПП-541, СТО БР ИББС-1.0-2014.

Стоит отметить, что FIRST Framework и NIST 800-61 определяют довольно широкий перечень сервисов CSIRT. Помимо Incident Response, в CSIRT могут быть встроены десятки сервисов и процессов: от проектирования систем ИБ, аудита и консалтинга ИБ, пентестов, всевозможной аналитики до разработки средств защиты информации. Поскольку большую часть этих задач «Инфосистемы Джет» уже успешно решает, для создания Jet CSIRT нужно было консолидировать часть уже реализуемых функций Центра информационной безопасности в единый сервисный продукт. В Jet CSIRT мы решили поместить только сервисы экспертного аутсорсинга Incident Response и эксплуатацию СЗИ.

 

Рисунок 5. Место Jet CSIRT в составе услуг Центра информационной безопасности «Инфосистемы Джет»

 

Jet CSIRT тесно взаимодействует с другими командами «Инфосистемы Джет», что позволяет включаться на любом этапе развития системы ИБ клиента и предлагать широкий перечень услуг, совмещая услуги создания, развития систем ИБ и консалтинга с услугами экспертного аутсорсинга, создавая продукты «под ключ» и обеспечивая их последующую поддержку.

 

Рисунок 6. Структура команды Jet CSIRT и взаимодействие с командами Центра информационной безопасности компании «Инфосистемы Джет»

 

Как правило, применяются две основные схемы подключения клиентов.

 

Рисунок 7. Схема подключения к инфраструктуре клиента: внешняя экспертиза, собственные ресурсы клиента

 

Первая подразумевает привлечение только экспертизы и аналитики в рамках Incident Response — за процессы отвечает команда Jet CSIRT, используя собственный инструментарий клиента. Такой подход позволяет Jet CSIRT подключаться практически ко всем популярным SIEM и СЗИ на стороне клиента. Подобная гибкость достигается благодаря большой команде Центра информационной безопасности, в которой есть эксперты по всем SIEM и СЗИ на рынке.

 

Рисунок 8. Схема подключения к инфраструктуре клиента: внешняя экспертиза, ресурсы Jet CSIRT

 

Вторая схема предполагает как использование экспертизы и аналитики Jet CSIRT, так и инструментария «Инфосистемы Джет». Ядро Jet CSIRT располагается в защищенном облаке виртуального ЦОД компании.

Таким образом, используемые источники событий Jet CSIRT и применяемый инструментарий представляют собой весьма большой и гибко изменяемый перечень.

 

Рисунок 9. Источники данных и применяемый инструментарий в Jet CSIRT

 

Уже при выполнении первых контрактов, работая с обновленной концепцией Jet CSIRT, мы на практике убедились в ее преимуществах. Так, мы отметили ускорение фаз обработки и анализа инцидентов ИБ, улучшение качества аналитики, что привело к повышению уровня удовлетворенности клиентов. Действительно, важной особенностью оказалась возможность работы с единым сервис-провайдером по очень широкому спектру задач. Например, помимо сервисов Incident Response, наши клиенты получили возможность подключения специалистов по анализу защищенности, комплексные рекомендации по развитию систем и служб ИБ, а также помощь в проектировании и настройке средств защиты.

 

Выводы

Таким образом, общий подход и цели Jet CSIRT можно сформулировать следующим образом:

• Услуга полного цикла Incident Response и даже шире (эксплуатация, пентесты и т. д.).
• Максимально гибкий подход, насколько это вообще возможно (разные схемы включения, SLA, бизнес-модели).
• Приоритет не на количество клиентов, а на глубину погружения в инфраструктуру, процессы компании (приоритет на долговременные отношения).
• Работа от модели угроз, возможность подключения на любом уровне зрелости и на любом этапе создания системы ИБ.
• Развитие передовых аналитических подходов по Forensics, Threat Hunting, Threat Intelligence, разработка уникального подхода к реагированию на инциденты ИБ.

В настоящий момент Jet CSIRT уже полноценно функционирует, и «Инфосистемы Джет» оказывает комплексные услуги экспертного аутсорсинга клиентам из самых разных отраслей. Подробнее об услугах Jet CSIRT вы можете узнать здесь.