Checks We Perform

Azure AD is extended to include Azure AD B2B collaboration, allowing you to invite people from outside your organization to be guest users in your cloud account and sign in with their own work, school, or social identities. Guest users allow you to share your company's applications and services with users from any other organization, while maintaining control over your own corporate data.

Work with external partners, large or small, even if they don't have Azure AD or an IT department. A simple invitation and redemption process lets partners use their own credentials to access your company's resources a a guest user.

Subscription ownership should not include permission to create custom owner roles. The principle of least privilege should be followed and only necessary privileges should be assigned instead of allowing full administrative access.

Enable security alert emails to subscription owners.

Use Azure Active Directory Authentication for authentication with SQL Database.

Ensure that RBAC is enabled on all Azure Kubernetes Services Instances

Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app.

Managed service identity in App Service makes the app more secure by eliminating secrets from the app, such as credentials in the connection strings. When registering with Azure Active Directory in the app service, the app will connect to other Azure services securely without the need of username and passwords.

Security defaults in Azure Active Directory (Azure AD) make it easier to be secure and help protect your organization. Security defaults contain preconfigured security settings for common attacks.

Microsoft is making security defaults available to everyone. The goal is to ensure that all organizations have a basic level of security-enabled at no extra cost. You turn on security defaults in the Azure portal.

Disable anonymous access to blob containers and disallow blob public access on storage account.

Restricting default network access helps to provide a new layer of security, since storage accounts accept connections from clients on any network. To limit access to selected networks, the default action must be changed.

The storage account container containing the activity log export should not be publicly accessible.

Disable RDP access on network security groups from the Internet.

Disable SSH access on network security groups from the Internet.

Ensure that no SQL Databases allow ingress from 0.0.0.0/0 (ANY IP).

Disable Internet exposed UDP ports on network security groups.

By default, Azure Functions, Web and API Services can be deployed over FTP. If FTP is required for an essential deployment workflow, FTPS should be required for FTP login for all App Service Apps and Functions.

Enable automatic provisioning of the monitoring agent to collect security data.

Enables emailing security alerts to the subscription owner or other designated security contact.

Enable auditing on SQL Servers.

SQL Server Audit Retention should be configured to be greater than 90 days.

Enable log_checkpoints on PostgreSQL Servers.

Enable log_connections on PostgreSQL Servers.

Enable log_disconnections on PostgreSQL Servers.

Enable connection_throttling on PostgreSQL Servers.

Enable log_retention_days on PostgreSQL Servers.

Enable Diagnostic settings for exporting activity logs. Diagnostic setting are available for each individual resources within a subscription. Settings should be configured for all appropriate resources for your environment.

The diagnostic setting should be configured to log the appropriate activities from the control/management plane.

Enable AuditEvent logging for key vault instances to ensure interactions with key vaults are logged and available.

Create an activity log alert for the Create Policy Assignment event.

Create an activity log alert for the Delete Policy Assignment event.

Create an Activity Log Alert for the "Create" or "Update Network Security Group" event.

Create an activity log alert for the Delete Network Security Group event.

Create an activity log alert for the Create or Update Network Security Group Rule event.

Create an activity log alert for the Delete Network Security Group Rule event.

Create an activity log alert for the Create or Update Security Solution event.

Create an activity log alert for the Delete Security Solution event.

Create an activity log alert for the Create or Update or Delete SQL Server Firewall Rule event.

Diagnostic Logs capture activity to the data access plane while the Activity log is a subscription-level log for the control plane. Resource-level diagnostic logs provide insight into operations that were performed within that resource itself, for example, getting a secret from a Key Vault. Currently, 32 Azure resources support Diagnostic Logging (See the references section for a complete list), including Network Security Groups, Load Balancers, Key Vault, AD, Logic Apps and CosmosDB. The content of these logs varies by resource type. For example, Windows event system logs are a category of diagnostics logs for VMs, and blob, table, and queue logs are categories of diagnostics logs for storage accounts.

A number of back-end services were not configured to log and store Diagnostic Logs for certain activities or for a sufficient length. It is crucial that logging systems are correctly configured to log all relevant activities and retain those logs for a sufficient length of time. By default, Diagnostic Logs are not enabled. Given that the mean time to detection in an enterprise is 240 days, a minimum retention period of two years is recommended.

Note: The CIS Benchmark covers some specific Diagnostic Logs separately.

