영어로 읽기

다음을 통해 공유


Essential Eight 애플리케이션 제어

이 문서에서는 Microsoft App Locker 및 Windows Defender 애플리케이션 제어를 사용하여 애플리케이션 제어를 위한 호주 ACSC(Cyber Security Center) Essential Eight Maturity 모델을 달성하는 방법을 자세히 설명합니다.

ACSC Essential Eight 애플리케이션 제어 지침을 추구하는 이유는 무엇인가요?

애플리케이션 제어는 시스템에서 실행되는 악성 코드로부터 보호하도록 설계된 보안 접근 방식입니다. 이 보안 접근 방식을 구현하면 실행 파일, 소프트웨어 라이브러리, 스크립트, 설치 관리자 및 드라이버와 같은 승인된 코드만 실행할 수 있습니다. 그 효과로 인해 애플리케이션 제어는 ACSC의 사이버 보안 인시던트 완화 전략의 Essential Eight 중 하나입니다.

응용 프로그램 제어

애플리케이션 제어는 시스템에서 실행되는 악성 코드로부터 보호하도록 설계된 보안 접근 방식입니다. 이 보안 접근 방식을 구현하면 실행 파일, 소프트웨어 라이브러리, 스크립트, 설치 관리자 및 드라이버와 같은 승인된 코드만 실행할 수 있습니다.

애플리케이션 제어는 주로 시스템에서 악성 코드의 실행 및 확산을 방지하도록 설계되어 있지만 승인되지 않은 애플리케이션의 설치 및 사용을 방지할 수도 있습니다.

조직의 완성도 수준 요구 사항 달성

  • 완성도 수준 1(ML1): Microsoft AppLocker를 사용하여 달성할 수 있습니다.
  • 완성도 수준 2 및 3(ML2 & ML3): Microsoft Windows Defender 애플리케이션 컨트롤을 사용하여 달성할 수 있습니다.

애플리케이션 제어 구현

애플리케이션 제어 구현에는 organization 대해 다음과 같은 개략적인 단계가 포함됩니다.

  • 승인된 애플리케이션 식별
  • 승인된 애플리케이션만 실행할 수 있도록 애플리케이션 제어 규칙 개발
  • 변경 관리 프로세스를 사용하여 애플리케이션 제어 규칙 유지 관리
  • 애플리케이션 제어 규칙의 유효성을 자주 검사

오스트레일리아 사이버 보안 센터는 organization 내에서 애플리케이션 권한 부여를 적용하는 방법을 결정할 때 올바르게 구현될 때 적합한 다음 방법을 고려합니다.

  • 암호화 해시 규칙
  • 게시자 인증 규칙
  • 경로 규칙(폴더 및 파일 권한, 폴더 콘텐츠 및 개별 파일의 무단 수정을 방지하기 위해 파일 시스템 권한이 구성된 경우)

애플리케이션 제어는 승인되지 않은 애플리케이션의 무단 실행을 방지할 수 있습니다. 또한 애플리케이션 제어는 위협 행위자가 시스템에서 악성 코드를 실행하려는 시도를 식별하는 데 기여할 수 있습니다. 권한 있는 실행 및 무단 실행에 대한 이벤트 로그를 생성하도록 WDAC를 구성하면 organization 보안 운영 센터에 중요한 정보를 제공할 수 있습니다.

애플리케이션 제어 솔루션은 바이러스 백신 및 이미 있는 다른 보안 소프트웨어 솔루션을 대체하지 않는다는 점에 유의해야 합니다. WDAC는 항상 Defender 바이러스 백신 같은 바이러스 백신 솔루션과 함께 작동합니다. Microsoft 보안 솔루션을 함께 사용하면 시스템 손상을 방지하는 효과적인 심층 방어 접근 방식에 기여합니다.

애플리케이션 제어를 위한 ML(완성도)

오스트레일리아 사이버 보안 센터에는 Essential Eight를 구성하는 완화 전략에 대한 세 가지 완성도가 있습니다. 성숙도는 위협 행위자가 사용하는 무역 기술의 증가 수준을 완화하는 것을 기반으로 합니다. 애플리케이션 제어의 컨텍스트 내에서 오스트레일리아 사이버 보안 센터는 ML 1, 2 및 3을 충족하는 데 필요한 사항을 결정합니다.

