We’ve been busy in 2018…

Cloud security platforms like Cloud Conformity are only as useful as the underlying rules powering the engine that checks your infrastructure. Currently, our platform checks your infrastructure for just under 400 rules across 43 different services. This is the most comprehensive AWS management tool currently available in the market. However, if we were to let up our velocity for even just a few months, changes to AWS would mean that our users are exposed to security risks that previously did not even exist. This is why our team is entirely dedicated to keeping up with Amazon Web Services’ pace of change.

As proof, here are a few of the new rules we’ve developed in 2018 and are currently actively checking for.

DynamoDB — Backup and Restore

Part of the reliability pillar of the Well-Architected Framework, turning on and using on-demand backup and restore will ensure your data remains safe from application errors that may slip through your QA process. Furthermore, many different security and best practice compliance standards often have clauses requiring the long-term archival of data. Request a backup of your DDB tables at the frequency your compliance standard requires, and rest assured that your database’s performance will not suffer during the backup process.

ELBv2 — AWS ALB Security Policy

Part of the security pillar, this rule prescribes the continuous updating of the security policies you use to regulate communication between your the Elastic Load Balancers and the wider internet. This is important because these ELBs may have access to critical EC2 instances or other resources within your infrastructure. Using an outdated security policy may mean that you are exposed to older vulnerabilities that extremely easy to exploit for hackers seeking access to your system. Patch your security policy means these older vulnerabilities will be closed off.


This is a no-brainer. There is no reason why you should not be using GuardDuty. Unless your AWS account is non-critical (you don’t care what happens inside it), GuardDuty should always be enabled. It will help you detect if any of your AWS resources are actively being probed by potential hackers or malicious users. If you currently use Cloud Conformity, GuardDuty findings will be presented in the same way other security violations are, enabling yourself and your team to use the same workflow when resolving findings from GuardDuty and the rest of our rules.

AWS Organizations — Detect Configuration Changes

Another no-brainer. If you’re using our Real Time Threat Monitoring, you will be instantly notified if anyone attempts to change any configuration within your organization. Securing your AWS Organizations service is as important as controlling access to your root account. AWS Orgs allows you to centralize multiple AWS accounts into an organization that you create and administer. Unauthorized changes can have wide-reaching impact.

Lambda — One IAM Role Per Function

For those of you using serverless compute, your individual functions should not share permissions. Follow the Principle of Least Privilege, each Lambda function should have its own IAM role: a Lambda function working with users should not have access to the accounts table, and vice-versa. If ever one of your functions is compromised, following this rule will limit the potential damage to your infrastructure.

Elasticsearch Service — Encryption at Rest

Elasticsearch is increasingly being used by organisations as a primary or secondary data storage technology. This means the greatest care needs to be taken when the technology is used for production data, and ever more so for data that contains users’ personally identifiable information. If you were to follow the security pillar of the Well-Architected Framework, you would need to apply defence-in-depth to your infrastructure. Enabling encryption at rest for your Elasticsearch clusters means that any stolen data will be unusable by unauthorized users.

Simple Email Service — Prevent Cross Account Access & Close Exposed Identities

As one of AWS’ oldest services, access to SES is still defined in the AWS resource itself, like S3 policy. Unless you have a very good reason for it, it is important to make sure that your SES resources are not accessible to unknown AWS accounts, or the public. Without this safeguard, anyone can impersonate you via email communication that will look exactly like if it were coming from your system, creating a huge security risk for anyone that normally receives email communication from you.

This is just a small sample of the newest rules available for automated audit (and sometimes automated resolution: github.com/cloudconformity/auto-remediate) by Cloud Conformity. So far in 2018, we’ve released a total of 32 new rules, with lots more on the way.

For a full list of rules, consult our free access Knowledge Base here: