Hand reaching for key in the clouds

AWS Password Monitoring & Security Events

cloudcoreo Paul Allen 0 Comments

For many organizations, security is a key concern as they move business critical workloads to the cloud. There have been many claims about the security of the cloud ranging from “inherently insecure” to “more secure than your datacenter,” but the truth is, cloud datacenters really are more secure than yours. The issue lies in the fact that a cloud environment needs to be managed appropriately—a daunting task in a rapidly evolving environment. This includes, like any critical system, carefully managing login access and passwords to your key cloud assets and user accounts.

Password management sounds easy, but often times we simply don’t know what is going on in all of our cloud accounts at all times. As security and DevOps professionals, it becomes our job to monitor and educate our peers rather than lock them down and stifle innovation.

Password Policy & Enforcement

Cloud provides broader access to infrastructure for your development team, allowing them to move fast and innovate. The rapid pace of innovation is, and should be, a huge asset to your organization. However, this also inevitably means an ever-increasing number of AWS accounts, each with its own policies, IAM roles, and surface area to manage. And as control becomes distributed across your team, you need to diligently monitor and audit your password policy. Unfortunately, this often entails more work than you may expect.

Security has been touted publicly as the number one focus of AWS and other cloud providers. All of their innovation and added services rank a distant second to security. AWS, for instance, won’t even send a faulty disk drive back under warranty. That disk is wiped then physically shredded, because nothing leaves the datacenter.

Knowing the lengths cloud providers go to in order to protect your organization, the least you can do is set up a strong password policy and make sure it is set for any and all of your AWS accounts. In their IAM Best Practices, Amazon recommends requiring your users to create strong passwords and to rotate their passwords periodically. If you already have a strong password policy set, great! But that’s only step one.

Step two is validating that these policies are being enforced, and more importantly, that they are being enforced when it matters most.

The Cloudbleed Effect

On February 23, 2017, news of the Cloudbleed bug broke:

“Cloudbleed is a major flaw in the Cloudflare Internet infrastructure service that causes the leakage of private session keys and other sensitive information across websites hosted behind Cloudflare.”
Serious Bug Exposes Sensitive Data from Millions Sites Sitting Behind Cloudflare, Hacker News

Cloudbleed, believed to be worse than the Heartbleed bug, caused a commotion when it was publicly disclosed because Cloudflare is a popular service that potentially impacted many customers. While Cloudflare’s open and frank discussion of what went wrong, what the risks are, and what you should do has done much to calm nerves, security-minded companies should (and many did) require administrators to change passwords, particularly for accounts that have administrator rights and are used on a day-to-day basis.

Simply put, Cloudflare admits they cannot guarantee that username/password data did not leak. (Again, their blog is full of relevant information for those who want more data about the bug.) Plus, the forgetful nature of humans (and the overwhelming number of passwords we need to remember these days) makes it likely that many of your colleagues use the same password for everything—another topic we can get into later.

Mitigating Cloudbleed & Other Security Events

Cloudbleed is only the latest in a string of security events—think Yahoo, LinkedIn, Tumblr, Target, Home Depot…the list goes on. Each report of a new security breach comes with the recommendation to “change your passwords.” It helps if your password policy already requires your users to change their passwords every 30 or 90 days, but what if a security event happens one day after your team has just rotated their passwords? How can you adapt your password policy to accommodate these one-off events?

CloudCoreo was built for this exact type of flexibility. Our Cloud Audit already allows you to check that passwords have been rotated within a given time frame, so we simply added another rule that will check if all users have rotated their passwords after a specific date.

How the Cloudbleed rule appears in the CloudCoreo interface

When the IAM-cloudbleed-passwords-not-rotated rule finds accounts that haven’t been changed since Cloudbleed was resolved, this violation card is shown in your Cloud Audit results in the CloudCoreo interface.

I like to call these occurrences “security events” because it seems less apocalyptic. Rather than raising an alarm, running around the company yelling “Cloudbleed hit us!” you can just say, “The world just experienced another security event.”

In this case, the “security event” was Cloudbleed, so our new rule is called IAM-cloudbleed-passwords-not-rotated, and it uses the AWS API to check for any accounts that have not changed their password since Feb 22nd (because Cloudflare resolved the issue on Feb 21st). Now, when you run our AWS Audit on your account, we will return a list of any accounts that haven’t changed their password since Cloudbleed was resolved. This makes it easy to calmly (yet briskly) walk over to Jim and Monica and let them know, “Hey guys, you haven’t changed your passwords since the last security event took place.”

Cloudbleed & Other Audit Rules

If you want to see the code for the Cloudbleed rule, you can view it directly on GitHub. It is fairly simple: Check for all accounts that have passwords and see when they were last rotated! If they were not rotated after midnight on the 22nd of Feburary (UTC) than we need to have a conversation with those users. The best part is, when the world has another “security event,” all that needs to be done is to change the date (and probably the description of the event, for clarity’s sake).

The code driving the IAM-cloudbleed-passwords-not-rotated rule, written in CloudCoreo's Domain-Specific Language (DSL).

The code driving the IAM-cloudbleed-passwords-not-rotated rule, written in CloudCoreo’s Domain-Specific Language (DSL).

All of our audit rules work this same way—they are best practice rules that can be adapted to match the organizational policies, like password rotation, you want to continuously enforce in a way that can respond instantly to world events. We’ve created this platform for ultimate flexibility so that when even the most complex combination of policies come together to form a security hole, CloudCoreo can find, alert, and resolve the issues.

Keep in mind that while there are dozens of advanced attacks that can be carried out against an organization, it’s most often these simple and easy to miss violations that can leave you open to security breaches. Our goal is to help you find those needles in the haystack early and often.

Conclusion

Whether you are trying to simply audit account policies in the cloud, or reacting to a large-scale risk like Cloudbleed, having an advanced set of tools to help determine where the weaknesses are and offer descriptions of remedies is essential to security automation and secure DevOps. Security is not a moment in time. It is an ongoing and ever evolving situation. Staying informed and adapting and releasing quickly is the number one defense an organization has against attackers.

 

Leave a Reply

Your email address will not be published. Required fields are marked *