ISM 2024년 9월 제어 완성도 수준 완화
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 Microsoft의 권장 애플리케이션 차단 목록이 구현됩니다.
ISM-1657 1, 2, 3 애플리케이션 제어는 실행 파일, 소프트웨어 라이브러리, 스크립트, 설치 관리자, 컴파일된 HTML, HTML 애플리케이션 및 제어판 애플릿의 실행을 organization 승인된 집합으로 제한합니다.
ISM-1658 3 애플리케이션 제어는 드라이버의 실행을 organization 승인된 집합으로 제한합니다.
ISM-1582 2, 3 애플리케이션 제어 규칙 집합은 매년 또는 더 자주 유효성을 검사합니다.
ISM-1659 3 Microsoft의 취약한 드라이버 차단 목록이 구현됩니다.
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년 9월 제어 완성도 수준 제어 측정
ISM-0109 3 워크스테이션의 이벤트 로그는 적시에 분석되어 사이버 보안 이벤트를 검색합니다. 엔드포인트용 Defender P2를 사용합니다. Windows 이벤트 로그는 AMA 또는 Windows 전달 이벤트 솔루션을 통해 Windows 보안 이벤트를 사용하여 Microsoft Sentinel 및 Microsoft Defender XDR 내에서 캡처됩니다.
ISM-0140 2, 3 사이버 보안 인시던트가 발생하거나 발견된 후 가능한 한 빨리 ASD에 보고됩니다. 이 문서의 scope 없습니다. 이 표 뒤의 참고 사항을 참조하세요. 3
ISM-0123 2, 3 사이버 보안 인시던트가 발생하거나 발견된 후 가능한 한 빨리 최고 정보 보안 책임자 또는 대리인 중 한 명과 보고됩니다. 이 문서의 scope 없습니다. 이 표 뒤의 참고 사항을 참조하세요. 3
ISM-0843 1, 2, 3 애플리케이션 제어는 워크스테이션에서 구현됩니다. organization 성숙도 요구 사항에 따라 Windows Defender 애플리케이션 제어/AppLocker를 구성하고 사용합니다.
ISM-1490 2, 3 애플리케이션 제어는 인터넷 연결 서버에서 구현됩니다. Windows Defender 애플리케이션 제어 구성 및 사용
ISM-1656 3 애플리케이션 제어는 인터넷 연결이 아닌 서버에서 구현됩니다. Windows Defender 애플리케이션 제어 구성 및 사용
ISM-1544 2, 3 Microsoft의 권장 애플리케이션 차단 목록이 구현됩니다. Microsoft의 '권장 블록 규칙'이 구현됩니다.
ISM-1657 1, 2, 3 애플리케이션 제어는 실행 파일, 소프트웨어 라이브러리, 스크립트, 설치 관리자, 컴파일된 HTML, HTML 애플리케이션 및 제어판 애플릿의 실행을 organization 승인된 집합으로 제한합니다. Microsoft는 애플리케이션 제어 정책 내에서 정의된 파일 게시자 규칙 또는 파일 해시 목록을 만드는 것이 좋습니다. 1
ISM-1658 3 애플리케이션 제어는 드라이버의 실행을 organization 승인된 집합으로 제한합니다. 하이퍼바이저로 보호되는 코드 무결성이 사용하도록 설정되어 있으며 2022년 Windows 11 기본값입니다.
ISM-1582 2, 3 애플리케이션 제어 규칙 집합은 매년 또는 더 자주 유효성을 검사합니다. 이 문서의 scope 없습니다. 이 표 아래에 있는 참고 사항을 참조하세요. 3
ISM-1659 3 Microsoft의 취약한 드라이버 차단 목록이 구현됩니다. Microsoft의 '권장 드라이버 블록 규칙'이 구현됨
ISM-1660 2, 3 허용되고 차단된 애플리케이션 제어 이벤트는 중앙에서 기록됩니다. 엔드포인트용 Defender P2를 사용합니다. Windows 이벤트 로그는 AMA 또는 'Windows 전달 이벤트' 솔루션을 통해 'Windows 보안 이벤트'를 사용하여 Microsoft Sentinel 및 Microsoft Defender XDR 내에서 캡처됩니다.
ISM-1815 2, 3 이벤트 로그는 무단 수정 및 삭제로부터 보호됩니다. Microsoft Defender XDR 및 Microsoft Sentinel 대한 Role-Based Access Control 적용됩니다.
ISM-1819 2, 3 사이버 보안 인시던트가 식별되면 사이버 보안 인시던트 대응 계획이 제정됩니다. 이 문서의 scope 없습니다.  이 표 아래에 있는 참고 사항을 참조하세요. 3
ISM-1870 1, 2, 3 애플리케이션 제어는 운영 체제, 웹 브라우저 및 전자 메일 클라이언트에서 사용하는 사용자 프로필 및 임시 폴더에 적용됩니다. Microsoft는 애플리케이션 제어 정책 내에서 정의된 파일 게시자 규칙 또는 파일 해시 목록을 만드는 것이 좋습니다. 완성도 수준 1은 Microsoft AppLocker를 사용하여 달성할 수 있습니다. 완성도 수준 2 및 3에는 Windows Defender 애플리케이션 제어가 필요합니다. 2
ISM-1871 2, 3 애플리케이션 제어는 운영 체제, 웹 브라우저 및 전자 메일 클라이언트에서 사용하는 사용자 프로필 및 임시 폴더를 제외한 모든 위치에 적용됩니다. Windows Defender 애플리케이션 제어 구현 및 구성
ISM-1228 2, 3 사이버 보안 이벤트는 사이버 보안 인시던트 식별을 위해 적시에 분석됩니다. 이 문서의 scope 없습니다.  이 표 뒤의 참고 사항을 참조하세요. 3
ISM-1906 2, 3 인터넷 연결 서버의 이벤트 로그는 적시에 분석되어 사이버 보안 이벤트를 검색합니다. 엔드포인트용 Defender P2를 사용합니다. Windows 이벤트 로그는 AMA 또는 Windows 전달 이벤트 솔루션을 통해 Windows 보안 이벤트를 사용하여 Microsoft Sentinel 및 Microsoft Defender XDR 내에서 캡처됩니다.
ISM-1907 3 인터넷 연결이 아닌 서버의 이벤트 로그는 적시에 분석되어 사이버 보안 이벤트를 검색합니다. 엔드포인트용 Defender P2를 사용합니다. Windows 이벤트 로그는 AMA 또는 Windows 전달 이벤트 솔루션을 통해 Windows 보안 이벤트를 사용하여 Microsoft Sentinel 및 Microsoft Defender XDR 내에서 캡처됩니다.

중요

1 ISM-1657을 충족하려면 애플리케이션 제어 정책 내에서 정의된 파일 게시자 규칙 또는 파일 해시 목록을 만드는 것이 좋습니다. 파일 경로 규칙을 너무 활용하는 경우 organization 사용자가 폴더 및 파일 권한, 폴더 콘텐츠 및 개별 파일을 무단으로 수정할 수 없도록 해야 합니다. 예를 들어 사용자는 NTFS 내에서 파일 경로 규칙 위치에 대한 쓰기 액세스 권한이 없어야 합니다.

2 ISM-1870을 충족하려면 애플리케이션 제어 정책 내에서 정의된 파일 게시자 규칙 또는 파일 해시 목록을 만드는 것이 좋습니다. 완성도 수준 1은 Microsoft AppLocker를 사용하여 달성할 수 있습니다. 성숙도 수준 2 및 3에는 추가 ISM 요구 사항으로 인해 Windows Defender 애플리케이션 제어에 대한 요구 사항이 있습니다. 파일 경로 규칙은 사용자의 프로필 및 임시 폴더 내에서 파일 시스템 권한이 있는 사용자가 있으므로 ISM-1870에는 권장되지 않습니다.

