BIS Journal №4(35)/2019

27 декабря, 2019

На новом уровне

В этой статье мы постараемся приоткрыть занавес технических проблем со стороны SIEM-систем и их компонентов, с которыми сталкиваются организации при переходе на следующий уровень развития собственного ситуационного центра (SOC) в модели сервис-провайдера услуг по информационной безопасности (MSSP, Managed Security Service Provider).

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

С целью коммерциализации своей деятельности и получения дополнительной финансовой прибыли ряд компаний переводят свои ситуационные центры в модель оказания услуг информационной безопасности SaaS (Security asa Service), выступая в роли MSSP-провайдеров. При этом на первом этапе компании, как правило, начинают предоставлять услуги только для собственных дочерних предприятий, а затем уже выходят на рынок предоставления услуг для сторонних организаций.

 

БАЗОВЫЕ РЕКОМЕНДАЦИИ

Чтобы начать процесс построения MSSP модели,необходимо убедиться в наличии:

  • квалифицированных кадров;
  • документальной базы (политики ИБ, регламенты, инструкции и т.д.);
  • выстроенных процессов выявления и реагирования на инциденты;
  • эффективно работающей SIEM-системы;
  • проверенного контента в SIEM-системе для выявления инцидентов ИБ(правила, фильтры, отчеты, дашборды и др.);
  • компонентов и дополнительных программных комплексов для реализации SOC;
  • шины данных и специализированных программных средств для работы клиентов MSSP.

Если Вы приняли решение начать предоставлять MSSP-услуги другим лицам и компаниям на базе Вашего SOC, то мы рекомендуем учитывать следующее:

  1. Масштабируемость SIEM-систем зачастую является проблемой, когда необходимо подключить несколько заказчиков и правильно распределить потоки поступающей информации.
  2. Четкое проектирование каналов связи и «кратчайших путей» до вашей входной точки в SOC будет немаловажным подспорьем при реализации MSSP модели.
  3. Изучение специфики и особенностей каждого подключающегося заказчика к Вашей услуге является отправной точкой к фильтрации бескрайнего количества событий, которые будут поступать к Вам. В противном случае SOC просто «захлебнется» и не сможет обработать поступающие события.
  4. Организация работы первой линии уже не будет выглядеть настолько просто, что можно брать на нее студентов и людей с низкой компетенцией.
  5. Каждый монитор первой линии в Вашем SOC больше не может показывать «возможно-нужную» информацию – необходимость в оперативном мониторинге и качество визуализации метрик SOC будет стоять на первом месте.
  6. Существующий контент в SIEM системе должен в автоматическом режиме перестраиваться под каждого заказчика и добавлять оперативную информацию в события каждого клиента.
  7. Предоставление отчетности и визуализации каждому клиенту является неотъемлемой частью оказания услуги MSSP.
  8. Необходимо предусмотреть механизм добавления или изменения подключенных услуг клиенту MSSP.
  9. Необходимо продумать механизмы оповещения о выявленных инцидентах ИБ в ночное и нерабочее время, так как привлечение сотрудников разных подразделений (ИТ, ИБ, Network, Руководителей проектов и др.) – задача, требующая отдельной проработки. Для организации оповещений зачастую используются механизмы интеграции со Skype, Telegram bot и другие.
  10. Ведение услуг MSSP предполагает наличие руководителей проекта для клиента и заказчика, так как интеграционные работы зачастую схожи по уровню сложности с работами по внедрению компонентов SIEM.
  11. Далее рассмотрим более подробно некоторые аспекты построения модели MSSP.

 

SIEM КАК УСЛУГА MSSP

На сегодняшний день большое количество владельцев SOC уверены, что они готовы принимать «на борт» нагрузку потенциальных клиентов без каких-либо трудностей. Однако их мечты в большинстве случаев обречены разбиться о входной EPS (объем событий поступающих в секунду), отсюда вытекает следующее:

