The cloud brings scalability, reliability and security features that allow companies of all sizes to run their online business efficiently. These powerful capabilities often bring a false sense of a “security is already done” mentality and organizations are prone to take a more relaxed approach to their security efforts. Additionally, while many of the cloud platform features are “built-in”, that doesn’t mean they are optimized for your organization out of the box – they still must be analyzed in the context of a larger security strategy and re-evaluated frequently.
The recent compromise of almost 200 million registered U.S. voters AKA, the Upguard RNC Breach, was accidentally exposed online due to an improperly configured database setting that resided in the cloud. Much has been written about this breach, so I won’t rehash that. Instead, I want to focus on issues that I’ve seen with cloud deployment:
- You must protect your data, no matter where it resides, cloud included
- The cloud won’t automatically apply your appropriate risk tolerance level, you must set it appropriately
- You must take steps to ensure each service, endpoint, etc. has been properly configured
- You must treat the applications you run in the cloud as if they were running in a hostile environment, taking steps to protect yourself
- In this particular case, S3 buckets and other services must be appropriately protected
The first lesson learned is that you still need to understand the underpinnings of the cloud infrastructure to take full advantage of its benefits. Had Upguard configured their AWS S3 bucket to not allow download or access privileges, this breach could have been avoided. This may sound oversimplified and in actuality, it sadly is - but the point remains that misconfigurations, both obvious and obscure, happen frequently with cloud operations; thus, regular expert scrutiny is necessary.
This is also a perfect example of why regular attack simulations and red teaming are necessary – had Upguard conducted these, they would have most likely found the dra-dw amazon subdomain, realized it was an attack vector, and secured it in a proper manner.
