How to Address Security Alerts in Azure
The key to effectively addressing security alerts in Azure is determining which ones matter and which matter most.
December 7, 2021
One of the greatest benefits to using Microsoft Azure Security Center is that it provides actionable security insights and alerts based on an analysis of your environment. The key to taking full advantage of these insights is to determine which insights really matter, which are important but of slightly lower priority and which are essentially just noise alerts. Thankfully, Azure Security Center can help you prioritize security alerts, enabling you to effectively address them.
Insights vs. Alerts
The first thing that must be understood about addressing Azure security issues is that Microsoft differentiates between security insights and security alerts. Insights, which are displayed on Security Center’s Overview tab, generally pertain to high-level Azure configuration tasks. In Figure 1, for instance, Azure indicates that Azure Defender for open source relational databases should be enabled. I’m not using any open source relational databases, so this advice would not really fall under the category of a security alert. Even so, enabling Azure Defender for open source relational databases could be regarded as a security best practice.
Security alerts in azure 1
Figure 1
Azure security insights are displayed on Azure Security Center’s Overview tab.
In contrast, Azure Security Center displays security alerts on a dedicated Security Alerts tab. Although I do not have any active alerts at the moment, you can see what this tab looks like in Figure 2.
Security alerts in azure 2
Figure 2
Security related alerts are displayed on the Security Alerts tab.
Prioritizing Alerts and Taking Action
Although the previous screen capture showed that there were no security alerts, it is actually very unusual for no alerts to be present. The only reason why my Azure deployment is not displaying any alerts is because this is a lab deployment with very few objects. Organizations that actively use Microsoft Azure in their production environments often have hundreds of alerts, if not more. So how do you go about prioritizing these alerts?
Although it is not always the case, security alerts should generally take priority over security insights. In either case, though, Microsoft Azure attempts to help you prioritize alerts or insights by assigning a severity level to them. The severity ratings consist of a color-coded indicator that usually reflects the status of low, medium or high, depending upon how severe Microsoft deems a particular issue to be. If you look at Figure 3, you can see that this particular security insight has been given a severity level of high.
Security alerts in azure 3
Figure 3
Security insights and alerts are automatically assigned a severity level.
In the case of a security insight, the insight will be accompanied by a Freshness Interval rating that essentially tells you how recently the issue was detected or confirmed. This helps you to better understand whether the issue is current or if it’s an old issue that may no longer be relevant. In a similar way, security alerts display an indication of when a particular activity occurred. In other words, security alerts are often tied to events, whereas insights generally point to configuration changes that are needed to comply with security best practices.
Once you have determined which insights or alerts are of the highest priorities, the next step is to address those issues. For both insights and alerts, Microsoft provides a detailed description of the issues, along with a list of affected resources. This can help you to more easily determine how the issue is actually impacting your organization.
In addition, Microsoft provides recommended steps for dealing with issues. In some cases, Azure Security Center displays a quick-fix button that can be used to automatically correct the issue. In other cases, the issue must be manually dealt with, but Microsoft provides instructions for doing so.
In the case of a security alert, there are other actions that you can take beyond just mitigating a threat. For example, you can trigger an automated response. In other words, if a security alert was raised in response to a particular event, you can configure Azure Security Center to take automated action in the event that it happens again.
You can also automatically suppress similar alerts. Not every security alert represents a condition that needs to be addressed. Sometimes alerts are just noise. When that happens, you can suppress the alert and similar alerts that may occur in the future. That way, the list of alerts becomes smaller, making it easier to identify the alerts that really matter.
About the Author
You May Also Like