Threat Modeling For Cloud Native Infrastructure

OWASP defines a threat model as a structured representation of all the information that affects the security of an application. It allows a view a view of applications and its environment through security lens. Threat models can be applied to virtually every digital system - serverless applications, cloud infrastructure, mobile and web applications.

However, threat modeling for cloud-native infrastructure requires a mindset shift ! In traditional security scenarios, heavy emphasis is made on the use of data flow diagrams, attack graphs, attack trees etc.

Realistically though, some of these approaches might hinder agility and not be easily digestible for DevSecOps teams. Developers and SRE teams use several tools and workflows for their daily work. Some of these tools & workflows would be better appreciated than the traditional threat modeling tools.

For example, observability tools like AWS X-Ray can be leveraged to understand attacker flows rather than using attack trees. If possible, both kids of visualization can be used. The key thing is empathy, the security pulse of the participants should be felt and used as a yardstick for selecting commensurate approaches.

Another really cool thing, a mix of qualitative and quantitative approaches is feasible. Cloud security solutions like Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platforms (CWPP) provide unimaginable insights into cloud infrastructure and applications. These tools can be useful for deriving info on cloud resources usage, deployment info (e.g. regions), configuration errors, vulnerabilities, security risk info e.t.c.

Furthermore, the references from OWASP e.g. the Threat Modeling document remain invaluable resources to strike a balance.

Neglecting threat modeling exercises in modern cloud environments is indeed a recipe for disaster. The sheer amount of complexity is beyond our mental models hence the need for well-structured, intentional, and pragmatic threat analysis.

Gladly though, it seems a lot of security teams are still passionate about threat modeling, the overwhelming reception I received from a related post on LinkedIn is evident! Wow 🎉

I recently went through an excellent AWS threat modeling workshop I deemed it instructive to share a few lessons I personally grabbed:

• Threat modeling is interdisciplinary & cross-functional! All stakeholders need to be part of the show; they probably have better context and understanding than security teams. The security folks' main job is to coordinate the session and wear different hats (black, grey, white …).🤠

• The target application or infrastructure should be split into smaller parts to enable deeper analysis. A complex AWS Connected Vehicle Solution was used in the workshop, going through the entire application in a go would not be optimal.🍕

• Leverage user stories to understand different use-cases and threat vectors. 🐞🐞

• Clear documentation is not optional. In the workshop a workbook is provided as a guide/template. Use your preferred documentation system e.g. Confluence. Hopefully, its the same system used by the other teams participating 😇

• Take advantage of 😷 Adam Shostack's 4 Question Frame for threat modeling:👇

👉 What are we working on? Use data flow diagrams to represent features and data flows between the various elements e.g. AWS databases, S3 , API gateway.

👉 What can go wrong? - What are the threat vectors to be considered and possible impacts. - STRIDE is super useful here.

👉 What are we going to do about it? This is about risk response strategies - avoid, mitigate, transfer or accept.

👉 Did we do a good enough job? This is really tricky and difficult to measure during the session. Lessons learnt are to be taken and applied to other parts of the infrastructure.