Considerations Regarding Azure Security Center Adoption

One common question that I receive from customers is: how do I fit Azure Security Center in my overall Security Operations and Incident Response plan? The answer may vary according to your SOC model, the size of the organization, cloud workload, and maturity level. For this reason, is important to take in consideration some key aspects of Azure Security Center adoption before you enable it and start using it. For this post, I'm going to cover the following aspects: Roles and Permissions, Operations and Incident Response. Keep in mind that each one of those areas could be deeply explored, but the purpose here is just to give you an overview to assist you during the planning phase.

Roles and Permission

Depending on the size and structure of your organization, multiple individuals and teams may use Security Center to perform different security-related tasks. Security Center uses Role-Based Access Control (RBAC), which provides built-in roles that can be assigned to users, groups, and services in Azure. When a user opens Security Center, they only see information related to resources they have access to. Which means the user is assigned the role of Owner, Contributor, or Reader to the subscription or resource group that a resource belongs to. In addition to these roles, there are two specific Security Center roles:

• Security reader: a user that belongs to this role can view only Security Center configurations, which include recommendations, alerts, policy, and health, but it won't be able to make changes.
• Security administrator: same as security reader but it can also update the security policy, dismiss recommendations and alerts.

We recommend that you assign the least permissive role needed for users to complete their tasks. For example, users who only need to view information about the security state of resources but not take action, such as applying recommendations or editing policies, should be assigned the Reader role. Permissions should be adjusted according to your SOC model, using a three-tier example you could have:

Operations

After initial configuration and application of Security Center recommendations, the next step is considering Security Center operational processes. When you first opt in to use Security Center for your current Azure environment, make sure that you review all recommendations, which can be done in the Recommendations tile or per resource (Compute, Networking, Storage & data, Application). Once you address all recommendations, the Prevention section should be green for all resources that were addressed. Ongoing monitoring at this point becomes easier since you will only take actions based on changes in the resource security health and recommendations tiles. Most Azure environments are dynamic, with new resources being spun up and down on a regular basis, configurations or changes, etc. Security Center helps ensure that you have visibility into the security state of these new resources. You will also want to regularly monitor the state of existing resources to identify configuration changes that have created security risks, drift from recommended baselines, and security alerts.

In the latest Microsoft Security Intelligence Report (SIR), Azure Security Center service witnessed several outbound attack attempts, and most were efforts to establish communications with malicious IP addresses (51 percent) and RDP (Remote Desktop Protocol) brute force attempts (23%) as shown below.

Most of the successful RDP brute force attack could be reduced by applying preventative measures. As part of your security operations, you should also adopt preventative measures to restrict access to VMs and control the applications that are running on VMs. By locking down inbound traffic to your Azure VMs, you are reducing the exposure to attacks, and at the same time providing easy access to connect to VMs when needed. Use Just in Time VM access feature to hardening access to your VMs. You can use Adaptive Application Controls to help control which applications can run on your VMs located in Azure, which among other benefits helps harden your VMs against malware. Security Center uses machine learning to analyze the processes running in the VM and helps you apply whitelisting rules using this intelligence.

Incident Response

Using the Microsoft Azure Security Response in the Cloud lifecycle, you can use Security Center Alerts during the following stages:

• Detect: identify a suspicious activity in one or more resources.
• Assess: perform the initial assessment to obtain more information about the suspicious activity.
• Diagnose: use the remediation steps to conduct the technical procedure to address the issue.

Each Security Alert provides information that can be used to better understand the nature of the attack and suggest possible mitigations. Some alerts also provide links to either more information or to other sources of information within Azure. You can use the information provided for further research and to begin mitigation, and you can also search security-related data that is stored in your workspace. Once you identify the compromised system, you can run security playbooks that were previously created. Security playbook is a collection of procedures that can be executed from Security Center once a certain playbook is triggered from selected alert. You can find a sample of how to use Security Center in an incident response scenario here, or watch my interview below where I go over some of the key aspects of using Security Center for IR:

If your SecOps uses a SIEM solution, you can integrate it with Azure Security Center. This way the Security Center alerts will be send to the SIEM solution. Read Azure Security data export to SIEM- Pipeline Configuration, and also check the current SIEM solutions that are supported.

References and More Information Azure Security Center Planning and Operations Guide Using Azure Security Center for an incident response Hybrid Cloud Workload Protection with Azure Security Center
Available at Microsoft Press Store and Amazon.