3 컨트롤 ISM-0140, 0123, 1582, 1819 및 1228은 명시적으로 기본 사용자 및 프로세스 컨트롤입니다. Microsoft는 필수 8 규정 준수 검토에 대한 자동화된 기술 증거의 일환으로 사용자와 프로세스가 Purview 규정 준수 관리자에서 문서로 문서화되고 저장될 것을 권장합니다.

Windows용 애플리케이션 제어

사용할 솔루션은 무엇입니까?

Microsoft는 고객이 AppLocker가 아닌 WDAC(Windows Defender 애플리케이션 제어)를 구현하는 것이 좋습니다. Windows Defender 애플리케이션 제어는 지속적으로 개선되고 있습니다. AppLocker는 보안 수정 사항을 계속 수신하지만 기능 향상을 받지 못합니다.

그러나 일부 사용자가 특정 애플리케이션을 실행하지 못하도록 하는 것이 중요한 공유 디바이스와 같은 시나리오에 대해 Windows Defender 애플리케이션 제어를 보완하기 위해 AppLocker를 배포할 수도 있습니다. Microsoft는 organization Organization 가능한 가장 제한적인 수준으로 Windows Defender 애플리케이션 제어를 적용하고 필요한 경우 AppLocker를 사용하여 사용자 모드 제한을 추가로 미세 조정하는 것이 좋습니다.

WDAC가 선호되지만 대부분의 조직에서 시작점으로 AppLocker만 사용하여 ML1을 달성하는 것이 더 간단하고 쉬울 수 있지만 두 솔루션 모두 무료입니다.

AppLocker

AppLocker는 Windows 7에서 도입되었으며 organization Windows 운영 체제에서 실행할 수 있는 사용자 모드(애플리케이션) 프로세스를 제어할 수 있습니다. AppLocker 정책은 시스템의 모든 사용자 또는 다음을 기반으로 정의할 수 있는 규칙이 있는 개별 사용자 및 그룹에 적용할 수 있습니다.

  • 암호화 해시 규칙
  • 게시자 인증 규칙
  • 경로 규칙

AppLocker 정책은 Windows 운영 체제의 지원되는 버전 및 추가에 대해 만들 수 있으며 그룹 정책, PowerShell 또는 모바일 장치 관리 솔루션을 사용하여 배포할 수 있습니다.

Windows Defender 응용 프로그램 제어

WDAC(Windows Defender 애플리케이션 제어)는 Windows 10 도입되었습니다. 조직에서 Windows 운영 체제에서 실행할 수 있는 사용자 모드(애플리케이션) 및 커널 모드(드라이버) 프로세스를 제어할 수 있습니다. WDAC 정책은 관리되는 시스템 전체에 적용되며 다음을 기반으로 정의할 수 있는 규칙을 사용하여 디바이스의 모든 사용자에게 영향을 줍니다.

  • 암호화 해시 규칙
  • 게시자 인증 규칙
  • 경로 규칙
  • Microsoft의 지능형 보안 그래프에 의해 결정된 애플리케이션의 평판
  • 관리되는 설치 관리자가 애플리케이션 설치를 시작한 프로세스의 ID

WDAC 정책은 지원되는 모든 클라이언트 버전의 Windows 10, Windows 11 또는 Windows Server 2016 이상에서 만들 수 있습니다. WDAC 정책은 모바일 장치 관리 솔루션인 그룹 정책 Configuration Manager 또는 PowerShell을 사용하여 배포할 수 있습니다.

Microsoft의 Windows as a Service를 통해 고객에게 새로운 기능을 개발 및 배포할 수 있으므로 WDAC의 일부 기능은 특정 Windows 버전에서만 사용할 수 있습니다.

Windows Defender 애플리케이션 제어 및 Applocker에 대한 자세한 내용은 Windows Defender 애플리케이션 제어 및 AppLocker 기능 가용성을 참조하세요.

ML1용 AppLocker를 사용하는 Essential Eight 애플리케이션 제어

AppLocker를 사용하여 ML1 달성

관리자가 사용자 기반 애플리케이션 제어에 대한 AppLocker 정책을 배포하는 경우 다음 규칙을 샘플 경로 기반 구현으로 사용할 수 있습니다. 여기에는 규칙, 규칙 적용 및 애플리케이션 ID 서비스의 자동 시작이 포함됩니다.

다음 경로를 최소한으로 차단하는 것이 좋습니다.

  • C:\Windows\Temp\*.*
  • %USERPROFILE%\AppData\Local\*.*
    • %USERPROFILE%\AppData\Local\Microsoft\WindowsApps에 대한 예외 추가
  • %USERPROFILE%\AppData\Roaming\*.*

ML1의 AppLocker에 대한 자세한 내용은 다음 문서를 참조하세요.

ML1을 달성하기 위한 AppLocker 정책 만들기

Microsoft AppLocker 정책은 여러 가지 방법을 사용하여 만들 수 있습니다. Microsoft는 Microsoft 오픈 소스 프로젝트 AaronLocker를 사용하여 AppLocker 정책을 만드는 데 도움을 줄 것을 권장합니다. AaronLocker를 사용하면 PowerShell 스크립트 서비스를 사용하여 최대한 쉽고 실용적인 AppLocker에 대한 강력하고 엄격한 애플리케이션 제어를 만들고 유지 관리할 수 있습니다. AaronLocker는 비관리 사용자에 의해 프로그램 및 스크립트 실행을 제한하도록 설계되었습니다.

Aaronlocker에 대한 자세한 내용은 AaronLocker: Windows용 강력하고 실용적인 애플리케이션 제어를 참조하세요.

ML1을 달성하기 위해 AppLocker 정책 배포

Microsoft AppLocker는 Microsoft Intune, 그룹 정책 또는 PowerShell을 사용하여 배포할 수 있습니다. 배포 방법은 organization 현재 관리 솔루션에 따라 달라집니다.

App Locker 배포에 대한 자세한 내용은 다음 문서를 참조하세요.

