Secure AWS Workloads in the Cloud

Checklist For Securing Your AWS Workloads in The Cloud

In this article today, I will provide you with a checklist that you can use to make sure you have processes and programs in place for properly securing your workloads in the cloud. I will provide specific tips and resources for AWS, although this checklist can be used for any public cloud computing environment.

Take this checklist to your next meeting and review your current project.

Threat Modeling

Make sure your team is using a threat model to identify and maintain a current list of relevant threats to your application/system/workload.

Partner with your DevOps team as early in the process as possible and then continue to update the model all the way through production.

Don’t gloss over this step and if you don’t know how to create and use a threat model for cloud based applications, I will be writing a comprehensive article about this in the near future.

Identify and Validate Security Control Objectives

Often times in larger enterprise environments, security controls assessments can lean towards meeting compliance objectives versus helping you discover and document relevant gaps in your security posture.

Use a standard set of cloud-focused controls like the Cloud Security Alliance Cloud Controls Matrix and leverage the personalized information derived from your Threat Modeling process.

Document Attack Vectors & Attack Surfaces

Based on your threat model exercises for each workload, build a custom library of attack vectors and attack surfaces based on your cloud architecture. This makes future threat modeling exercises much more efficient and effective.

Get Connected

Stay up to date with both AWS and industry security recommendations by subscribing to trusted newsletters from AWS as well as a few select industry sources. Many security and cloud vendors use their blogs and newsletters for marketing purposes, however, AWS does a good job of sharing key information that will help keep you up to date on the latest cloud security matters.

Regular Review Cloud Provider Security Services/Features

AWS continues to develop and evolve their cloud security services and offerings, so make sure you are connected to your cloud service providers in a way that ensures a healthy level of awareness.

For example, I subscribe to the AWS Security Blog. As a matter of my daily routine, I check the blog daily to see if there is anything important or relevant that I need to be aware of. The Dark Reading Cloud Security website is also a good resource to put on your frequent reading list.

Automate Testing and Validation of Security Controls in Your CI/CD Pipeline

By automating your testing and validation of your CI/CD pipeline, you will make great strides in improving your security posture. Use relevant tools and automation to test and validate all security controls continuously and if you are not doing this right now, it needs to go to the top of your list.

For example, you should be scanning machine images and infrastructure as code templates for security vulnerabilities, irregularities, and drift from an established baseline at each stage.

Reducing the number of security misconfigurations introduced into a production environment is critical for your overall cybersecurity health. CI/CD pipelines offer a unique opportunity to enhance security at each stage of build and delivery. Also, CI/CD security tooling must also be kept updated to mitigate evolving threats.

Some common cybersecurity risk terms you should know

Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)

Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)

Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)

Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)

Likelihood: chance of something happening. (ISO 27001)

Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)

Risk: effect of uncertainty on objectives. (ISO 27001)

Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)

Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)

Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)

Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)

Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)

Conclusion

Thank you for reading. I hope you have found this useful in helping to guide you along the path of best practices when it comes to cloud computing security. I welcome your thoughts in the comments.

Further resources

• Cloud Controls Matrix
• AWS Security Blog
• Dark Reading Cloud Security
• Security Best Practices The Well Architected Way (Video)
• Automate Security on AWS (Video)

About the author: Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise.

Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier. Get Tim’s Free Cloud Security Journal

You can also visit his website: http://CloudSecurityLaunchPad.com

More content at plainenglish.io