Today we will be understanding, how a product is build under a Secure Software Development Lifecycle (SDLC) and we will also try to understand where does Threat Modelling actually applies into Secure SDLC process. We will try to keep things simple and beginner friendly, so that even a newbie can understand well and we will also see an e-commerce application example at the very end.
Please start your engines (brain)…
Secure Software Development Life Cycle (SDLC) is a methodology where we are trying to implement security at each and every stage of SDLC, and not just at the top layer of a product/application . You might be wondering what are these actual stages, so there are a total of 5 stages when it comes to SDLC as mentioned below:
- Security Requirements
- Design <- Here is where Threat Modelling kicks in (we will discuss this)
- Development
- Testing
- Deployment & Maintenance.
In all the above steps, security is applied so that the application becomes robust and hardened and once the product/application creation is finished, we are left off with a very small number of vulnerabilities/ flaws/ issues. Let's discuss each step carefully.
- Security Requirements
We here define which data needs to be protected such as PII, username and password, DB information, role based access regarding how a user should be provided access to a resource, etc.
2. Design
Here is where the Threat Modelling (STRIDE — one of the specific threat modelling approach) applies and where we actually think like an attacker:
Firstly let's discuss STRIDE:
S — Spoofing (can a user impersonate another user)
T — Tampering (Can a data be tampered, say for example, can price be changed)
R — Repudiation (No maintenance of Logs in the backend)
I — Information disclosure (PII leak, sensitive information leak, etc.)
D — DOS (attacker makes the site un-accessible, impacting Availability factor of the CIA Triad)
E — Elevation of Privileges (Normal user -> Admin privileges)
Don't worry we will map all this in the example section at the end.
Now, as we know what STRIDE is, let's discuss a but about how Threat Modelling is done in the Design phase.
a. Architecture: Analyze What is the architecture, think of it like a blueprint of the house before actually creating the house, like how many rooms are present in the house, how many windows, how many doors, what all are the ways to move from one room to another room, etc. Basically, a very high level overview of the product / application.
b. Design: Analyze what are the crucial assets within the organization which would be a pain point if compromised (like user accounts, payment details, PII, etc.)
c. Entry Points: Analyzing what all are the entry points for the application, such as login form, rest APIs, various endpoints with parameters which could identify users or user data, etc.
d. Trust Boundaries: Analyze trust boundaries (Data moving from low trust (browser) to High trust (DB)). Another example would be from to Third Party service providers to Backend DB. It is an imaginary trust boundary, for which we need to create a map in our mind.
e. Threat: Analyzing what could be the threat if an attacker access the crucial assets (user accounts, PII, etc.) → Mitigations: Providing mitigations for vulnerabilities identified.
f. Mitigations: How can we mitigate the threats which we had identified.
3. Development
In this phase, we perform Static Application Security Testing (SAST) for secure coding at Development phase, using manually + making use of automated tools such as checkmarkx for scanning the code when it is static and not in a running state (dynamic).
4. Testing
In this phase the Dynamic Application Security Testing (DAST) + Penetration Testing (manually) is done of the application, meaning, we will make use of automated scanner such as Burpsuite Professional, Qualys, Acunetix, Owasp ZAP, etc. to find vulnerabilities / flaws in a dynamic state while the application is deployed and is in a running state.
5. Deployment & Logging
Here, we will Log and Monitor all the traffic for suspicious or malicious activities, while the application is into the production environment.
Now, as we understand the 5 stages of Secure SDLC process + Threat Modelling in the Design phase, let us club all of it together to understand using an e-commerce application example.
The company is discussing about the e-commerce product and the developers have not yet started coding. Now, applying Secure SDLC:
- Security Requirements — What data needs to be protected ? Username, password, address, payment card details, etc. What kind of access should be given to whom ? Admin v/s customer roles, guest user roles, etc.
- Design + Threat Modelling (STRIDE) —
Architecture: Draw the blueprint of the app — frontend, backend, database, third-party APIs.
Assets: Identify valuable stuff (user accounts, payments, order history).
Entry Points: Look at all doors and windows — login forms, APIs, mobile app, admin panel.
Trust Boundaries: Which parts trust others? Browser (low trust) → API server → Database (high trust). Data crossing these boundaries is high risk.
Threats (STRIDE):
- S = Spoofing → Can someone pretend to be another user?
- T = Tampering → Can someone change the price in an order?
- R = Repudiation → Can someone deny placing an order?
- I = Information disclosure → Can sensitive data leak?
- D = Denial of Service → Can attacker crash the site?
- E = Elevation of Privilege → Can a normal user get admin rights?
- Mitigations: Decide how to prevent threats.
- Use strong passwords + MFA → prevent spoofing
- Encrypt database → prevent info leaks
- Input validation → prevent tampering
- Logging → prevent repudiation
3. Development — Write code securely using best practices. SAST (Static Analysis): Automatically check your code for vulnerabilities before running it. Example: Check for SQL injection in your backend code.
4. Testing — DAST (Dynamic Analysis): Test the app while it's running — try to "attack" it like a hacker. Penetration Testing: Ethical hacker tries to find vulnerabilities. Example: Test if login page can be bypassed, test payment API security.
5 . Deployment & Maintenance — Monitor the app for unusual activity: failed logins, suspicious payments. Keep the app updated with security patches. Log everything for forensic analysis in case of attacks.
I hope that I was able to provide you with a high level overview of Secure SDLC + Threat Modelling concept which is essential in Security interviews.
Thanks.
Happy to connect on Linkedin: https://www.linkedin.com/in/toufique-belim