AppLocker 정책 이벤트 모니터링

Microsoft AppLocker 관련 이벤트는 Microsoft의 Sentinel 같은 보안 정보 및 이벤트 관리 솔루션에 의해 모니터링됩니다. 또한 이벤트는 엔드포인트용 Microsoft Defender 고급 헌팅 정보를 사용하여 모니터링됩니다.

엔드포인트용 Microsoft Defender: AppLocker 참조

엔드포인트용 Microsoft Defender Microsoft AppLocker와 관련하여 다음 이벤트를 캡처합니다.

ActionType 이름 이벤트 원본 ID
AppControlExecutableAudited 8003
AppControlExecutableBlocked 8004
AppControlPackagedAppAudited 8021
AppControlPackagedAppBlocked 8022
AppControlPackagedAppBlocked 8006
AppControlScriptBlocked 8007
AppControlCIScriptAudited 8001

이벤트 뷰어 및 고급 헌팅에 대한 자세한 내용은 다음 문서를 참조하세요.

ML2용 WDAC를 사용하는 Essential Eight 애플리케이션 제어

Microsoft는 WDAC를 사용하는 Essential Eight 애플리케이션 제어 ML2 및 ML3을 충족하기 위한 디자인 프로세스, 수명 주기 관리, 배포 및 운영 지침을 설명합니다.

Essential Eight Application Control ML1에 대한 요구 사항이 있는 고객은 Microsoft AppLocker를 사용하여 수행할 수 있습니다.

이 지침을 사용하기 위한 필수 구성 요소는 다음과 같습니다.

  • Windows 11 22H2 Enterprise
  • 관리 솔루션에 Intune 사용
  • 엔드포인트용 Defender( 엔드포인트 보안 솔루션용)
  • 보안 정보 및 이벤트 관리를 위한 Microsoft Sentinel
  • 이 문서 내에서 사용되는 솔루션 전체에서 관리자의 적절한 권한

이 가이드의 경우 windows Server 운영 체제의 WDAC가 scope 없습니다. Windows Server에 대한 지침은 향후 릴리스에서 제공됩니다.

라이선스 요구사항

M365 관련 서비스는 필요한 서비스, 가치 제안 및 라이선스 요구 사항을 이해하기 위해 Microsoft 365 및 Office 365 서비스 설명 내에 있을 수 있습니다.

Microsoft 365 및 Office 365 서비스 설명

WDAC와 연결된 제품에 대한 자세한 내용은 다음 문서를 참조하세요.

WDAC 시작

정책 디자인

organization WDAC 계획을 시작하면 디자인 결정에 대한 고려 사항이 정책 배포 및 애플리케이션 제어 정책 유지 관리에 미치는 영향을 구체화합니다.

WDAC는 다음과 같은 경우 organization 애플리케이션 제어 정책의 일부로 사용해야 합니다.

  • organization 지원되는 버전의 Windows를 배포하거나 배포할 계획입니다.
  • organization 애플리케이션에 대한 액세스 및 사용자의 액세스 데이터에 대한 향상된 제어가 필요합니다.
  • organization 애플리케이션 관리 및 배포를 위해 잘 정의된 프로세스가 있습니다.
  • organization 요구 사항에 대해 정책을 테스트할 리소스가 있습니다.
  • 지원 센터와 관련되거나 최종 사용자 애플리케이션 액세스 문제에 대한 자가 진단 프로세스를 빌드할 리소스가 있습니다.
  • 생산성, 관리 효율성 및 보안에 대한 그룹의 요구 사항은 제한적인 정책에 의해 제어될 수 있습니다.

WDAC는 '신뢰의 원'의 개념을 통합합니다. 각 organization 비즈니스 요구 사항에 고유한 '신뢰의 원'에 대한 다른 정의가 있습니다. ACSC Essential 8 관련 정의는 ISM 컨트롤 1657 - '애플리케이션 제어는 실행 파일, 소프트웨어 라이브러리, 스크립트, 설치 관리자, 컴파일된 HTML, HTML 애플리케이션 및 제어판 애플릿의 실행을 organization 승인된 집합으로 제한합니다.'

Microsoft는 %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies 아래 Windows에 있는 XML 형식 내에서 몇 가지 예제 정책을 제공합니다. Microsoft 예제 정책을 사용하면 organization 기존 기본 정책에서 시작하고 필요한 경우 사용자 지정 정책을 빌드하는 규칙을 추가하거나 제거할 수 있습니다.

정책 디자인에 대한 자세한 내용은 다음 문서를 참조하세요.

정책 형식

WDAC는 다음 두 가지 정책 형식을 지원합니다.

  • 단일 정책 형식: Windows 10 RTM 및 Windows Server 2016 사용하여 릴리스된 원래 정책 형식입니다. 단일 정책 형식은 지정된 시간에 시스템에서 단일 활성 정책만 지원합니다.

  • 여러 정책 형식(권장): 이 정책 형식은 Windows 10 1903 이상, Windows 11 및 Windows Server 2022에서 지원됩니다. 여러 정책 형식을 사용하면 Windows Defender 애플리케이션 제어를 보다 유연하게 배포할 수 있으며 디바이스에서 최대 32개의 활성 정책을 지원합니다. 또한 다음 시나리오를 수행할 수 있습니다.

    • 함께 적용 및 감사: 적용을 배포하기 전에 정책 변경 내용의 유효성을 검사합니다. 사용자는 기존 적용 모드 기반 정책과 함께 감사 모드 기본 정책을 배포할 수 있습니다.
    • 여러 기본 정책: 사용자가 두 개 이상의 기본 정책을 동시에 적용할 수 있습니다.
    • 추가 정책: 사용자는 하나 이상의 추가 정책을 배포하여 기본 정책을 확장할 수 있습니다. organization 내의 다른 가상 사용자(예: HR 및 IT)에 대한 추가 정책을 사용할 수 있습니다.

