Editor's note: This blog post reflects the author's own opinions and is not intended to describe the policies or procedures of the author's workplace or any other specific organization.
The OWASP Top 10 Web Applications Risks list in 2021 had a debutant all the way up at #4: Insecure Design. Since then, “Secure-by-Design” and “Shift-Left-Security” have gained a surge of awareness, acknowledgement and call-to-action.
The Secure Software Development Lifecycle (S-SDLC) is the process of planning, designing, coding, testing, deploying and maintaining every application within the guardrails of security, with the understanding that bringing security to the conversation, right at the project feasibility phase, is crucial to developing world-class, robust, resilient, cost-effective, and sustainable software.
The traditional approach to software development has been about gathering the business requirements, translating them to technical requirements, and building the software based on them. When software vulnerabilities were found – in the best case through in-house scans and penetration tests, or in worst, found and exported by threat actors – “security” was quickly slapped onto the already-built software.
Not considering “security” as an essential part of the SDLC increases the risk profile of the software and opens it up to losses – both financial and reputational. It also limits the number and type of security control options, as these must be “bolted on” to an already architected solution. Further, the mitigation of the risk leads to increased costs and timelines, while still only creating software with added-on security and shaky foundations.
An essential piece of “secure-by-design” is threat modeling. Believe it or not, almost all of us already threat model in our everyday lives.
At home, we consider all the entry points: doors and windows, understanding that threat actors can enter through them and gain access to your most valuable assets: our family. We build in controls: fortified doors, barred windows, security cameras, alarms, locks, motion detectors, and lights. That is pretty much threat modeling!
Here are a few essential steps to threat modeling for software applications, while designing them:
Identify the Flows
Every software is built to satisfy use cases. And use cases have flows, process flows and data flows.
Understanding what is being built and how it will operate is the crucial first step to threat modeling. Plot the boundaries of the software and what flows across them, the internet, the demilitarized zone (DMZ), and the internal network.
Identify the Assets
What are assets in the flow? Personally Identifiable Information (PII)? Servers? Passwords? Secrets? Session IDs? Identify everything that is of value and must be protected, and that will leave an impact if its confidentiality, integrity or availability is compromised.
Identify Vulnerabilities
Look for weak points. Points of entry. Points of transition. Points of temporary storage. What could be a weakness that could be exploited? Input that is not validated, weak password policies, lack of mutual authentication and logs with sensitive data are all examples of vulnerabilities.
Identify Threats
Threat actors could be external, internal unprivileged users and internal privileged users. Threats could be accidental or intentional/malicious. Mapping out the different threats and threat actors, and their path of attack by exploiting the various vulnerabilities and impact on the security of the assets, is an essential step to understanding the threat landscape for the application.
Identify Controls
Identifying what controls (preventative, detective, administrative, technical) can be part of the design to help reduce the severity of the threats is an essential next step. Input validation to prevent injections, certificate exchange to prevent spoofing, and MFA to override weak passwords, generic logs, and databases encrypted with strong ciphers are all examples of controls that can be designed into the software architecture.
Threat modeling methodologies
There are various methodologies for threat modeling. Some common ones are:
- STRIDE: This stands for Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of Privilege. It was developed by Microsoft and is the most mature methodology in use.
- PASTA: Process for Attack Simulation and Threat Analysis is a risk-centric methodology that has seven stages, each with multiple actives under it.
- VAST: The Visual, Agile, and Simple Threat (VAST) Modeling method is based on ThreatModeler, an automated threat-modeling tool. It requires creating two types of models: application threat models and operational threat models.
- OCTAVE: The Operationally Critical Threat, Asset and Vulnerability Evaluation method is a risk-based strategic assessment and planning method for cybersecurity. It focuses on determining organizational risks and does not address technological risks.
Regardless of the methodology in use, creating secure software requires developers, architects and security professionals to all adopt a threat-modeling frame of mind, ensuring that threats are identified and that controls are designed in to address them at the nascent stages of the SDLC.
About the author: Divya Aradhya (Div-yuh Uh-RAHD-yuh) is a Senior Application Security Architect at Citi with a career spanning close to 20 years. She holds an MS in Cybersecurity and the CISSP and CISM certifications. Divya spent the first half of her career as a C++ and .NET developer and then meandered into the application security and DevSecOps space. She works as a strong empathetic ally for the developer community even while diffusing security into every developer practice. Divya is passionate about protecting digital assets, safeguarding children and the elderly from cybercrimes, and is focused on making information security simple, de facto, and intrinsically adaptive.