Revise MS.AAD.4.1v1 Azure AD logs policy based on feedback and pilots

[tkol2022]

💡 Summary

Regarding AAD policy 4.1 which is centered on collecting logs, we received feedback in the form of comments and from interactions with agencies during the pilots. This issue is to revise the baseline policy and implementation section accordingly.

Revised 4.1 Azure AD logs policy first paragraph

Configure Azure AD to send critical security logs to a centralized SIEM and/or storage location for auditing, analytics and incident response. The SIEM and storage location are secured systems, decoupled from the M365 tenant to help protect the integrity of the logs.

Rationale

Without a record of security events it isn't possible to perform critical security monitoring, threat hunting and incident response functions.

Revised Policy bullets

• The logs SHALL be collected at the agency's SIEM.

  • If it is not possible to send the logs directly to the SIEM yet, the logs SHALL be collected at an Azure storage account and configured to be immutable.

• The following critical logs SHALL be collected at a minimum: AuditLogs, SignInLogs, RiskyUsers, UserRiskEvents, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ADFSSignInLogs, RiskyServicePrincipals, ServicePrincipalRiskEvents.

  • If managed identities are used for Azure resources, also include the ManagedIdentitySignInLogs log type.

  • If the Azure AD Provisioning Service is used to provision users to SaaS apps or other systems, also include the ProvisioningLogs log type.

Resources

Remove links to NCPS documents.

License Requirements

• An Azure subscription is required if implementing an Azure storage account as per the implementation example below.

Revised Implementation section:

The implementation steps are specific to each SIEM product, however we provide a generic list below to assist.

1. Configure Azure AD to send the logs listed in the policy section to the agency's specific SIEM system.
2. Ensure that the logs are stored in immutable containers (i.e. they cannot be modified so that integrity is preserved).

If a SIEM is not integrated at this time, an Azure storage account can be used. Follow the instructions at this link to configure sending the logs listed in the policy section to a storage account. Set the retention to a minimum of 365 days or the agency's specific requirement. Follow the instruction at this link to configure the storage to be immutable.

Acceptance Criteria

• [ ] Have a discussion about adding more requirements around logging/CLAW/etc now that that technology has been proved out for integration with AAD
• [ ] This topic should be tied up as part of finalizing the AAD baseline

[schrolla]

This item is blocked based on the need for a team discussion on handling logging. Adding to blocked state until questions are resolved and discussion provides a clear way forward.

[tkol2022]

@schrolla @ssatyapal123 Wanted to circle back with you on this topic since it has been a while.

• I streamlined the AAD policy on logging MS.AAD.4.1v1. It should look similar to what was there before, with some strategic tweaks. Feel free to make any further revisions you see fit. Here is an explanation of tweaks that I made:
  • The specific types of logs that are to be sent to the SOC are described in the Scope comment.
  • I included a CLAW requirement that is specific to Federal agencies (as per what CISA wanted) - see the Federal Agencies comment. Right now, this is a comment under the main 4.1 requirement. It is not clear to me if this really should be its own policy item, but something for you to think about.

I'm still unsure of how someone would be able to audit this policy 4.1. I still think it is too generic compared to our other policies, which, for the most part, are pretty specific. I can't see how a human auditor could check the Azure AD configurations using a standard set of steps to verify that the policy has been implemented as intended. Can't see how ScubaGear could perform checks either. Here are some potential ideas we can discuss and for you to think about:

• Check the Azure AD Diagnostic settings and look for a configuration in the list that selects the specific logs mentioned in the policy section. There can be numerous rows of diagnostic settings configured in the Azure AD diag settings page and we cannot know which one is the "correct" one to audit, so we might need to look at all of them. If any of the logs mentioned in the policy section are not selected in the settings, then ScubaGear would flag it as a policy failure. Maybe the ScubaGear report could list the specific logs that are missing from the configuration. Notice in the screenshot below, there are three diagnostic configurations - we would need to check all three to see if any of them are compliant.

  • I do not think we will be able to check the value in Destination field at this time, because we won't know exactly how an agency has configured their specific data flow to get their AAD logs to their SIEM/SOC. They might select "Stream to an event hub" or "Send to partner solution". I am not sure we know enough about all the potentially different data flows to be able to standardize a check of the Destination field. Therefore, if we decide to just code a ScubaGear check that looks at the Log types selected but does not examine the Destination, it would be a partial solution, and we might need to output a disclaimer in the report.

• Regarding CLAW integration, which could be its own separate requirement, I sent you an email with the instructions file that CISA prepared for agencies to send their AAD logs to CLAW. You will notice in those instructions that the Azure AD Diagnostic settings are not mentioned, however CISA instructs agencies to setup an Event Hub which CISA's centralized log collection system "pulls" data from. You will notice that an Event Hub is one of the potential destinations in the AAD Diagnostic settings. This leads me to think that one possible data integration flow for an agency to send their logs to CISA CLAW would be 1) configure an event Hub the way CISA described in the CLAW integration guide, 2) Configure an AAD Diagnostic setting - select the appropriate log types and set the Destination to the Event Hub created in step 1. If this is the standard end to end data flow for agency to CLAW integration, then maybe we could code a ScubaGear check that looks for these integration configurations. We need confirmation from the CLAW team that @buidav got us in contact with.

[tkol2022]

@ahuynhMITRE For your awareness, the results of this issue may result in a change to the logging policy in the AAD baseline. You should be aware given the status of the document review lifecycle.

[schrolla]

Discuss possibilities in parking lot with team.