Проблема MSSP №1 - Клиент зачастую сам не знает, что нужно собирать и обрабатывать.

Правило MSSP №1 - Собирать и обрабатывать следует только те события, под которые у Вас есть необходимый контент в SIEM-системе.

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

Основным инструментом для выявления инцидентов ИБ является Ваш контент в SIEM (правила, фильтры, отчеты, дашборды и другое). Такой контент должен удовлетворять следующим требованиям:

  • создан по мировым практикам реализации MSSP моделей;
  • прост и удобен в эксплуатации – в случае необходимости должен быть изменен любым членом команды SOC, ответственным за контент;
  • классифицирован – классификация событий и инцидентов ИБ необходима для реализации модели выявления инцидентов и их визуализация для каждого заказчика;
  • оптимизирован – быстродействие работы всех компонентов SIEM-системы это залог быстрой обработки поступающих событий. Также немаловажную роль играет отсутствие неиспользуемых ресурсов и/или ресурсов тестового назначения в продуктивной среде;
  • разграничительным, – обладающим функциями работы для любого из заказчиков без дополнительной настройки;
  • масштабируемый  – контент должен легко масштабироваться для легкого перехода на следующий уровень развития SOC – MDR (Managed Detection and Response).

На сегодняшний день на российском рынке есть несколько предложений по готовому контенту для SIEM-систем. Так, например, компания «ДиалогНаука» предлагает самодостаточный SOC-пакет правил корреляции собственной разработки,который в том числе может использоваться для реализации MSSP-модели.

 

МАНИПУЛЯЦИЯ УСЛУГАМИ MSSP

Необходимо понимать, что предоставляемый сервис MSSP – это возможность заказчика выбирать те услуги и компоненты, в которых у него есть потребность в данный момент, а также возможность отключать услуги в случае их неактуальности (DDoS, вирусная эпидемия).

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

Проблема MSSP №2 - Для предоставления услуг должного уровня количество разрабатываемых и необходимых к оптимизации сервисов для MSSP возрастает в разы.

Правило MSSP №2 - Использование решений с открытым исходным кодом (Open Source) в MSSP не всегда плохо, а зачастую просто необходимо (например, The Hive, Elastic Stack, Metron, Hadoop).

 

ОТЧЁТНОСТЬ И ВИЗУАЛИЗАЦИЯ  

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

В случае MDR-архитектуры дополнительно потребуется предоставление информации об этапности реализации атаки (killchain), классификации угрозы и возможных объектов,находящихся в зоне риска. Отсюда можно сделать следующий вывод:

Проблема MSSP №3 - Качественная визуализация – отдельный программный комплекс, входящий в состав SOC и требующий компетентных специалистов.

Правило MSSP №3 - Отчетность и визуализация – главный инструмент для анализа эффективности работы сервиса MSSP для клиента.

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

Примером отчетности могут послужить уведомления об инциденте ИБ в Telegram или другой корпоративный мессенджер. Основная идея заключается в том, что при наступлении инцидента ИБ корреляционное правило запускает скрипт, который добавляет в клиентский telegram-канал всю необходимую информацию.

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

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

24.04.2024
У «Сбера» (и рынка?) будет свой SAP за «миллиарды рублей»
24.04.2024
В I квартале хакеры совершили более 19 млн атак на смартфоны россиян
24.04.2024
Минпромторг раздаёт деньги на отечественные решения
24.04.2024
Правительство одобрило ужесточение наказания за утечку ПДн
24.04.2024
«Мы разработали законодательную инициативу по дропам»
24.04.2024
«Мы обеспечили определённый уровень заказа». ГРЧЦ продолжает импортозамещать чипы
23.04.2024
В АП не поддержали поправки о штрафах за утечки ПДн
23.04.2024
Хакеры всё активнее DDoS-ят российскую отрасль энергетики
23.04.2024
Минпромторг начнёт выдавать баллы блокам питания?
23.04.2024
Microsoft — угроза для нацбезопасности? Бывает и такое

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных