Unused access credentials can threaten the security of your cloud infrastructure. The modern workplace sees it’s fair share of turnover; people move from company to company, employees retire, and individuals are sacked or made redundant. That’s just part of doing business, but these things have the potential to be major security risks if former employees still have access. In other words, is anyone deleting or deactivating their accounts after their farewell cake is gone and “jolly good fellow” echoes through cubicles? What happens when a bad actor gains access to a “dead account”?
Imagine a scenario where you get to work and begin reviewing your Amazon spend. You notice that there is a sudden spike in your bill and the activity in your AWS account and costs are going through the roof. You instinctively go into vigilante incident-response mode.
Why is this happening?
There are various scenarios that could cause a spike in spend and your protocol is to treat every incident as a potential threat. You might suspect someone may have planted bitcoin miner in your EC2 environment. Or perhaps there is a tremendous uptick of downloads/uploads to one of your S3 buckets, which makes you wonder if someone is accessing it and your organization’s’ most sensitive data is being syphoned off. Your morning cup of coffee is now cold and you think, “Oh no! Someone is accessing a secure non-public bucket that shouldn’t be accessible…”
You are experiencing the dawn of the dead accounts.
An old or unused AWS access key remains enabled in IAM and a bad actor has taken advantage of your mistake. How did the bad guy get in? Maybe there was a wide open S3 bucket or a snippet of code with account credentials was accidently checked into GitHub. Regardless, this dead account has reanimated and is back to haunt you. What’s even more frightening is that these don’t have to be “dead-accounts” to be dangerous. Even accounts that are barely used run just as high a risk for becoming patient zero in the zombie apocalypse.
As you’re watching the devastation unfold you have to ask – “Could I have prevented this?”
The answer is YES! Why did you wait for your AWS bill to arrive to detect a bad actor in your infrastructure? The sheer volume of damage a bad actor could do while you wait for your statement would decimate even the most resilient organization. This is why you need to set up continuous monitoring to proactively look for services popping up that you don’t expect or regions in use that you don’t use and/or didn’t approve.
In order to prevent an outbreak of any kind, deploy Evident Security Platform (ESP). Think of it as a zombie virus vaccine. ESP comes with an out-of-the-box security control for IAM user credentials – ESP will alert you to deactivate any user credentials that have been unused for a specified amount of time. It’s then a simple matter to use the AWS Identity and Access Management console to delete or deactivate the unnecessary keys. Even if you do suffer a breach, as long as user attribution is enabled on ESP, the zombie can be identified and quarantined immediately.
Keep in mind, old, unused credentials might still be stored in undeleted EBS volumes, forgotten software, on old hard drive backups, or burned into the memories of ex-employees for eternity. It’s important to keep access to your AWS resources locked down to just known actors. Disabling or removing unnecessary credentials will reduce the window of opportunity for malicious use of compromised credentials. Maintaining strict control of access keys means that they won’t fall into the hands of attackers.
And the good news is you can automate all of this with ESP – helping AWS infrastructures be zombie-free since 2013.