Microsoft는 잘 정의된 시나리오 또는 Windows Server 2016 및 Windows Server 2019와 같은 여러 정책 형식을 사용할 수 없는 경우 여러 정책 형식을 사용하고 단일 정책 형식만 사용하는 것이 좋습니다.

WDAC 제어 정책에 대한 자세한 내용은 여러 Windows Defender 애플리케이션 제어 정책 사용을 참조하세요.

정책 규칙 및 파일 규칙

WDAC에는 다음과 같은 두 가지 개념이 포함되어 있습니다.

  • WDAC 정책 규칙: WDAC 정책 규칙은 감사 모드, 관리형 설치 관리자, 스크립트 적용, 추가 정책(다중 정책 형식), Reputation-Based 인텔리전스(ISG 권한 부여/스마트 앱 제어) 등의 구성을 지정합니다. 정책 규칙은 커널 모드 및 사용자 모드 이진 파일 모두에 대한 WDAC도 결정합니다.
  • WDAC 파일 규칙: WDAC 파일 규칙은 Windows에서 실행하기 위한 권한 부여 및 재승인을 지정합니다. 파일 규칙은 해시, 파일 이름, 파일 경로 및 게시자 규칙을 지원하므로 고객이 organization 승인된 허용 애플리케이션 집합을 정의할 수 있습니다. 규칙은 먼저 찾은 모든 명시적 거부 규칙을 처리한 다음 모든 명시적 허용 규칙을 처리합니다. 거부 또는 허용 규칙이 없는 경우 WDAC는 관리되는 설치 관리자를 확인합니다. 마지막으로 이러한 집합이 없으면 WDAC는 Reputation-Based 인텔리전스로 대체됩니다.

정책 규칙 및 파일 규칙에 대한 자세한 내용은 다음 문서를 참조하세요.

정책 만들기

PowerShell 또는 WDAC 마법사를 사용하여 WDAC 정책을 만드는 두 가지 기본 방법이 있습니다.

  • PowerShell: WDAC 정책은 PowerShell에서 구성 가능한 코드 무결성 Cmdlet을 사용하여 만들어집니다. PowerShell을 사용하면 IT 전문가가 정책 XML을 생성하는 WDAC 정책 시스템 검사를 자동화할 수 있습니다. PowerShell을 사용하여 정책 XML을 병합하고, 정책 규칙을 설정하고, 필요한 경우 다른 정책 파일 규칙을 추가할 수 있습니다. 구성 가능한 코드 무결성 Cmdlet을 사용하여 WDAC 예제 정책을 수정하여 organization 요구 사항을 충족할 수도 있습니다.
  • Windows Defender 애플리케이션 제어 마법사(권장): WDAC 정책 마법사는 C#으로 작성되어 MSIX 패키지로 번들로 제공되는 오픈 소스 Windows 데스크톱 애플리케이션입니다. 보안 설계자와 시스템 관리자에게 애플리케이션 제어 정책을 만들고, 편집하고, 병합할 수 있는 보다 친숙한 수단을 제공하도록 빌드되었습니다. 이 도구는 백 엔드의 Config CI PowerShell cmdlet을 사용하므로 도구 및 PowerShell cmdlet의 출력 정책은 동일합니다.

정책 만들기에 대한 자세한 내용은 다음 문서를 참조하세요.

Microsoft는 Application Control용 Essential Eight를 구현하기 위해 Windows Defender 애플리케이션 제어 마법사를 사용하는 것이 좋습니다. 또는 예제 정책을 기반으로 사용하거나 참조 시스템에서 잘 정의된 시나리오에 대한 정책을 만들려는 DevOps 운영 모델의 고급 요구 사항이 있는 조직에서 PowerShell을 사용할 수 있습니다.

정책 수명 주기

organization 애플리케이션 제어 솔루션 구현을 시작하기 전에 시간이 지남에 따라 정책을 관리하고 유지 관리하는 방법을 고려해야 합니다. 대부분의 WDAC 정책은 시간이 지남에 따라 진화하고 수명 동안 식별 가능한 일련의 단계를 계속 진행합니다. 이러한 단계는 다음과 같습니다.

  1. 정책을 정의하고 정책 XML의 감사 모드 버전을 빌드합니다. 감사 모드에서는 차단 이벤트가 생성되지만 파일이 실행되지는 않습니다.
  2. 의도한 시스템에 감사 모드 정책 배포
  3. 의도한 시스템에서 감사 블록 이벤트를 모니터링하고 예기치 않은/원치 않는 블록을 해결하기 위해 필요에 따라 규칙을 구체화합니다.
  4. 감사 내에서 나머지 블록 이벤트가 기대에 부합할 때까지 이러한 단계를 반복합니다.
  5. 정책의 적용 모드 버전을 생성합니다. 적용 모드에서는 정책에서 허용하는 대로 정의되지 않은 파일이 실행되지 않고 해당 블록 이벤트가 생성됩니다.
  6. 의도한 시스템에 적용 모드 정책 배포
  7. 이러한 모든 단계를 지속적으로 반복하여 예기치 않은/원치 않는 블록 작업을 해결합니다.

WDAC 정책을 효과적으로 관리하려면 정책 XML 문서를 중앙 리포지토리에 저장하고 유지 관리해야 합니다. Microsoft는 GitHub와 같은 소스 제어 솔루션 또는 버전 제어를 제공하는 SharePoint와 같은 문서 관리 솔루션을 권장합니다.

관리되는 설치 관리자에 대한 WDAC 필수 구성 요소

이 섹션은 PowerShell 및 Microsoft Intune 사용하여 WDAC 관리형 설치 관리자를 구성하는 요구 사항에 대한 고객의 지침을 제공하기 위한 것입니다.

  • Windows Defender 애플리케이션 제어를 사용하여 관리되는 설치 관리자가 자동으로 배포하는 앱 허용(/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer)을 검토합니다.

참고

이 샘플 스크립트는 AppLocker를 사용하지 않으므로 1단계에서 무해한 DENY 규칙이 없습니다. 이 AppLocker 구성은 관리되는 설치 관리자가 필요한 모든 디바이스에 대해 만들어집니다.

  • 다음을 완료하는 PowerShell 스크립트를 만듭니다.
    • AppLocker XML 저장
    • AppLocker XML 내보내기
    • 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 관리형 설치 관리자

