Common security oversights within an AWS environment
There's often an assumption that AWS systems can't be tested, as they're hosted in the cloud; however, this is not the case. Discover common security oversights in AWS environments.
When looking at the security posture of an application environment, it's easy to overlook systems that are deployed in Amazon Web Services. Sometimes, there's an assumption that these systems cannot be subjected to security testing simply because they're hosted in the cloud; however, they can. There is also the assumption that, because they're running in an AWS environment, everything's secure. But this is not the case.
With the growing dependence on cloud services such as AWS, enterprise applications and their underlying systems hosted in the cloud have to be scrutinized for security flaws just like anything else, if not more.
Books could be -- and have been -- written about AWS security, and I encourage you to reference them for further information. In the meantime, here's some low-hanging fruit I often uncover in AWS environments that goes beyond traditional application security gaps, but can still create unnecessary business risks:
using the AWS root account for day-to-day administration, rather than just initial setup;
lack of multifactor authentication for key AWS accounts -- especially for root, service, and standard Identity and Access Management (IAM) user accounts;
lack of formal or proactive logging event management processes tailored toward security events using AWS CloudTrail or a third-party product, such as Cloud Conformity or CloudCheckr;
failure to encrypt or properly maintain CloudTrail -- or similar -- log files;
failure to address data classification and retention involving AWS S3 buckets;
weak IAM password policy configurations or policies that conflict with corporate domain password policies;
active IAM user accounts that have never logged in or no longer need access; and
You must take a holistic view of your AWS environment, including both internet-facing network hosts and applications, as well as internal network hosting applications. Look at the systems themselves via traditional vulnerability and penetration testing methods, but also go to the next level and look at your actual AWS configuration. Sometimes, just reviewing network diagrams that outline the AWS architecture can uncover security weaknesses. Looking at things from all angles, including documented policies and procedures applicable to AWS, will yield the best results.
You must take a holistic view of your AWS environment, including both internet-facing network hosts and applications, as well as internal network hosting applications.
Remember that the Pareto principle -- the 80/20 rule -- applies to everything in security, including your cloud-based application environment. It's up to you to find the vital few flaws -- the 20% -- that make up 80% of your cloud-based risks; some are technical in nature, while others are more related to administrative or operational issues. Either way, Amazon does not guarantee the security of your systems. Amazon, like virtually all other cloud service providers, is in the business of system uptime -- it's ultimately up to you to find and resolve cloud-centric security weaknesses.
Furthermore, AWS provides every account holder with tools to help improve security. And there are plenty of third-party options, as well, including dedicated tools like Cloud Conformity and vulnerability scanners such as Nessus that have AWS policy review capabilities. Use these tools to your advantage, as they contain a wealth of information that can be used to truly lock down AWS.
Like with traditional vulnerability scanners, the data produced by these types of tools can be overwhelming, so go for the quick wins first, such as the risks listed above, as well as any others you may deem a business risk. Use this information and combine it with Amazon's own guide -- "AWS Security Best Practices" -- and you'll know you have taken reasonable steps to address AWS security. Moving forward, your AWS environment will likely never be without security flaws, but the most important thing is you find the gaps and resolve them before someone else exploits them.
