Often the purposes or differences between a Cloud Access Security Broker (CASB) like Microsoft's Cloud App Security (MCAS) product and a Security Information & Event Management (SIEM) product like Microsoft's Azure Sentinel can be misunderstood. In this two part blog series, both products will be discussed in terms of their differences and importance for CMMC compliance and an ideal cloud security strategy. For an overview of MCAS and its capabilities for security and compliance, check out Part 1 here..
Webinar on Incident Response
Sentinel is a Security Information & Event Management software product (SIEM)
Many of the requirements found in CMMC Domains Incident Response, Audit and Accountability, and Access Control tie to a SIEM or set of tools collectively accomplishing similar goals. Sentinel can be configured properly to achieve the current requirements set for CMMC Level 3.
Azure Sentinel became generally available on March 13, 2020, and charges for the service started April 1, 2020. Sentinel can pull log data at no cost for Incident Response from AWS CloudTrail, Azure Activity Logs, Office 365/Microsoft 365 Audit Logs (all SharePoint activity and Exchange admin activity) and alerts from Microsoft Threat Protection products, which underwent a name change in October of 2020. Read more about the name change here. (Azure Security Center, Microsoft Defender for Office 365, Microsoft Defender for Identity, Microsoft Defender for Endpoint, Microsoft Cloud App Security, Azure Information Protection).
Logs can also come from other sources:
Many organizations following security best practices were likely using Azure Security Center (ASC) as an alerting tool prior, Azure Sentinel takes these alerts from ASC, other 3rd Party data sources, and custom applications to provide a single pane of glass across your organization. The following dashboard can highlight common alerts, threats by region, and more.
Sentinel is necessary for collecting, investigating, and retaining records from all sources. However, ASC is still important for ongoing mitigation planning and strategy. CMMC requires this activity in the Security Awareness (CA) section - CA.2.159: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems. and RM.2.142 - Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
ASC will identify what resources are vulnerable and provide insights into which settings or configurations need to be remediated for greater security. Below is a sample snapshot of a company's secure score (left) in ASC and recommendations for mitigation (bottom).
Going beyond ASC and continuous improvement, there are 29 CMMC Practices within the Audit and Accountability (AU) and Incident Response (IR) Domains. Azure Sentinel helps to address most of these Practices in part or whole.
AU 2.042 Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity.
Before you can review logs, you must create the logs (of course) and define what "unlawful or unauthorized system activity" means for each of your resources. This primarily is intended for information systems housing Controlled Unclassified Information (CUI) or Federal Contract Information (FCI); however, best practices suggest you define logging requirements and investigative processes for all systems.
In many cases, you will want to log authentication attempts and report or alert on higher quantities of unsuccessful login attempts. Another example is logging VM creation throughout your Azure Government environment, and alerting and reporting on higher creation or change rates of VMs in your environment. Azure Sentinel will contextualize an incident to provide a complete picture of a system activity: what resources are involved (directly and indirectly), where the action was taken, when the action and associated actions were taken, what identities were involved, and more.
AU 2.044 - Review audit logs.
Totaling a whopping three words, this Practice is the shortest CMMC practice of all 171. However, its importance is understated. The call to arms in this requirement is expounded on in the clarification section of CMMC: "become familiar with the logs... and identify key events in the logs that might indicate malicious activity." Azure Sentinel, as with many SIEM tools, is intended to surface key events as determined by you or out of the box alert rules. Below is a typical set of rule templates in the Azure Sentinel dashboard and a snapshot of rule creation.
Rules can be configured for query frequency, what sources should be queried and for what anomalies, and what alerts need to be distributed: to whom, what severity level, etc.
Playbooks then extend the rules and alerts to automatically take action on your behalf via Azure Logic Apps. Thankfully, CMMC permits organizations to check and investigate logs "manually" or with "automation".
AU.3.045 - Review and update logged events
With Azure Sentinel, teams can more readily curate logged events, track what incidents resulted in threat identification, and modify the SIEM with Microsoft's machine learning capabilities to better catch bad actors and lessen noise. Below is a quick example of native capabilities within Azure Sentinel to close out incidents with a three click process while capturing important improvement information. When closing an incident you can specify if it was due to one of the following reasons:
AU.3.048 - Collect audit information (e.g., logs) into one or more central repositories.
Azure Sentinel is cloud native, which means it is collecting and processing audit data into a single location in your Azure Government tenant with protected administrative rights, as well as reporting on administrative actions within Sentinel. All signals pour into a single source hosted and run in your cloud environment, adding a higher level of resiliency and availability.
IR.2.093 - Detect and report events.
The requirement here is for detection of all activities, not only digital ones. This partly involves creating a culture and mechanism for individuals within your organization to report adverse security behaviors or processes. CMMC defines events to include cybersecurity and any activity that hinders productivity significantly - such as a major outage. From a digital perspective, Sentinel is looking at all events across your data estate, enterprise network, workstations, and user base to collect events for anomaly detection, investigation, and response.
IR.2.094 - Analyze and triage events to support event resolution and incident declaration.
Sentinel provides an incident (not a formal incident to be reported to the DoD) board for your internal or external Security Operations Center (SOC) to triage and prioritize events. The incident or event is automatically given a severity level based on preestablished rules but can be manually changed after creation. Severity is often determined by the extent of the incident, impact, and reach, as well as correlations to large scale attacks taking place across Microsoft's immense landscape. Playbooks can also be created in Sentinel to automatically escalate and notify individuals or organizations of significant high severity events/incidents.
Once a decision is made on which SIEM tool to purchase, IT and security leadership need to grasp several data points.
These questions will determine overall costs on a reoccurring basis, and some can be complicated due to risk, business, and compliance variables. For example, retention beyond 90 days will incur a fee for Azure Sentinel, yet NISPOM requires 1 year log data retention for some companies and the data they manage. Up front installation and implementation costs also need to be considered, regardless of using internal or external resources.
The key benefits of Azure Sentinel: