Исследование скомпрометированных и вредоносных приложений

Статья
2025-03-12

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

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

Предварительные условия

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

Чтобы использовать сигналы защиты идентификации, клиент должен быть лицензирован для Microsoft Entra ID P2.
- Понимание концепций рисков защиты идентификации
- Понимание концепций исследования по защите идентичности
Учетная запись с по крайней мере ролью администратора безопасности.
Возможность использовать Обозреватель Microsoft Graph и быть знакомыми (в некоторой степени) с API Microsoft Graph.
Ознакомьтесь с концепциями аудита приложений (частью https://aka.ms/AzureADSecOps).
Убедитесь, что все корпоративные приложения в вашем арендаторе имеют владельца с целью обеспечения подотчетности. Ознакомьтесь с основными понятиями о владельцах приложений и назначении владельцев приложений.
Ознакомьтесь с понятиями исследования предоставления согласия приложения (часть https://aka.ms/IRPlaybooks).
Убедитесь, что вы понимаете следующие разрешения Microsoft Entra:
- Рискованные разрешения
- Модель согласия и рабочий процесс согласия администратора
Ознакомьтесь с концепциями обнаружения рисков, связанных с идентификацией рабочей загруженности.
Для использования приложений Microsoft Defender для облака необходимо иметь полную лицензию Microsoft 365 E5.
- Основные понятия исследования оповещений об обнаружении аномалий
Ознакомьтесь со следующими политиками управления приложениями:
- Обзор API методов проверки подлинности приложений Microsoft Entra (предварительная версия)
- Тип ресурса appManagementPolicy
Ознакомьтесь со следующими политиками управления приложениями:
- Блог по управлению приложениями
- Управление приложениями в приложениях Defender для облака

Необходимые средства

Для эффективного исследования установите следующий модуль PowerShell и набор средств на компьютере для исследования:

Рабочий процесс

Подробные блок-схемы действий по расследованию.

Шаги для исследования

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

Этот плейбук создан с учетом того, что не все клиенты Microsoft и их команды расследования имеют полный набор лицензий Microsoft 365 E5 или Microsoft Entra ID P2, доступный или настроенный. В этом сборнике схем выделены другие возможности автоматизации при необходимости.

Определение типа приложения

Важно определить тип приложения (нескольких или отдельных клиентов) на этапе исследования, чтобы получить правильную информацию, необходимую для обращения к владельцу приложения. Дополнительные сведения см. в разделе «Тенант» в Microsoft Entra ID.

Мультитенантные приложения

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

Приложения с одним клиентом

Найдите контактные данные владельца приложения в организации. Его можно найти на вкладке "Владельцы" в разделе " Корпоративные приложения ". Кроме того, в вашей организации может быть база данных с этой информацией.

Вы также можете выполнить этот запрос Microsoft Graph:

GET https://graph.microsoft.com/v1.0/applications/{id}/owners

Проверка защиты идентичности — рисковые идентичности рабочих нагрузок

Эта функция находится на стадии предварительного просмотра на момент написания этого плейбука, и к её использованию применяются лицензионные требования. Удостоверения рабочей нагрузки рискованно могут быть триггером для исследования субъекта-службы, но также можно использовать для дальнейшего изучения других триггеров, которые вы определили. Вы можете проверить состояние риска субъекта-службы с помощью вкладки «Защита идентификационных данных» — «Удостоверения с рисковой нагрузкой» или использовать API Microsoft Graph. Вы также можете использовать запросы естественного языка для получения аналитики по рискованным идентификаторам рабочих нагрузок с помощью Microsoft Security Copilot в Microsoft Entra.

Снимок экрана: страница портала сведений об обнаружении рисков.

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

Пример API Графа обнаружения рисков субъекта-службы.

Первым шагом расследования является поиск доказательств необычных шаблонов подтверждения подлинности при использовании Service Principal. На портале Azure, в Azure Monitor, Microsoft Sentinel или системе управления информацией и событиями безопасности (SIEM) вашей организации найдите следующее в разделе входов служебного принципала:

Находится ли принципал-служба в местах/IP-адресах, откуда вы не ожидали проверку подлинности?
Сбои — существует большое количество сбоев проверки подлинности для субъекта-службы?
Метки времени — есть ли успешные проверки подлинности, происходящие в такое время, которое вы бы не ожидали?
Частота — увеличилось ли количество проверок подлинности для Service Principal?
Утечка учетных данных — являются ли учетные данные приложения жестко закодированные и опубликованные в общедоступном источнике, например GitHub?

Если вы развернули защиту идентификации Microsoft Entra ID — рискованные идентификаторы рабочих нагрузок, проверьте подозрительные входы в систему и обнаружение утечки учетных данных. Дополнительные сведения см. в статье о рисках идентификации рабочей нагрузки.

Проверка целевого ресурса

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

Снимок экрана: проверка ресурса для субъекта-службы.

Проверка ненормальных изменений учетных данных

Используйте журналы аудита для получения сведений об изменениях учетных данных в приложениях и основных объектах безопасности. Фильтр для категории по управлению приложениями, и мероприятия по обновлению приложений — управление сертификатами и секретами.

Проверьте, были ли недавно созданы или непредвиденные учетные данные, назначенные субъекту-службе.
Проверьте учетные данные сервисного принципала с помощью API Microsoft Graph.
Проверьте как приложение, так и связанные объекты субъекта-службы.
Проверьте любую пользовательскую роль , созданную или измененную. Обратите внимание на указанные ниже разрешения.

Снимок экрана: проверка пользовательских ролей, созданных или измененных.

Если вы развернули управление приложениями в Microsoft Defender для облака Apps, проверьте портал Azure для оповещений, связанных с приложением. Дополнительные сведения см. в статье «Обнаружение и устранение угроз приложения».

Если вы развернули Защиту идентификации, проверьте отчет "Обнаружение рисков" и "историю рисков" в учетной записи пользователя или рабочей нагрузки.

Снимок экрана: пользовательский интерфейс портала обнаружения рисков.

Если вы развернули Microsoft Defender для облачных приложений, убедитесь, что включена политика "Необычное добавление учетных данных в приложение OAuth", и проверьте наличие открытых оповещений.

Дополнительные сведения см. в статье о необычном добавлении учетных данных в приложение OAuth.

Кроме того, вы можете запросить API servicePrincipalRiskDetections и API user riskDetections, чтобы извлечь эти обнаружения рисков.

Поиск изменений конфигурации аномальных приложений

Проверьте разрешения API, назначенные приложению, чтобы убедиться, что разрешения соответствуют ожидаемым для приложения.
Проверьте журналы аудита (фильтруйте действие по обновлению приложения или обновлению основной службы).
Убедитесь, что строки подключения являются согласованными, и проверьте, был ли изменен URL-адрес выхода.
Убедитесь, что домены в URL-адресе соответствуют зарегистрированным.
Определите, добавил ли любой пользователь URL-адрес несанкционированного перенаправления.
Подтвердите владение URI перенаправления, чтобы убедиться, что его срок действия не истек и он не был захвачен злоумышленником.

Кроме того, если вы развернули Microsoft Defender для облачных приложений, проверьте портал Azure на наличие оповещений, связанных с приложением, которое вы расследуете в настоящий момент. Не все политики оповещений включены по умолчанию для приложений OAuth, поэтому убедитесь, что эти политики включены. Дополнительные сведения см. в политиках приложений OAuth. Вы также можете просмотреть сведения о распространенности приложений и последних действиях на вкладке Расследование>OAuth приложения.

Проверка подозрительных ролей приложения

Журналы аудита также можно использовать. Фильтрация действий путем добавления назначения роли приложения субъекту-службе.
Убедитесь, что назначенные роли имеют высокий уровень привилегий.
Убедитесь, необходимы ли эти привилегии.

Проверка наличия непроверенных коммерческих приложений

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

Проверка на наличие признаков раскрытия информации о свойстве keyCredential

Проверьте вашего клиента на предмет потенциального раскрытия информации о свойстве keyCredential, как описано в CVE-2021-42306.

Чтобы определить и исправить затронутые приложения Microsoft Entra, связанные с затронутыми учетными записями запуска от имени службы автоматизации, перейдите к руководству по исправлению репозитория GitHub.

Внимание

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

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

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

Ниже приведены некоторые шаги, которые можно предпринять для дальнейшего изучения.

Проверьте единый журнал аудита Microsoft 365 (UAL) для фишинговых показаний за последние семь дней

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

Владельцы приложения
Администраторы согласия

Просмотрите учетные записи на предмет признаков фишинговых атак за последние 24 часа. Увеличьте этот интервал времени при необходимости до 7, 14 и 30 дней, если нет непосредственных признаков. Для получения подробного руководства по расследованию фишинга смотрите Руководство по расследованию фишинга.

Поиск согласий для вредоносных приложений в течение последних семи дней

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

Проверка журналов аудита

Чтобы просмотреть все предоставления согласия для этого приложения, отфильтруйте действие по согласию на приложение.

Использование журналов аудита Центра администрирования Microsoft Entra
Использование Microsoft Graph для запроса журналов аудита

a) Фильтрация для определенного интервала времени:

GET https://graph.microsoft.com/v1.0/auditLogs/auditLogs/directoryAudits?&$filter=activityDateTime le 2022-01-24

b) Отфильтруйте журналы аудита для записей "Согласие на приложения":