<3.3 - Ensure Storage logging is enabled for Queue service for read, write, and delete requests>
<6.4 Ensure that Network Security Group Flow Log retention period is 'greater than 90 days'>

Network Security Group Flow Logs should be enabled and the retention period is set to greater than or equal to 90 days.

Security Center emails the subscription owners whenever a high-severity alert is triggered for their subscription. You should provide a security contact email address as an additional email address.

Enable data encryption in transit.

The secure transfer option enhances the security of a storage account by only allowing requests to the storage account by a secure connection. For example, when calling REST APIs to access storage accounts, the connection must use HTTPS. Any requests using HTTP will be rejected when 'secure transfer required' is enabled. When using the Azure files service, connection without encryption will fail, including scenarios using SMB 2.1, SMB 3.0 without encryption, and some flavors of the Linux SMB client. Because Azure storage doesn’t support HTTPS for custom domain names, this option is not applied when using a custom domain name.

The Azure Storage blobs contain data like ePHI, Financial, secret or personal. Erroneously modified or deleted accidentally by an application or other storage account user cause data loss or data unavailability.

It is recommended the Azure Storage be made recoverable by enabling soft delete configuration. This is to save and recover data when blobs or blob snapshots are deleted.

Enable sensitive data encryption at rest using Customer Managed Keys rather than Microsoft Managed keys.

Enable Transparent Data Encryption on every SQL server.

Enable SSL connection on PostgreSQL Servers.

Enable SSL connection on MYSQL Servers.

TDE with Customer-managed key support provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties.

With TDE, data is encrypted at rest with a symmetric key (called the database encryption key) stored in the database or data warehouse distribution. To protect this data encryption key (DEK) in the past, only a certificate that the Azure SQL Service managed could be used. Now, with Customer-managed key support for TDE, the DEK can be protected with an asymmetric key that is stored in the Key Vault. Key Vault is a highly available and scalable cloud-based key store which offers central key management, leverages FIPS 140-2 Level 2 validated hardware security modules (HSMs), and allows separation of management of keys and data, for additional security.

Based on business needs or criticality of data/databases hosted a SQL server, it is recommended that the TDE protector is encrypted by a key that is managed by the data owner (Customer-managed key).

The storage account with the activity log export container is configured to use BYOK (Use Your Own Key).

Ensure that OS disks (boot volumes) and data disks (non-boot volumes) are encrypted with CMK.

Ensure that unattached disks in a subscription are encrypted with a Customer Managed Key (CMK).

Ensure that all keys in Azure Key Vault have an expiration time set.

Ensure that all Secrets in the Azure Key Vault have an expiration time set.

The key vault contains object keys, secrets and certificates. Accidental unavailability of a key vault can cause immediate data loss or loss of security functions (authentication, validation, verification, non-repudiation, etc.) supported by the key vault objects. \nIt is recommended the key vault be made recoverable by enabling the "Do Not Purge" and "Soft Delete" functions. This is in order to prevent loss of encrypted data including storage accounts, SQL databases, and/or dependent services provided by key vault objects (Keys, Secrets, Certificates) etc., as may happen in the case of accidental deletion by a user or from disruptive activity by a malicious user.

Azure App Service Authentication is a feature that can prevent anonymous HTTP requests from reaching the API app, or authenticate those that have tokens before they reach the API app. If an anonymous request is received from a browser, App Service will redirect to a logon page. To handle the logon process, a choice from a set of identity providers can be made, or a custom authentication mechanism can be implemented.

Azure Web Apps allows sites to run under both HTTP and HTTPS by default. Web apps can be accessed by anyone using non-secure HTTP links by default. Non-secure HTTP requests can be restricted and all HTTP requests redirected to the secure HTTPS port. It is recommended to enforce HTTPS-only traffic.

The TLS(Transport Layer Security) protocol secures transmission of data over the internet using standard encryption technology. Encryption should be set with the latest version of TLS. App service allows TLS 1.2 by default, which is the recommended TLS level by industry standards, such as PCI DSS.

Enable "Azure Defender for SQL" on critical SQL Servers.

Enable Vulnerability Assessment (VA) service scans for critical SQL servers and corresponding SQL databases.

Enable Vulnerability Assessment (VA) Periodic recurring scans for critical SQL servers and corresponding SQL databases.

Configure 'Send scan reports to' with email ids of concerned data owners/stakeholders for a critical SQL servers.

Enable Vulnerability Assessment (VA) setting 'Also send email notifications to admins and subscription owners'.