[See also the second installment in this series "Threat Modeling - Team Building".]
We have mentioned Threat Modeling in many of our recent posts including the Zen of Venn series (Static versus Dynamic Analysis, Left-Shifting, and Ops) and "Zero" Trust and Boundaries. Cylidify offerings feature Threat Modeling training and practice development as well as model development and analysis for new and existing solutions. At Microsoft, I helped develop the practice and Threat Modeling Tool (TMT) running exercises with a variety of product teams to design, analyze, track, and do remediation of issues. This allowed me to develop a depth and breadth of Threat Modeling experience with ingrained lessons on diversity and value propositions. Threat Modeling is still a cornerstone of the Microsoft SDL and a practice I highly recommend.
It may be obvious, but we at Cylidify are fans and advocates of Threat Modeling as well as implementation experts. This post provides a high-level introduction to Threat Modeling, linking our previous posts and kicking off a blog post series. It is not intended as a full primer, but there is significant information in our previous posts (links above), much available online (see references at the end of this post), and more to come from Cylidify. This post's theme is "Starting out..." which is key with this practice. You can ease into Threat Modeling, then ramp-up and improve over time — "one foot in front of the other," which can actually work in security and privacy.
Threat Modeling is a long-standing, but evolving practice that forms an effective transition point between static and dynamic analysis. It relies on a static diagram of the system to model the components, data, interactions, and controls, then shifts to dynamic in the analysis of the model. Notes on Threat Modeling:
Helps build and maintain an architecture, design, and operational model (which every solution should have). This can serve many purposes in your organization and is critical in the context of audits, certifications, and incident response.
Inclusive of disciplines and helps converge and align teams earlier in an SDLC. Architects, developers, support and services, and operations staff can be included providing technical and team building benefits.
Two distinct phases — design and analysis. These are typically done together, but you can do design without analysis (especially very early) and analysis can be done more frequently as a checkpoint to changes — e.g., to later stage operational configuration or controls.
Design doesn't have to be UML or captured in a specific medium or tool. The details needed for Threat Modeling such as (trust) boundaries, endpoints, data and key/credential stores, data flows (with direction and "sensitivity"), etc. can be overlaid onto your existing diagrams (Visio, Enterprise Architect, etc.) or started as paper or whiteboard captures.
Designs can be "zoomed" depending on phase and audience adding implementation and operational details as they develop in the SDLC. This supports agile methodologies and allows the various disciplines to be included as needed.
Analysis can be done in many ways: whiteboard and table top exercises, gamification (e.g., EoP or threat hunts), tooling (see references below), etc. There are also opportunities to pull analysis out into your testing and operational practices improving checklists and automation.
Tracking of security requirements and issues surfaced via Threat Modeling is critical. These issues should be tracked in the same database as other project tasks and issues/bugs for proper visibility, prioritization, and burn downs.
Tools that "crawl" existing deployments to produce an operational diagram are emerging. If you can produce a diagram from something that is deployed (perhaps fed into a Graph database?), it can have huge value in correctness, visibility, and convergence of models and teams. Everyone wants a diagram of what is deployed and operational — being able to do manual and automated Threat Modeling on that diagram is a win-win(-win).
Again, the theme and primary takeaway of this post is get started! If you are already started, leverage that momentum to improve and refine the practice by Left-Shifting and increasing coverage of your solutions. The best value is with end-to-end approach — develop a threat model early during architecture and design, then keep it current via checkpoints as the solution progresses toward release and then as deployments carry it forward to changes in configuration, maintenance, and updates. However, you can do Threat Modeling at any point in an SDLC, make it ad-hoc, and get good value (or ROI). Refactoring and redeployment, incidents, transitions (ownership, servicing, operations, etc.), or new integrations can all be opportunities to create, update, or (re)analyze a threat model. Formal training is good, but not a prerequisite since it can be "on the job." Cylidify has found that designing, analyzing, and iterating a threat model in the context of an actual solution (developing or deployed) can be that immersive, running start many organizations need. Ask us about our introductory engagements, which are time-bound and lower-cost, but still raise awareness, build enthusiasm, and converge teams — all while producing reusable artifacts and real ROI.
References:
Microsoft Threat Modeling overview and tool (TMT)
Other tools: ThreatModeler, UML, Tutamantic, PyTm, IrisRisk, OWASP Threat Dragon, etc.
Adam Shostack: Threat Modeling book, LinkedIn learning, RSAC 2019 session, and EoP game