개요

관리되는 설치 관리자라는 WDAC 기능을 사용하면 organization 애플리케이션 제어 정책을 적용할 때 보안 및 관리 효율성의 균형을 맞출 수 있습니다. 이렇게 하면 Microsoft Configuration Manager 또는 Intune 같은 소프트웨어 배포 솔루션에서 애플리케이션을 설치할 수 있습니다.

WDAC 정책 내에서 "관리되는 설치 관리자" 규칙을 구성하는 것이 일반적인 오해입니다. 이는 올바르지 않으며 이 기능이 작동하려면 AppLocker의 또 다른 구성이 필요합니다.

관리되는 설치 관리자는 AppLocker 내의 규칙 컬렉션을 사용하여 애플리케이션 설치를 위해 organization 신뢰할 수 있는 이진 파일을 지정합니다. Windows는 구성된 이진 파일의 프로세스와 디스크에 기록되는 관련 파일을 모니터링하는 동안 실행되는 모든 자식 프로세스를 모니터링합니다. 이러한 파일은 관리되는 설치 관리자에서 시작된 것으로 태그가 지정되므로 실행할 수 있습니다.

관리되는 설치 관리자 배포

GPO 편집 및 AppLocker PowerShell cmdlet 내에서 AppLocker 정책 만들기는 관리되는 설치 관리자 컬렉션에 대한 규칙을 만드는 데 직접 사용할 수 없습니다. 관리되는 설치 관리자 규칙 컬렉션을 만들려면 VS Code 또는 다른 편집기 도구를 사용해야 합니다.

AppLocker CSP(구성 서비스 공급자)는 현재 관리되는 설치 관리자 규칙 컬렉션 유형을 지원하지 않으므로 AppLocker 정책은 Microsoft Intune PowerShell을 사용하여 수신되어야 합니다.

ISM-1657을 충족하려면 Windows Defender 애플리케이션 컨트롤의 기능 "스크립트 적용"이 필요하므로 PowerShell, VBscript, cscript, cscript, HSMTA 및 MSXML을 제어하려면 스크립트 적용이 필요합니다. '관리되는 설치 관리자'를 구성하는 PowerShell 스크립트는 해시 또는 게시자를 사용하는 WDAC 파일 정책 규칙 내에 있어야 합니다.

Microsoft는 Microsoft Intune 관리되는 설치 관리자의 구성을 권장합니다. Intune Windows Defender 애플리케이션 제어 정책을 자주 업데이트할 요구 없이 Microsoft Intune 사용하여 패키지된 애플리케이션을 강력하게 관리할 수 있습니다.

관리되는 설치 관리자용 PowerShell 스크립트 배포

관리되는 설치 관리자에 대한 이 구성 스크립트의 배포는 시나리오에 따라 Microsoft Intune 사용하여 두 가지 방법으로 수행할 수 있습니다.

  • 해시: 스크립트의 해시는 Microsoft Intune 내에서 Microsoft Win32 콘텐츠 준비 도구 또는 PowerShell 스크립트 기능을 사용하여 WDAC 파일 정책 내에서 알려지고 패키지되고 배포되어야 합니다.
  • 코드 서명(게시자): PowerShell 스크립트는 신뢰할 수 있는 기관에서 서명했으며 Microsoft Intune 내에서 Microsoft Win32 콘텐츠 준비 도구 또는 PowerShell 스크립트 기능을 사용하여 패키지 및 배포된 WDAC 파일 정책으로 알려져 있습니다.

PowerShell 스크립트 배포에 대한 자세한 내용은 다음 문서를 참조하세요.

WDAC 감사 정책 만들기

감사 정책 만들기

옵션을 이해하고 결정을 설계하면 organization Windows Defender 앱 제어 마법사를 사용하여 첫 번째 감사 정책을 만들 수 있습니다.

  1. Windows Defender 앱 제어 마법사를 열고 "정책 작성자"를 선택합니다.

  2. 정책 작성자 내에서 여러 정책 형식기본 정책을 선택한 다음, 다음을 선택합니다.

  3. 정책 템플릿 내에는 다음 세 가지 옵션이 제공됩니다.

    • 기본 Windows 모드에는 Windows OS, 스토어 앱, 엔터프라이즈용 Microsoft 365 앱(Office 365 Pro Plus) 및 WHQL 서명된 커널 드라이버가 포함됩니다.
    • Microsoft 모드 허용 에는 기본 Windows 모드 및 모든 Microsoft 서명 애플리케이션 내의 모든 섹션이 포함됩니다.
    • 서명 및 평판 모드 에는 이전의 모든 섹션과 Reputation-Based 인텔리전스가 포함됩니다.

중요

Reputation-Based Intelligence for Application Control은 "조직 승인 집합"(ISM 1657) 및 "애플리케이션 제어 규칙 집합의 유효성을 연간 또는 더 자주 확인"(ISM 1582) 요구 사항으로 인해 Essential Eight Application Control을 충족하지 않습니다. WDAC 내의 이 기능은 ML2 또는 ML3에 대한 요구 사항을 충족하지 않습니다. Microsoft는 Essential Eight Application Control의 컨텍스트 외부에서 WDAC를 채택하는 조직에 Reputation-Based 인텔리전스를 사용하는 것이 좋습니다.

  1. organization 요구 사항에 따라 기본 Windows 모드 또는 Microsoft 모드 허용을 선택합니다. 이 문서에서 Microsoft는 Microsoft 모드 허용을 사용합니다.
  2. 정책 이름위치를 원하는 정책 이름정책 파일 위치로 수정하여 파일을 저장하고 다음을 선택합니다.

참고

