Security Control v3: Logging and threat detection

Logging and Threat Detection covers controls for detecting threats on Azure and enabling, collecting, and storing audit logs for Azure services, including enabling detection, investigation, and remediation processes with controls to generate high-quality alerts with native threat detection in Azure services; it also includes collecting logs with Azure Monitor, centralizing security analysis with Azure Sentinel, time synchronization, and log retention.

LT-1: Enable threat detection capabilities

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.11 AU-3, AU-6, AU-12, SI-4 10.6, 10.8, A3.5

Security Principle: To support threat detection scenarios, monitor all known resource types for known and expected threats and anomalies. Configure your alert filtering and analytics rules to extract high-quality alerts from log data, agents, or other data sources to reduce false positives.

Azure Guidance: Use the threat detection capability of Azure Defender services in Microsoft Defender for Cloud for the respective Azure services.

For threat detection not included in Azure Defender services, refer to the Azure Security Benchmark service baselines for the respective services to enable the threat detection or security alert capabilities within the service. Extract the alerts to your Azure Monitor or Azure Sentinel to build analytics rules, which hunt threats that match specific criteria across your environment.

For Operational Technology (OT) environments that include computers that control or monitor Industrial Control System (ICS) or Supervisory Control and Data Acquisition (SCADA) resources, use Defender for IoT to inventory assets and detect threats and vulnerabilities.

For services that do not have a native threat detection capability, consider collecting the data plane logs and analyze the threats through Azure Sentinel.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

LT-2: Enable threat detection for identity and access management

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.11 AU-3, AU-6, AU-12, SI-4 10.6, 10.8, A3.5

Security Principle: Detect threats for identities and access management by monitoring the user and application sign-in and access anomalies. Behavioral patterns such as excessive number of failed login attempts, and deprecated accounts in the subscription, should be alerted.

Azure Guidance: Azure AD provides the following logs that can be viewed in Azure AD reporting or integrated with Azure Monitor, Azure Sentinel or other SIEM/monitoring tools for more sophisticated monitoring and analytics use cases:

  • Sign-ins: The sign-ins report provides information about the usage of managed applications and user sign-in activities.
  • Audit logs: Provides traceability through logs for all changes done by various features within Azure AD. Examples of audit logs include changes made to any resources within Azure AD like adding or removing users, apps, groups, roles and policies.
  • Risky sign-ins: A risky sign-in is an indicator for a sign-in attempt that might have been performed by someone who is not the legitimate owner of a user account.
  • Users flagged for risk: A risky user is an indicator for a user account that might have been compromised.

Azure AD also provides an Identity Protection module to detect, and remediate risks related to user accounts and sign-in behaviors. Examples risks include leaked credentials, sign-in from anonymous or malware linked IP addresses, password spray. The policies in the Azure AD Identity Protection allow you to enforce risk-based MFA authentication in conjunction with Azure Conditional Access on user accounts.

In addition, Microsoft Defender for Cloud can be configured to alert on deprecated accounts in the subscription and suspicious activities such as an excessive number of failed authentication attempts. In addition to the basic security hygiene monitoring, Microsoft Defender for Cloud's Threat Protection module can also collect more in-depth security alerts from individual Azure compute resources (such as virtual machines, containers, app service), data resources (such as SQL DB and storage), and Azure service layers. This capability allows you to see account anomalies inside the individual resources.

Note: If you are connecting your on-premises Active Directory for synchronization, use the Microsoft Defender for Identity solution to consume your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

LT-3: Enable logging for security investigation

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.12 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3

Security Principle: Enable logging for your cloud resources to meet the requirements for security incident investigations and security response and compliance purposes.

Azure Guidance: Enable logging capability for resources at the different tiers, such as logs for Azure resources, operating systems and applications inside in your VMs and other log types.

