Frequently asked questions

Can't find the answer you're looking for? Reach out to our customer support team.

How do I add Corrected Cloud monitoring for my account?

To enable Corrected Cloud in your AWS environment, simply utilise the provided CloudFormation template (either directly, or launched from Terraform). If you have multiple AWS accounts to add, you can re-use the same template in those accounts.

The provided CloudFormation template provisions AWS Eventbridge rules to send metadata about the actions performed in your account to our systems, utilising AWS CloudTrail. Additionally, a role with limited permissions is provided which allows us to check the current state - this is used when you first add Corrected Cloud, and then again infrequently as we add new checks for which we were not previously collecting data.

From time to time (2-3 times a year) you may be asked to update CloudFormation in order to allow us to support new AWS services.

Because we need to monitor all regions (security problems are not confined to regions that should be in use), the CloudFormation template we provide utilises CloudFormation StackSets to create AWS Eventbridge rules in every region.

What access to my AWS account does Corrected Cloud have?
We provide a CloudFormation template which provides only specific, limited access to the metadata within your AWS account to enable us to perform security monitoring. For a more detailed answer, please see What access do you have to my account?.
What resources do you create in my AWS account?

For Corrected Cloud to function we deploy two types of resources: a role and one AWS EventBridge rule per region. The role in your account has limited permissions and can be assumed from our account. This role allows us to fetch metadata about the current state of your environment, and is used when your account is first created, and then infrequently afterwards to gather data for newly created checks.

To create the EventBridge rule in every region, the provided template creates an AWS CloudFormation StackSet, which in turn creates one CloudFormation stack per region with the necessary AWS EventBridge ruleset. The AWS EventBridge rules send realtime management events from CloudTrail and relevant AWS security services to our API for real-time analysis. We analyse several hundred different types of events, with examples including IAM policy updates, EC2 instance creation and termination and security group attachment and removal.

I have multiple AWS accounts - how can I add Corrected Cloud to all of them?
We provide a CloudFormation StackSet template for use with AWS Organizations, enabling you to automatically deploy Corrected Cloud to all accounts in your orgaisation, or optionally just a specific Organizational Unit. This will also automatically deploy to newly created accounts.
How do you determine the priority for findings?

When creating a new alert, we focus on the ease and impact of someone exploiting the uncovered vulnerability.

For example, a world writeable S3 bucket is marked as critical - anyone could easily run up huge AWS bills on your account, or worse fill the bucket with illegal content, possibly causing your AWS account to be suspended.

By comparisson, whilst most competing tools would mark a lack of encryption at rest in an S3 bucket as high criticality or above, we mark this as low. This is because it would be almost impossible to exploit this lack of encryption to gain access to the data stored across many disks across multiple Amazon data centres. We of course would always recommend encryption at rest as a best practice, but when choosing what security problem to address next there may well be more immediate concerns to look at first.

How is this different to AWS GuardDuty?
AWS GuardDuty analyses activity within your account for suspicious activity that suggests compromise has occurred. Corrected Cloud analyses the configuration within your account to try and prevent a compromise from ever happening. We strongly recommend enabling both Corrected Cloud and AWS GuardDuty.
How is this different to AWS Config?

AWS Config provides a suite of tools to assist users with evaluating configurations in their environments.

AWS Config logs configuration changes across your account, and stores the history of changes. AWS Config Rules provide a way to programmatically (for example, by writing Python or Java code) provide alerts on configuration changes. This is useful for those managing environments who have both very clear ideas on what their environments should and should not look like, and a development team to implement this. AWS Config Managed Rules provide helpers for those creating rules to check for specific conditions - for example, “Does this SNS topic have encryption enabled?”. Again, those writing rules need to know what they wish to look for, and a team to implement these ideas.

AWS Config Conformance Packs provide canned collections of AWS Config Managed Rules for various purposes, primarily ‘operational best practice’ (for example, checking that multiple availability zones are in use, or whether DynamoDB has autoscaling enabled). Whilst some security focussed conformance packs are available, these are simplistic in nature, typically simple boolean checks (“Does this security group allow unrestricted SSH?”). It is left up to the users to evaluate the checks, work out what gaps exist, and implement AWS Config Rules to cover these gaps.

With Corrected Cloud, we take the responsibility for working out what problems may occur, what traps users can fall in to, and implementing suitable checks. Our in-house developed technology stack features full IAM policy and network traffic evaluation, allowing us to provide much more nuanced and detailed alerts, with realistic priorities. Where other tools may raise a simple alert “Security group allows unrestricted SSH”, we provide alerts based on the context it is used in. Such a rule when attached to an instance with a public IP and direct network access would provide a higher priority alert than when the rule was attached to one with only a private IP. Additionally, for users of AWS CloudFormation, Corrected Cloud provides the ability to perform checks before infrastructure is created, maximising the protection offered.

Can't I do all this with Splunk, Sumologic, Elastic or another SIEM?

If you are running a SIEM, you should already be ingesting all CloudTrail data. This is the same data used by Corrected Cloud to generate alerts.

Where the tools are different are that Corrected Cloud has an in depth understanding of the meaning of each CloudTrail event, the current state of the environment and the implications of that event. For a SIEM to have this level of detail, it would need to know the specifics of how AWS provides functionality for each service - something that doesn’t make sense in the case of a general purpose logging tool.

To give a concrete example, imagine an event in which a new EC2 instance is started. The event will show the ID of the security group used by that instance, and Corrected Cloud will use this to ascertain what network ports are open, and correlate this with the subnet in which this instance has been launched at the configuration of that subnet. By connecting multiple data points, Corrected Cloud can use this to provide an alert that an instance has been launched which allows Internet accessible RDP.

For customers using a SIEM, Corrected Cloud findings should be ingested and utilised in that way.