Технологии успешного SOC: стратегии и сценарии реагирования31.12.2021 14:15

Данила Луцив, руководитель отдела развития продукта Security Vision, и Руслан Рахметов, генеральный директор компании, уже рассказали CNews об источниках данных, необходимых для выявления инцидентов информационной безопасности, а также о правилах их детектирования. Оба аспекта деятельности SOC эксперты рассматривали через призму того,  какие из общедоступных проектов и материалы могут быть либо напрямую использованы, либо вдохновить на создание новых подходов и решений.

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

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

Сценарии реагирования решают следующие задачи:

• Погружают аналитика SOC в контекст расследуемого инцидента, снабжая его всей необходимой информацией о характере инцидента, правилах анализа вовлеченных внешних и внутренних объектов, а также описанием правил корреляций, референсных исследований и возможных причин ложноположительных срабатываний;
• Классифицируют инцидент по уровню критичности в зависимости от его типа и вовлеченных объектов.
• Формируют надлежащий перечень необходимых действий для успешной обработки инцидента на всех стадиях его жизненного цикла;
• Закрепляют процедуры формирования рабочей группы и триггеров, при которых происходит эскалация;
• Создают инструментарий для накопления подобного рода экспертизы в виде, удобном для использования, последующего улучшения и распространения внутри компании и за ее пределами.

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

Этапы роста уровня зрелости процесса реагирования на инциденты информационной безопасности

Какую методологию формирования этих самых сценариев реагирования стоит выбрать? Опрос в социальных сетях — хоть и не самый достоверный, но весьма показательный инструмент, говорящий о том, что большинство опрошенных отдают свои предпочтения одному из стандартов: NIST Computer Security Incident Handling Guide (800–61 R2) и SANS 504-B Incident Response Cycle (PICERL).

Сами эти методологии чрезвычайно похожи друг на друга. Обе уделяют большое внимание процессу подготовки, инвентаризации и категорирования активов, созданию списков коммуникации по различным типам инцидентов, базовых уровней (baselinse) поведения систем для последующего сравнения с потенциально скомпрометированной и т.д. SANS и NIST на этапе анализа инцидента уделяют особое внимание поиску точки входа и охвату вовлечённых объектов. И, наконец, на финальном этапе формируется закрепление полученных результатов в виде обратной связи для постоянного улучшения процесса реагирования. Различие, и то достаточно номинальное, заключается в том, что NIST объединяет в один этап Сдерживание, Искоренение и Восстановление, в то время как SANS считает каждый из них отдельным этапом.

Если с методологией все более-менее понятно, то с ее практическим применениями и источниками прикладных сценариев все обстоит не так радужно. В прикладном смысле сценарий (плейбук) — это набор инструкций и действий, которые должны выполняться участниками и системами на каждом этапе процесса реагирования на инцидент. Такой план действий предназначен для того, чтобы указать организациям четкий путь через весь процесс, хотя и с определенной степенью гибкости в случае, если расследуемый инцидент не укладывается в рамки.

В качестве примера рассмотрим структуру сценария распространенной угрозы фишинга с учетом описанных ранее этапов.

• Подготовка (Preparation). В случае фишинговых атак этот этап может включать осведомленность сотрудников для выявления потенциальных фишинговых сообщений в электронной почте или использование средств защиты, которые сканируют вложения на наличие вредоносных программ и ссылок.
• Обнаружение (Detection). О фишинговых атаках организации часто получают предупреждение от ответственных сотрудников или с помощью средств контроля безопасности электронной почты. Они также должны планировать получение предупреждений с помощью средств антивирусной защиты или других систем предотвращения вторжений на конечных устройствах. Типовые вредоносные техники, такие как выполнение вредоносного кода из офисных документов, также должны быть покрыты правилами детектирования на SIEM- системах на основе анализа событий конечных устройств.
• Анализ (Analysis). Если событие обнаружено, анализ любых имеющихся вовлеченных объектов будет иметь решающее значение для классификации инцидента и надлежащего реагирования на него. В этом случае анализ может включать в себя: — изучение индикаторов компрометации (Indicator of Compromise, IoC) и исполняемых объектов на предмет их репутации и наличия признаков вредоносности;
  — изучение журналов событий на предмет подозрительных активностей;
  — проверку исходящего сетевого трафика, как направленного в сеть интернет, так и внутри защищаемого периметра;
  — также применяется анализ памяти устройства, служебных областей файловой системы и конфигураций, таких как реестр, WMI, сервисы и запланированные задачи на предмет наличия индикаторов атак (Indicator of Attack, IOA).
• Сдерживание (Containment). Если хост был идентифицирован как взломанный, он должен быть изолирован от сети.
• Искоренение (Eradication). В случае обнаружения вредоносного ПО его следует удалить. В противном случае в сценарии должна быть альтернатива, позволяющая выполнить развертывание системы с заведомо исправным образом.
• Восстановление (Recovery). Этап восстановления включает сканирование хоста на предмет потенциальных уязвимостей и мониторинг системы на предмет аномального трафика.
• Действия после инцидента (Post-incident activity). На данном этапе подготавливаются отчеты, используемые как для внутреннего пользования, так и направляемые в отраслевые и государственные центры мониторинга. Кроме того, производится анализ качественных и количественных метрик успешности процесса обработки и факторов, которые негативно повлияли на него и могут быть улучшены в будущем. Зафиксированные индикаторы компрометации на данном этапе также фиксируются во внутренних TI-системах.

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

