3 common mistakes that lead to misconfigured cloud environments.

2. Filthy Cloud Environments

“Cleanliness is next to godliness” – Babylonian and Hebrew proverb

I don’t care about your physical hygiene, unless I’m sitting next to you at a conference, but your cyber asset hygiene is very important to your organization’s security. One way to improve cyber asset hygiene is to have a governance naming scheme for your security groups so they aren’t a jumbled mess.

It also means cleaning up your digital trash when you are done. Cloud providers make it really easy to create new resources on demand, a great thing when you want to try out a new idea. But when a team moves on, what happens to those resources? They need to be cleaned up. Hopefully, all the teams are doing this as they build but too often teams abandon their work in process when a high-priority task suddenly gets dropped on them. They then move on to the next thing and previous resources are abandoned increasing their organizational attack surface.

Regular Audits

This is why regular audits are so important. AWS has published guidelines advising you to audit your configuration at four intervals.

• During organizational lifecycle events, i.e., whenever someone joins, leaves, or changes role within the organization.
• Whenever services or software are activated or deactivated within your AWS account.
• Whenever an attack has been carried out against your infrastructure, or you suspect an unauthorized party may have accessed your account.
• Periodically, regardless of changes in your organization or account.

By regularly auditing your system, you can clean up any lost resources and ensure that you’re familiar with all rules and policies. Cleaning up unrequired resources reduces the attack surface for potential attackers and often helps reduce costs. At a minimum, you should:

• Delete inactive users
• Delete any roles that are no longer required.
• Remove EC2 instances that are no longer needed.
• Delete any key pairs no longer used
• Delete any unrequired security group rules.
• Check for new users and ensure all users with console access have MFA enabled
• Ensure that logging and alerting are enabled for all relevant services.
• Review permissions for services that use resource-based policies such as KMS and S3. This is particularly important for S3 as S3 leaks are becoming more common

3.  Policy Blindness

“Our team is great DevOps.” “How do you know that?” “They told us so.”

Another area we often see organizations blind to is their teams’ compliance with governance policies. Teams set governance standards, and then mistakenly believe that everyone will follow through. For instance, all the teams at a company may agree to not allow public access to their storage containers. If the organization doesn’t have visibility into the actual compliance numbers then they are working blind. Those organizations often learn too late, that in reality, everyone was using the cloud defaults and assets are now exposed.

“Trust but verify” – Russian Proverb

Using a Security-as-Code tool like Paladin Cloud teams can make sure they aren’t flying blind. By turning policies into security-as-code an organization can learn their compliance rate to best practice policies. Teams can also understand who is accountable and work with asset owners to remediate any violations.

Put it into practice

You are now ready to Increase the security of your organization’s cloud configuration management by avoiding these mistakes

Avoid misconfigurations as code by implementing peer and programmatic review of your infrastructure-as-code.

Avoid filthy cloud environments and reduce your attack surface by cleaning up with regular cyber assets audits.

Avoid being policy blind by implementing a tool to provide visibility into your compliance.

For more on this topic: The Best Practices for Cloud Security Configuration Management