https://graph.microsoft.com/v1.0/auditLogs/directoryAudits?directoryAudits?$filter=ActivityType eq 'Consent to application'


"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#auditLogs/directoryAudits",
"value": [
    {
        "id": "Directory_0da73d01-0b6d-4c6c-a083-afc8c968e655_78XJB_266233526",
        "category": "ApplicationManagement",
        "correlationId": "aaaa0000-bb11-2222-33cc-444444dddddd",
        "result": "success",
        "resultReason": "",
        "activityDisplayName": "Consent to application",
        "activityDateTime": "2022-03-25T21:21:37.9452149Z",
        "loggedByService": "Core Directory",
        "operationType": "Assign",
       "initiatedBy": {
            "app": null,
            "user": {
                "id": "8b3f927e-4d89-490b-aaa3-e5d4577f1234",
                "displayName": null,
                "userPrincipalName": "[email protected]",
                "ipAddress": "55.154.250.91",
                "userType": null,
                "homeTenantId": null,
                "homeTenantName": null
            }
        },
        "targetResources": [
            {
                "id": "d23d38a1-02ae-409d-884c-60b03cadc989",
                "displayName": "Graph explorer (official site)",
                "type": "ServicePrincipal",
                "userPrincipalName": null,
                "groupType": null,
                "modifiedProperties": [
                    {
                        "displayName": "ConsentContext.IsAdminConsent",
                        "oldValue": null,
                        "newValue": "\"True\""
                    },

c) Использование Log Analytics

AuditLogs
| where ActivityDisplayName == "Consent to application"

Для получения дополнительной информации см. руководство по исследованию предоставления согласий для приложения.

Пользователь может разрешить приложению доступ к некоторым данным на защищенном ресурсе, действуя при этом от имени этого пользователя. Разрешения, разрешающие этот тип доступа, называются делегированными разрешениями или согласием пользователя.

Чтобы найти приложения, предоставленные пользователями, используйте LogAnalytics для поиска журналов аудита:

AuditLogs
| where ActivityDisplayName == "Consent to application" and (parse_json(tostring(parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue)) <> "True")

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

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

Теперь следуйте инструкциям по перечислению и просмотру разрешений в расследовании предоставления согласий приложений.

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

Проверка с помощью журналов аудита:

AuditLogs
| where OperationName == "Consent to application" 
//| where parse_json(tostring(TargetResources[0].modifiedProperties))[4].displayName == "ConsentAction.Permissions"

Вы также можете использовать журналы аудита Microsoft Entra, фильтруя по согласию на приложение. В разделе сведений журнала аудита щелкните Измененные свойства, а затем просмотрите ConsentAction.Permissions:

Снимок экрана: использование журналов аудита Microsoft Entra.

Действия по сдерживанию

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

Внимание

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

Отключение скомпрометированного приложения

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

Снимок экрана: отключение входа пользователя.

Для отключения входа в приложение можно также использовать следующий код Microsoft Graph PowerShell :

# The AppId of the app to be disabled
$appId = "{AppId}"

# Check if a service principal already exists for the app
$servicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$appId'"

if ($servicePrincipal) {
   # Service principal exists already, disable it

  $ServicePrincipalUpdate =@{
    "accountEnabled" = "false"
  }
   Update-MgServicePrincipal -ServicePrincipalId $servicePrincipal.Id -BodyParameter $ServicePrincipalUpdate
   
} else {
   # Service principal does not yet exist, create it and disable it at the same time
   
   $ServicePrincipalID=@{
	"AppId" = $appId
	"accountEnabled" = "false"
   }
   
   $servicePrincipal = New-MgServicePrincipal -BodyParameter $ServicePrincipalId
   
}

Действия по восстановлению

Исправление субъектов-служб

Перечислить все учетные данные, назначенные служебному принципалу Risky Service Principal. Лучший способ сделать это — выполнить вызов Microsoft Graph с помощью GET ~/application/{id}, где переданный идентификатор является идентификатором объекта приложения.
- Выполните разбор выходных данных для извлечения учетных данных. Выходные данные могут содержать passwordCredentials или keyCredentials. Запишите ключи для всех.
```
"keyCredentials": [],
     "parentalControlSettings": {
         "countriesBlockedForMinors": [],
         "legalAgeGroupRule": "Allow"
     },
     "passwordCredentials": [
         {
             "customKeyIdentifier": null,
             "displayName": "Test",
             "endDateTime": "2021-12-16T19:19:36.997Z",
             "hint": "7~-",
             "keyId": "aaaaaaaa-0b0b-1c1c-2d2d-333333333333",
             "secretText": null,
             "startDateTime": "2021-06-16T18:19:36.997Z"
         }
     ],
```
Добавьте новые учетные данные сертификата (x509) в объект приложения с помощью API addKey приложения.
```
POST ~/applications/{id}/addKey
```
Немедленно удалите все старые учетные данные. Для каждого старого пароля удалите его с помощью:
```
POST ~/applications/{id}/removePassword
```
Для каждого старого ключа удалите его с помощью:
```
POST ~/applications/{id}/removeKey
```
Исправьте все служебные учетные записи, связанные с приложением. Выполните этот шаг, если клиент размещает или регистрирует мультитенантное приложение и (или) регистрирует несколько субъектов-служб, связанных с приложением. Выполните аналогичные действия, описанные ранее:

GET ~/servicePrincipals/{id}
Найдите passwordCredentials и keyCredentials в ответе и зафиксируйте все старые идентификаторы ключей.

Удалите все старые учетные данные пароля и ключа. Используйте:

POST ~/servicePrincipals/{id}/removePassword and POST ~/servicePrincipals/{id}/removeKey for this, respectively.

Исправление затронутых ресурсов субъекта-службы

Исправьте секреты KeyVault, к которым субъект-служба имеет доступ, сменив их в следующем приоритете:

Секреты раскрываются непосредственно при вызовах GetSecret.
Остальные секреты в открытых KeyVaults.
Остальные секреты, раскрытые в подписках.

Для получения дополнительной информации см. Интерактивное удаление и продление сертификатов и секретов субъекта-службы или приложения.

Для получения руководства по работе с приложениями Microsoft Entra SecOps см. Руководство по операциям безопасности Microsoft Entra для приложений.

В порядке приоритета этот сценарий будет следующим:

Обновите командлеты Graph PowerShell (Добавление и удаление ApplicationKey + ApplicationPassword), чтобы включить примеры для переката учетных данных.
Добавьте пользовательские командлеты в Microsoft Graph PowerShell для упрощения сценария.

Отключение или удаление вредоносных приложений

Приложение можно отключить или удалить. Чтобы отключить приложение, в разделе "Включено" для входа пользователей переместите переключатель в "Нет".

Вы можете удалить приложение либо временно, либо окончательно, в портал Azure или через API Microsoft Graph. При обратимом удалении приложение можно восстановить до 30 дней после удаления.

DELETE /applications/{id}

Чтобы окончательно удалить приложение, используйте этот вызов API Microsoft Graph:

DELETE /directory/deletedItems/{id}

Если вы отключите или временно удалите приложение, настройте мониторинг журналов аудита Microsoft Entra, чтобы узнать, если состояние изменится на включенное или восстановленное.

Ведение журнала включено:

Служба — основной каталог
Тип действия — обновление субъекта-службы
Категория — управление приложениями
Инициировано (актером) — UPN актера
Целевые объекты — идентификатор приложения и отображаемое имя
Измененные свойства — название свойства = учетная запись включена, новое значение = true

Ведение журнала для восстановленного:

Служба — основной каталог
Тип активности — добавление основного субъекта службы
Категория — управление приложениями
Инициировано субъектом (актёром) — уникальное имя субъекта
Целевые объекты — идентификатор приложения и отображаемое имя
Изменённые свойства — название свойства = включение учетной записи, новое значение = истина

Примечание.

Корпорация Майкрософт глобально отключает приложения, которые нарушают условия обслуживания. В этих случаях эти приложения отображаются DisabledDueToViolationOfServicesAgreement в свойстве disabledByMicrosoftStatus связанных типов ресурсов приложения и субъекта-службы в Microsoft Graph. Вы не сможете удалить эти объекты, чтобы предотвратить их создание экземпляров в вашей организации в будущем.

Настройка защиты идентичности для удостоверений рабочих процессов

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

Для получения дополнительной информации см. раздел «Защита удостоверений рабочих нагрузок с использованием защиты идентификации».

Эти оповещения отображаются на портале защиты идентификации и могут быть экспортированы в средства SIEM с помощью параметров диагностики или API защиты идентификации.

Снимок экрана: просмотр рисков и оповещений на портале защиты идентификации.

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

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

Снимок экрана: управление доступом пользователей на основе политики условного доступа.

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

Реализация политик риска приложений

Просмотрите параметры согласия пользователей в Microsoft Entra ID>Раздел корпоративных приложений>Согласие и разрешения>Параметры согласия пользователей.

Снимок экрана: разрешение согласия пользователя для приложений.

Сведения о параметрах конфигурации см. в статье "Настройка согласия пользователей на приложения".

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

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

Для высоко привилегированных операций, таких как согласие администратора, у вас есть стратегия привилегированного доступа, определенная в нашем руководстве.

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

Убедитесь, что он включен в клиенте и просмотрите параметры конфигурации, описанные здесь.

Ссылки

Дополнительные инструкции по реагированию на инциденты

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

Ресурсы по реагированию на инциденты

Обзор продуктов и ресурсов безопасности Майкрософт для новых сотрудников и опытных аналитиков
Планирование для центра информационной безопасности (SOC)
Microsoft Defender XDR реагирование на инциденты
Microsoft Defender для облака (Azure)
Реагирование на инциденты Microsoft Sentinel
Руководство группы реагирования на инциденты Майкрософт предоставляет рекомендации для групп безопасности и лидеров
Руководства по реагированию на инциденты Майкрософт помогают командам безопасности анализировать подозрительные действия