Azure Security Benchmark v2 is now available with expanded security control assessments

by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Today we are pleased to announce the Azure Security Benchmark v2. To accelerate the security of your cloud adoption journey, Microsoft has developed the Azure Security Benchmark (ASB). The benchmark is designed to provide clarity on security best practices and controls for configuring and operating Azure and Azure Services.

ASB v2 builds on the work of ASBv1 and includes these updates:

• Mapping of NIST SP 800-53 controls (in addition to existing CIS control framework v7.1)
• Mapping of security stakeholders to benchmark recommendations
• Expansion and restructure of controls to make them clear and actionable
• Integration of Azure Security Compass guidance

Vision for azure security guidance

We have learned that securing Azure means different things to different roles in the organization and have built a system of integrated security guidance. Each of these are aligned together to simplify your security journey:

• Microsoft Security Best Practices – Recommendations for securing all assets in your enterprise, typically integrated into security architectures and strategies.
• Azure Well-Architected Framework – Guidance for workload owners to architect workloads that meet goals for security, performance, cost, and more.
• Cloud Adoption Framework (CAF) – Guidance for cloud adoption initiatives to plan and execute on a strategy that meets organizational goals for security, cost management, reliability, and more (includes Enterprise Scale Landing Zone reference implementation and automation)
• Azure Security Benchmark – Prescriptive best practices and controls to guide all roles in the security organizations on securing Azure and Azure Services

Over the course of the last few months, the teams working on ASB, Enterprise Scale Landing Zone in CAF, Azure Security Compass, Azure Security Top 10 Best Practices, and Microsoft Best Practices have been working to consolidate and align all this guidance together to make it simpler and easier for you to rapidly secure your Azure resources.

As with all our guidance, we would love to hear your feedback on how this is working for you and how we can improve it. You can reach us by sending us email.

What’s new in ASB v2?

In addition to mapping and aligning all the guidance together, the team focused on these improvements in ASBv2:

• Mapped to NIST SP 800-53 Controls: NIST SP 800-53 is one of the most used control frameworks in the Industry, so we updated the ASB controls to map with the NIST controls. Now you can use ASB to meet the NIST requirements in Azure and can monitor the requirements in Azure Security Center Compliance dashboard. The benchmark and mapping to NIST controls is also available in excel format for easy consumption.
• Identified Security Stakeholders: We added security stakeholders to each recommendation to help you bring in the right people in your organization to plan, approve, or implement it. The stakeholders are identified by their roles and responsibility definitions from the CAF.
• Updated and restructured the security controls to provide more clarity: We made changes to the Azure security controls to make them actionable and more effective. A few examples are:
  • Updated the controls to provide clear guidance on security outcomes rather than just technical configurations.
  • Created a Governance and Strategy control to guide your strategic planning and governance strategy for security.
  • Updated the Logging and Threat detection control to focus more on the outcome of threat detection rather than just collection of logs.
  • Added Privileged Access as a separate control to provide clear recommendations on the critically important discipline of protecting privileged accounts (which can have an outsized business impact if compromised).
  • Added the Posture and Vulnerability Management control to provide clear guidance on how to monitor and improve your cloud security posture.
  • Identified a number of opportunities to modernize legacy security approaches with modern cloud approaches in Network Security, Endpoint Security, Logging and Threat detection, and more.
  • Updated and added controls to ensure a full lifecycle view for all controls including Data Protection, Asset Management, Identity Management, and Backup and Recovery.

What’s coming next?

Here is a brief overview of upcoming features:

• Monitoring of ASB v2 recommendations: Today, you can use the Azure Security Center Regulatory Compliance Dashboard to monitor your live Azure environment status with all the Azure Security Benchmark controls. In upcoming weeks, Security Center will be fully integrated with ASB v2, automatically monitoring your environment with policies implementing the complete ASB v2 control set by default. 
• Implementing the Benchmark recommendations: In coming weeks, we will be publishing the ASB v2 blueprint which will help you to implement and enforce the benchmark requirements. Today you can achieve that by using Enterprise scale landing zone to get a head start and use it to implement the Benchmark recommendations.
• Security Baselines based on ASB v2: So far, we have published security baselines for 50 Azure services based on ASB v1. These baselines provide service guidance on how you can meet the Benchmark requirements for a specific service. Azure customers today use these baselines as part of their cloud service assessment process. In upcoming months, we will be updating these baselines and adding more service baselines based on the ASB v2 recommendations.
• Control framework targeted next: After CIS v7.1 and NIST SP 800-53 control mapping, we are working on adding mapping of PCI DSS control requirements in coming months. This will help you to meet PCI DSS control requirements using the Azure Security Benchmark.

Call to Action

You can get started now with planning and implementing the Azure Security Benchmark v2, automate deployment with  Landing Zone, and monitor status using the Azure Security Center Regulatory Compliance Dashboard.

We want to thank the multiple teams within Microsoft, contributors from the Azure community, and NIST for the help with ASBv2 effort!

If you would like to participate in improving the benchmark or provide feedback, please send us an email. We would love to hear your success stories and feedback on how to make it better!

A closer look at Azure Arc enabled servers

by Scott Muniz | Sep 22, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Unified operations for hybrid IT

