Application Control for Business, Schema Definition
Watching my miniature schnauzer, Raven, explore my backyard, I’m reminded of the importance of having a clear set of rules and guidelines. Just like Raven has her own schema to navigate her environment—knowing where she can wander, where she shouldn't venture, and how to interact. Application Control for Business (ACfB) provides a robust schema to help organizations manage and secure their digital landscapes. Note: ACfB has also been known as Windows Defender Application Control (WDAC), Application Control for Windows and Code Integrity. Application Control for Windows | Microsoft Learn In Raven's serene world, her schema might look something like this: Safe Zones: The grassy lawn where she can leisurely sniff around and her favorite shady spot under the tree. Restricted Zones: The delicate garden beds and the tempting koi pond, which are off-limits to her curious paws. Behavior Rules: Guidelines for greeting other animals and people, ensuring she remains the friendly neighborhood pup. Similarly, ACfB's schema defines the rules and guidelines for managing applications and code within an organization: Approved Applications: Software that is allowed to run, ensuring it is safe and trusted. Restricted Applications: Programs that are blocked from execution to prevent potential security threats. Execution Rules: Policies that dictate how applications can interact with the system, ensuring a secure and controlled environment. For Raven, following her schema with precision is key. It keeps her out of trouble and ensures she enjoys her outdoor time without any mishaps. The order of her schema is equally important. She needs to know the safe zones before understanding the restricted ones, and she must learn the behavior rules to interact safely with others. Similarly, for organizations, adhering to ACfB's schema is crucial. It ensures that only approved applications run, restricted applications are blocked, and execution rules are followed, maintaining a secure and efficient digital landscape. Similarly, ACfB's schema defines precise rules for applications, ensuring that only trusted software runs on your systems, protecting against malicious code and unauthorized access. The order in which these rules and policies are defined is critical. Just as Raven's schema order helps her navigate her environment effectively, the correct order of elements in the ACfB schema ensures that the policy is correctly interpreted and enforced. Application Control for Business - Schema Overview The ACfB schema provides a comprehensive framework for defining rules and policies that control which applications are allowed to run on your systems. It ensures that only trusted applications are executed, enhancing security and compliance. XML Structure Overview The XML structure used in the schema provides a high-level view of how the elements and attributes are organized. This structure ensures that the policy is correctly interpreted and enforced by Application Control for Business. Policy Information This section includes metadata about the policy, such as its name, ID, version, and description. It provides essential information for identifying and managing different policies. SiPolicy Elements (Policy controls) Detailed descriptions of the elements that control the policy, such as rules for allowing or blocking applications. These elements define the core functionality of the policy. Rules Definitions of the various rules that can be applied within the policy, specifying what is allowed or denied. These rules are crucial for controlling application behavior. FileRules Specific rules related to files, including how they are identified and controlled. This section ensures that only trusted files are allowed to execute. Signers Information about the entities that sign the applications, ensuring they are trusted. This section is crucial for maintaining the integrity and trustworthiness of applications. SigningScenarios Different scenarios in which signing is used, providing context for when and how applications should be signed. This section helps ensure that signing practices are consistently applied. CiSigners Information about code integrity signers, who are responsible for ensuring the integrity of the code. This section is crucial for maintaining code integrity. Settings General settings for the policy, including various configuration options. These settings control the overall behavior of the policy. EKUs Extended Key Usages, which specify the purposes for which a certificate can be used. This section ensures that certificates are used appropriately. UpdatePolicySigners Information about the signers who are authorized to update the policy. This section ensures that only trusted entities can modify the policy. HVCIOptions Detailed descriptions of the hypervisor-protected code integrity options. These details define the characteristics and configurations of each option. Macros Definitions of macros used within the policy, allowing for reusable configurations. This section provides flexibility and efficiency in policy management. SupplementalPolicySigners Information about additional signers who can supplement the main policy. This section ensures that the policy can be extended and updated as needed. SupplementalPolicySigners Elements and Attributes Application Control for Business Schema The ACfB schema, as defined in the provided file (CiPolicy.xsd), is a comprehensive XML schema that outlines the structure and rules for creating and managing security policies within the Application Control for Business framework. This schema includes various elements and attributes that specify how policies are constructed, validated, and enforced. Key components of the schema include definitions for file rules, signers, signing scenarios, and policy settings, each with specific attributes and nested elements that provide detailed control over the security configurations. The primary purpose of the ACfB schema is to enhance the security posture of Windows environments by ensuring that only trusted and verified code is allowed to execute. By defining rules for allowing or denying specific files, managing trusted signers, and specifying conditions under which certain policies apply, the ACfB schema helps administrators create granular and flexible security policies. These policies protect against unauthorized code execution, maintain system integrity, and ensure compliance with organizational security standards. Application Control Bypass ACfB provides the ability to lock down endpoints effectively, but there are some potential bypasses that need to be addressed. Certain legitimate applications, such as powershell.exe, msbuild.exe, and wscript.exe, can be exploited by attackers to circumvent these controls. Blocking these applications is recommended unless they are absolutely necessary for business operations. Additionally, keeping software up to date is crucial to mitigate vulnerabilities. For instance, older versions of BGInfo are vulnerable and should be blocked, while the latest version has resolved these security issues. The security community has been instrumental in identifying these vulnerabilities and helping to protect users. Following these recommendations is vital to ensure our systems remain secure. For complete details, please refer to the full article on Microsoft's website: Applications that can bypass App Control and how to block them | Microsoft Learn XML Structure Overview An ACfB policy XML file consists of several key sections: Policy Information: Metadata about the policy. Rules: Definitions of what is allowed or denied. File Rules: Specific rules for files and applications. Signing Rules: Rules for signed applications and drivers. Policy Information The <SiPolicy> Root Element is used to define the overall security policy for the system. This element encompasses various configurations and settings that dictate how the security policy is enforced. It includes details such as policy type, policy rules, and other critical parameters that ensure the integrity and security of the system. By configuring <SiPolicy>, organizations can establish a comprehensive security framework that governs the behavior of applications and code execution on the system. SiPolicy |----- Attributes | |----- FriendlyName | |----- PolicyType | |------------------------ "Base Policy" | |------------------------ "Supplemental Policy" | |------------------------ "AppID Tagging Policy" | |----- Elements |----- VersionEx *1, *2 |----- PolicyTypeID *2 |----- PlatformID *1, *2 |----- PolicyID * 2 |----- BasePolicyID *2 |----- Rules |----- Rule |----- EKUs |----- FileRules |----- Signers |----- SigningScenarios |----- UpdatePolicySigners |----- CiSigners |----- HvciOptions |----- Settings |----- Macros |----- SupplementalPolicySigners |----- AppSettings *1 - Required *2 - These elements are used for defining and managing the ACfB policies on an endpoint. SiPolicy Elements (Policy controls) Element Names Description VersionEx Specifies the extended version of the policy. PolicyTypeID Used to uniquely identify and manage different types of polices PolicyID The unique identifier for the policy. BasePolicyID The GUID of the base policy, if applicable. PlatformID The identifier for the platform the policy applies to. <SiPolicy> <VersionEx>1.0.3.0</VersionEx> <PolicyID>{31351756-3F24-4963-8380-4E7602335AAE}</PolicyID> <BasePolicyID>{31351756-3F24-4963-8380-4E7602335AAE}</BasePolicyID> <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID> <!-- Other policy elements here --> </SiPolicy> There are a total of 17 sub-elements available under <SiPolicy> in a ACfB policy XML file. Element Names Description Notes <VersionEx> Specifies the version of the System Integrity policy. Required <PolicyTypeID> Unique identifier for the policy type. <PlatformID> Unique identifier for the platform. Required <PolicyID> Unique identifier for the policy. <BasePolicyID> Unique identifier for the base policy. <Rules> The <Rules> sub-element is used to define various options and settings related to the rules enforced by the policy. These options can include configurations such as enabling or disabling specific rule types, setting enforcement levels, and other parameters that control how the rules are applied. By configuring <RulesOptions>, organizations can fine-tune the behavior of their security policies to meet specific requirements and ensure that the rules are enforced in a manner that aligns with their security objectives. Contains a sequence of <Rule> elements defining various policy rules. <EKUs> The <EKUs> element defines Extended Key Usage (EKU) settings for the ACfB policy. EKUs specify the purposes for which a certificate can be used, such as code signing or server authentication. This element can include multiple EKU definitions, each specified within an <EKU> element. By defining EKUs, administrators can ensure that only certificates with the appropriate usage attributes are trusted, providing an additional layer of security for the system. Collection of Extended Key Usage (EKU) elements. FileRules The <FileRules> element specifies how applications and drivers are identified and allowed or denied. This element can include rules based on file attributes, hashes, paths, publishers, and certificates. For example, you can allow a specific file by its hash or allow all files in a particular directory. The flexibility of <FileRules> allows administrators to create granular policies that precisely control which files are permitted to execute, enhancing the security posture of the system. Collection of file rules. Signers The <Signers> element defines trusted signers for applications and drivers. This element can include various types of signers, such as FilePublisher, LeafCertificate, PcaCertificate, and RootCertificate. Each signer type specifies different levels of trust, from individual files to entire certificate chains. By defining trusted signers, administrators can ensure that only applications and drivers signed by recognized entities are allowed to run, reducing the risk of malware and unauthorized software. Collection of signers. SigningScenarios The <SigningScenarios> element specifies different scenarios under which signing rules apply. This element can include scenarios for drivers, Windows components, and other specific use cases. Each scenario is defined within a <SigningScenario> element, which includes details such as the scenario value, ID, and friendly name. By defining signing scenarios, administrators can create policies that apply different rules based on the context in which an application or driver is executed, providing more nuanced control over software execution. Collection of signing scenarios. UpdatePolicySigners The <UpdatePolicySigners> element defines signers that are trusted to update the ACfB policy. This element can include various types of signers, such as FilePublisher, LeafCertificate, PcaCertificate, and RootCertificate. By specifying trusted update policy signers, administrators can ensure that only authorized entities can modify the ACfB policy, preventing unauthorized changes that could compromise the security of the system. Collection of signers for system integrity policy updating. CiSigners The <CiSigners> element defines Code Integrity signers that are trusted for all builds, including retail builds. This element is typically used to include enterprise signers or production signers that are trusted across the organization. By specifying trusted Code Integrity signers, administrators can ensure that only code signed by recognized entities is allowed to run, enhancing the overall security of the system. Collection of signers trusted for CI signing levels. HvciOptions Hypervisor-Protected Code Integrity (HVCI) leverages virtualization-based security (VBS) to ensure that only trusted code runs in kernel mode Specifies (HVCI) settings. Settings The <Settings> element includes additional settings for the ACfB policy. This element can define various configuration options, such as policy information, enterprise-defined settings, and other custom settings. Each setting is specified within a <Setting> element, which includes details such as the provider, key, value name, and value. By configuring these settings, administrators can customize the behavior of the ACfB policy to meet the specific needs of their organization. Collection of setting elements. Macros The <Macros> element defines a collection of macro definitions that can be used throughout the policy. Macros allow for text substitution, making it easier to manage and update policy configurations. Each macro is defined within a <Macro> element, which includes an ID and a value. By using macros, administrators can simplify the policy management process and ensure consistency across different policy elements. Collection of macro definitions. SupplementalPolicySigners The <SupplementalPolicySigners> element defines a collection of signers for supplemental policies. These signers are trusted to sign additional policies that extend or modify the base policy. By specifying supplemental policy signers, administrators can ensure that only authorized entities can create or update supplemental policies, maintaining the integrity and security of the overall policy framework. Collection of signers for supplemental policies. AppSettings The <AppSettings> element defines a collection of application settings. These settings can include various configuration options specific to applications, such as manifest paths and custom settings. Each application setting is defined within an <App> element, which includes details such as the manifest path and individual settings. By configuring application settings, administrators can tailor the behavior of specific applications to meet organizational requirements. Collection of application settings. Rules The <Rules> sub-element is used to organize and manage various rules within the policy. It contains a sequence of <Rule> elements, each defined by the Rules complex type. These rules specify configurations such as enabling or disabling specific options, setting enforcement levels, and other parameters that control how the rules are applied. By configuring the <Rules> sub-element, organizations can fine-tune the behavior of their security policies to meet specific requirements and ensure that the rules are enforced in a manner that aligns with their security objectives. Rules |------ Rule |------ RuleType |------ Option |------ Enabled:UMCI |------ Enabled:Boot Menu Protection |------ Enabled:Intelligent Security Graph Authorization |------ Enabled:Invalidate EAs on Reboot |------ Required:WHQL |------ Enabled:Developer Mode Dynamic Code Trust |------ Enabled:Allow Supplemental Policies |------ Disabled:Runtime FilePath Rule Protection |------ Enabled:Revoked Expired As Unsigned |------ Enabled:Audit Mode |------ Disabled:Flight Signing |------ Enabled:Inherit Default Policy |------ Enabled:Unsigned System Integrity Policy |------ Enabled:Dynamic Code Security |------ Required:EV Signers |------ Enabled:Boot Audit On Failure |------ Enabled:Advanced Boot Options Menu |------ Disabled:Script Enforcement |------ Required:Enforce Store Applications |------ Enabled:Secure Setting Policy |------ Enabled:Managed Installer |------ Enabled:Update Policy No Reboot |------ Enabled:Conditional Windows Lockdown Policy Rules Options Option Types Description Enabled:UMCI Enables User Mode Code Integrity (UMCI), ensuring that only trusted code runs in user mode. Enabled:Boot Menu Protection Enables protection for the boot menu, preventing unauthorized changes to boot configurations. Enabled:Intelligent Security Graph Authorization Utilizes the Intelligent Security Graph to authorize applications, enhancing security by leveraging Microsoft's threat intelligence. Enabled:Invalidate EAs on Reboot Invalidates Extended Attributes (EAs) on reboot, ensuring that any changes to EAs are not persistent across reboots. Required:WHQL Requires that drivers are Windows Hardware Quality Labs (WHQL) certified, ensuring they meet Microsoft's quality standards. Enabled:Developer Mode Dynamic Code Trust Enables dynamic code trust for developer mode, allowing developers to run and test code that may not be signed. Enabled:Allow Supplemental Policies Allows the use of supplemental policies, which can extend or modify the base policy. Disabled:Runtime FilePath Rule Protection Disables runtime protection for file path rules, potentially reducing security but allowing more flexibility. Enabled:Revoked Expired As Unsigned Treats revoked or expired certificates as unsigned, preventing code signed with such certificates from running. Enabled:Audit Mode Enables audit mode, which logs policy violations without enforcing them, useful for testing and monitoring. Disabled:Flight Signing Disables flight signing, which is used for pre-release software testing. Enabled:Inherit Default Policy Allows the policy to inherit settings from the default policy, ensuring consistency and reducing configuration effort. Enabled:Unsigned System Integrity Policy Enables the use of unsigned system integrity policies, which can be useful in certain testing or development scenarios. Enabled:Dynamic Code Security Enhances security by enabling dynamic code security measures, which help protect against runtime code modifications. Required:EV Signers Requires Extended Validation (EV) certificates for code signing, providing a higher level of trust. Enabled:Boot Audit On Failure Enables auditing of boot failures, helping to diagnose and troubleshoot boot issues. Enabled:Advanced Boot Options Menu Enables the advanced boot options menu, providing additional boot options for troubleshooting and recovery. Disabled:Script Enforcement Disables enforcement of script policies, allowing scripts to run without being subject to policy restrictions. Required:Enforce Store Applications Requires that only applications from the Microsoft Store are allowed to run, enhancing security by restricting software sources. Enabled:Secure Setting Policy Enables secure setting policies, which enforce additional security settings. Enabled:Managed Installer Allows the use of a managed installer, which can install and manage applications according to policy. Enabled:Update Policy No Reboot Enables policy updates without requiring a reboot, reducing downtime and improving user experience. Enabled:Conditional Windows Lockdown Policy Enables conditional lockdown policies, which can enforce stricter security measures based on certain conditions. <!-- Other policy elements here --> <Rules> <Rule> <Option>Enabled:Unsigned System Integrity Policy</Option> </Rule> <Rule> <Option>Enabled:Advanced Boot Options Menu</Option> </Rule> Rule> <Option>Disabled:Script Enforcement</Option> </Rule> </Rules> <!-- Other policy elements here --> FileRules The <FileRules> sub-element is used to define various options and settings related to file rules enforced by the policy. These options can include configurations such as specifying file types to be monitored, setting enforcement levels for different file operations, and other parameters that control how file rules are applied. By configuring <FileRules>, organizations can customize the behavior of their file security policies to meet specific requirements and ensure that file operations are monitored and controlled in a manner that aligns with their security objectives. FileRules |------ Allow | |-------- ID *1 | |-------- FriendlyName | |-------- FileName | |-------- InternalName | |-------- FileDescription | |-------- ProductName | |-------- PackageFamilyName | |-------- PackageVersion | |-------- MinimumFileVersion | |-------- MaximumFileVersion | |-------- Hash | |-------- AppIDs | |-------- FilePath | |------ Deny | |-------- ID *1 | |-------- FriendlyName | |-------- FileName | |-------- InternalName | |-------- FileDescription | |-------- ProductName | |-------- PackageFamilyName | |-------- PackageVersion | |-------- MinimumFileVersion | |-------- MaximumFileVersion | |-------- Hash | |-------- AppIDs | |-------- FilePath | |------ FileAttrib | |-------- ID *1 | |-------- FriendlyName | |-------- FileName | |-------- InternalName | |-------- FileDescription | |-------- ProductName | |-------- PackageFamilyName | |-------- PackageVersion | |-------- MinimumFileVersion | |-------- MaximumFileVersion | |-------- Hash | |-------- AppIDs | |-------- FilePath | |------ FileRule |-------- ID *1 |-------- FriendlyName |-------- FileName |-------- InternalName |-------- FileDescription |-------- ProductName |-------- PackageFamilyName |-------- PackageVersion |-------- MinimumFileVersion |-------- MaximumFileVersion |-------- Hash |-------- AppIDs |-------- FilePath |-------- Type *1 |------------------- "Match" |------------------- "Exclude" |------------------- "Attribute" *1 = Required FileRules Elements and Attributes There are 4 elements and 13 attributes available for FileRules. The elements specify how applications and drivers are identified and allowed or denied based on various attributes within the ACfB policy. The attributes allow administrators to specify criteria based on various properties of files, such as their cryptographic hash, file name, file path, publisher's certificate, and more. This ensures that only trusted and verified files are permitted to execute Element Names Attribute Names Description Allow Deny FileAttrib FileRule AppIDs Application IDs associated with the file, used for additional identification and management. FileDescription A description of the file, providing more context about its purpose and usage. FileName Specifies the name of the file to allow. Ensures that only files with this exact name are permitted to run. FilePath Specifies the path of the file to allow. Ensures that only files located in this specific path are permitted to run. FriendlyName A user-friendly name for the rule, making it easier to identify and manage. Hash Specifies the cryptographic hash of the file to allow. Provides a high level of security by ensuring that only the exact file with this hash is permitted to run. ID Unique identifier for the rule. (Required) InternalName The internal name of the file, often used for additional verification. MaximumFileVersion Specifies the maximum version of the file to allow. Prevents the execution of potentially outdated or insecure versions. MinimumFileVersion Specifies the minimum version of the file to allow. Ensures that only updated and secure versions are permitted. PackageFamilyName The package family name for the file, used to group related files together. PackageVersion The version of the package that the file belongs to, ensuring compatibility and version control. ProductName The name of the product associated with the file, helping to identify the software it belongs to. FileRule (only) Type Specifies the type of rule being applied, such as Match, Exclude, or Attribute. This attribute defines the condition under which the rule applies, allowing for precise control over how files are identified and managed. (Required) <!-- Other policy elements here --> <FileRules> <FileAttrib ID="ID_FILEATTRIB_A_1" FriendlyName="Allow files based on file attributes: 16.0.18429.20114 and WinWord.exe" FileName="*" MinimumFileVersion="16.0.18429.20114"/> <Allow ID="ID_ALLOW_PATH_0_1_0" FriendlyName="Allow by path: %OSDRIVE%\Program Files\PuTTY\putty.exe" FilePath="%OSDRIVE%\Program Files\PuTTY\putty.exe"/> <Deny ID="ID_DENY_PATH_0_1_0" FriendlyName="Deny by path: %OSDRIVE%\Program Files\Notepad++\notepad++.exe" FilePath="%OSDRIVE%\Program Files\Notepad++\notepad++.exe"/> <Allow ID="ID_ALLOW_A_1_1_0" FriendlyName="Allow files based on file attributes: Google Chrome" FileDescription="Google Chrome"/> </FileRules> <!-- Other policy elements here --> Signers The <Signers> sub-element is a collection of <Signer> elements that are trusted to sign applications and drivers. It includes various sub-elements that define the details of each signer. These options can include configurations such as specifying the criteria for trusted signers, setting validation levels for signer certificates, and other parameters that control how signers are managed and verified. By configuring <Signers>, organizations can ensure that only authorized and trusted signers are allowed, enhancing the security and integrity of the system by preventing unauthorized code from being executed. Sub-element:<Signer> of <Signers> The <Signer> sub-element defines an individual signer and includes several attributes and nested elements that specify the details of the signer's certificate and other relevant information. Signers |------ Signer |------ Attributes | |------ Name | |------ ID | |------ SignTimeAfter | |------ Certroot *1 | |------ Attribute | |------ Type *1 | |----- "TBS" | |----- "WellKnown" | | |------ Value *1 |------ CertEKU | |------ Attribute | |------ ID *1 |------ CertIssuer | |------ Attribute | |------ Value *1 |------ CertPublisher | |------ Attribute | |------ Value *1 |------ CertOemID | |------ Attribute | |------ Value *1 |------ FileAttribRef |------ Attribute |------ RuleID *1 *1 = Required Signers Elements and Attributes Element Names Attribute Names Description Signers A collection of Signer elements that define individual signers trusted to sign applications and drivers. Signer Name Specifies the name of the signer. ID Unique identifier for the signer. SignTimeAfter Specifying the time after which the signer's certificate is valid. CertRoot Type Specifies the root certificate for a signer. (Required) Value Specifies the value of the root certificate in hexBinary form. CertEKU ID Specifies the EKU ID. CertIssuer Value Specifies the value of the issuer certificate. CertPublisher Value Specifies the value of the publisher certificate. CertOemID Value Specifies the value of the OEM ID. FileAttribRef RuleID References a file attribute rule through its ID. <!-- Other policy elements here --> <FileRules> <FileAttrib ID="ID_FILEATTRIB_A_2" FriendlyName="Allow files based on file attributes: 132.0.6834.111 and chrome.exe" FileName="*" MinimumFileVersion="132.0.6834.111"/> <FileAttrib ID="ID_FILEATTRIB_A_1_1_0" FriendlyName="Deny files based on file attributes: 21.4.7.25431 and SNAGIT32.EXE" FileName="*" MinimumFileVersion="21.4.7.25431"/> </FileRules> <Signers> <Signer Name="DigiCert Trusted Root G4" ID="ID_SIGNER_S_1_0_0"> <CertRoot Type="TBS" Value="11533EFD6B326A4E065A936DE300FE0586A479F93D569D2403BD62C7AD35F1B2199DAEE3ADB510F429C4FC97B4B024E3"/> <CertPublisher Value="Google LLC"/> <FileAttribRef RuleID="ID_FILEATTRIB_A_2"/> </Signer> <Signer Name="DigiCert EV Code Signing CA (SHA2)" ID="ID_SIGNER_S_1_1_0"> <CertRoot Type="TBS" Value="EEC58131DC11CD7F512501B15FDBC6074C603B68CA91F7162D5A042054EDB0CF"/> <CertPublisher Value="TechSmith Corporation"/> <FileAttribRef RuleID="ID_FILEATTRIB_A_1_1_0"/> </Signer> </Signers> <!-- Other policy elements here --> SigningScenarios The <SigningScenarios> element is used to define the different scenarios in which code signing is required or trusted. These scenarios specify the conditions under which code must be signed to be considered valid and executable. By configuring <SigningScenarios>, organizations can enforce code signing policies that ensure only authorized and trusted code is allowed to run. This helps in maintaining the integrity and security of the system by preventing the execution of unauthorized or malicious code. SigningScenarios | SigningScenario |---------- Attributes | |---------- ID *1 | |---------- FriendlyName | |---------- Value *1 | |---------- InheritedScenarios | |---------- MinimumHashAlgorithm | |---------- ProductSigners *1 | |---------- AllowedSigners | | |--------------- Attributes | | | |--------- Workaround | | | | | |--------------- AllowedSigner | | |--------- Attributes | | | |------- SignerId | | | | | |--------- ExceptDenyRule | | |------- Attributes | |---------- DeniedSigners |------- DenyRuleId | | |--------------- Attributes | | | |--------- Workaround | | | | | |--------------- DeniedSigner | | |--------- Attributes | | | |------- SignerId | | | | | |--------- ExceptAllowRule | | |------- Attributes | |---------- FileRulesRef |------- AllowRuleId | |--------------- Atributes | | |--------- Workaround | | | |--------------- FileRuleRef | |--------- RuleId | |---------- TestSigners | |---------- AllowedSigners | | |--------------- Attributes | | | |--------- Workaround | | | | | |--------------- AllowedSigner | | |--------- Attributes | | | |------- SignerId | | | | | |--------- ExceptDenyRule | | |------- Attributes | |---------- DeniedSigners |------- DenyRuleId | | |--------------- Attributes | | | |--------- Workaround | | | | | |--------------- DeniedSigner | | |--------- Attributes | | | |------- SignerId | | | | | |--------- ExceptAllowRule | | |------- Attributes | |---------- FileRulesRef |------- AllowRuleId | |--------------- Atributes | | |--------- Workaround | FileRuleRef | |--------------- Atributes | | |--------- Workaround | | | |--------------- FileRuleRef | |--------- RuleId | |---------- TestSigningSigners | |---------- AllowedSigners | | |--------------- Attributes | | | |--------- Workaround | | | | | |--------------- AllowedSigner | | |--------- Attributes | | | |------- SignerId | | | | | |--------- ExceptDenyRule | | |------- Attributes | |---------- DeniedSigners |------- DenyRuleId | | |--------------- Attributes | | | |--------- Workaround | | | | | |--------------- DeniedSigner | | |--------- Attributes | | | |------- SignerId | | | | | |--------- ExceptAllowRule | | |------- Attributes | |---------- FileRulesRef |------- AllowRuleId | |--------------- Atributes | | |--------- Workaround | FileRuleRef | |--------------- Atributes | | |--------- Workaround | | | |--------------- FileRuleRef | |--------- RuleId | |---------- AppIDTags |---------- Attributes | |--------------- EnforceDLL | |---------- AppIDTag |--------------- Attributes |--------- Key |--------- Value *1 = Required SigningScenarios Elements and Attributes Element Names Nested Elements Attribute Name Description SigningScenarios ID A unique identifier for the signing scenario. FriendlyName Helps in easily identifying and managing the signing scenario. InheritedScenarios Allows the signing scenario to inherit rules and settings from other defined scenarios, promoting reuse and consistency. MinimumHashAlgorithm Ensures that only cryptographic hashes meeting the specified algorithm criteria are considered valid. Value Required and defines the specific context or condition under which the signing scenario applies. ProductSigners, TestSigners, TestSigningSigners AllowedSigners WorkAround Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges. AllowedSigner SignerId Each signer can be distinctly recognized and referenced within the ACfB policy, allowing for precise control over which signers are trusted or denied. AllowedSigner/ExceptDenyRule DenyRuleId Used in the ExceptDenyRule element to reference a specific deny rule, making the allow rule conditional based on the deny rule. DeniedSigners WorkAround Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges. DeniedSigner SignerId Used in the AllowedSigner and DeniedSigner elements to distinctly recognize and reference each signer. DeniedSigner/ExceptAllowRule AllowRuleId Specification of the AllowRuleId. FileRulesRef Workaround Provides flexibility in handling specific scenarios or exceptions that may not be directly addressed by the standard schema definitions, allowing for customized solutions to unique challenges. FileRuleRef RuleId Specifies the ID of the file rule. AppIDTags EnforceDLL If enabled ensures that only trusted DLLs are allowed to load. AddIDTag Key Specifies the key for the application ID tag. Value Specifies the value for the application ID tag. CiSigners <CiSigners> are signers that ConfigCI asks CI to trust for all builds, including retail builds. Normally CiSigners is empty or only includes production signers. For enterprise ConfigCI policy, you may need to include enterprise signers. Just make sure it is understood that CiSigners will be trusted by CI for ALL builds. CiSigners |------ CiSigner *1 |------ Attribute |------ SignerId *1 = Required Element Names Attribute Names Description CiSigners A collection of CiSigner elements. CiSigner SignerId To distinctly recognize and reference each signer within the ACfB policy. <cisigner /> CiSigners Elements and Attributes <!-- Other policy elements here --> <CiSigners> <CiSigner SignerId="ID_SIGNER_STORE"/> </CiSigners> <!-- Other policy elements here --> Settings The <Settings> sub-element is used to define various configuration settings for the policy. These settings can include options such as enabling or disabling specific features, setting enforcement levels, and other parameters that control the behavior of the policy. By configuring <Settings>, organizations can customize the policy to meet their specific security requirements and operational needs. This helps in ensuring that the policy is applied in a manner that aligns with the organization's security objectives and operational practices. Settings |----- Setting |----- Attribute | |----- Provider *1 | |----- Key *1 | |----- ValueName *1 | |----- Value |----- SettingValueType *1 |------------ BooleanType |------------ DWordType |------------ xs:hexBinary |------------ xs:string *1 = Required Settings, Elements, Attributes and SettingValueType Element Names Attribute Names Description Settings Collection of Setting(s). Setting Provider Specifies the source or context of the setting. Required Key Defines the category or type of information the setting pertains to. Required ValueName Specifies the name of the specific value being set. Required Setting/Value/SettingValueType Required BooleanType Represents a Boolean value, which can be either true or false. DWordType Represents a double word (32-bit unsigned integer) value. xs:hexBinary Represents binary data encoded as hexadecimal. xs:string Represents a sequence of characters. <!-- Other policy elements here --> <Settings> <Setting Provider="AllHostIds" Key="{0468C085-CA5B-11D0-AF08-00609797F0E0}" ValueName="EnterpriseDefinedClsId"> <Value> <Boolean>true</Boolean> </Value> </Setting> <Setting Provider="PolicyInfo" Key="Information" ValueName="Name"> <Value> <String>DefaultMicrosoftEnforced</String> </Value> </Setting> <Setting Provider="PolicyInfo" Key="Information" ValueName="Id"> <Value> <String>022422</String> </Value> <!-- Other policy elements here --> EKUs The <EKUs> sub-element is used to define the Extended Key Usage (EKU) attributes for certificates. EKUs specify the purposes for which the certificate's public key can be used, such as code signing, server authentication, and client authentication. By specifying EKUs, organizations can ensure that certificates are only used for their intended purposes, enhancing security and trust in digital communications. EKUs |---- EKU |---- Attributes |------ ID *1 |------ Value *1 |------ FriendlyName *1 = Required EKUs Elements and Attributes Element Names Attribute Names Description EKUs Collection of EKU(s) EKU ID A unique identifier for the Extended Key Usage. Required Value Specifies the value of the EKU in hexBinary form. Required FriendlyName An optional user-friendly name for the EKU. <!-- Other policy elements here --> <EKUs> <EKU ID="ID_EKU_STORE" FriendlyName="Windows Store EKU - 1.3.6.1.4.1.311.76.3.1 Windows Store" Value="010a2b0601040182374c0301"/> </EKUs> <!-- Other policy elements here --> UpdatePolicySigners The <UpdatePolicySigners> sub-element is used to define the code signing certificates that are trusted for updating policy files. This ensures that only authorized entities can make changes to the policy, enhancing the security and integrity of the system. By specifying trusted signers, organizations can prevent unauthorized modifications and maintain control over policy updates. updatepolicysigners |--------- updatepolicysigner |--------- Attribute |----- SignerId UpdatePolicySigner Elements and Attributes Element Names Attribute Names Description UpdatePolicySigners Collection of UpdatePolicySigner(s) UpdatePolicySigner SignerId A unique identifier for the signer. This attribute ensures that each signer authorized to update the ACfB policy can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to make policy updates. <!-- Other policy elements here --> <UpdatePolicySigners> <UpdatePolicySigner> <SignerId>Example SignerId</SignerId> </UpdatePolicySigner> </UpdatePolicySigners> <!-- Other policy elements here --> HvciOptions The <HvciOptions> sub-element is used to define the Hypervisor-protected Code Integrity (HVCI) settings. Hypervisor-Protected Code Integrity (HVCI) leverages virtualization-based security (VBS) to ensure that only trusted code runs in kernel mode, providing an additional layer of protection against malware and other threats. HVCI uses the Windows hypervisor to create an isolated virtual environment that becomes the root of trust for the operating system. This isolated environment ensures that kernel mode code integrity checks are performed within a secure context, preventing unauthorized code from executing. This helps in preventing unauthorized code from executing, thereby maintaining the integrity and security of the operating environment. HVCIOptions Element Name Description HVCIOptions A friendly name for the HVCI option. The <HvciOptions> element expects a numeric value that represents the specific configuration settings. Here’s a detailed explanation: Possible Values for HvciOptions Enabled (Value: 1): Turns on HVCI, ensuring that only trusted code can run at the hypervisor level. Strict (Value: 2): Enforces stricter code integrity checks, providing an additional layer of security. DebugMode (Value: 4): Enables debugging features for HVCI, useful for development and troubleshooting. DisableAllowed (Value: 8): Allows HVCI to be disabled by the user outside of the Code Integrity policy enablement method. These values can be combined using bitwise OR operations to enable multiple settings simultaneously. <!-- Other policy elements here --> <HvciOptions>2</HvciOptions> <!-- Other policy elements here --> Macros A collection of macro definitions that can be used throughout the policy. Macros allow for text substitution, making it easier to manage and update policy configurations by using predefined values. Each macro is defined within a Macro element, which includes an ID and a value. By using macros, administrators can simplify the policy management process and ensure consistency across different policy elements. Macros |----- Macro | |----- Attributes | | |----- Id *1 | | |----- Value *1 | | | |----- Annotations | |------- Documentation | |--------- (A Macro element defines a text substitution macro that can be used in other elements. Macros are referenced using NMAKE syntax, i.e. $(runtime.windows).) | |--------- (Required. The Id for this macro, used in macro references. For example, if the Id for this macro is "runtime.windows", the macro would be referenced as $(runtime.windows).) | |--------- (Required. The value that will be substituted for macro references in macro-enabled XML attributes.) | |----- UniqueMacroId |---------------- Selector (xpath="ps:Macro") |---------------- Field (xpath="@Id") *1 = Required Macros Elements and Constraints Element Names Attribute Names Description Macro Id Used in macro references, allowing the macro to be called by its ID in other elements, ensuring consistency and ease of management. Required Value Specifies the text to be substituted for macro references. This ensures that the defined value is consistently used wherever the macro is referenced, simplifying updates and maintenance. Required “Macros” Constraints UniqueMacroId Specifies the unique constraint's name, which in this case is UniqueMacroId. It ensures that each macro ID within the Macros element is unique, preventing duplication. Selector Defines the XPath expression used to select the elements to which the unique constraint applies. In this case, it selects the Macro elements within the Macros element. Field Specifies the field within the selected elements that must be unique. Here, it ensures that the Id attribute of each Macro element is unique within the Macros element. SupplementalPolicySigners The <SupplementalPolicySigners> element defines a collection of signers that are trusted to sign supplemental policies. Supplemental policies are additional policies that extend or modify the base policy, allowing for more granular and flexible control over application execution. The <SupplementalPolicySigners> element ensures that only authorized entities can create or update these supplemental policies, maintaining the integrity and security of the overall policy framework SupplementalPolicySigners |---------------- SupplementalPolicySigner |---------------- Attributes |------- SignerId *1 *1 = Required SupplementalPolicySigners Elements and Attributes Element Names Attribute Names Description SupplementalPolicySigner Collection of Collection of SupplementalPolicySigner(s) SignerId A unique identifier for the signer. Ensures that each signer authorized to sign supplemental policies can be distinctly recognized and referenced, allowing for precise control over which signers are trusted to create or update supplemental policies Required Schema Definition (CiPolicy.xsd - 1/27/2025) and location The current schema definition can be found on a Windows 11 device at: C:\Windows\schemas\CodeIntegrity\cipolicy.xsd ACfB Example Policy locations On Windows 11, ACfB example policies are saved in the following locations: DefaultWindows_*.xml: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_*.xml %ProgramFiles%\WindowsApps\Microsoft.AppControl.WDACWizard*\DefaultWindows_Audit.xml AllowMicrosoft.xml: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowMicrosoft.xml %ProgramFiles%\WindowsApps\Microsoft.AppControl.WDACWizard*\AllowMicrosoft.xml AllowAll.xml: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml AllowAll_EnableHVCI.xml: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml DenyAllAudit.xml: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DenyAllAudit.xml SmartAppControl.xml: %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml These example policies can be used as a starting point to create custom policies for your organization's needs. By implementing a well-structured and ordered schema, organizations can create a secure and efficient environment, much like how Raven's schema keeps her safe and happy in our backyard.Deploying Microsoft Defender for Identity
When Raven and I are out in my backyard, she's always on high alert, her keen senses picking up on every subtle change in her environment. Just like Raven, Microsoft Defender for Identity (MDI) is constantly on the lookout, sniffing out potential threats to your network. Whether it's an unusual login attempt or a suspicious movement within your system, MDI is there to detect and alert you to any signs of trouble. Raven's ability to sense danger is akin to MDI's advanced threat detection capabilities. She can differentiate between a harmless passerby and a potential predator, much like how MDI distinguishes between normal user behavior and potential security breaches. This vigilant monitoring ensures that any threat is identified and addressed before it can cause harm, keeping your network as safe as Raven keeps our home. Just as I trust Raven to protect us from unseen dangers, you can rely on MDI to safeguard your network from cyber threats. With its continuous monitoring and real-time alerts, MDI acts as your loyal guardian, always ready to spring into action at the first sign of trouble. The following blog will help you roll out MDI, whether you are new to MDI or a seasoned expert. So, as you enjoy the peace of mind that comes with having Raven by your side, you can also rest easy knowing that MDI is tirelessly working to keep your digital environment secure. Introduction to Microsoft Defender for Identity (MDI) Microsoft Defender for Identity (MDI) is a security solution designed to help protect your organization from advanced threats, compromised identities, and insider actions. By leveraging on-premises Active Directory signals, MDI provides comprehensive monitoring and analysis to detect suspicious activities and potential security breaches. This tool is essential for maintaining the integrity and security of your network infrastructure. Deploying MDI involves several critical steps, starting with a thorough performance and sizing review to ensure your Domain Controllers (DCs) can handle the additional load. The MDI agent collects and analyzes data from your DCs, which requires adequate processing power and network capacity. Proper planning and execution of this deployment will help you maximize the effectiveness of MDI in safeguarding your environment. This guide will walk you through the entire deployment process, from initial preparation to the final configuration. Whether you are an experienced administrator or new to MDI, this document provides the necessary information and resources to successfully deploy and manage Microsoft Defender for Identity in your organization. MDI Documentation Microsoft Defender for Identity documentation - Microsoft Defender for Identity | Microsoft Learn Monitored Activities Monitored activities - Microsoft Defender for Identity | Microsoft Learn Security alert name and mapping with MITRE https://learn.microsoft.com/en-us/defender-for-identity/alerts-overview#security-alert-name-mapping-and-unique-external-ids Integration with the XDR Portal Microsoft Defender for Identity in the Microsoft Defender portal - Microsoft Defender XDR | Microsoft Learn Note 1: MDI data is available for advanced hunting using KQL queries within the XDR portal. Note 2: The name of this product started out as Advanced Threat Analytics (ATA). The ATA reference may pop up, but it is now MDI. Deploying MDI This guide is designed to assist administrators who are deploying Microsoft Defender for Identity for the first time, using the new Defender for Identity PowerShell Module. Performance and Sizing Review Before deploying, it's crucial to ensure that your Domain Controllers (DCs) can handle the load imposed by the Defender for Identity (MDI) agent. To assist with this, Microsoft provides a load/performance testing tool. This sizing tool can be executed on either a desktop or a DC and must be run by a domain administrator. You can find the MDI sizing tool at the following locations: GitHub - microsoft/Microsoft-Defender-for-Identity-Sizing-Tool Plan capacity for deployment - Microsoft Defender for Identity | Microsoft Learn The tool should be run 24 hours to capture data from all DCs globally. It only needs to be executed on a single device, and the results will be compiled into a single .xlsx file. To run the sizing tool against a single domain, extract the tool and use the following command in a command prompt, after navigating to the directory where the tool is located: C:\temp\TriSizingTool.exe -UseCurrent=UserDomain The screen grabs below are from a simple domain within my lab environment, providing a sample of what the output file looks like (with 2 tabs). The tool only ran for a couple of hours, so the sample size is smaller than recommended. ATA Summary tab can be ignored. Azure ATP Summary tab Please walk through the findings and identify any recommendations within the Azure ATP summary tab. Make adjustments where necessary. Enabling Defender for Identity within the XDR Portal The first time an administrator browses to the “Identities” section: They will get an error on the Dashboard Browse to System > Settings Identities This will bring up a screen notifying the administrator the environment is now being configured. Once complete, you should see a Defender for Identity configuration page. Prerequisites Once the hardware is confirmed to be sufficient, configuration changes need to be made. Initially, deploying Microsoft Defender for Identity (MDI) required multiple configuration changes, which increased the risk of human error. However, the recent release of a PowerShell module for MDI has greatly simplified this process. Manual configuration of the Active Directory Domain Services (AD DS) environment involves numerous steps. As the complexity of these steps increases, so does the potential for human error. Utilizing the PowerShell module can help mitigate these risks by streamlining the configuration process. Prerequisites - Microsoft Defender for Identity | Microsoft Learn Configure audit policies for Windows event logs - Microsoft Defender for Identity | Microsoft Learn MDI PowerShell Module Introducing the new PowerShell Module for Microsoft Defender for Identity PowerShell Gallery | DefenderForIdentity 1.0.0.2 DefenderForIdentity Module | Microsoft Learn Note: To use the MDI PowerShell module, it must be run on a server or Domain Controller with both the Active Directory and Group Policy modules installed. This new module simplifies the configuration of auditing and permissions within your environment, automating the entire process for the administrator. The steps outlined in this process are designed for a single domain. Install-Module DefenderforIdentity After downloading and installing the PowerShell module, the administrator should import it using the following command: Import-Module DefenderForIdentity Once the module is imported, the administrator can test the AD DS environment for MDI readiness. From an administrator PowerShell command line, run: New-MDIConfigurationReport -Path C:\Temp -OpenHtmlReport Note: If you are prompted for the Identity name, this is the Identity to be used to run the installed sensor. This will generate an HTML report. Now that a report has been generated, there are a number of PowerShell commands for the DefenderForIdentity module. This list can be found from the link above, or you can just run a get-command for a list. Get-Command -module DefenderForIdentity Service Account Creation and Installation Even though the example above reports that changes need to be made, it doesn't account for the user or service account that will be used. Using a user account with elevated permissions is discouraged. Instead, a group Managed Service Account (gMSA) with limited permissions is recommended. The only permissions needed are: Read Only for Active Directory Read Only for Deleted Objects Container In the first example, I ran a test against my Domain Administrator account. Notice that there are two "False" returns; ideally, everything should be set to "True" when running the specific test for the identity. Test-MdiDSA -Identity pbbergs -verbose -detailed While it's possible to set up a group Managed Service Account (gMSA) manually, using the DefenderForIdentity PowerShell cmdlet ensures that all configuration settings are completed correctly. This cmdlet also creates a group that grants Domain Controllers the ability to access the gMSA password. New-MDIDSA -Identity “gMSA-MDI” -GmsaGroupName “gMSA-MDI-Grp” -Verbose Once I set up a new gMSA account, I re-ran the Identity test. As shown below, the gMSA account is not overly privileged and passes the test. https://learn.microsoft.com/en-us/defender-for-identity/deploy/create-directory-service-account-gmsa#prerequisites-grant-permissions-to-retrieve-the-gmsa-accounts-password Note: If you plan on using Active Directory Federation Services (ADFS) or Active Directory Certificate Services (ADCS), the security group created in the previous step will need to include the ADFS and/or ADCS servers. Next, the gMSA identity needs to be added to the Identity blade within the XDR portal. Security.microsoft.com > Settings > Identities > General > Directory Service Accounts Click on “+ Add Credentials” Complete the Information to update the new Identity Click “Save” The portal is now ready to accept Domain Controllers, ADFS and/or ADCS servers. Validate the Network Infrastructure Before deploying the sensor, it's important to complete tests to ensure that the sensors can communicate with Azure and its logging engine. To facilitate this, we can use the new PowerShell cmdlet from the MDI PowerShell module, Test-MDISensorApiConnection. Test-MDISensorApiConnection (DefenderForIdentity) | Microsoft Learn Before running the PowerShell command, you will need to know the “WorkspaceName” since this is used within the parameter “-SensorApiURL”. It is built via the following: "https://<your_workspace_name>sensorapi.atp.azure.com" To find “your_workspace_name” XDR portal > Settings > Identities > General > About If the device has the MDI sensor installed, then the -BypassConfiguration is not needed. The parameter then is concatenated to the result of: https://mngenvmcap99999sensorapi.atp.azure.com To complete the validation test Bring up an administrative PowerShell command box o Enter Test-MDISensorApiConnection -Verbose -SensorApiUrl https://mngenvmcap99999sensorapi.atp.azure.com -BypassConfiguration The result should return a value of “True” if the device has access to Azure. If the device has the MDI sensor installed, then the -BypassConfiguration is not needed. Configuration Changes to Prepare for the Deployment of the MDI Sensor Let’s do a test of the auditing settings of the domain. This can be completed by running: Test-MDIConfiguration -Mode Domain -Configuration NTLMAuditing If we look at the Active Directory Group policy GUI, we can see that there are no policies in place for MDI at this time within the domain. We could manually go in and build the policies needed -or- we could use the Set-MDIConfiguration and let the PowerShell cmdlet do the work for us. There are other configuration settings that can also be configured which include: ADFSAuditing AdvancedAuditPolicyCAs AdvancedAuditPolicyDCs CAAuditing ConfigurationContainerAuditing DomainObjectAuditing NTLMAuditing ProcessorPerformance All (The complete list from the above bullets) Configuring the Power Option to High Performance One of the MDI PowerShell Module options (If used) can change the Domain Controller’s Power Option to “High Performance” via GPO. This is recommended for optimal performance when running the MDI sensor. Updating the Auditing Configuration of the Active Directory Environment Instead of changing these configurations one at a time, the “All” setting can be used which will configure the environment and build the GPOs as needed. Set-MDIConfiguration -Mode Domain -Configuration All -Identity gMSA-MDI -verbose Note: In my environment I don’t have Exchange, ADFS or Certificate Services installed. Taking another look at the Group policy shows that there is now a complete set of policies in place for auditing. Notice that the system isn’t aware of whether or not a CA is installed so it added a CA policy to the base of the domain. If you aren’t using a CA these can be left as is or the link removed from the root of the domain. Lateral Movement detection via SAM-R has been removed Configuring Detection for Lateral Movement The “Microsoft Defender for Identity – Remote SAM Access” isn’t linked to the root of the domain by default, this is an administrator’s choice. This helps with the discovery of potential lateral account movement. As you read the Note below, this is no longer an issue with the newest version of the MDI sensor. Configure SAM-R to enable lateral movement path detection - Microsoft Defender for Identity | Microsoft Learn One of the requirements for using this Group Policy Object (GPO) is to not grant the “Network access: Restrict clients allowed to make remote calls to SAM” setting to the “Domain Controllers” Organizational Unit (OU). When the PowerShell command Set-MDIConfiguration -Mode Domain -Configuration All -Identity gMSA-MDI -Verbose was run, it created and configured the GPO named “Microsoft Defender for Identity – Remote SAM Access.” This GPO is designed to be linked to the root of the domain and to “Deny”, “Apply group policy” on the “Domain Controllers” group. To detect Lateral Account Movement paths within your domain, link this GPO to the domain root. In the example below, the GPO has been linked to the domain root. If the “Access this computer from the network” setting has been configured, an additional step is required to grant the gMSA access. Ensure the gMSA account is allowed to access computers from the network by following these steps: Open the Group Policy that has configured the network setting. Add the gMSA account to the policy to allow it access. Computer Configuration > Policies > Windows Settings > Local Policies > User Right Assignment Include the gMSA account Select “Access this computer from the network” Looking at the links within the Group Policy Management console, you can see there is the “…Remote SAM access” GPO linked at the domain root, but not for the “Domain Controllers” OU. Review the Configuration Running the following cmdlet will show that ADFS fails, causing the entire test to fail. This failure occurs because ADFS requires manual linking of the GPO to the appropriate OU. If you aren’t using ADFS, you can skip this step. However, ensure that the 'Microsoft Defender for Identity – Remote SAM Access' GPO is correctly configured and linked. Once this is done, the Remote SAM Access test should pass successfully. Test-MDIConfiguration -Mode Domain -Identity gMSA-MDI -Configuration All -Verbose In my instance, it indicates that Entra Connect is not set up to be monitored. However, this is irrelevant since I am not using it in my environment. Therefore, the Domain Controllers' (DCs) sensors are now ready for deployment. I want to run my HTML report one more time to have a hard copy for later use if needed. This report will verify that everything is ready for completion and can be saved for historical purposes. New-MDIConfigurationReport -Path C:\temp -OpenHtmlReport Note: If you are prompted for the Identity, this is the Identity to be used to run the installed sensor. As can be seen this warns about Entra Connect not being monitored, but we already knew that. Installing the Sensor Installing the Sensor with the GUI For this example, the installation of the sensor will be done manually via the GUI. In a corporate environment, this process can be automated using a Device Management tool. Browse to: Security.microsoft.com > Settings > Identities > General > Sensors Click on “+ Add sensor” A new box will pop up, this will provide the agent installation software and “Access key”. Click on “Download installer” and save to a location that can be accessed by the DC(s) Copy the “Access key” and place it in a secure location that is also accessible by the DC(s) Login to the DC that you want to install the MDI agent on to Start up an administrative command shell and browse to the MDI agent location Execute “Azure ATP Sensor Setup.exe” An installation window should pop up Select your “Language” Select “Next” Verify that the sensor is installed on the correct service type Select “Next” Copy and paste the “Access key” (Copied earlier when downloading the Sensor binary) Click “Install” Installation should begin Click “Finish” The sensor has now been successfully installed. Repeat this process for any other Domain Controllers (DCs), ADFS, or ADCS servers. Be sure to update the security group with the server names related to ADFS and ADCS. In the next screen grab, you will notice that I now have two DCs being monitored. The first was installed yesterday, and the second was installed a few minutes ago. If you look at the “Health status,” you can see that the most recent installation is going through a review process and initially reports as “Not healthy.” If everything is functioning correctly on the device (DC, ADFS, or ADCS), the health status should change to “Healthy” within a few minutes. In my case, it took approximately 5 minutes. Installing the Sensor from a Deployment Tool There is the ability to install via a management tool the Sensor which includes the ability to be in “Silent” mode. Complete details and parameter options can be found at: https://learn.microsoft.com/en-us/defender-for-identity/deploy/install-sensor#commands-for-running-a-silent-installation PowerShell syntax: .\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<Access Key>" Proxy Configuration If your enterprise uses a proxy, the MDI Sensor can be configured to utilize this appliance. Although I don't have a proxy environment available, I can still walk you through the steps to configure your MDI Sensor to use it. To configure a \ silent installation of the MDI sensor with a proxy, you need to include the proxy configuration in the command line using the appropriate parameters. "Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="<access key>" ProxyUrl=http://: ProxyUser="" ProxyPassword=""</access key> Explanation of Parameters: AccessKey="<Access Key>": Your MDI instance access key. ProxyUrl="http://<proxy-address>:<port>": The full URL of your proxy server. ProxyUser="<username>": (Optional) Username for proxy authentication. ProxyPassword="<password>": (Optional) Password for proxy authentication. Important: Make sure to replace the placeholders (<Access Key>, <proxy-address>, etc.) with your actual values. Also, be cautious with storing credentials in plain text—consider using secure methods for deployment like encrypted scripts or managed identities if possible. If you want to add the Proxy after deployment: As of this writing, there isn't a Group Policy setting to control the MDI Proxy Configuration, so we will use PowerShell. If deploying the sensor via a management tool, the sensor configuration can be added as an additional step in its deployment. Let’s verify that there isn’t currently any proxy configuration at this time. Get-MDISensorProxyConfiguration -Verbose As can be seen, there is no configuration set up. Now we can configure the Sensor to: ## Insert a proxy server into the Sensor deployment $proxyServer = http://proxy.contoso.com:8080 $Credential = "FakeCredentials" Set-MDISensorProxyConfiguration -ProxyUrl $proxyServer -ProxyCredential $Credential -Verbose The Sensor tried to connect to the proxy and failed, but we can still verify the configuration worked. Get-MDISensorProxyConfiguration -Verbose Note: For readability the window was reduced in size If you ever need to clear the Proxy settings Clear-MDISensorProxyConfiguration -Verbose Once again, let’s look at its Proxy configuration Get-MDISensorProxyConfiguration -Verbose It is once again clean from any Proxy configuration settings. Post Deployment Configuration Threshold Configuration for Alerts Threshold configuration in Microsoft Defender for Identity (MDI) allows administrators to customize the sensitivity of specific alerts to better align with their organization's security needs. By adjusting alert thresholds, you can control the volume of alerts generated, reducing false positives and focusing on more critical threats. The thresholds can be set to High, Medium, or Low, with High being the default setting that minimizes false positives. Medium and Low settings increase the number of alerts, which can be useful during comprehensive testing or in environments with higher security requirements. These configurations help ensure that MDI provides relevant and actionable alerts, enhancing the overall security posture of the organization. To configure the available alerts: Settings > Identity > General > Adjust alerts thresholds Entity Tags Entity tags in Microsoft Defender for Identity (MDI) are crucial for enhancing the security and monitoring capabilities within an organization. These tags help categorize and prioritize different entities, such as users, devices, and servers, based on their sensitivity and role within the network. By appropriately tagging entities, MDI can more effectively detect and respond to potential threats, ensuring that high-value assets receive the necessary attention and protection. The primary types of entity tags include Sensitive, Honeytoken, and Exchange server tags, each serving a unique purpose in the overall security strategy. Sensitive Tags Sensitive tags are used to identify high-value assets that require heightened security measures. These tags are automatically applied to entities that are part of critical Active Directory groups, such as Administrators, Domain Admins, and Schema Admins. Additionally, administrators can manually tag other users, devices, or groups as sensitive to ensure they receive appropriate monitoring and protection Honeytoken tags Honeytoken tags are a strategic tool used to detect malicious activity by setting traps for attackers. Honeytoken accounts are typically dormant and have no legitimate activity associated with them. Any authentication attempt involving a honeytoken account triggers an alert, allowing security teams to quickly identify and respond to potential threats. These tags are particularly useful for identifying lateral movement and other suspicious behaviors within the network. Exchange server tags Exchange server tags are automatically applied to devices running Microsoft Exchange Server, recognizing them as high-value targets due to their critical role in email communication and data storage. By tagging these servers, MDI ensures they are closely monitored for any signs of compromise or unauthorized access. Administrators can also manually tag other devices as Exchange servers if needed. Actions and Exclusions The "Actions" and "Exclusions" settings are essential components for customizing the security response and detection framework. The "Actions" setting enables administrators to define automated responses to identified threats, ensuring timely and consistent mitigation efforts. Meanwhile, the "Exclusions" setting allows for the exclusion of specific entities from detection rules, helping to minimize false positives and streamline threat management. Actions The "Actions" setting in Microsoft Defender for Identity is pivotal for automating the response to security threats. By configuring automated responses, administrators can ensure that predefined actions are taken immediately when a threat is detected. This can include actions such as isolating a compromised device, disabling a user account, or triggering an alert to the security team. Automated responses help in minimizing the time between detection and mitigation, thereby reducing the potential impact of security incidents. This proactive approach is essential for maintaining a secure and resilient identity infrastructure. Exclusions The "Exclusions" setting allows administrators to exclude specific entities, such as IP addresses, devices, or user accounts, from certain detection rules. This is particularly useful for reducing false positives that can arise from legitimate activities being flagged as suspicious. For example, security scanners or certain administrative tasks might trigger alerts that are not indicative of a real threat. By configuring exclusions, these benign activities can be ignored, allowing the security team to focus on genuine threats. Exclusions can be set globally or by specific detection rules, providing flexibility in managing the security landscape. Notifications Health Issue Notifications Users can be notified of health issues. This is configured in the settings page. Portal > Settings > Notifications > Health issues notifications > Add recipient email Alert Notifications Administrators can be notified of Alerts. This is configured in the settings page. Portal > Settings > Notifications > Alert notifications > Add recipient email Summary of Microsoft Defender for Identity Deployment Deploying Microsoft Defender for Identity (MDI) involves several critical steps, from verifying hardware capabilities to configuring the environment and installing sensors. By following this comprehensive guide, administrators can ensure a smooth and efficient deployment process. The use of the MDI PowerShell module significantly reduces the complexity and risk of human error, streamlining the configuration of auditing and permissions within the Active Directory Domain Services (AD DS) environment. The initial phase of the deployment focuses on performance and sizing reviews to confirm that your Domain Controllers (DCs) can handle the load imposed by the MDI agent. This step is crucial to ensure that the deployment does not negatively impact the performance of your network. The MDI sizing tool provides valuable insights and helps administrators make informed decisions about their infrastructure. Once the hardware is verified, the configuration phase begins. The PowerShell module for MDI simplifies this process by automating many of the necessary steps, reducing the potential for human error. This includes setting up a group Managed Service Account (gMSA) with the appropriate permissions, ensuring that the account is not overly privileged and meets the security requirements. The installation of the MDI sensors is the next critical step. This guide covers both manual installation via the GUI and automated deployment using a Device Management tool. Ensuring that the sensors are correctly installed and configured is essential for effective monitoring and threat detection. The guide also addresses the configuration of proxy settings if your enterprise uses a proxy, providing a comprehensive approach to deployment. The value of deploying MDI lies in its ability to provide robust security monitoring and threat detection. By leveraging on-premises Active Directory signals, MDI helps protect your organization from advanced threats, compromised identities, and insider actions. The automated processes and detailed configuration steps outlined in this guide ensure that your environment is well-prepared to handle potential security breaches, ultimately enhancing the overall security posture of your organization. In summary, the deployment of Microsoft Defender for Identity is a critical step in safeguarding your network infrastructure. By following this guide, administrators can ensure a thorough and efficient deployment, leveraging the power of MDI to detect and respond to security threats effectively. The streamlined processes and automation provided by the PowerShell module make this deployment accessible and manageable, even for those new to MDI. In conclusion, just as Raven's vigilant presence in our backyard ensures our safety, Microsoft Defender for Identity (MDI) provides robust protection for your network. By continuously monitoring and analyzing activities, MDI helps you stay ahead of potential threats, ensuring your digital environment remains secure. Whether you're new to MDI or a seasoned expert, implementing this powerful tool can significantly enhance your organization's security posture. Additionally, it's important to note that if you own a Microsoft 365 E5, A5, F5 Security, or G5 license, you already have access to MDI. This means you can leverage its advanced threat detection capabilities without any additional cost. So, take advantage of this valuable resource and ensure your network is as well-guarded as my home is with Raven on patrol. Note: The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages. Thanks to David Loder for proof reading and edit checks for this blog.Forward On-Premises Windows Security Event Logs to Microsoft Sentinel
There is no need to load an agent on every device to capture the Windows Security Event Logs from your on-premises Windows workstations & servers. Windows hosts already have this built into the operating system. To capture the events without having to load the Azure Monitoring Agent (AMA) the Windows Event Forwarding process can be used to send logs to a “Windows Event Collector” (WEC). The WEC will then need the AMA loaded to send the events to a Log Analytics Workspace (LAW) that is monitored by Microsoft Sentinel.How to Create an xPath Filter for a Data Collection Rule
In the world of data collection, efficiency is key. Just as my miniature schnauzer buddy, Raven, has a knack for sniffing out the most interesting scents while ignoring the mundane, an xPath filter can be used to streamline data collection by focusing only on the most relevant information. This document will guide you through the process of writing an xPath filter for a data collection rule, ensuring that your data ingress is as efficient and effective as Raven’s nose. Imagine Raven on a walk, surrounded by countless scents. If she were to investigate every single one, she’d waste a lot of time and energy. Instead, she selectively sniffs out the most intriguing smells, saving her effort for what truly matters. Similarly, an xPath filter helps you avoid the unnecessary data, allowing you to zero in on the specific pieces of information you need. By the end of this guide, you’ll be able to create xPath filters that reduce data ingress and improve the overall efficiency of your data collection processes. Windows Event Log capture is a cornerstone of effective security monitoring. It provides a detailed record of events across a multitude of logs, including but not limited to system, application, security, and Application and Service event logs. By capturing these logs, organizations can monitor for suspicious activities, detect potential security breaches, and ensure compliance with regulatory requirements. The detailed information contained in these logs helps security teams identify patterns and anomalies that may indicate malicious behavior, enabling a proactive approach to threat detection and response. One of the primary benefits of Windows Event Log capture is its ability to provide real-time visibility into the activities occurring within an IT environment. This visibility is crucial for identifying and responding to security incidents promptly. For instance, logs can reveal unauthorized access attempts, changes to critical system files, or unusual network traffic patterns. By analyzing these logs, security teams can quickly pinpoint the source of an issue and take appropriate action to mitigate the risk. However, the sheer volume of data generated by Windows Event Logs can be overwhelming. This is where xPath filters come into play. xPath, or XML Path Language, is a powerful tool for querying and filtering XML data. When applied to Windows Event Logs, xPath filters can help security teams focus on the most relevant events, reducing the noise and making it easier to identify significant security incidents. By using xPath filters, organizations can create customized queries that extract specific information from the logs, such as failed login attempts, changes to user privileges, specific error codes, or even events related to specific applications like Microsoft Exchange or SQL Server. The use of xPath filters not only enhances the efficiency of log analysis but also improves the accuracy of threat detection. By narrowing down the data to only the most pertinent events, security teams can reduce false positives and concentrate their efforts on genuine threats. This targeted approach ensures that critical security incidents are not overlooked amidst a sea of irrelevant data. Additionally, xPath filters can be tailored to meet the unique needs of an organization, allowing for a highly customized and effective log monitoring solution. In essence, Windows Event Log capture is an invaluable tool for maintaining the security and integrity of an IT environment. By leveraging xPath filters, organizations can optimize their log analysis processes, ensuring that they can quickly and accurately identify and respond to security threats. Just as Raven, my miniature schnauzer, efficiently sniffs out the most interesting scents, xPath filters help security teams focus on the most critical events, enhancing their ability to protect their systems and data. This document provides guidance on creating an xPath filter for a Data Collection Rule (DCR) for the Azure Monitoring Agent (AMA). A DCR is used to create a filter for user-defined Event IDs from Windows event logs. The xPath filter, which is created by the user, can be applied to both Windows – Azure, Hybrid and Azure Arc devices. The collected events are then sent to an Azure Monitor, Log Analytics Workspace table named "EVENT". To get started the user will need to define a list of Windows Event Logs to capture and the Event IDs within those log(s). There is the option to collect all of the Event IDs but that is not recommended unless specifically needed. All data collected and stored consume storage space which cost money for data ingressed and stored. For the examples within this document, I will collect the following Event IDs from the Event Logs: Security 1102, 4624 System 111, 113, 117 PowerShell Root PowerShell 400 Operational PowerShell 4103, 4104 To review where these are located within the Event logs, there are screen grabs to help find them. Start up the Windows Event Viewer Drill in the Event Viewer to find each Event Log To create an xPath filter, you can have the Event Log Viewer assist in the build. Right click on an Event Log log and select “Filter Current Log” This will bring up the following Window (There are two tabs available): On the “Filter” tab, enter the Event IDs, separating each with a comma. Select the “XML” tab To convert the Event Log Filter into an xPath form for the DCR, the following steps should be performed. Looking at the first screen capture above (Encased in red): <Query Id=”0” Path=”Security”> Copy the name within the quotes Security Append “!” on to the previous results Security! Looking at the second screen capture above (Encased in red): <Select Path=”Security”>*[System[(EventID=1102 or EventID=4624)]]</Select> Copy everything between the two greater than and less than symbols > < on to the previous results Security!*[System[(EventID=1102 or EventID=4624)]] The result is now an xPath filter that can be used with your DCR (To be created later). Note 1: Additional EventIDs can be added to the filter by simply inserting “ or EventID=9999” before the close parenthesis “)”within the xPath filter. Note 2: If all you would like to capture ALL events from a log then only the first 2 bullets above would need to be completed and then a “*” would need to be appended to include all events. Security!* Repeat the process above for each Event Log you would like to capture/filter. From the examples to be used the complete list of xPath filters can be found below. Save the xPath definitions in a text file that will be used in the DCR creation process, coming up next. Security!*[System[(EventID=1102 or EventID=4624)]] System!*[System[(EventID=111 or EventID=113 or EventID=117)]] Windows PowerShell!*[System[(EventID=400)]] Microsoft-Windows-PowerShell/Operational!*[System[(EventID=4103 or EventID=4104)]] Creating a new DCR to capture the data Browse to https://portal.azure.com > “Monitor” Settings > Data Collection Rules Create a Data Collection Rule Select “+ Create” On the “Basic” tab, enter “Rule Name”, “Subscription”, “Resource Group”, “Region” and Windows Using a “Data Collection Endpoint” is optional for this demo On the “Resources” tab, select “Add resources” Browse to the resources to apply this DCR against On the “Collect and deliver” tab Select “+ Add data source” On the sub-tab “Data source”, one by one, copy and paste each xPath filter. Hit “Add” after each paste. After all the xPath’ s have been added they should now be displayed below the entry line as you can see in the example below. On the sub-tab “Destination”, enter “Destination Type”, “Subscription”, and “Destination Details”. The “Destinations Details”, Log Analytics Workspace, is where the Event ID details will be sent within Azure. Enter any Tags required Review the “Review and create”, if all ok, select “Create” The Data Collection Rules blade should now reflect the new rule. When using a “Custom” xPath filter, the “Basic” tab reflects like nothing has been defined. Ensure you review the “Custom” / “Data source” tab to see the filters. After you have created this DCR (xPath filter) the devices that will have this defined against will soon start to send their EventID activities to the “Event” table within the Log Analytics Workspace. To ensure that a device has had the DCR applied against it, the following PowerShell commands can be done to review the definition on the device. From a PowerShell command prompt run the below: Note: The xml output will be stored at c:\temp. Ensure that path exists before running the script below. Connect-AzAccount $subscriptionId = "-------------------------------------" Set-AzContext -SubscriptionId $subscriptionId $resourceGroupName = "RG-Security" $dcrName = "CustomerSpecificRuleSet" # Get the Data Collection Rule and output to a file Get-AzDataCollectionRule -ResourceGroupName $resourceGroupName -Name $dcrName -SubscriptionId $subscriptionId | ConvertTo-Xml -As String -Depth 3 | Out-File -FilePath "C:\temp\dcr.xml" Write-Host "Data Collection Rule details have been written to C:\temp\dcr.xml" Looking in the dcr.xml finds the following: Once the DCR has been applied and events start to be pushed you can now find the events in the “Event” table. Query the Event Table In Azure Monitor > Logs the data can now be queried. A simple query: Event | project TimeGenerated, Source, EventLog, EventID If you notice the event log name and any EventIDs associated are populated within the query. The example only outputs 4 columns, but this was done to provide for display simplicity. Review the schema for a complete set of columns available. In conclusion, just as Raven efficiently sniffs out the most interesting scents on her walks, an xPath filter can help you streamline your data collection by focusing on the most relevant information. By applying the techniques outlined in this document, you can reduce data ingress and ensure that your data collection processes are both efficient and effective. Remember, the key to a successful xPath filter is precision and selectivity, much like Raven’s keen sense of smell. With these skills, you’ll be able to navigate through vast amounts of data and extract only what is necessary, saving time and resources. Happy filtering!Migrating from the Azure MMA to AMA Agent
I have another conversation about the sunset of the Microsoft Monitoring Agent (MMA). Back on November 13, 2023 I posted and article on how to do a bulk removal of the Azure MMA agent, but before you can remove the MMA agent you need to have the AMA agent ready to take over the work. Below are details to assist in this endeavor.Azure MMA Agent Bulk Removal
The Legacy Azure Microsoft Monitoring Agent (MMA) is scheduled for retirement in August 2024. To ensure a smooth transition and prevent duplication of logging data, it is strongly recommended to replace the MMA agent with the new Azure Monitor Agent (AMA) as soon as possible.Archive MDE Data to Event Hubs to ADX
Embark on a journey through the digital landscape as we uncover the secrets of exporting data from Defender for Endpoint to Azure Storage. Whether it’s basking in the cloud’s expanse or lying in wait for future endeavors, this guide will illuminate the path to securing your data’s sunny future. Stay tuned for a tale of vigilance and preparedness, where no critter—or data breach—can disturb the peace.Monitoring for an Azure Server Going Offline
Azure Monitor is a beneficial tool that has low costs for logs that are already in the tool. The main expenses for Azure Monitor come from ingesting the logs, so using the monitoring tool for data that is already there is a good way to help your enterprise reduce their spending.Manage USB Devices on Windows Hosts
Microsoft has built in security controls in our modern o/s’s to assist our customers in controlling the use of defined USB devices. The explanation below covers USB storage, but it really pertains to ALL USB devices that can be controlled. So, lets walk through the device management and control of devices.
