Основные восемь элементов управления приложениями
В этой статье подробно описаны методы реализации модели основной восьми зрелости Австралийского центра кибербезопасности (ACSC) для управления приложениями с помощью Microsoft App Locker и управления приложениями в Защитнике Windows.
Управление приложениями — это подход к обеспечению безопасности, предназначенный для защиты от вредоносного кода, выполняемого в системах. При реализации этого подхода к безопасности он гарантирует, что только утвержденный код, такой как исполняемые файлы, библиотеки программного обеспечения, скрипты, установщики и драйверы, имеет право на выполнение. Благодаря своей эффективности управление приложениями является одним из основных восьми из стратегий ACSC по устранению инцидентов кибербезопасности.
Управление приложениями — это подход к обеспечению безопасности, предназначенный для защиты от вредоносного кода, выполняемого в системах. При реализации этого подхода к безопасности он гарантирует, что только утвержденный код, такой как исполняемые файлы, библиотеки программного обеспечения, скрипты, установщики и драйверы, имеет право на выполнение.
Хотя управление приложениями в основном предназначено для предотвращения выполнения и распространения вредоносного кода в системе, оно также может предотвратить установку и использование неутвержденных приложений.
- Уровень зрелости 1 (ML1): можно достичь с помощью Microsoft AppLocker
- Уровни зрелости 2 и 3 (ML2 & ML3): можно достичь с помощью управления приложениями в Защитнике Windows
Реализация управления приложениями включает в себя следующие общие шаги для организации:
- Определение утвержденных приложений
- Разработка правил управления приложениями для обеспечения возможности выполнения только утвержденных приложений
- Поддержание правил управления приложениями с помощью процесса управления изменениями
- Частая проверка правил управления приложениями
При определении способа принудительной авторизации приложений в организации Центр кибербезопасности Австралии считает, что при правильной реализации подходят следующие методы:
- Правила шифрования хэша
- Правила сертификации издателя
- Правила пути (если разрешения файловой системы настроены для предотвращения несанкционированного изменения разрешений для папок и файлов, содержимого папки и отдельных файлов)
Управление приложениями может предотвратить несанкционированное выполнение неутвержденных приложений. Управление приложениями также может способствовать идентификации попыток субъекта угрозы выполнить вредоносный код в системе. Настройка WDAC для создания журналов событий для авторизованных и несанкционированных выполнений может предоставить ценную информацию в центр управления безопасностью организации.
Важно отметить, что решение для управления приложениями не заменяет уже существующие антивирусные и другие решения по обеспечению безопасности. WDAC всегда работает совместно с антивирусными решениями, такими как антивирусная программа Defender. Совместное использование решений безопасности Майкрософт способствует эффективному глубокому подходу к предотвращению компрометации систем.
Центр кибербезопасности Австралии имеет три уровня зрелости для своих стратегий по устранению рисков, которые составляют основные восемь. Уровни зрелости основаны на смягчении возрастающих уровней торговли, используемых субъектом угрозы. В контексте управления приложениями Центр кибербезопасности Австралии определяет, что необходимо для соответствия ML 1, 2 и 3.
Элемент управления ISM за сентябрь 2024 г. | Уровень зрелости | Устранение рисков |
---|---|---|
ISM-0109 | 3 | Журналы событий с рабочих станций своевременно анализируются для обнаружения событий кибербезопасности. |
ISM-0140 | 2, 3 | Об инцидентах кибербезопасности сообщается ASD как можно скорее после их возникновения или обнаружения. |
ISM-0123 | 2, 3 | Об инцидентах кибербезопасности сообщается главному сотруднику по информационной безопасности или одному из их делегатов, как можно скорее после их возникновения или обнаружения. |
ISM-0843 | 1, 2, 3 | Управление приложениями реализуется на рабочих станциях. |
ISM-1490 | 2, 3 | Управление приложениями реализуется на серверах с выходом в Интернет. |
ISM-1656 | 3 | Управление приложениями реализуется на серверах, не подключенных к Интернету. |
ISM-1544 | 2, 3 | Реализован рекомендуемый список блокировок приложений Майкрософт. |
ISM-1657 | 1, 2, 3 | Элемент управления приложениями ограничивает выполнение исполняемых файлов, программных библиотек, сценариев, установщиков, скомпилированных HTML, HTML-приложений и апплетов панели управления набором, утвержденным организацией. |
ISM-1658 | 3 | Управление приложениями ограничивает выполнение драйверов набором, утвержденным организацией. |
ISM-1582 | 2, 3 | Наборы правил управления приложениями проверяются ежегодно или чаще. |
ISM-1659 | 3 | Реализован список блокировок уязвимых драйверов Майкрософт. |
ISM-1660 | 2, 3 | События управления разрешенными и заблокированными приложениями регистрируются централизованно. |
ISM-1815 | 2, 3 | Журналы событий защищены от несанкционированного изменения и удаления. |
ISM-1819 | 2, 3 | После выявления инцидента кибербезопасности вводится план реагирования на инциденты кибербезопасности. |
ISM-1870 | 1, 2, 3 | Управление приложениями применяется к профилям пользователей и временным папкам, используемым операционными системами, веб-браузерами и почтовыми клиентами. |
ISM-1871 | 2, 3 | Управление приложениями применяется ко всем расположениям, кроме профилей пользователей и временных папок, используемых операционными системами, веб-браузерами и почтовыми клиентами. |
ISM-1228 | 2, 3 | События кибербезопасности своевременно анализируются для выявления инцидентов кибербезопасности. |
ISM-1906 | 2, 3 | Журналы событий с серверов, подключенных к Интернету, своевременно анализируются для обнаружения событий кибербезопасности. |
ISM-1907 | 3 | Журналы событий с серверов, не подключенных к Интернету, своевременно анализируются для обнаружения событий кибербезопасности. |
Элемент управления ISM за сентябрь 2024 г. | Уровень зрелости | Control | Measure |
---|---|---|---|
ISM-0109 | 3 | Журналы событий с рабочих станций своевременно анализируются для обнаружения событий кибербезопасности. | Используйте Defender для конечной точки P2. Журналы событий Windows записываются в Microsoft Sentinel и Microsoft Defender XDR с помощью событий Безопасность Windows через решения AMA или Переадресация событий Windows. |
ISM-0140 | 2, 3 | Об инцидентах кибербезопасности сообщается ASD как можно скорее после их возникновения или обнаружения. | Не в область этого документа. См. примечание после этой таблицы. 3 |
ISM-0123 | 2, 3 | Об инцидентах кибербезопасности сообщается главному сотруднику по информационной безопасности или одному из их делегатов, как можно скорее после их возникновения или обнаружения. | Не в область этого документа. См. примечание после этой таблицы. 3 |
ISM-0843 | 1, 2, 3 | Управление приложениями реализуется на рабочих станциях. | Настройте и используйте управление приложениями Или AppLocker в Защитнике Windows в зависимости от требований организации к уровню зрелости. |
ISM-1490 | 2, 3 | Управление приложениями реализуется на серверах с выходом в Интернет. | Настройка и использование элемента управления приложениями в Защитнике Windows |
ISM-1656 | 3 | Управление приложениями реализуется на серверах, не подключенных к Интернету. | Настройка и использование элемента управления приложениями в Защитнике Windows |
ISM-1544 | 2, 3 | Реализован рекомендуемый список блокировок приложений Майкрософт. | Реализованы рекомендуемые блочные правила Майкрософт |
ISM-1657 | 1, 2, 3 | Элемент управления приложениями ограничивает выполнение исполняемых файлов, программных библиотек, сценариев, установщиков, скомпилированных HTML, HTML-приложений и апплетов панели управления набором, утвержденным организацией. | Корпорация Майкрософт рекомендует создать определенный список правил издателя файлов или хэшей файлов в политике управления приложениями. 1 |
ISM-1658 | 3 | Управление приложениями ограничивает выполнение драйверов набором, утвержденным организацией. | Целостность кода, защищенная гипервизором, включена и по умолчанию для Windows 11 2022+ |
ISM-1582 | 2, 3 | Наборы правил управления приложениями проверяются ежегодно или чаще. | Не в область этого документа. См. примечание под этой таблицей. 3 |
ISM-1659 | 3 | Реализован список блокировок уязвимых драйверов Майкрософт. | Реализованы "рекомендуемые правила блока драйверов" корпорации Майкрософт. |
ISM-1660 | 2, 3 | Разрешенные и заблокированные события управления приложениями регистрируются централизованно. | Используйте Defender для конечной точки P2. Журналы событий Windows записываются в Microsoft Sentinel и Microsoft Defender XDR с помощью решений "события Безопасность Windows" через AMA или "Переадресованные события Windows". |
ISM-1815 | 2, 3 | Журналы событий защищены от несанкционированного изменения и удаления. | применяется Role-Based контроль доступа для Microsoft Defender XDR и Microsoft Sentinel. |
ISM-1819 | 2, 3 | После выявления инцидента кибербезопасности вводится план реагирования на инциденты кибербезопасности. | Не в область этого документа. См. примечание под этой таблицей. 3 |
ISM-1870 | 1, 2, 3 | Управление приложениями применяется к профилям пользователей и временным папкам, используемым операционными системами, веб-браузерами и почтовыми клиентами. | Корпорация Майкрософт рекомендует создать определенный список правил издателя файлов или хэшей файлов в политике управления приложениями. Уровень зрелости 1 можно достичь с помощью Microsoft AppLocker. Для зрелости уровня 2 и 3 требуется управление приложениями в Защитнике Windows. 2 |
ISM-1871 | 2, 3 | Управление приложениями применяется ко всем расположениям, кроме профилей пользователей и временных папок, используемых операционными системами, веб-браузерами и почтовыми клиентами. | Реализация и настройка управления приложениями в Защитнике Windows |
ISM-1228 | 2, 3 | События кибербезопасности своевременно анализируются для выявления инцидентов кибербезопасности. | Не в область этого документа. См. примечание после этой таблицы. 3 |
ISM-1906 | 2, 3 | Журналы событий с серверов, подключенных к Интернету, своевременно анализируются для обнаружения событий кибербезопасности. | Используйте Defender для конечной точки P2. Журналы событий Windows записываются в Microsoft Sentinel и Microsoft Defender XDR с помощью событий Безопасность Windows через решения AMA или Переадресация событий Windows. |
ISM-1907 | 3 | Журналы событий с серверов, не подключенных к Интернету, своевременно анализируются для обнаружения событий кибербезопасности. | Используйте Defender для конечной точки P2. Журналы событий Windows записываются в Microsoft Sentinel и Microsoft Defender XDR с помощью событий Безопасность Windows через решения AMA или Переадресация событий Windows. |
Важно!
1 Чтобы соответствовать ISM-1657, корпорация Майкрософт рекомендует создать определенный список правил издателя файлов или хэшей файлов в политике управления приложениями. Если правила пути к файлам используются слишком, организация должна убедиться, что пользователю запрещено несанкционированное изменение разрешений для папок и файлов, содержимого папок и отдельных файлов. Например, пользователь не должен иметь доступ на запись в NTFS к расположению правила пути к файлам.
2 Чтобы соответствовать ISM-1870, корпорация Майкрософт рекомендует создать определенный список правил издателя файлов или хэшей файлов, созданных в политике управления приложениями. Уровень зрелости 1 можно достичь с помощью Microsoft AppLocker. Уровень зрелости 2 и 3 требует управления приложениями в Защитнике Windows из-за дополнительных требований ISM. Правила пути к файлам не рекомендуется использовать для ISM-1870, так как пользователь имеет разрешение файловой системы в профиле пользователя и временных папках.
3 Элементы управления ISM-0140, 0123, 1582, 1819 и 1228 явно являются основными пользователями и элементами управления процессами. Корпорация Майкрософт рекомендует, чтобы люди и процессы были задокументированы и сохранены в качестве артефактов в диспетчере соответствия требованиям Purview в рамках автоматизированных технологических подтверждений для проверки соответствия требованиям Essential 8.
Корпорация Майкрософт рекомендует клиентам реализовать управление приложениями в Защитнике Windows (WDAC), а не AppLocker. Управление приложениями в Защитнике Windows постоянно совершенствуется. Хотя AppLocker продолжает получать исправления безопасности, он не получает улучшений функций.
Однако AppLocker также можно развернуть в качестве дополнения к управлению приложениями в Защитнике Windows для таких сценариев, как общие устройства, где важно предотвратить запуск определенного приложения некоторыми пользователями. Корпорация Майкрософт рекомендует вашей организации применять управление приложениями в Защитнике Windows как наиболее строгий уровень, возможный для вашей организации, и при необходимости использовать AppLocker для дальнейшей точной настройки ограничений пользовательского режима.
Совет
Хотя WDAC является предпочтительным, большинству организаций может быть проще и проще получить ML1, используя только AppLocker в качестве отправной точки, оба решения являются бесплатными.
AppLocker появился в Windows 7 и позволяет организации контролировать, какие процессы пользовательского режима (приложения) могут выполняться в операционных системах Windows. Политики AppLocker могут применяться ко всем пользователям в системе или к отдельным пользователям и группам с правилами, которые можно определить на основе:
- Правила шифрования хэша
- Правила сертификации издателя
- Правила путей
Политики AppLocker можно создавать в любых поддерживаемых версиях и дополнениях операционной системы Windows и развертывать с помощью групповая политика, PowerShell или решения для мобильных Управление устройствами.
Управление приложениями в Защитнике Windows (WDAC) появилось в Windows 10. Это позволяет организациям управлять тем, какие процессы пользовательского режима (приложения) и режима ядра (драйверы) могут выполняться в операционных системах Windows. Политики WDAC применяются к управляемой системе в целом и затрагивают всех пользователей устройства с помощью правил, которые можно определить на основе:
- Правила шифрования хэша
- Правила сертификации издателя
- Правила пути
- Репутация приложения, определяемая корпорацией Майкрософт Intelligent Security Graph
- Удостоверение процесса, который инициировал установку приложения с помощью управляемого установщика
Политики WDAC можно создавать в любом поддерживаемом клиентском выпуске Windows 10, Windows 11 или на Windows Server 2016 и выше. Политики WDAC можно развернуть с помощью групповая политика, решения для мобильных Управление устройствами, Configuration Manager или PowerShell.
Из-за того, что microsoft Windows как услуга позволяет разрабатывать и развертывать новые функции для наших клиентов, некоторые возможности WDAC доступны только в определенных версиях Windows.
Подробные сведения об управлении приложениями в Защитнике Windows и Applocker см. в разделе Управление приложениями в Защитнике Windows и доступность функций AppLocker.
Когда администратор развертывает политику AppLocker для пользовательского управления приложениями, следующие правила можно использовать в качестве примера реализации на основе пути. Сюда входят правила, применение правил и автоматический запуск службы удостоверений приложений.
Рекомендуется заблокировать (как минимум) следующие пути:
- C:\Windows\Temp\*.*
- %USERPROFILE%\AppData\Local\*.*
- Добавление исключения для %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
- %USERPROFILE%\AppData\Roaming\*.*
Сведения о AppLocker в ML1 см. в следующих статьях:
Политики Microsoft AppLocker можно создать с помощью нескольких методов. Корпорация Майкрософт рекомендует использовать проект Microsoft С открытым исходным кодом AaronLocker для создания политик AppLocker. AaronLocker позволяет создавать и обслуживать надежное, строгое управление приложениями для AppLocker, как это возможно, с помощью службы сценариев PowerShell. AaronLocker предназначен для ограничения выполнения программ и скриптов неадминистративных пользователей.
Подробные сведения об Aaronlocker см. в статье AaronLocker: надежное и практическое управление приложениями для Windows.
Microsoft AppLocker можно развернуть с помощью Microsoft Intune, групповая политика или PowerShell. Метод развертывания будет зависеть от текущего решения управления организации.
Подробные сведения о развертывании App locker см. в следующих статьях:
События, связанные с Microsoft AppLocker, отслеживаются с помощью решения для управления информационной безопасностью и событиями, например Sentinel Майкрософт. События также отслеживаются с помощью сведений о расширенной охоте Microsoft Defender для конечной точки.
Microsoft Defender для конечной точки: справочник по AppLocker
Microsoft Defender для конечной точки фиксирует следующие события в отношении Microsoft AppLocker.
Имя ActionType | Идентификатор источника события |
---|---|
AppControlExecutableAudited | 8003 |
AppControlExecutableBlocked | 8004 |
AppControlPackagedAppAudited | 8021 |
AppControlPackagedAppBlocked | 8022 |
AppControlPackagedAppBlocked | 8006 |
AppControlScriptBlocked | 8007 |
AppControlCIScriptAudited | 8001 |
Подробные сведения о Просмотр событий и расширенной охоте см. в следующих статьях:
- Использование Просмотр событий с AppLocker
- Централизованное выполнение запросов к событиям управления приложениями с помощью расширенной охоты
Корпорация Майкрософт излагает процесс проектирования, управление жизненным циклом, развертывание и операционные рекомендации в соответствии с основными восемью системами управления приложениями ML2 и ML3 с помощью WDAC.
Для клиентов с требованием о базовых восьми элементах управления приложениями ML1 можно добиться с помощью Microsoft AppLocker.
Необходимые условия для использования этого руководства:
- Windows 11 22H2 Enterprise
- Использование Intune для решения для управления
- Defender для конечной точки, для решения по обеспечению безопасности конечной точки
- Microsoft Sentinel для управления информационной безопасностью и событиями; и
- Соответствующие разрешения администраторов в решениях, используемых в этом документе
WDAC в операционных системах Windows Server не в область для этого руководства. Руководство по Windows Server будет предоставлено в будущем выпуске.
Служба, связанная с M365, может находиться в Microsoft 365 и Office 365 описания служб, чтобы понять необходимые службы, ценностные предложения и требования к лицензированию:
Описание служб Microsoft 365 и Office 365
Сведения о продуктах, связанных с WDAC, см. в следующих статьях:
Когда организация начинает планировать WDAC, рассмотрение решений по проектированию определяет, как это влияет на развертывание политики и обслуживание политики управления приложениями.
WDAC следует использовать в рамках политик управления приложениями организации, если верно следующее:
- Вы развернули или планируете развернуть поддерживаемые версии Windows в вашей организации
- Вам нужен улучшенный контроль над доступом к приложениям вашей организации и данным, доступом пользователей
- В вашей организации есть четко определенный процесс управления приложениями и их развертывания.
- У вас есть ресурсы для тестирования политик в соответствии с требованиями организации
- У вас есть ресурсы для привлечения службы поддержки или для создания процесса самостоятельной помощи для проблем с доступом к приложениям конечных пользователей
- Требования группы к производительности, управляемости и безопасности можно контролировать с помощью ограничительных политик.
WDAC включает в себя концепцию "круга доверия". Каждая организация имеет свое определение "круга доверия", уникальное для их бизнес-требований. AcSC Essential 8— это элемент управления ISM 1657. "Элемент управления приложениями ограничивает выполнение исполняемых файлов, программных библиотек, сценариев, установщиков, скомпилированных HTML, HTML-приложений и апплетов панели управления набором, утвержденным организацией.
Корпорация Майкрософт предоставляет несколько примеров политик в формате XML, расположенных в Windows в разделе %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies. Примеры политик Майкрософт позволяют вашей организации начать работу с существующей базовой политики и при необходимости добавлять или удалять правила для создания пользовательских политик.
Дополнительные сведения о проектировании политик см. в следующих статьях:
WDAC поддерживает два формата политик:
Формат единой политики. Исходный формат политики, выпущенный с Windows 10 RTM и Windows Server 2016. Один формат политики поддерживает только одну активную политику в системе в любой момент времени.
Несколько форматов политики (рекомендуется). Этот формат политики поддерживается в Windows 10 1903+, Windows 11 и Windows Server 2022. Формат нескольких политик обеспечивает большую гибкость при развертывании управления приложениями в Защитнике Windows и поддерживает до 32 активных политик на устройстве. Кроме того, он позволяет использовать следующие сценарии:
- Принудительное применение и аудит параллельно: проверка изменений политики перед развертыванием принудительного применения. Пользователи могут развертывать базовую политику в режиме аудита параллельно с существующей политикой на основе режима принудительного применения.
- Несколько базовых политик. Пользователи могут одновременно применять две или более базовых политик.
- Дополнительные политики. Пользователи могут развернуть одну или несколько дополнительных политик для расширения базовой политики. Вы можете использовать дополнительные политики для разных пользователей в вашей организации, например для отдела кадров и ИТ
Корпорация Майкрософт рекомендует использовать несколько форматов политик и использовать только один формат политики для четко определенных сценариев или в тех случаях, когда несколько форматов политик недоступны, например Windows Server 2016 и Windows Server 2019.
Подробные сведения о политиках управления WDAC см. в статье Использование нескольких политик управления приложениями в Защитнике Windows.
WDAC содержит два понятия:
- Правила политики WDAC. Правила политики WDAC определяют такие конфигурации, как режим аудита, управляемый установщик, принудительное применение скриптов, политики дополнения (формат нескольких политик), аналитика Reputation-Based (авторизация ISG или интеллектуальное управление приложениями) и, возможно, другие. Правила политики также определяют, используется ли WDAC как для двоичных файлов в режиме ядра, так и в режиме пользователя.
- Правила файлов WDAC. Правила файлов WDAC указывают авторизацию и повторную авторизацию для выполнения в Windows. Правила файлов поддерживают хэш, имя файла, путь к файлу и правила издателя, позволяющие клиенту определить утвержденный организацией набор разрешенных приложений. Правило сначала обрабатывает все явные правила запрета, которые оно находит, а затем обрабатывает все явные правила разрешения. Если правило запрета или разрешения не существует, WDAC проверяет наличие управляемого установщика. Наконец, если ни один из этих наборов не существует, WDAC возвращается на Reputation-Based аналитики
Подробные сведения о правилах политики и правилах файлов см. в следующей статье:
Существует два основных способа создания политики WDAC с помощью PowerShell или мастера WDAC.
- PowerShell. Политики WDAC создаются с помощью настраиваемых командлетов целостности кода в PowerShell. PowerShell позволяет ИТ-специалистам автоматизировать проверку системы политики WDAC, которая создает XML-код политики. PowerShell можно использовать для слияния политик XML, задания правил политики и добавления других правил файлов политики при необходимости. Командлеты настраиваемой целостности кода также можно использовать для изменения примеров политик WDAC в соответствии с требованиями вашей организации.
- Мастер управления приложениями в Защитнике Windows (рекомендуется): мастер политики WDAC — это классическое приложение Windows с открытым исходным кодом, написанное на C# и включено в пакет MSIX. Он был создан для обеспечения безопасности архитекторов безопасности, а системные администраторы — более удобные средства для создания, редактирования и слияния политик управления приложениями. Это средство использует командлеты PowerShell Config CI в серверной части, поэтому политика вывода средства и командлетов PowerShell идентична.
Подробные сведения о создании политики см. в следующих статьях:
- Создание политики WDAC с помощью компьютера-образца
- Мастер управления приложениями в Защитнике Windows
- ConfigCI
- Мастер политик WDAC
Корпорация Майкрософт рекомендует использовать мастер управления приложениями в Защитнике Windows для реализации основных восьми для управления приложениями. Кроме того, PowerShell может использоваться организациями с расширенными требованиями в операционной модели DevOps, используя примеры политик в качестве базы или кто хочет создать политику для четко определенных сценариев из эталонной системы.
Прежде чем организация начнет реализацию решения для управления приложениями, необходимо подумать о том, как политики управляются и поддерживаются с течением времени. Большинство политик WDAC со временем развиваются и продолжаются через набор идентифицируемых этапов в течение их жизненного цикла. Ниже приведены следующие этапы:
- Определите политику и создайте версию XML-кода политики в режиме аудита. В режиме аудита создаются события блоков, но файлы не препятствуют выполнению
- Развертывание политики режима аудита в предполагаемых системах
- Мониторинг событий блока аудита в предполагаемых системах и уточнение правил по мере необходимости для устранения непредвиденных или нежелательных блоков
- Повторите эти действия до тех пор, пока оставшиеся события блока не о соответствуют ожиданиям в ходе аудита.
- Создайте версию политики в принудительном режиме. В режиме принудительного применения запрещается выполнение файлов, которые не определены как разрешенные политикой, и создаются соответствующие события блоков.
- Развертывание политики принудительного режима в предполагаемых системах
- Повторяйте все эти действия непрерывно, чтобы устранить любые непредвиденные или нежелательные действия блока.
Для эффективного управления политиками WDAC следует хранить XML-документы политики и хранить их в центральном репозитории. Корпорация Майкрософт рекомендует решение системы управления версиями, например GitHub, или решение для управления документами, например SharePoint, которое обеспечивает управление версиями.
В этом разделе содержатся рекомендации клиента по настройке управляемого установщика WDAC с помощью PowerShell и Microsoft Intune.
- См . раздел Защита от угроз Windows автоматически разрешает приложения, развернутые управляемым установщиком, с помощью управления приложениями в Защитнике Windows (/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)
Примечание
В этом примере скрипта не используется AppLocker, поэтому на шаге 1 отсутствуют правила DENY . Эта конфигурация AppLocker будет создана для всех устройств, для которых требуется управляемый установщик.
- Создайте скрипт PowerShell, который выполняет следующие действия:
- Хранение XML-файла AppLocker
- Экспорт XML-файла AppLocker
- Настройка политики AppLocker
- Запуск службы AppLocker
Ниже приведен пример скрипта, который можно развернуть с помощью расширения управления Intune — сценариев PowerShell.
$ScriptDir = Split-Path $script:MyInvocation.MyCommand.Path
$AppLockerMIPolicy =
@"
<AppLockerPolicy Version="1">
<RuleCollection Type="ManagedInstaller" EnforcementMode="Enabled">
<FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
<BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="6ead5a35-5bac-4fe4-a0a4-be8885012f87" Name="CMM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="8e23170d-e0b7-4711-b6d0-d208c960f30e" Name="CCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
</AppLockerPolicy>
"@
$AppLockerMIPolicy | Out-File -FilePath $ScriptDir\AppLockerMIPolixy.xml
Set-AppLockerPolicy -XmlPolicy $ScriptDir\AppLockerMIPolixy.xml -Merge -ErrorAction SilentlyContinue
Start-Process -FilePath "$env:windir\System32\appidtel.exe" -ArgumentList "start -mionly" | Wait-Process
Remove-Item -Path $ScriptDir\AppLockerMIPolixy.xml
Важно!
Администратору необходимо добавить скрипт конфигурации в политику правила файлов WDAC с помощью хэша или издателя.
Функция WDAC, называемая управляемым установщиком , позволяет организации сбалансировать безопасность и управляемость при применении политик управления приложениями. Это позволяет устанавливать приложения с помощью решения для распространения программного обеспечения, например Microsoft Configuration Manager или Intune.
Распространенное заблуждение заключается в том, что настройка правила "управляемого установщика" в политике WDAC является единственным обязательным шагом. Это неправильно, и для работы этой функции требуется другая конфигурация AppLocker.
Управляемый установщик использует коллекцию правил в AppLocker для назначения двоичных файлов, которым ваша организация доверяет установку приложений. Windows отслеживает процесс настроенного двоичного файла и все дочерние процессы, которые он запускает при мониторинге связанных файлов, записываемых на диск. Эти файлы помечены как исходящие из управляемого установщика, поэтому их можно выполнять.
Создание политики AppLocker в редакторе объекта групповой политики и командлетах PowerShell для AppLocker нельзя напрямую использовать для создания правил для коллекции управляемого установщика. Для создания коллекции правил управляемого установщика необходимо использовать VS Code или другое средство редактора.
Поставщик службы конфигурации AppLocker (CSP) в настоящее время не поддерживает тип коллекции правил управляемого установщика, поэтому политика AppLocker должна быть входящего с помощью PowerShell для Microsoft Intune.
Так как функция "Принудительное применение скриптов" в Элементе управления приложениями Защитника Windows необходима для соответствия ISM-1657, принудительное применение скриптов необходимо для управления PowerShell, VBscript, cscript, cscript, HSMTA и MSXML. Сценарий PowerShell для настройки управляемого установщика должен находиться в правиле политики файлов WDAC с помощью хэша или издателя.
Корпорация Майкрософт рекомендует настроить управляемый установщик для Microsoft Intune. Intune позволяет надежно управлять приложениями, упакованными с помощью Microsoft Intune, без необходимости часто обновлять политику управления приложениями в Защитнике Windows.
Развертывание этого скрипта конфигурации для управляемого установщика можно выполнить двумя способами с помощью Microsoft Intune в зависимости от сценария:
- Хэш. Хэш скрипта должен быть известен в политике файлов WDAC, упаковать и развернуть с помощью средства подготовки содержимого Microsoft Win32 или скрипта PowerShell в Microsoft Intune.
- Подписанный кодом (издатель). Сценарий PowerShell подписан доверенным центром и известен с помощью политики файлов WDAC, упаковывается и развертывается с помощью средства подготовки содержимого Microsoft Win32 или функции скрипта PowerShell в Microsoft Intune.
Подробные сведения о развертывании сценариев PowerShell см. в следующих статьях:
- Автоматическое разрешение приложений, развернутых управляемым установщиком с помощью управления приложениями в Защитнике Windows
- CSP AppLocker
- Принудительное применение скриптов с помощью управления приложениями в Защитнике Windows (WDAC)
- Управление приложениями Win32 с помощью Microsoft Intune
- Использование сценариев PowerShell для устройств Windows 10/11 в Intune
Благодаря понятным параметрам и принятым решениям по проектированию организация может создать первую политику аудита с помощью мастера управления приложениями в Защитнике Windows:
Откройте мастер управления приложениями в Защитнике Windows и выберите "Создатель политики".
В разделе Создатель политики выберите Несколько форматов политики и Базовая политика , а затем нажмите кнопку Далее.
В шаблоне политики представлены три варианта:
- Режим Windows по умолчанию включает в себя ОС Windows, приложения Магазина, Приложения Microsoft 365 для enterprise (Office 365 Pro Plus) и драйверы ядра со знаком WHQL.
- Разрешить режим Майкрософт включает все разделы режима Windows по умолчанию и все приложения, подписанные Корпорацией Майкрософт.
- Подписанный и авторитетный режим включает все предыдущие разделы и Reputation-Based аналитику.
Важно!
Reputation-Based аналитика для управления приложениями не соответствует основным восьми элементам управления приложениями из-за требований "Утвержденный организацией набор" (ISM 1657) и "Наборы правил управления приложениями проверяются ежегодно или чаще" (ISM 1582). Эта функция в WDAC не соответствует требованиям для ML2 или ML3. Корпорация Майкрософт рекомендует использовать аналитику Reputation-Based для внедрения WDAC в организации вне контекста основных восьми элементов управления приложениями.
- Выберите Режим Windows по умолчанию или Разрешить режим Майкрософт в зависимости от требований вашей организации. В этом документе корпорация Майкрософт использует разрешить режим Майкрософт.
- Измените имя ирасположение политики на нужные имя политики и расположение файла политики , чтобы сохранить файл, и нажмите кнопку Далее.
Примечание
Подробные сведения о правилах политики WDAC можно найти здесь.
- Для ISM 1657 и 1658 для управления скриптами, соответствующими HTML-приложениями и приложениями HTML требуется отключить принудительное применение скриптов.
- Для ISM 1657, 1658 и 1582 требуется граф интеллектуальной безопасности, для параметра "Отключено".
- Управляемый установщик рекомендуется использовать для поддержки жизненного цикла политики WDAC.
- Целостность кода в пользовательском режиме необходима для применения политик WDAC как к двоичным файлам в режиме ядра, так и в режиме пользователя.
- Разрешить политики дополнения требуется для использования формата с несколькими политиками, чтобы помочь организации с жизненным циклом политики WDAC.
Примечание
Все остальные правила политики WDAC зависят от требований в организации.
- В правилах подписи администратор может просматривать все сертификаты Майкрософт, которые были добавлены в качестве разрешенных правил издателя. Мы рассмотрим добавление настраиваемого правила далее в этой статье.
- Нажмите кнопку Далее.
Мастер управления приложениями в Защитнике Windows создает:
- XML-код политики
- {GUID}. CIP
Подробные сведения о правилах политики WDAC можно найти здесь.
Примечание
Каждая политика, созданная с помощью мастера управления приложениями Защитника Windows, приобретает новый глобальный уникальный идентификатор (GUID).
Политика WDAC успешно создана.
Так как организация создала политику WDAC с помощью мастера WDAC, организация может просматривать контекст этого файла в текстовом редакторе. XML-код разделен на несколько разных разделов. Для контекста Essential Восемь запишите PolicyID и BasePolicyID.
Примечание
Хотя можно напрямую изменить XML-код политики. Корпорация Майкрософт рекомендует вносить все дополнительные изменения в правила политики или файлы подписи с помощью мастера управления приложениями Защитника Windows или настраиваемых командлетов целостности кода в PowerShell.
Теперь, когда организация создала политику аудита, пришло время развернуть ее с помощью Intune управления устройствами.
- Войдите в Центр администрирования Intune.
- В центре администрирования Intune перейдите в раздел Устройства, а затем выберите Профили конфигурации.
- Затем создайте платформу профилей>— Windows 10 или более поздней версии, Шаблоны типов профилей и Настраиваемая.
- Создайте имя политики (например, "Управление приложениями — Microsoft Allow – Audit") и нажмите кнопку Далее.
- В разделе Параметры OMA-URI выберите Добавить.
Примечание
Эти сведения зависят от идентификатора политики, созданного мастером управления приложениями в Защитнике Windows >, для XML-кода политики, созданного из раздела выше:
- Name = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
— Тип данных = Base64 (Файл)
- Когда мастер управления приложениями Защитника Windows создал XML-код политики, он также создал (GUID). Файл CIP. CIP-файл необходимо скопировать и переименовать расширение файла в . BIN, например {CB46B243-C19C-4870-B098-A2080923755C}.bin.
- Отправьте bin в base64 (файл).
- Выберите Сохранить.
- Следуйте инструкциям, чтобы создать профиль конфигурации.
- Разверните созданную политику, например "Управление приложениями — разрешить Майкрософт — аудит", профиль конфигурации в нужной системе.
После жизненного цикла политики WDAC организация должна просмотреть созданные события из политики "Разрешить аудит Майкрософт". Мониторинг политики аудита WDAC можно обеспечить двумя способами:
- Идентификаторы событий управления приложениями. Идентификаторы событий управления приложениями — это традиционный метод проверки событий, проверенных в операционной системе Windows. Эти идентификаторы событий можно перенаправить в централизованное расположение с помощью переадресации журналов событий Windows или стороннего управления сведениями и событиями безопасности.
Сведения об идентификаторах событий см. в статье Общие сведения об идентификаторах событий управления приложениями — безопасность Windows.
- Microsoft Defender для конечной точки (рекомендуется): события, связанные с Защитником Windows для конечной точки и AppLocker, фиксируются в разделе Advanced Hunting for Microsoft Defender для конечной точки. Сведения, включенные в события: Device, FileName, FolderPath, InitiatingProcessFileName, File Hashes и многое другое. См. статью Запрос событий управления приложениями с помощью расширенной охоты (Windows) — безопасность Windows
Корпорация Майкрософт рекомендует использовать интеграцию Microsoft Defender XDR (MDE) для Microsoft Sentinel. MDE и Sentinel позволяют хранить данные телеметрии Advanced Hunting дольше 30 дней по сравнению с Microsoft Defender для конечной точки.
Подробные сведения о подключениях и мониторинге см. в следующих статьях:
- Подключение данных из Microsoft Defender XDR к Microsoft Sentinel
- Агент Azure Monitor на клиентских устройствах Windows
- Сбор событий и счетчиков производительности с виртуальных машин с помощью агента Azure Monitor
В следующем примере показано, что у пользователя есть несколько приложений, используемых для повседневных задач организации. В этом примере содержатся приложения Майкрософт и различные приложения открытый код.
Так как пример находится в режиме принудительного аудита, администратор (но не влияет на пользователя), что события, активируемые для WinSCP, VLC, Putty и FileZilla, так как эти приложения не являются частью первоначальной политики аудита.
Теперь на портале Microsoft Defender введите Расширенная охота, чтобы сузить количество событий аудита, чтобы понять, какие непредвиденные или нежелательные блоки будут возникать, если режим аудита отключен, и, таким образом, в этом примере режим принудительного применения.
Используя эталонную схему с предыдущей страницы, найдите все события аудита политики, активированные WDAC за последние семь дней, и отобразит соответствующую информацию с помощью примера запроса языка запросов клавиатуры (KQL):
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| project DeviceId, // The device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
Ниже приведен пример выходных данных с использованием предыдущего запроса KQL.
В записях содержится подробный отчет о таких сведениях, как дерево обработки, путь к файлу, сведения о SHA, подписыватель и сведения о издателе.
Следующий шаг — сузить результаты.
Используя тот же запрос KQL, добавьте еще одно поле, где имя файла процесса инициатора — Windows Обозреватель. В запросе KQL отображаются приложения, выполняемые пользователями в графическом интерфейсе пользователя.
DeviceEvents
| where ActionType startswith "AppControlCodeIntegrityPolicyAudited"
| where Timestamp > ago(7d)
| where InitiatingProcessFileName startswith "explorer.exe" // Users starting an Application via File Explorer / GUI
| project DeviceId, // The device ID where the audit block happened
FileName, // The audit blocked app's filename
FolderPath, // The audit blocked app's system path without the FileName
InitiatingProcessFileName, // The file name of the parent process loading the executable
InitiatingProcessVersionInfoCompanyName, // The company name of the parent process loading the executable
InitiatingProcessVersionInfoOriginalFileName, // The original file name of the parent process loading the executable
InitiatingProcessVersionInfoProductName, // The product name of the parent process loading the executable
InitiatingProcessSHA256, // The SHA256 flat hash of the parent process loading the executable
Timestamp, // The event creation timestamp
ReportId, // The report ID - randomly generated by MDE AH
InitiatingProcessVersionInfoProductVersion, // The product version of the parent process loading the executable
InitiatingProcessVersionInfoFileDescription, // The file description of the parent process loading the executable
AdditionalFields // Additional fields contains FQBN for signed binaries. These contain the CN of the leaf certificate, product name, original filename and version of the audited binary
Ниже приведен пример выходных данных с использованием предыдущего запроса KQL.
Теперь действие запроса KQL сузило сведения до дополнительного набора данных управления. Можно увидеть приложения, используемые в предполагаемых системах. Эти приложения должны быть добавлены в политику организации или считаются добавленными с помощью контроля за организационными изменениями.
Примечание
KQL — это мощный инструмент для отображения неструктурированных и структурированных наборов данных. Это просто пример использования KQL, и корпорация Майкрософт рекомендует ознакомиться со следующей документацией: Изучите расширенный язык запросов охоты в Microsoft Defender XDR
После сужения результатов поиска с помощью KQL следующим шагом является обновление базовой политики WDAC или использование политики дополнения. В следующем примере используются политики дополнения.
Откройте мастер управления приложениями в Защитнике Windows и выберите Создатель политики.
В разделе Создатель политики выберите Несколько форматов политики и Дополнительная политика, перейдите к базовой политике, обновите расположение, чтобы сохранить дополнительную политику, и нажмите кнопку Далее.
Выберите Далее в правилах политики.
В разделе Правила подписывания политик выберите Пользовательский правило.
В пользовательских условиях правила доступно множество параметров:
- Правило пользовательского режима области правила или правило режима ядра
- Действие правила: разрешить или запретить
- Тип правила
- Издатель (рекомендуется)
- File
- Атрибут файла
- Упакованое приложение
- Мешанина
- Файл ссылки
Примечание
Корпорация Майкрософт рекомендует использовать правила на основе издателей, где это необходимо, и вернуться к правилам на основе хэша для неподписанных ссылочных файлов для реализации элемента управления приложениями Essential Восемь.
Использование Microsoft Defender для конечной точки
- Найдите имя файла в поле Поиск , перейдите к файлу Сведения и скачайте файл.
- Проверьте запись непосредственно из Advanced Hunting и скачайте файл, который затем скачивает необходимые двоичные файлы.
- С необходимыми двоичными файлами продолжайте создавать другую политику для приложений ISV вашей организации.
- В мастере управления приложениями Защитника Windows выберите нужный тип правила и перейдите к ссылочным двоичным файлам из предыдущего шага. В следующем примере показано, что VLC соответствует требуемым сведениям об издателе.
Примечание
Корпорация Майкрософт рекомендует выпустить ЦС, издатель должен быть как минимум селективным для создания правила на основе издателя. Название продукта можно включить, и рекомендуется ACSC для правил на основе издателя.
- Нажмите кнопки Далее и Создать.
- Разверните эту политику дополнения, выполнив действия, описанные ранее в разделе "Развертывание политики аудита управления приложениями в Защитнике Windows с помощью Microsoft Intune".
Чтобы переключиться на принудительное применение политики, выполните следующие действия:
Откройте мастер управления приложениями Защитника Windows и выберите Политика Редактор.
Перейдите к XML-коду политики, который необходимо изменить на принудительное.
Отключите переключатель режима аудита в правилах политики.
Выберите Далее в правилах политики.
Создается политика обновления с измененным номером версии и создан новый CIP-файл.
В Центре Администратор Microsoft Endpoint Manager перейдите в раздел Устройства, а затем — Профили конфигурации.
Затем создайте профиль, Платформа — Windows 10 или более поздней версии, Шаблоны типов профилей и Пользовательский.
Создайте имя политики, например Элемент управления приложениями — принудительное применение политики, и нажмите кнопку Далее.
В разделе Параметры OMA-URI выберите Добавить.
Примечание
Эти сведения зависят от идентификатора политики, созданного мастером управления приложениями в Защитнике Windows, для XML-кода политики, созданного из раздела "Создание аудита" выше.
- Name = Microsoft Allow Enforce
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
— Тип данных = Base64 (Файл)Когда мастер управления приложениями Защитника Windows создал XML-код политики, он также создал (GUID). Файл CIP. Следующим шагом является копирование этого CIP-файла и переименование расширения файла в . BIN, например {CB46B243-C19C-4870-B098-A2080923755C}.bin.
Отправьте bin в base64 (файл).
Выберите Сохранить.
Следуйте инструкциям, чтобы создать профиль конфигурации.
Развертывание управления приложениями — принудительное применение профиля конфигурации политики в предполагаемой системе.
Примечание
Администратор должен исключить ранее созданную политику "Приложение — аудит" из предполагаемой системы, которая переключается на принудительное применение.