The Philosophy of Corrected Cloud
At Corrected Cloud, we set out with a clear mission to reduce the stress of those working with AWS by making it easy to have confidence that the infrastructure they are responsible for is built in a secure manner.
As part of this, when building our solution we followed the following core principles which guide our thinking about what we build and how build it.
- Provide as few alerts as possible
- Provide realistic priorities for alerts
- Provide feedback about problems as early and quickly as possible
Provide as few alerts as possible
Many security tools seem to focus on producing as large a list as possible of all the things ‘wrong’.
We explicitly seek to do the opposite - to provide details that cover only real problems that exist right now.
Why do we do this? Because alert fatigue is a very real problem, with large volumes of scientific research on its negative effect. When a tool provides large lists of ‘issues’, where many, even most can be discounted, people start to ignore the output of that tool. By drowning people in alerts, we simply train them to ignore them, no matter how well meaning the alerts may be.
By contrast, we want Corrected Cloud to be a tool that developers always pay attention to. We want them to have the confidence that if Corrected Cloud tells them there is a problem, they can be confident they need to fix it.
What does this mean in practice?
Let’s look at a concrete example - the creation of a security group with a single rule. Let us imagine that the rule allows traffic from everywhere to the ‘Remote Desktop’ port. Most tools would immediately generate an alert on this, but we would not.
Why not? Because this security group is inactive. It is not attached to anything, and there is no threat created by its existence. If the rule were to be attached to an instance, we would immediately raise an alert, and we can have a higher confidence that this alert will be responded to - because users know that when Corrected Cloud highlights something they need to pay attention because there is a real security impact.
Provide realistic priorities for alerts
It’s not good enough just to tell people about a problem - we need to tell them how urgent it is to look at. Is it something that we can create a ticket about in the backlog? Is this something we should get everyone to drop what they are doing to look at?
In order to do this well, we need to understand the context of the problem. A security group rule allowing access to the ‘Remote Desktop’ port from anywhere on an instance in a public subnet with a public IP address needs to be reviewed more urgently than when that same rule is attached to an instance on a private subnet behind NAT.
We also acknowledge that priorities might differ between organizations, or even between teams within a single organization. For some, encryption at rest might be a ’nice to have’ or even entirely unimportant given the type of data they are working with. For others, encryption at rest might be something they are contractually or legally obligated to utilize, with serious consequences for violations. We make it easy for organizations and teams to ensure their alerts are appropriate for their use case by allowing adjustments to the defaults we provide.
Provide feedback about problems as early and quickly as possible
At Corrected Cloud, we believe that if a developer deploys a change and is immediately notified of a problem with it, they are much more likely to correct it. This is even more true if they get the alert in their development environment, and especially true if they are told as part of their code review process.
Corrected Cloud is built from the ground up as an event driven tool. As soon as a change is made to your AWS infrastructure, our tool immediately evaluates the impact of that change and notifies the relevant people - typically in under five seconds.