This guide is for information technology (IT) professionals, IT architects, information security analysts, and cloud administrators whose organizations are planning to use Azure Security Center.
Beginning in early June 2017, Security Center will use the Microsoft Monitoring Agent to collect and store data. See Azure Security Center Platform Migration to learn more. The information in this article represents Security Center functionality after transition to the Microsoft Monitoring Agent.
This guide covers a set of steps and tasks that you can follow to optimize your use of Security Center based on your organization’s security requirements and cloud management model. To take full advantage of Security Center, it is important to understand how different individuals or teams in your organization use the service to meet secure development and operations, monitoring, governance, and incident response needs. The key areas to consider when planning to use Security Center are:
- Security Roles and Access Controls
- Security Policies and Recommendations
- Data Collection and Storage
- Ongoing Security Monitoring
- Incident Response
In the next section, you will learn how to plan for each one of those areas and apply those recommendations based on your requirements.
Read Azure Security Center frequently asked questions (FAQ) for a list of common questions that can also be useful during the designing and planning phase.
Security roles and access controls
Depending on the size and structure of your organization, multiple individuals and teams may use Security Center to perform different security-related tasks. In the following diagram you have an example of fictitious personas and their respective roles and security responsibilities:
Security Center enables these individuals to meet these various responsibilities. For example:
Jeff (Cloud Workload Owner)
- Manage a cloud workload and its related resources
- Responsible for implementing and maintaining protections in accordance with company security policy
- Responsible for all aspects of security for the company
- Wants to understand the company's security posture across cloud workloads
- Needs to be informed of major attacks and risks
David (IT Security)
- Sets company security policies to ensure the appropriate protections are in place
- Monitors compliance with policies
- Generates reports for leadership or auditors
Judy (Security Operations)
- Monitors and responds to security alerts 24/7
- Escalates to Cloud Workload Owner or IT Security Analyst
Sam (Security Analyst)
- Investigate attacks
- Work with Cloud Workload Owner to apply remediation
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: user that belongs to this role is be able to view rights to Security Center, which includes recommendations, alerts, policy, and health, but it won't be able to make changes.
- Security admin: same as security reader but it can also update the security policy, dismiss recommendations and alerts.
The Security Center roles described above do not have access to other service areas of Azure such as Storage, Web & Mobile, or Internet of Things.
A user needs to be at least a subscription, resource group owner, or contributor to be able to see Security Center in Azure.
Using the personas explained in the previous diagram, the following RBAC would be needed:
Jeff (Cloud Workload Owner)
- Resource Group Owner/Collaborator
David (IT Security)
- Subscription Owner/Collaborator or Security Admin
Judy (Security Operations)
- Subscription Reader or Security Reader to view Alerts
- Subscription Owner/Collaborator or Security Admin required to dismiss Alerts
Sam (Security Analyst)
- Subscription Reader to view Alerts
- Subscription Owner/Collaborator required to dismiss Alerts
- Access to the workspace may be required
Some other important information to consider:
- Only subscription Owners/Contributors and Security Admins can edit a security policy
- Only subscription and resource group Owners and Contributors can apply security recommendations for a resource
When planning access control using RBAC for Security Center, be sure to understand who in your organization will be using Security Center. Also, what types of tasks they will be performing and then configure RBAC accordingly.
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.
Security policies and recommendations
A security policy defines the set of controls, which are recommended for resources within the specified subscription. In Security Center, you define policies according to your company's security requirements and the type of applications or sensitivity of the data.
Policies that are enabled in the subscription level automatically propagate to all resources groups within the subscription as shown in the following diagram:
If you need to review which policies were changed, you can use Azure Audit Logs. Policy changes are always logged in Azure Audit Logs.
Before configuring security policies, review each of the security recommendations, and determine whether these policies are appropriate for your various subscriptions and resource groups. It is also important to understand what action should be taken to address Security Recommendations and who in your organization will be responsible for monitoring for new recommendations and taking the needed steps.
Security Center will recommend that you provide security contact details for your Azure subscription. This information will be used by Microsoft to contact you if the Microsoft Security Response Center (MSRC) discovers that your customer data has been accessed by an unlawful or unauthorized party. Read Provide security contact details in Azure Security Center for more information on how to enable this recommendation.
Data collection and storage
Azure Security Center uses the Microsoft Monitoring Agent – this is the same agent used by the Operations Management Suite and Log Analytics service – to collect security data from your virtual machines. Data collected from this agent will be stored in your Log Analytics workspace(s).
After data collection is enabled in the security policy, the Microsoft Monitoring Agent (for Windows or Linux) is installed on all supported Azure VMs and any new ones that are created. If the VM already has the Microsoft Monitoring Agent installed, Azure Security Center will leverage the current installed agent. The agent’s process is designed to be non-invasive and have very minimal impact on VM performance.
The Microsoft Monitoring Agent for Windows requires use TCP port 443. See the Troubleshooting article for additional details.
If at some point you want to disable Data Collection, you can turn it off in the security policy. However, because the Microsoft Monitoring Agent may be used by other Azure management and monitoring services, the agent will not be uninstalled automatically when you turn off data collection in Security Center. You can manually uninstall the agent if needed.
To find a list of supported VMs, read the Azure Security Center frequently asked questions (FAQ).
Data collected from the Microsoft Monitoring Agent (on behalf of Azure Security Center) will be stored in either an existing Log Analytics workspace(s) associated with your Azure subscription or a new workspace(s), taking into account the Geo of the VM.
In the Azure portal, you can browse to see a list of your Log Analytics workspaces, including any created by Azure Security Center. A related resource group will be created for new workspaces. Both will follow this naming convention:
- Workspace: DefaultWorkspace-[subscription-ID]-[geo]
- Resource Group: DefaultResouceGroup-[geo]
For workspaces created by Azure Security Center, data is retained for 30 days. For exiting workspaces, retention is based on the workspace pricing tier.
Microsoft make strong commitments to protect the privacy and security of this data. Microsoft adheres to strict compliance and security guidelines—from coding to operating a service. For more information about data handling and privacy, read Azure Security Center Data Security.
Ongoing security monitoring
After initial configuration and application of Security Center recommendations, the next step is considering Security Center operational processes.
To access Security Center from the Azure portal you can click Browse and type Security Center in the Filter field. The views that the user gets are according to these applied filters, the example below shows an environment with many issues to be addressed:
Security Center will not interfere with your normal operational procedures, it will passively monitor your deployments and provide recommendations based on the security policies you enabled.
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.
The Detection section is more reactive, these are alerts regarding issues that are either taking place now, or occurred in the past and were detected by Security Center controls and 3rd party systems. The Security Alerts tile will show bar graphs that represent the number of threat detection alerts that were found in each day, and their distribution among the different severity categories (low, medium, high). For more information about Security Alerts, read Managing and responding to security alerts in Azure Security Center.
You can also leverage Microsoft Power BI to visualize your Security Center data. Read Get insights from Azure Security Center data with Power BI.
Monitoring for new or changed resources
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.
When you add new resources (VMs, SQL DBs) to your Azure Environment, Security Center will automatically discover these resources and begin to monitor their security. This also includes PaaS web roles and worker roles. If Data Collection is enabled in the Security Policy, additional monitoring capabilities will be enabled automatically for your virtual machines.
- For virtual machines, click Compute, under Prevention section. Any issues with enabling data or related recommendations will be surfaced in the Overview tab, and Monitoring Recommendations section.
- View the Recommendations to see what, if any, security risks were identified for the new resource.
- It is very common that when new VMs are added to your environment, only the operating system is initially installed. The resource owner might need some time to deploy other apps that will be used by these VMs. Ideally, you should know the final intent of this workload. Is it going to be an Application Server? Based on what this new workload is going to be, you can enable the appropriate Security Policy, which is the third step in this workflow.
- As new resources are added to your Azure environment, it is possible that new alerts appear in the Security Alerts tile. Always verify if there are new alerts in this tile and take actions according to Security Center recommendations.
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. Start at the Security Center dashboard. From there you have three major areas to review on a consistent basis.
- The Prevention section panel provides you quick access to your key resources. Use this option to monitor Compute, Networking, Storage & data and Applications.
- The Recommendations panel enables you to review Security Center recommendations. During your ongoing monitoring you may find that you don’t have recommendations on a daily basis, which is normal since you addressed all recommendations on the initial Security Center setup. For this reason, you may not have new information in this section every day and will just need to access it as needed.
- The Detection section might change on either a very frequent or very infrequent basis. Always review your security alerts and take actions based on Security Center recommendations.
Security Center detects and alerts you to threats as they occur. Organizations should monitor for new security alerts and take action as needed to investigate further or remediate the attack. For more information on how Security Center threat detection works, read Azure Security Center detection capabilities.
While this article doesn’t have the intent to assist you creating your own Incident Response plan, we are going to use Microsoft Azure Security Response in the Cloud lifecycle as the foundation for incident response stages. The stages are shown in the following diagram:
You can use the National Institute of Standards and Technology (NIST) Computer Security Incident Handling Guide as a reference to assist you building your own.
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.
The following example shows a suspicious RDP activity taking place:
As you can see, this blade shows details regarding the time that the attack took place, the source hostname, the target VM and also gives recommendation steps. In some circumstances the source information of the attack may be empty. Read Missing Source Information in Azure Security Center Alerts for more information about this type of behavior.
In the How to Leverage the Azure Security Center & Microsoft Operations Management Suite for an Incident Response video you can see some demonstrations that can help you to understand how Security Center can be used in each one of those stages.
Read Leveraging Azure Security Center for Incident Response for more information on how to use Security Center capabilities to assist you during your Incident Response process.
In this document, you learned how to plan for Security Center adoption. To learn more about Security Center, see the following:
- Managing and responding to security alerts in Azure Security Center
- Security health monitoring in Azure Security Center — Learn how to monitor the health of your Azure resources.
- Monitoring partner solutions with Azure Security Center — Learn how to monitor the health status of your partner solutions.
- Azure Security Center FAQ — Find frequently asked questions about using the service.
- Azure Security blog — Find blog posts about Azure security and compliance.