Welcome

Welcome to the very first post on the Corrected Cloud Blog. My name is Sam Bashton, and I am the founder and lead developer on Corrected Cloud.

I wanted to take this opportunity to write about why I decided to build Corrected Cloud.

Corrected Cloud is a security tool built for the real world. It exists to improve the security configuration of AWS environments, and by equal measure eliminate that uneasy feeling that maybe there’s something, somewhere that is going to allow an attacker to compromise you. We want to spot problems before they have been exploited - within seconds of those problems being created.

Corrected Cloud is far from the first tool to try and improve security, or even the first tool to try and improve Cloud security. In my career I have used many of the existing tools, and found using them exasperating. In general, the products that existed before Corrected Cloud are essentially an automated auditors checklist. That might not sound like such a bad thing in principle, but let’s look at a typical usage scenario for such a product.

Let’s imagine you are a product owner at small to medium sized enterprise. One day, you are contacted by someone in your security team, telling you that a security product they are using has warned them of a very high severity problem - your environment has a security group which allows traffic from anywhere in the world to the Windows Remote Desktop port.

You read the email in horror for two reasons - firstly because this sounds pretty serious (it’s very high severity!), and secondly because you and your team are already behind schedule and now you have to divert one or more members of your team from the work you’re already late delivering to address this very high severity problem.

First things first - you ask one of your team members to stop what they are doing and check the alert is accurate. You quickly get the response back - the security group does exist, and port 3389 (remote desktop) is open from anywhere. The team member isn’t sure what is using this security group, and so is reluctant to just close the port.

You message the team on Slack asking if anyone knows what this security group is for, and a discussion ensues. No-one seems to know what it could be used for, but everyone is certain that they wouldn’t have created it. One member of the team writes a small script to list everything using this security group, and says that it seems to be unused. You are doubtful - the security tool is report this as a very high severity incident - surely a rule which isn’t even being used doesn’t qualify as very high severity?

You look on in horror at your project getting further derailed, with now almost every single team member speculating on what could be done about this bad security group rule.

You decide to ask one team member to look into this more deeply, and ask everyone else to get back to their work on their current project. After a couple of hours, the team member comes back with their answer. The security group was created seven months ago, when someone who has now left was trying to debug something. On further investigation, the rule was attached to an instance that once ran for a few minutes - most likely because the VPC doesn’t allow external traffic anyway, so the rule wouldn’t have had any effect.

You let out an exasperated sigh, ask the team member to delete the security group, and reply to the security team letting them know the very high severity problem is now resolved.

If it was you in this scenario, how would you feel? More importantly, how quickly are you likely to act next time you can an alert from your security team? For many people, events like this reduce trust in their security tooling and even their colleagues in the security team.

Corrected Cloud avoids these situations by using contextual data. For the example of a security group, we would look at what was using it. In this instance, nothing is using the security group, so it has no current security implications. If it then gets attached to an instance which has no external Internet access, this warrants a higher priority warning. If it is attached to an instance with an Internet facing IP address, this should be of much higher priority still. We do everything we can do ensure the findings we create accurately reflect the real world impact of the current configuration.

At Corrected Cloud, we understand that there are people who need to read and act on our recommendations. These people have priorities of their own, and whilst security is obviously important to them, we need to earn their trust by providing them with clear information that accurately reflects the urgency with which they need to address problems. Giving people a huge list of things that might be a problem or could become a problem is not useful.

Corrected Cloud exists to give people confidence - in their environments, and in their teams. We want to let people be able to get on with their work, reassured that if they inadvertently configuring something in a way that could be a security problem they will be told.