WDAC에 대한 자세한 정보 – 정책 규칙은 여기에서 찾을 수 있습니다.

  • ISM 1657 및 1658에서 스크립트, 규격 HTML 및 HTML 애플리케이션을 제어하려면 스크립트 적용을 "사용 안 함"으로 설정해야 합니다.
  • ISM 1657, 1658 및 1582에는 "Disabled"로 설정된 지능형 보안 그래프가 필요합니다.
  • WDAC 정책 수명 주기를 사용하여 organization 지원하려면 관리되는 설치 관리자를 "사용"하는 것이 좋습니다.
  • WDAC 정책이 커널 모드와 사용자 모드 이진 파일 모두에 적용하려면 사용자 모드 코드 무결성이 필요합니다.
  • 다중 정책 형식을 사용하여 WDAC 정책 수명 주기에서 organization 지원하려면 추가 정책 허용이 필요합니다.

참고

다른 모든 WDAC 정책 규칙은 organization 내의 요구 사항에 따라 달라집니다.

  1. 서명 규칙 내에서 관리자는 게시자 규칙 허용으로 추가된 모든 Microsoft 인증서를 볼 수 있습니다. 이 문서의 뒷부분에서 사용자 지정 규칙 추가 를 다룹니다.
  2. 다음을 선택합니다.

Windows Defender 앱 제어 마법사는 다음을 생성합니다.

  • 정책 XML
  • {GUID}. CIP

WDAC에 대한 자세한 정보 – 정책 규칙은 여기에서 찾을 수 있습니다.

참고

Windows Defender 앱 제어 마법사를 사용하여 생성된 각 정책은 새로운 GUID(Globally Unique Identifier)를 조달합니다.

WDAC 정책이 성공적으로 만들어졌습니다.

정책 XML

organization WDAC 마법사를 사용하여 WDAC 정책을 만들었으므로 organization 텍스트 편집기 내에서 이 파일의 컨텍스트를 볼 수 있습니다. XML은 PolicyIDBasePolicyID를 적어 두는 Essential Eight의 컨텍스트에 대해 여러 섹션으로 분할됩니다.

참고

그러나 정책 XML을 직접 편집할 수 있습니다. Microsoft는 Windows Defender 앱 제어 마법사 또는 PowerShell의 구성 가능한 코드 무결성 Cmdlet을 사용하여 정책 규칙 또는 서명 파일에 대한 모든 추가 변경을 권장합니다.

WDAC 감사 정책 배포

Intune 통해 WDAC 감사 정책 배포

이제 organization 감사 정책을 만들었으므로 Intune 디바이스 관리를 사용하여 배포해야 합니다.

  1. Intune 관리 센터에 로그인합니다.
  2. Intune 관리 센터 내에서 디바이스로 이동한 다음 구성 프로필로 이동합니다.
  3. 다음으로 프로필>플랫폼( Windows 10 이상, 프로필 형식 템플릿 및 사용자 지정)을 만듭니다.
  4. 정책 이름(예: '애플리케이션 제어 - Microsoft 허용 – 감사')을 만들고 다음을 선택합니다.
  5. OMA-URI 설정에서 추가를 선택합니다.

참고

이 정보는 위의 섹션에서 "감사 정책 만들기"에서 만든 정책 XML에 대해 Windows >Defender 앱 제어 마법사에서 생성된 정책 ID에 따라 달라집니다.

