- \n
- The AWS environment that I am specifically evaluating is the most common, which is the Elastic Cloud Computing (EC2) Web Service.<\/li>\n<\/ul>\n\n\n\n
AWS Infrastructure<\/h2>\n\n\n\n
Amazon Web Services uses a Shared-Responsibility Model for the Security Infrastructure of their virtual environments, which works tremendously well due to its cloud-based nature. As you can see on AWS\u2019 own model below, AWS secures the background infrastructure that allows your virtual environment to run, the storage, the database accessed and the networking side, while the Client is responsible for the security of their platform, its applications, and general security configurations that you would have on any other network. Leaving the upper layer security of the environment up to the Client allows them to manage and tweak the security based on the clients needs efficiently and effectively.<\/p>\n\n\n\n
![\"\"](\"https:\/\/sites.wp.odu.edu\/cmayo\/wp-content\/uploads\/sites\/25864\/2023\/07\/Shared_Responsibility_Model_V2.59d1eccec334b366627e9295b304202faf7b899b-1024x561.jpg\")
<\/figure>\n\n\n\nAWS Security Controls<\/h2>\n\n\n\n
- \n
- AWS provides heavy security within its networks, as each virtual environment has built-in Firewalls and automatically all traffic for its data storage facilities.<\/li>\n\n\n\n
- AWS CloudTrail \u2013 Cloud Deployment Management Software<\/li>\n\n\n\n
- AWS CloudWatch \u2013 Built-In and Scalable Network Monitoring Software<\/li>\n\n\n\n
- AWS GuardDuty \u2013 Threat Detection Service that can even mitigate several threats without user intervention<\/li>\n\n\n\n
- AWS IAM \u2013 Multi-Factor Authentication Service and Federated Access For virtual environments<\/li>\n\n\n\n
- AWS HSM and Key Management \u2013 Amazon Proprietary Hardware Security Module and Cryptographic key Management<\/li>\n<\/ul>\n\n\n\n
Possible Vulnerabilities<\/h1>\n\n\n\n
No Operator Access<\/h2>\n\n\n\n
The AWS Nitro System is the virtualization platform that the EC2 Instance uses to build its applications from. It comes with the previously mentioned security features, with one of them being a lack of AWS Operator Access because of the Shared Responsibility Model. AWS Operators are heavily limited in their access and abilities within a Client\u2019s EC2 environment. This is not a high-level vulnerability, however this stops an AWS Operator from helping secure the environment with debugging the system. In fact, if the Client needed assistance with an issue within the environment, the AWS Operator would have to host a separate environment and try to recreate the issue on their side. Now if there was an issue such as a malicious code in the Operating System that the user didn\u2019t know how to debug, the issue would be hard to recreate for the AWS operator.<\/p>\n\n\n\n
User Misconfigurations<\/h2>\n\n\n\n
AWS\u2019 Shared Responsibility Model leaves the responsibility of configuring the environment\u2019s policies and security up to the user. This can lead to major vulnerabilities within the environment due to human error in every part of the user\u2019s configurations. Simple issues such as not using secured ports and lacking enough authentication levels on their endpoints can create significant room for threats.<\/p>\n\n\n\n
Resources<\/h2>\n\n\n\n