IRM (Incident Response Methodologies by CERT Societe Generale) — наверное старейший и самый знаменитый публично доступный архив сценариев. Плейбуки локализованы на русском и испанском. Насчитывают 14 законченных типов, и, несмотря на свой солидный возраст, они до сих пор актуальны и вполне применимы, хотя стоит делать поправку на новые версии операционных систем.

GuardSIght Playbook Battle Cards. Довольно свежий проект, вдохновленный предыдущим ресурсом CERT Societe Generale, представила GuardSight, Inc. Ресурс содержит порядка пятидесяти сценариев и активно обновляется. Приятно видеть, что сценарии имеют референсы на техники Mitre ATT&CK, однако информация в самих карточках достаточно скупа на технические детали и призвана скорее направить, нежели дать исчерпывающую информацию. Соседние ветки репозитария также содержат Cybersecurity Incident Response Plan— тактический план компании по обработке инцидентов, Mission-model— шаблон отчета, который создается в процессе обработки инцидента, и ряд других интересных проектов.

Counteractive Playbooks— проект компании CounteractiveSecurity. Он содержит пока лишь пять сценариев реагирования, многие пункты из которых пока в ToDo. Однако в отличие от предыдущего проекта, сфокусированного на концентрированном предоставлении всей информации, это достаточно технически погруженные в детали сценарии реагирования.

IR Workflow Gallery — проект, схемы из которого не стыдно показать руководству. Содержит девять сценариев, каждый этап сформирован в схему, доступную для скачивания в pdf и visio. Схемы скупы на технические детали, однако отлично подойдут в качестве ментальных карт, а открытый для изменения формат легко адаптировать под себя.

Flexibleir— стартап для создания новых плейбуков и конвертирования имеющихся в формат интерактивных досок. Плейбуки постоянно обновляются, появляются специализированные, касающиеся эксплуатации трендовых уязвимостей или активности хакерских группировок.

Incident-Playbook — недавно появившийся проект, продвигаемый энтузиастами кибер-сообщества в рамках вселенной Mitre ATT&CK. Он создан для максимальной интеграции данных фреймворка в процесс обработки инцидентов. Сам концепт крайне интересный, есть отдельные ветки по настройке хардеринга систем, идентификации атак с описанием типов событий, роли, метрики эффективности и списки наблюдаемых значений. Однако проект остро нуждается в новых авторах для наполнения экспертизой.

Phantom Cyber playbooks — репозиторий публично доступных сценариев для Splunk Phantom, однако в принятой в данной статье терминологии, большинство сценариев в нем плейбуками все же не являются, так как выполняют лишь атомарную операцию по анализу или предотвращению. Аналогичные ранбуки можно найти в ветке Cortex-Analyzers проекта The Hive.

ThreatHunter-Playbook — проект, относящийся, скорее, к сфере Threat Hunting (TH), нежели классический DFIR (Digital Forensics and Incident Response), однако безусловно заслуживающий внимания. Аналогично описанным выше шагам в процессе расследования инцидентов, автор проектаРоберто Родригес (Roberto Rodriguez) поэтапно описывает работы с TH-гипотезами. Сценарии имеют Jupyter-формат и ссылаются на публичный датасет событий безопасности OTRF/Security-Datasets, что позволяет повторить анализ за автором в режиме онлайн.

Microsoft Security Best Practices. Даже Microsoft начинает публиковать свои сценарии реагирования. Пока их лишь три: Phishing, Password spray иApp consent grant, и касаются они облачных сервисов в Azure.

И в заключение еще несколько шаблонов сценариев реагирования от разных компаний:

Подготовка подробного рода сценариев реагирования и, главное, их внедрение в продуктивную эксплуатацию требует значительных ресурсов. Для наиболее скорого возврата этих инвестиций создание таких методик реагирования лучше сразу начинать в решениях класса SOAR (Security Orchestration, Automation and Response). Он как раз и создан для конструирования сценариев, автоматизации взаимодействия людей и систем, анализа наблюдаемых объектов, формирования отчетов и подсчета метрик эффективности. Такие системы позволяют снабдить аналитика максимально возможной информацией для принятия решения, автоматизировать рутинные операции, упростить коллективную работу над инцидентом и закрепить полученные знания. Во главу угла же в системах подобного класса встает максимальная гибкость и кастомизируемость всех элементов системы. Описанные выше разнообразные подходы к формализации процесса реагирования являются тому прекрасным примером. Платформа Security Vision SOAR сочетает в себе простоту дружелюбного интерфейса и лежащий «под ее капотом» интеллектуальный механизм коннекторов, рабочих процессов, событий и объектов, который позволяет автоматизировать практически любой процесс информационной безопасности.

Полный текст статьи читайте на CNews