Secure software development: SDLC, design principles and threat modeling

Most security holes are not “badly coded lines” but badly made decisions: nobody thought about authorization, what happens on error was never defined, the admin panel was left open to the Internet. This week you learn how to put security inside the software life cycle (SDLC). The typical exam question is this: a short scenario is given and you are asked “which principle is violated?” or “which STRIDE category?”. A DREAD or risk calculation may also appear.

Golden rules:

1. Security is not a phase, it is every phase. It starts at requirements and doesn’t end at maintenance.
2. The default answer is “no”. If you are not sure, deny access.
3. Check every access. Checking once and forgetting is not enough.
4. Find threats systematically. STRIDE makes you question letter by letter and catches what you wouldn’t think of.
5. Rank risk by number. You can’t fix everything at once.

Secure SDLC (secure software development life cycle)

You get a secure SDLC by adding the security work to be done in each phase of the classic SDLC. Microsoft SDL, OWASP SAMM and BSIMM are different frameworks of this idea.

Why at the very start? Fixing a design flaw in the design phase is a diagram change. If the same flaw is found in a live system, code, data migration, customer notification and loss of reputation follow. The “cost of a late-found defect multiplies” curve in the literature is even steeper for security.

PITFALL · the “we’ll do a pentest at the end” approach. A penetration test shows the hole it finds, but fixing a design flaw afterwards is expensive. A pentest does not replace a secure SDLC, it is its final check.

Secure design principles (Saltzer & Schroeder)

The eight principles written by Saltzer and Schroeder in 1975 are still exam favorites today. We also add defense in depth, which is often included alongside them.

Fail-safe defaults: how it looks in code

// BAD: allows everyone when the service crashes
boolean canRead(User u, File f) {
    try { return acl.allows(u, f, READ); }
    catch (Exception e) { return true; }
}

// GOOD: deny when uncertain, log the event
boolean canRead(User u, File f) {
    try { return acl.allows(u, f, READ); }
    catch (Exception e) {
        log.warn("ACL check failed, denying", e);
        return false;
    }
}

The same idea applies to firewall rules: a “deny all” rule comes at the end, and what is allowed is written one by one (allowlist).

Defense in depth and probability

With independent layers, the probabilities of the attacker getting through each one are multiplied. Example: if the probability of getting past the WAF is 0.3, getting past in-application validation is 0.2, and getting past the database privilege restriction is 0.1, the probability of getting through all of them is:

$0.3 \times 0.2 \times 0.1 = 0.006$

Layers that look weak one by one are strong together. But note: if the layers share the same weakness (the same password, the same library), they are not independent, and the product is invalid.

TIP · how to find the principle. If the scenario has “too much privilege”, it is least privilege; “allow on error”, fail-safe; “checked once”, complete mediation; “secret algorithm”, open design; “one person is enough”, separation of privilege.

Threat modeling

Threat modeling looks for answers to four questions: What are we building? What can go wrong? What are we going to do about it? Did we do a good job?

Step 1: the data flow diagram (DFD)

You draw the system with four elements:

On top of these you draw trust boundary lines: between the Internet and the server, between the application and the database. Most threats appear in the flows that cross these boundaries, because one side should not trust the other’s data.

Step 2: STRIDE

You question each DFD element with six threat categories:

Example: for the “User → Login API” flow, S: logging in with someone else’s password; T: the request is modified on the way; R: the user denies logging in; I: the error message says “this email is not registered” and leaks the existence of the user; D: thousands of login attempts per second; E: trusting the role=admin field in the request.

Step 3: rank the risks

There are two common methods.

Risk = likelihood × impact. Likelihood 0-1, impact 1-10:

Order: T2 > T3 > T1. T1, with the greatest impact, comes last, because its likelihood is low.

DREAD. Five categories are scored 0-10 and averaged: Damage, Reproducibility, Exploitability, Affected users, Discoverability.

DREAD is subjective, so Microsoft has dropped it internally, but it still appears in textbooks and exams. CVSS is a more standard alternative.

Step 4: mitigation and verification

For each threat there are four options: mitigate, eliminate (remove the feature), transfer (insurance, a third party), accept (a documented decision). Then it is verified by testing that the mitigation really works.

Security requirements and misuse cases

A functional requirement says “what the system should do”. A security requirement says “what the system must not allow and how it must be protected”. A good security requirement is measurable and testable.

The way to find these requirements is to write misuse cases. In a normal use case the actor is “Customer” and the scenario is “Logs into their account”. In a misuse case the actor is “Attacker” (misactor) and the scenario is “Automatically tries a list of passwords”. A misuse case “threatens” the use case; a countermeasure “mitigates” the misuse case. Each misuse case yields a security requirement.

PITFALL · not writing a security requirement like a functional one. “Admins can delete users” is functional. The security side: “Only the admin role can delete, and every deletion is logged with who did it.” The second sentence is testable and closes the E and R threats.

Common mistakes

boolean canDelete(User u, Doc d) {
    try {
        return acl.check(u, d, "DELETE");
    } catch (Exception e) {
        return true;   // ACL service down, let it through
    }
}