Be mindful about different type of logs for security, audit, and other operation logs at the management/control plane and data plane tiers. There are three types of the logs available at the Azure platform:

  • Azure resource log: Logging of operations that are performed within an Azure resource (the data plane). For example, getting a secret from a key vault or making a request to a database. The content of resource logs varies by the Azure service and resource type.
  • Azure activity log: Logging of operations on each Azure resource at the subscription layer, from the outside (the management plane). You can use the Activity Log to determine the what, who, and when for any write operations (PUT, POST, DELETE) taken on the resources in your subscription. There is a single Activity log for each Azure subscription.
  • Azure Active Directory logs: Logs of the history of sign-in activity and audit trail of changes made in the Azure Active Directory for a particular tenant.

You can also use Microsoft Defender for Cloud and Azure Policy to enable resource logs and log data collecting on Azure resources.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

LT-4: Enable network logging for security investigation

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.6, 8.7, 13.6 AU-3, AU-6, AU-12, SI-4 10.8

Security Principle: Enable logging for your network services to support network-related incident investigations, threat hunting, and security alert generation. The network logs may include logs from network services such as IP filtering, network and application firewall, DNS, flow monitoring and so on.

Azure Guidance: Enable and collect network security group (NSG) resource logs, NSG flow logs, Azure Firewall logs, and Web Application Firewall (WAF) logs for security analysis to support incident investigations, and security alert generation. You can send the flow logs to an Azure Monitor Log Analytics workspace and then use Traffic Analytics to provide insights.

Collect DNS query logs to assist in correlating other network data.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

LT-5: Centralize security log management and analysis

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.9, 8.11, 13.1 AU-3, AU-6, AU-12, SI-4 N/A

Security Principle: Centralize logging storage and analysis to enable correlation across log data. For each log source, ensure that you have assigned a data owner, access guidance, storage location, what tools are used to process and access the data, and data retention requirements.

Azure Guidance: Ensure that you are integrating Azure activity logs into a centralized Log Analytics workspace. Use Azure Monitor to query and perform analytics and create alert rules using the logs aggregated from Azure services, endpoint devices, network resources, and other security systems.

In addition, enable and onboard data to Azure Sentinel which provides the security information event management (SIEM) and security orchestration automated response (SOAR) capability.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

LT-6: Configure log storage retention

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.3, 8.10 AU-11 10.5, 10.7

Security Principle: Plan your log retention strategy according to your compliance, regulation, and business requirements. Configure the log retention policy at the individual logging services to ensure the logs are archived appropriately.

Azure Guidance: Logs such as Azure Activity Logs events are retained for 90 days then deleted. You should create a diagnostic setting and route the log entries to another location (such as Azure Monitor Log Analytics workspace, Event Hubs or Azure Storage) based on your needs. This strategy also applies to the other resource logs and resources managed by yourself such as logs in the operating systems and applications inside the VMs.

You have the log retention option as below:

  • Use Azure Monitor Log Analytics workspace for a log retention period of up to 1 year or per your response team requirements.
  • Use Azure Storage, Data Explorer or Data Lake for long-term and archival storage for greater than 1 year and to meet your security compliance requirements.
  • Use Azure Event Hubs to forward logs to outside of Azure.

Note: Azure Sentinel uses Log Analytics workspace as its backend for log storage. You should consider a long-term storage strategy if you plan to retain SIEM logs for longer time.

Implementation and additional context:

Customer Security Stakeholders (Learn more):

LT-7: Use approved time synchronization sources

CIS Controls v8 ID(s) NIST SP 800-53 r4 ID(s) PCI-DSS ID(s) v3.2.1
8.4 AU-8 10.4

Security Principle: Use approved time synchronization sources for your logging time stamp which include date, time and time zone information.

Azure Guidance: Microsoft maintains time sources for most Azure PaaS and SaaS services. For your compute resources operating systems, use a Microsoft default NTP server for time synchronization unless you have a specific requirement. If you need to stand up your own network time protocol (NTP) server, ensure you secure the UDP service port 123.

All logs generated by resources within Azure provide time stamps with the time zone specified by default.

Implementation and additional context:

Customer Security Stakeholders (Learn more):