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

Статья
04/26/2024

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

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 с четырьмя шагами включает четыре этапа:

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

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

Одна из основных основ сборника схем эскалации заключается в том, чтобы обеспечить небольшую неоднозначность в отношении того, что каждая команда 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 Техническое сообщество.

Share via