This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Introduction:
Azure Defender helps organizations be more secure by providing dedicated security analytics for a variety of workloads. Once you’ve enabled Azure Defender for the workload you need, you will receive alerts based on the analytics that were created to detects threats for the type of workload you selected. To ensure security alerts meet your organization’s specific requirements, you can create suppression rule(s) to fine tune alerts. Each suppression rule has an expiration date, which can be altered either through the Azure portal or REST API.
The purpose of this article is to highlight an automation, which has been developed and that can be leveraged by organizations to automatically extend the expiration date of all enabled suppression rules that are about to expire. This automation has been published to Azure Security Center GitHub repository – from where it can be deployed directly to your environment, through the provided ARM template.
Learn more about suppression alerts.
Deployment:
The automation has been published to Azure Security Center GitHub repository – from where it can be deployed directly to your environment, through the provided ARM template. In order to deploy the automation, your account needs to have Contributor rights on the target Subscriptions. (see here for more information) S
During deployment, you can specify some details such as in which subscription (and resource group) you’d like the automation to be deployed, the region, the name of this automation. You can also configure the following:
- Sender Address: e-mail address from which the automation will send the approval and confirmation email.
- Recipient Address: e-mail address to which the automation will send the approval and confirmation email.
- Time Until Expiration: how many days from today, does your organization consider suppression rules as about to expire. E.g., selecting 7 days means that recipients will be notified when the suppression rules are expiring in 7 days.
- Extend Expiration Time By: by how many days would you like to extend the expiration date(time) of suppression rules that are about to expire.
Logic Implemented:
The automation itself leverages Logic Apps and REST APIs. It’s configured to run daily by using a scheduler (frequency of which can be adjusted to meet your organization’s needs). The automation (once triggered by the scheduler) retrieves the list of all subscriptions within a management group using the Subscriptions REST API. (see Figure 2).
For each subscription, returned as a result, the automation will retrieve all suppression rules for that particular subscription, leveraging the Alert Suppression Rules REST API (see Figure 3).
For each suppression rule, returned as a result, the automation checks if the rule is enabled (the state of the API equals “Enabled”) and if its expiration date is about to expire. The check if a rule is about to expire is based on the expiration date of the rule itself, plus two variables – “Current Time” and “timeUntilExpiration”. The “Current Time” variable is equal to date(time) when the automation is executed. The “timeUntilExpiration” variable allows your organization to define by how many days from today (“Current Time”) does your organization consider suppression rules as about to expire. I.e. an organization might need three more weeks to perform penetration testing exercises and would like to extend all suppression rules by an additional three weeks. In order to accomplish this, the organization will configure the variable “timeUntilExpiration” to equal the number of days they need to complete this exercise. In our example this is three weeks, which equals to 21 (calendar) days. Therefore, the organization would configure the value of variable “timeUntilExpiration” to be 21. This in turn means that the automation will check if there are any suppression rules, whose expiration date is withing the next 21 days, and if so, will consider these suppression rules, as about to expire (see Figure 4).
Should there be any suppression rules that are about to expire, the automation will add them to a variable and send an approval email (see Figure 5).
Note: Both the sender and recipient address can be configured when deploying the automation through the ARM template provided.
Selecting “Extend All” extends the expiration time of all enabled suppression rules, by the specified number of days (which is configurable through the “extendExpirationTImeBy” variable).
Selecting “Do Nothing” terminates the workflow.
Once “Extend All” has been selected, the automation adds the value of the “extendExpirationTimeBy” variable, to the current expiration date of each suppression rule that is about to expire (see Figure 6).
To update the suppression rule with the newly calculated expiration date (time), the automation leverages the Alerts Suppression Rules REST API (see Figure 7).
Once the expiration date(s) of all rules about to expire have been successfully extended, a confirmation email will be sent, summarizing which suppression rules have been updated and indicating by how many days their expiration date(time) has been extended (see Figure 8).
Conclusion:
This automation can be leveraged by organization’s to automatically extend the time of all suppression rules that are about to expire. To ensure this automation meets the needs of your organizations, you can fine tune by how many days the expiration date will be extended, and how many days from today your organization considers rules as about to expire. Furthermore, the frequency of how often the automation runs (and checks for rules that are about to expire) can be adjusted as well. Hopefully this automation provides real value to your organization, when looking to extending multiple alert suppression rules automatically.
Co-Author(s): Liana Tomescu, Prasad Patil
Reviewer(s): Yuri Diogenes
Contributor(s): Safeena Begum Lepakshi, Tom Janetscheck, Yuri Diogenes