Azure Arc enabled servers is a powerful new technology that will help Microsoft customers and partners build seamless solutions for managing hybrid IT resources from a single pane of glass. Servers running outside of Azure such as AWS EC2 instances, on-premises VMware or physical machines, or devices in edge scenarios can now be projected into Azure as first-class resources. These resources can then be managed using Azure Policy, resource tags, and other Azure capabilities like update management, change tracking, monitoring, and more as if they were native Azure virtual machines. Azure Arc provides a unified governance and management strategy using Azure tools for our hybrid IT and multi-cloud environments.

Azure Arc Connected Machine agent

Azure Arc enabled servers interact with Azure via the Connected Machine agent. This agent interfaces with an Azure Resource Manager (ARM) resource provider which gives us the ability to perform management operations on the server via Azure Portal, Azure CLI, or Azure SDK. This agent contains logical components that control how an Azure Arc enabled server interfaces with various Azure services. The Hybrid Instance Metadata Service manages communication with Azure AD, while the Extension Manager service and Guest Configuration service allow the server to easily use Azure Virtual Machine extensions and to be governed using Azure Policy. The agent is configured with an Azure service principal and other parameters to manage scope and resource placement it can be deployed manually or as part of scripted automation.

Azure Arc enabled servers in action

Let’s take a closer look now at the above concepts in action. Imagine that we have a mature hybrid IT organization with server assets spread out over various public clouds and on-premises datacenters. We have standardized on using Azure Policy and other Azure governance tools (e.g., Log Analytics, Update Management, Backup, tagging). Because of the various hosting platforms for our virtual machines, we need an easy way to apply a common policy strategy across them all. To accomplish this, we will use Azure Arc enabled servers.

One of my requirements is that all virtual machines must send logs to Log Analytics to manage updates, change tracking, inventory, and monitoring. The onboarding of the Log Analytics agent must be done automatically via policy. To accomplish this, I have set up a Log Analytics workspace and enabled Update Management and Change Tracking, and I can deploy a built-in Azure Policy that checks for the presence of the Log Analytics agent and automatically deploys it if it is not found. Below you can see I have deployed this built-in policy and that will accomplish this. 

If you look closely at the JSON in the screenshot below you can see that this policy is scoped to the Microsoft.HybridCompute/machines resource type. Once this policy is in place, new Azure Arc enabled servers that I onboard by deploying the Connected Machine agent should automatically have the Log Analytics agent deployed by the policy.

Onboarding a server

Our next step is to onboard some servers to Azure by deploying the Connected Machine agent. We can do this using our own Azure credentials, or we can use a service principal for automated scenarios. We can scope a service principal to the “Azure Connected Machine Onboarding” role to restrict actions using the service principal to onboarding Azure Arc enabled servers only.

Below, you can see I have deployed a virtual machine to AWS. This VM is running Ubuntu 18.04.

We can get the Connected Machine agent provisioned on this server by running some commands. First we will download the agent install script using wget and then install the agent by running the downloaded script.

#!/bin/bash
# Download the installation package
wget https://aka.ms/azcmagent -O ~/install_linux_azcmagent.sh

# Install the hybrid agent
sudo bash ~/install_linux_azcmagent.sh

The script will run and generate some output. When complete you should see something similar to the below screenshot.

Next, I will run azcmagent connect to onboard the server. We can see in the example below that this command requires us to pass our service principal and secret, Azure tenant and subscription id, which I am injecting as environment variables. I also pass an Azure region and resource group.

sudo azcmagent connect 
   --service-principal-id $TF_VAR_client_id 
   --service-principal-secret $TF_VAR_client_secret 
   --tenant-id $TF_VAR_tenant_id 
   --subscription-id $TF_VAR_subscription_id 
   --location "westus2" 
   --resource-group "Arc-AWS-Demo" 

Now that the server has been onboarded I can open the Azure Portal and it as a resource in the resource group I specified when running azcmagent connect. 

If I look at the Extensions blade, I can also see that the Log Analytics agent (MMAExtension) is provisioned. This happened automatically as a result of the policy we configured.

With the MMAExtension enabled and my server sending logs to my workspace, we can take advantage of many governance tools such as managing updates with Update Management, reviewing security posture with Azure Security Center, and proactively managing security and other incidents with Azure Sentinel.

Below we can see our server is missing some updates. With the Update Management solution we can apply the update automatically or generate an alert that creates an incident in Azure Sentinel if this is a critical security update.

We can also use Kusto to query logs on the server for custom reports or other monitoring scenarios.

By using this workflow of deploying policies that are scoped to Azure Arc enabled servers, I can enable a large variety of governance scenarios. Some other examples of using Azure Arc enabled servers with Azure Policy include:

• Automatically deploying Azure Security Center at scale on any server
• Hardening servers for compliance scenarios using Guest Configuration
• Applying inventory management tags for better organization of my diverse hybrid resources.
• Enable multi-tenant or multi-customer service provider solutions by using Azure Lighthouse together with Azure Arc

Next steps

I hope this has been a helpful primer on Azure Arc enabled servers. For additional Azure Arc content visit the Azure Arc Jumpstart GitHub repository, where you can find more than 30 Azure Arc deployment guides and automation and visit the official Azure Arc documentation page. Additionally, my colleagues have written some other articles on Azure Arc that you can read:

• Azure Arc & Lighthouse: Managing IT infrastructure anywhere at-scale
• The Azure Arc Jumpstart Project
• Azure Arc enabled Kubernetes Monitoring
• Azure Arc enabled Kubernetes with GitOps

Enjoy the rest of Ignite 2020!