Поделиться через


Этап 5. Разработка и тестирование вариантов использования

Область применения:

  • Microsoft Defender XDR

Рекомендуемые методы развертывания Microsoft Defender XDR в центре управления безопасностью (SOC) зависят от текущего набора средств, процессов и навыков команды SOC. Поддержание кибергигии на разных платформах может быть сложной задачей из-за огромного объема данных, поступающих из десятков, если не из сотен источников безопасности.

Средства безопасности взаимосвязаны. Включение одной функции в технологии безопасности или изменение процесса могут, в свою очередь, сломать другую. По этой причине корпорация Майкрософт рекомендует команде SOC формализовать метод для определения и определения приоритетов вариантов использования. Варианты использования помогают определять требования и тестировать процессы для операций SOC в разных командах. Она создает методологию для сбора метрик, чтобы определить, соответствуют ли нужные роли и набор задач правильной команде с правильным набором навыков.

Процесс разработки и формализации варианта использования

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

Действия по надзору SOC, связанные с разработкой вариантов использования, включают в себя:

  • Требования
  • Потребности в персонале или обучении
  • Лицензии на программное обеспечение
  • Заключение контрактов с поставщиком
  • Управление планом
  • Ведение реестра вариантов использования
  • Обслуживание и обновление шаблонов

Чтобы упростить процессы создания runbook и сборника схем, создайте дерево принятия решений по вариантам использования. На этом рисунке показан пример.

Процесс принятия решения по варианту использования

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

Пример использования 1. Новый вариант фишинга

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

Рабочий процесс варианта использования кампании по борьбе с фишингом

Вызов рабочего процесса варианта использования, например 1

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

Подробный рабочий процесс использования для кампании по борьбе с фишингом

Пример использования 2. Проверка угроз и уязвимостей

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

Ниже приведен пример высокоуровневой раскадровки для Управление уязвимостями Microsoft Defender ресурсов.

Рабочий процесс использования для контроль угроз и уязвимостей

Вызов рабочего процесса варианта использования, например 2

Ниже приведен пример процесса проверки угроз и уязвимостей.

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

Анализ выходных данных варианта использования и извлеченных уроков

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

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

Команда SOC Требование Люди для удовлетворения требований Процесс для удовлетворения требований Соответствующая технология Обнаруженный пробел Журнал изменений вариантов использования Исключение (Y/N)
Команда аналитики и аналитики угроз Источники данных правильно питают подсистемы аналитики угроз. Аналитик или инженер аналитики угроз Установленные требования к каналу данных, триггеры аналитики угроз из утвержденных источников Microsoft Defender для удостоверений, Microsoft Defender для конечной точки Команда аналитики угроз не использовала скрипт автоматизации для связывания Microsoft Defender XDR API с обработчиками intel для угроз Добавление Microsoft Defender XDR в качестве источников данных в подсистемы угроз

Обновление книги выполнения вариантов использования

N
Команда по мониторингу Источники данных правильно предоставляют панели мониторинга Аналитик SOC уровня 1,2— мониторинг & оповещений Рабочий процесс для отчетности по оценке безопасности Центра соответствия требованиям безопасности & Изучение оповещений в Microsoft Defender XDR

Мониторинг оценки безопасности

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

Просмотр отчетов о безопасности электронной почты на портале Microsoft Defender

Добавление процесса отслеживания улучшения оценки безопасности в рабочие процессы создания отчетов N
Команда разработчиков и разработчиков SecOps Обновления элемента управления изменениями выполняются в модулях Runbook группы SOC Инженер SOC уровня 2 Процедура уведомления управления изменениями для модулей Runbook группы SOC Утвержденные изменения устройств безопасности Для изменения Microsoft Defender XDR подключения к технологии безопасности SOC требуется утверждение Добавление Microsoft Defender for Cloud Apps, Defender для удостоверений, Defender для конечной точки, Центра соответствия требованиям безопасности & в модули Runbook SOC Да

Кроме того, команды SOC могли бы сделать обнаружения, описанные в таблице ниже, в отношении сценария управления уязвимостями Defender, описанного выше:

Команда SOC Требование Люди для удовлетворения требований Процесс для удовлетворения требований Соответствующая технология Обнаруженный пробел Журнал изменений вариантов использования Исключение (Y/N)
Контроль SOC Все ресурсы, подключенные к утвержденным сетям, определяются и классифицируются Контроль SOC, владельцы bu, владельцы приложений, владельцы ИТ-ресурсов и т. д. Централизованная система управления активами для обнаружения и перечисления категории активов и атрибутов на основе риска. ServiceNow или другие ресурсы.

