Cloud Security Migration Optimization Tips

Win your battle against Alert Fatigue using CloudHealth Secure State

It’s Monday morning, and your Slack is blowing up with security alerts from AWS, Azure, and GCP.  The dev team is testing some new code again, and it is triggering false positives with the native security solutions. You are trying to concentrate on a REAL vulnerability, that strangely, nothing you have deployed alerted you around, but you read about it on Twitter. Figuring out which alert is critical, as per your organization’s security policy took so much time that your coffee is already cold.

The diagnosis is clear: Its alert fatigue! Early security tools alerted on everything to everyone, causing Infosec teams to coin the phrase “alert fatigue”.  

Alert fatigue can cause your organization to miss critical cybersecurity threats. After all, there is only so much noise you can process before it ALL becomes noise to you and your team. This leads to employee burnout, and impacts recruitment – as key prospects reach out to your team to get the “skinny” on what it’s like to work there and hear about long hours, manual remediations, and no time to work on fun, proactive projects.      

VMware can help! CloudHealth Secure State not only gives you visibility into the security and compliance risks across your multi-cloud environment, but also gives you control of the alerts you get, from what medium, and to whom they go in a timely fashion.  

Let’s take a look at how CloudHealth Secure State helps you avoid “Alert Fatigue.” 

 Customizable Alerting

With CloudHealth Secure State, you choose what gets alerted on, to whom, and how.     

In the console screen-shot below, we can see that the Alerts menu is accessed under the actions tab of the main navigation bar.

Alerts can be custom named so that security administrators understand what the alert means, and whom it is going to.  The green toggle bars allow alerts to be enabled and disabled, which can come in handy when a test is being run in a dev environment, for example, and alerting would be around something known or letting run temporarily.

The context column allows you to choose who gets the alert – the whole organization or a project within the organization, and the last updated column allows you to see when the alert was last edited.

Alerts can also be cloned, edited, or deleted. The Integration column shows where this alert is sent. An alert can be sent to email, a webhook (which allows you to integrate with any messaging or ticketing system of choice), Slack, SQS, Splunk or even Jira Cloud, which allows an alert to be used to automatically create an issue.

Learn how easy it is to create these security alerts.

Role Based Access

No admin wants everyone in the organization to be able to create alerts, and we all know each department or project group has unique needs. To create individual “projects” with varied access, simply navigate to the Settings tab, then choose projects.

As you can see in this screen shot, individual project groups can be created that have access to only certain cloud accounts. In the context column of the Alerts page, these projects can be chosen so that only members of that project group will receive alerts. Here, we have Dev Orgs, and a New Demo Area as separate project groups.

Going up to the far right, you can see a tab called Current Context. Here you can choose to see the view that each project group has, assuming you are an administrator and have access to the whole organization (shown here appropriately as Organization).

Access can also be set up using the individual cloud accounts, such as AWS IAM permissions usage.

Supressions

Many CloudHealth Secure State customers have their “aha” moment when they see the Suppressions feature, as it allows a finding/rule to be temporarily suppressed or permanently suppressed for a specific group.

The Suppressions menu is also accessed via the Actions tab, as illustrated here:

Suppressions can be set up to run indefinitely, or for just a finite amount of time.   Setting up a new suppression request usually also requires identifying yourself as requester, and adding a reason, so that an administrator can approve. This prevents users from simply suppressing something they find annoying and allows the security admin to get better control of the cloud environment.

Suppressions can also be created from the findings page, as shown here:

You can suppress an individual finding, or a group of findings with similar criteria to save time as well. This prevents unwanted alerting or noise from cluttering your security focused team’s time and efforts.

In conclusion, time is the most valuable commodity a cloud operations or infosec team member has today, and burnout is frequent due to an overload of tasks and “alert fatigue”. We would love to show you how CloudHealth Secure State can help streamline your team’s work flow, why not set up a 14-day free trial today?