There are many benefits of Cloud computing, such as flexibility and quick deployments; there are also clear security advantages. But cybersecurity is a shared responsibility between the cloud provider and the customer. The vast majority of Cloud security failures are the customers’ fault. To achieve strong security, we as users need to consider the risks and prioritize cybersecurity in the Cloud.
This is a summary of what I have learned from working with the automated tool securiCAD and compliantly with AWS Security Requirements. Hopefully, it can be of good help to all of you developers and security professionals out there working in AWS.
To help you improve your Cloud security, AWS has developed the AWS Well-Architected Framework. Using the Framework, you will “earn current architectural best practices for designing and operating reliable, secure, efficient, and cost-effective workloads in the cloud”. The Security Pillar of the Framework discusses a number of security foundations including how to operate workloads securely.
Let’s get into the action and dig into some of the key requirements of how to operate workloads securely in AWS.
“Identify and prioritize risks using a threat model: Use a threat model to identify and maintain an up-to-date register of potential threats. Prioritize your threats and adapt your security controls to prevent,
detect, and respond. Revisit and maintain this in the context of the
evolving security landscape.”
Threat Modeling is typically a manual process. However, manual Threat Modeling can be very time-consuming, considering the extreme complexity that is growing at the same time as the models themselves. Not to mention the fact that one must prioritize to prevent, detect and respond to threats and that task is simply not possible to do manually, because of the time it would take and since it is too complex for one human brain to handle.
In other words, automated threat modeling taught me that it is possible to analyze complex environments and the process is way more time-efficient than I could ever imagine.
“Identify and validate control objectives: Based on your compliance requirements and risks identified from your threat model, derive and validate the control objectives and controls that you need to apply to your workload. Ongoing validation of control objectives and controls help you measure the effectiveness of risk mitigation.”
As I previously mentioned, the complexity of the environment grows rapidly in regard to the model size but often so do the risks as well. In the best of both worlds, it’s obvious that one would like to fix all potential threats. But, as we all know, that is not possible and what it often boils down to is what risks are most likely to happen and what can we do to prevent them from happening?
Automated tooling provides me with insights on key risks, what measures and controls I need to apply to my environment, and how to prioritize what would be the most efficient use of my time.
“Automate testing and validation of security controls in pipelines: Establish secure baselines and templates for security mechanisms that are tested and validated as part of your build, pipelines, and processes. Use tools and automation to test and validate all security controls continuously.”
If you ask me, the word continuously and manually doesn’t belong together when it comes to testing and validation of security controls because it is too time-consuming to do manually.
Automated tooling allows me to continuously test my security during the development process. And the best thing of all is that tests are running on a digital twin that did not interfere with the live environment.
To summarize my experience with the Security Requirements from the AWS Well-Architected Framework: Skip the manual Threat Modeling and save yourself and your colleagues some time, use an automated Threat Modeling tool.