Инвентаризация устройств Microsoft 365
Было обнаружено только 70 % активов. Microsoft Defender XDR отслеживание исправлений, действующее только для известных ресурсов Зрелые службы управления жизненным циклом активов, чтобы обеспечить Microsoft Defender XDR 100 % покрытия N
Инжиниринг & SecOps Teams Высокий уровень влияния и критические уязвимости в ресурсах устраняются в соответствии с политикой. Инженеры SecOps, аналитики SOC: Уязвимости & соответствие, инженеры безопасности Определенный процесс классификации уязвимостей с высоким риском и критических уязвимостей Панели мониторинга Управление уязвимостями Microsoft Defender Defender для конечной точки определил устройства с высоким уровнем влияния и высоким уровнем оповещений без плана исправления или реализации действий, рекомендуемых Корпорацией Майкрософт Добавьте рабочий процесс для уведомления владельцев активов о необходимости действий по исправлению в течение 30 дней для каждой политики; Реализуйте систему запросов, чтобы уведомлять владельцев активов о шагах по исправлению. N
Мониторинг Teams Сведения о состоянии угроз и уязвимостей передаются через портал интрасети компании Аналитик SOC уровня 2 Автоматически созданные отчеты из Microsoft Defender XDR, показывающие ход исправления ресурсов Изучение оповещений в Microsoft Defender XDR

Мониторинг оценки безопасности

Владельцам активов не передаются представления или отчеты панели мониторинга о состоянии угроз и уязвимостей ресурсов. Create скрипт автоматизации для заполнения состояния высокого риска и устранения уязвимостей критических ресурсов в организации. N

В этих примерах вариантов использования тестирование выявило несколько пробелов в требованиях команды SOC, которые были установлены в качестве базовых показателей ответственности каждой команды. Контрольный список вариантов использования может быть исчерпывающим по мере необходимости, чтобы убедиться, что команда SOC готова к Microsoft Defender XDR интеграции с новыми или существующими требованиями SOC. Так как это итеративный процесс, процесс разработки вариантов использования и выходное содержимое варианта использования, естественно, служат для обновления и развития модулей Runbook SOC с учетом извлеченных уроков.

Обновление рабочих модулей Runbook и сборников схем

После того как тестирование вариантов использования будет устранено для всех пробелов, извлеченные уроки и собранные в них метрики можно будет включить в рабочие runbook команды SOC (операционные процессы) и сборники схем (реагирование на инциденты и процедуры эскалации).

Обслуживание модулей runbook и схем группы SOC можно организовать различными способами. Каждая команда SOC может нести ответственность за свои собственные или может существовать единая централизованная версия для всех команд для совместного использования в центральном репозитории. Управление модулями Runbook и сборниками схем для отдельных организаций зависит от размера, набора навыков, ролей и разделения обязанностей. После обновления модуля Runbook следует выполнить процесс обновления сборника схем.

Использование стандартной платформы для эскалации

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

Процесс реагирования на инциденты NIST с четырьмя шагами включает четыре этапа:

  1. Подготовка
  2. Обнаружение и анализ
  3. Сдерживание, искоренение и восстановление
  4. Действия после инцидента

Пример. Отслеживание действий этапа подготовки

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

Например, этап подготовки может включать матрицу задач if/then или XoR. В случае примера использования нового варианта фишинга такая матрица может выглядеть следующим образом:

Почему эскалация оправдана? Дальнейшие действия
Оповещение в мониторинге SOC оценивается как критическое срабатывание >500 в час Перейдите в сборник схем A, раздел 2, действие 5 (со ссылкой на раздел сборника схем)
Электронная коммерция сообщила о потенциальной атаке DDoS Вызов сборника схем B-Section C, действие 19 (со ссылкой на раздел сборника схем)
Руководитель сообщил о подозрительном сообщении электронной почты как о попытке фишинга Перейдите в сборник схем 5, раздел 2, действие 5 (со ссылкой на раздел сборника схем)

После выполнения этапа подготовки организации должны вызвать остальные этапы, как описано в NIST:

  • Обнаружение и анализ
  • Сдерживание, искоренение и восстановление
  • Действия после инцидента

Следующее действие

Этап 6. Определение задач обслуживания SOC

Совет

Хотите узнать больше? Engage с сообществом Microsoft Security в нашем техническом сообществе: Microsoft Defender XDR Техническое сообщество.