- 이름 = Microsoft Allow Audit
- OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
- 데이터 형식 = Base64(파일)

  1. Windows Defender 앱 제어 마법사가 정책 XML을 생성했을 때 (GUID)도 만들었습니다. CIP 파일. CIP 파일을 복사하고 파일 확장명 이름을 로 바꿔야 합니다. BIN 예: {CB46B243-C19C-4870-B098-A2080923755C}.bin.
  2. Base64(파일) 아래에 BIN을 업로드합니다.
  3. 저장을 선택합니다.
  4. 프롬프트에 따라 구성 프로필을 만듭니다.
  5. 만든 정책(예: '애플리케이션 제어 - Microsoft 허용 – 감사', 구성 프로필을 의도한 시스템에 배포합니다.

WDAC – 감사 정책 모니터링

WDAC 정책 수명 주기에 따라 organization 'Microsoft 감사 허용' 정책에서 생성된 이벤트를 검토해야 합니다. WDAC 감사 정책 모니터링은 다음 두 가지 방법으로 수행할 수 있습니다.

  • 애플리케이션 제어 이벤트 ID: 애플리케이션 제어 이벤트 ID는 Windows 운영 체제에서 감사된 이벤트를 검토하는 기존의 방법입니다. 이러한 이벤트 ID는 Windows 이벤트 로그 전달 또는 타사 보안 정보 및 이벤트 관리를 사용하여 중앙 집중식 위치로 전달될 수 있습니다.

이벤트 ID에 대한 자세한 내용은 Application Control 이벤트 ID 이해 - Windows 보안을 참조하세요.

Microsoft는 Microsoft Defender XDR(MDE) 통합을 사용하여 Microsoft Sentinel 권장합니다. MDE 및 Sentinel 고급 헌팅 원격 분석 데이터를 엔드포인트용 Microsoft Defender 비교하여 30일 이상 저장할 수 있습니다.

연결 및 모니터링에 대한 자세한 내용은 다음 문서를 참조하세요.

엔드포인트용 Microsoft Defender 사용하여 WDAC 모니터링

다음 예제에서는 사용자에게 organization 일상적인 작업에 사용되는 여러 애플리케이션이 있음을 보여 줍니다. 이 예제에는 Microsoft 애플리케이션과 다양한 오픈 소스 애플리케이션이 모두 포함되어 있습니다.

이 예제는 적용 감사 모드에 있으므로 관리자가 WinSCP, VLC, Putty 및 FileZilla에 대해 트리거된 이벤트가 초기 감사 정책의 일부가 아니기 때문에 관리자가 볼 수 있습니다.

이제 Microsoft Defender 포털을 사용하여 감사 이벤트를 좁히기 위해 고급 헌팅을 입력하여 감사 모드를 사용하지 않도록 설정한 경우 발생하는 예기치 않은/원치 않는 블록을 파악하여 이 예제 내에서 적용 모드로 전환합니다.

고급 헌팅의 스크린샷

이전 페이지의 참조 스키마를 사용하여 지난 7일 동안 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 Explorer 다른 필드를 추가합니다. KQL 쿼리는 GUI 내에서 사용자가 실행한 애플리케이션을 표시합니다.

 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 쿼리 작업으로 정보가 더 많은 관리 데이터 세트로 좁혀집니다. 의도한 시스템에서 사용하는 애플리케이션을 볼 수 있습니다. 이러한 애플리케이션은 organization 정책에 추가하거나 조직 변경 제어를 통해 추가되는 것으로 간주되어야 합니다.

참고

KQL은 구조화되지 않은 구조화된 데이터 세트를 표시하는 강력한 도구입니다. 이는 KQL을 사용하는 예제일 뿐이며 Microsoft는 다음 설명서를 검토하는 것이 좋습니다. Microsoft Defender XDR

WDAC – 감사 정책 업데이트

엔드포인트용 Microsoft Defender 및 WDAC 마법사를 사용하여 감사 정책 업데이트

KQL을 사용하여 검색 결과가 축소되면 다음 단계는 WDAC 기본 정책을 업데이트하거나 추가 정책을 사용하는 것입니다. 다음 예제에서는 보충 정책을 사용합니다.

  1. Windows Defender 앱 제어 마법사를 열고 정책 작성자를 선택합니다.

  2. 정책 작성자 내에서 여러 정책 형식추가 정책을 선택하고 기본 정책으로 이동하여 위치를 업데이트하여 추가 정책을 저장하고 다음을 선택합니다.

  3. 정책 규칙 내에서 다음을 선택합니다.

  4. 정책 서명 규칙 내에서 사용자 지정 규칙을 선택합니다.

  5. 사용자 지정 규칙 조건 내에서 다양한 옵션을 사용할 수 있습니다.

    • 규칙 범위 사용자 모드 규칙/커널 모드 규칙
    • 규칙 작업: 허용/거부
    • 규칙 유형
      • 게시자 (권장)
      • File
      • 파일 특성
      • 패키지된 앱
      • 해시
    • 참조 파일

참고

Microsoft는 필수 8 애플리케이션 컨트롤을 구현하기 위해 서명되지 않은 참조 파일에 대한 적절한 해시 기반 규칙으로 대체되는 경우 게시자 기반 규칙을 사용하는 것이 좋습니다.

엔드포인트용 Microsoft Defender 사용

  1. 검색에서 파일 이름을 검색 하고 파일 정보로 이동하여 파일을 다운로드합니다. 감사 정책 업데이트 스크린샷 2.
  2. 고급 헌팅에서 직접 레코드를 검사하고 파일을 다운로드한 다음 필요한 이진 파일을 다운로드합니다. 감사 정책 업데이트 스크린샷 3.
  3. 필요한 이진 파일을 사용하여 organization ISV 애플리케이션에 대한 다른 정책을 계속 만듭니다.
  4. Windows Defender 앱 제어 마법사 내에서 원하는 규칙 유형을 선택하고 이전 단계에서 참조 이진 파일로 이동합니다. 다음 예제에서는 VLC가 필요한 게시자 정보를 충족하는 것을 보여 줍니다. 감사 정책 업데이트 스크린샷 4.

참고

Microsoft는 게시자 기반 규칙을 만들기 위해 최소한 CA, 게시자를 선택적으로 발급하는 것이 좋습니다. 제품 이름을 포함할 수 있으며 게시자 기반 규칙에 대한 ACSC에서 권장합니다.

  1. 다음을 누르고 만들기를 누릅니다.
  2. "Microsoft Intune 통해 Windows Defender 애플리케이션 제어 감사 정책 배포" 섹션에 설명된 단계를 사용하여 이 추가 정책을 배포합니다.

WDAC – 정책 적용으로 전환

정책을 적용하도록 전환하려면 다음을 수행합니다.

  1. Windows Defender 앱 제어 마법사를 열고 정책 편집기 선택합니다.

  2. 적용되도록 변경할 정책 XML로 이동합니다.

  3. 정책 규칙 내에서 감사 모드 스위치를 사용하지 않도록 설정합니다.

  4. 정책 규칙 내에서 다음을 선택합니다.

  5. 업데이트 정책은 수정된 버전 번호로 만들어지고 새 CIP 파일이 만들어졌습니다.

  6. Microsoft Endpoint Manager 관리 Center 내에서 디바이스로 이동한 다음 구성 프로필로 이동합니다.

  7. 다음으로 프로필, 플랫폼 - Windows 10 이상, 프로필 형식 템플릿사용자 지정을 만듭니다.

  8. 정책 이름(예: 애플리케이션 제어 – 정책 적용)을 만들고 다음을 선택합니다.

  9. OMA-URI 설정에서 추가를 선택합니다.

    참고

    이 정보는 위의 감사 만들기 섹션에서 만든 정책 XML에 대한 Windows Defender 앱 제어 마법사에서 생성된 정책 ID에 따라 달라집니다.

    - 이름 = Microsoft Allow Enforce
    - OMA-URL = ./Vendor/MSFT/ApplicationControl/Policies/CB46B243-C19C-4870-B098-A2080923755C/Policy
    - 데이터 형식 = Base64(파일)

  10. Windows Defender 앱 제어 마법사가 정책 XML을 생성했을 때 (GUID)도 만들었습니다. CIP 파일. 다음 단계는 이 CIP 파일을 복사하고 파일 확장명 이름을 로 바꾸는 것입니다. BIN 예: {CB46B243-C19C-4870-B098-A2080923755C}.bin.

  11. Base64(파일) 아래에 BIN을 업로드합니다.

  12. 저장을 선택합니다.

  13. 프롬프트에 따라 구성 프로필을 만듭니다.

  14. 애플리케이션 제어 배포 – 정책 구성 프로필을 의도한 시스템에 적용합니다.

    참고

    관리자는 이전에 만든 애플리케이션 – 감사 정책을 적용하도록 전환되는 의도된 시스템에서 제외해야 합니다.