Building Security Judgment

1. Why Should You Care?

You’ve learned the algorithms. You know the pitfalls. But security isn’t a checklist—it’s a judgment call.

Every security decision is a trade-off between cost, usability, and protection level. There’s no “perfectly secure”—only “secure enough for this threat model.”

This article teaches you how to think about security, not just implement it.

2. The Security Mindset

Developers vs. Security Engineers

Developer mindset:
"How do I make this work?"
- Focus on functionality
- Happy path thinking
- Trust inputs
- Assume good faith

Security mindset:
"How can this be broken?"
- Focus on failure modes
- Adversarial thinking
- Distrust everything
- Assume malicious intent

Thinking Like an Attacker

For every feature, ask:
1. What assumptions does this make?
2. What if those assumptions are wrong?
3. Who has access to what?
4. What's the worst that could happen?
5. How would I exploit this if I were malicious?

Example: Password Reset
Developer: "User clicks link, enters new password, done."
Attacker:
- What if I intercept the email?
- What if I guess the reset token?
- What if I request reset for someone else?
- What if I use the token twice?
- What if I change the email after requesting reset?

The Paranoid Questions

Before deploying any feature:

Authentication:
- Can someone authenticate as another user?
- What happens if credentials are stolen?
- Are there rate limits on attempts?

Authorization:
- Can users access others' data?
- What if IDs are guessable?
- Are permissions checked at every layer?

Data handling:
- Where does data exist in plaintext?
- Who can access the encryption keys?
- What's in the logs?

Failure modes:
- What happens when things break?
- Do error messages leak information?
- Is there a safe fallback?

3. Threat Modeling

What Is a Threat Model?

A threat model answers:
1. What are we protecting? (Assets)
2. Who might attack it? (Threat actors)
3. How might they attack? (Attack vectors)
4. What could go wrong? (Impact)
5. How do we prevent it? (Mitigations)

Without a threat model, you're either:
- Securing against threats that don't exist
- Missing threats that do
- Spending resources inefficiently

STRIDE Framework

Microsoft's STRIDE categories:

S - Spoofing
    Pretending to be someone else
    Mitigation: Authentication

T - Tampering
    Modifying data or code
    Mitigation: Integrity checks, signatures

R - Repudiation
    Denying actions taken
    Mitigation: Logging, audit trails

I - Information Disclosure
    Exposing confidential data
    Mitigation: Encryption, access control

D - Denial of Service
    Making system unavailable
    Mitigation: Rate limiting, redundancy

E - Elevation of Privilege
    Gaining unauthorized access
    Mitigation: Least privilege, sandboxing

Practical Threat Modeling

Step 1: Draw the system
┌──────────┐     ┌──────────┐     ┌──────────┐
│  Client  │────▶│   API    │────▶│ Database │
└──────────┘     └──────────┘     └──────────┘
                       │
                       ▼
                 ┌──────────┐
                 │  Cache   │
                 └──────────┘

Step 2: Mark trust boundaries
┌─────────────────────────────────────────────┐
│ UNTRUSTED                                   │
│  ┌──────────┐                               │
│  │  Client  │                               │
│  └──────────┘                               │
└─────────────────────────────────────────────┘
          │ Trust Boundary
          ▼
┌─────────────────────────────────────────────┐
│ TRUSTED (but verify)                        │
│  ┌──────────┐     ┌──────────┐              │
│  │   API    │────▶│ Database │              │
│  └──────────┘     └──────────┘              │
└─────────────────────────────────────────────┘

Step 3: List threats at each boundary
Client → API:
- Injection attacks
- Authentication bypass
- Rate limit abuse
- Data tampering

API → Database:
- SQL injection
- Privilege escalation
- Data exfiltration

Threat Actor Profiles

Different attackers have different capabilities:

Script Kiddie:
- Uses existing tools
- Low sophistication
- High volume attacks
- Defend: Basic security hygiene

Cybercriminal:
- Financially motivated
- Moderate sophistication
- Targeted attacks
- Defend: Strong authentication, monitoring

Nation State:
- Unlimited resources
- Advanced capabilities
- Strategic targets
- Defend: Defense in depth, assume breach

Insider:
- Already has access
- Knows the system
- Trust exploitation
- Defend: Least privilege, audit logs

What's YOUR threat model?
A personal blog doesn't need nation-state defenses.
A bank handling billions does.

4. Assessing Risk

Risk = Probability × Impact

                    │ Low Probability │ High Probability │
────────────────────┼─────────────────┼──────────────────┤
High Impact         │ Monitor         │ Fix Immediately  │
────────────────────┼─────────────────┼──────────────────┤
Low Impact          │ Accept          │ Fix Eventually   │
────────────────────┴─────────────────┴──────────────────┘

Example assessments:

SQL injection in login:
- Probability: High (common attack)
- Impact: High (full database access)
- Priority: Fix immediately

Timing attack on comparison:
- Probability: Low (requires precision)
- Impact: Medium (credential leak)
- Priority: Fix eventually

XSS in admin panel:
- Probability: Low (limited users)
- Impact: High (account takeover)
- Priority: Monitor/fix

The Economics of Security

Attackers do cost-benefit analysis too:

Cost of attack vs. Value of target

Low-value target + High attack cost = Safe
High-value target + Low attack cost = Breached

Your goal:
1. Reduce target value (minimize data stored)
2. Increase attack cost (better security)
3. Reduce attacker reward (limit blast radius)

Real example:
- Target: Password database
- Without hashing: One breach = All credentials
- With bcrypt: One breach = Months of cracking per password
- Attack cost increased 1000x, same value to protect

What Is “Good Enough”?

Security is always relative to:

1. What you're protecting
   - Personal blog: Basic security
   - E-commerce: Strong security
   - Healthcare: Compliance + strong security
   - Defense: Maximum security

2. Who you're protecting against
   - Random internet: Standard practices
   - Targeted attackers: Advanced measures
   - Nation states: Specialized defenses

3. Consequences of failure
   - Embarrassment: Basic protection
   - Financial loss: Strong protection
   - Safety/lives: Maximum protection

4. Resources available
   - Startup: Prioritize highest risks
   - Enterprise: Comprehensive coverage
   - Government: Defense in depth

"Good enough" = Risk reduced to acceptable level
               within available resources

5. Common Security Decisions

When to Use What

Password Storage:
- Always: Argon2id or bcrypt
- Never: MD5, SHA-1, plain SHA-256

Symmetric Encryption:
- Default: AES-256-GCM
- Alternative: ChaCha20-Poly1305
- Never: DES, 3DES, ECB mode

Asymmetric Encryption:
- Key exchange: X25519 or ECDH P-256
- Signatures: Ed25519 or ECDSA P-256
- Legacy: RSA-2048+ with OAEP

Random Numbers:
- Always: secrets module or OS CSPRNG
- Never: random module for security

TLS:
- Minimum: TLS 1.2
- Preferred: TLS 1.3
- Never: SSL, TLS 1.0/1.1

Decision Framework

When choosing a security control:

1. What's the industry standard?
   - Start with established best practices
   - Deviate only with good reason

2. What does the threat model require?
   - Match protection to threats
   - Don't over-engineer

3. What are the tradeoffs?
   - Performance impact
   - Usability impact
   - Maintenance burden

4. What's the failure mode?
   - Fail secure vs. fail open
   - Graceful degradation

5. Can we detect if it fails?
   - Logging and monitoring
   - Alerting on anomalies

Red Flags in Security Discussions

Warning signs that someone doesn't understand security:

"We don't need to worry about that"
- Famous last words before a breach

"Security through obscurity"
- Attackers will figure it out

"We'll add security later"
- Technical debt compounds

"It's behind a firewall"
- Firewalls are one layer, not the only layer

"We use [buzzword] so we're secure"
- No single technology solves security

"Nobody would want to attack us"
- Everyone is a target

"Our users wouldn't do that"
- Never trust user behavior

"That's too unlikely to happen"
- Unlikely events happen constantly at scale

6. Building Your Skills

Learn from Breaches

Every breach report is a lesson:

1. What was the vulnerability?
   - Technical flaw
   - Process failure
   - Human error

2. How was it exploited?
   - Attack technique
   - Tools used
   - Time to exploit

3. How was it detected?
   - Monitoring caught it
   - Reported by attacker
   - Third party discovery

4. What could have prevented it?
   - Technical controls
   - Process improvements
   - Training

Resources:
- Krebs on Security
- Troy Hunt's blog
- Company breach reports
- CVE database

Practice Offensive Security

Understanding attacks helps build defenses:

Beginner:
- OWASP WebGoat
- HackTheBox starting point
- TryHackMe free rooms

Intermediate:
- Capture The Flag (CTF) competitions
- Bug bounty programs (read-only first)
- Vulnerable VMs (DVWA, Metasploitable)

Advanced:
- Code review for vulnerabilities
- Penetration testing courses
- Security certifications (OSCP)

You don't need to be an expert attacker.
But understanding attacks makes you a better defender.

Security Review Checklist

# Questions to ask during code review

class SecurityReviewChecklist:
    """
    Use this as a mental framework when reviewing code.
    """

    authentication = [
        "Are credentials stored securely (hashed passwords)?",
        "Is authentication checked on every request?",
        "Are sessions managed securely?",
        "Is there brute-force protection?",
    ]

    authorization = [
        "Is access control checked at the right layer?",
        "Are all sensitive operations protected?",
        "Is the principle of least privilege followed?",
        "Can users access other users' data?",
    ]

    input_handling = [
        "Is all input validated?",
        "Are queries parameterized (no SQL injection)?",
        "Is output encoded (no XSS)?",
        "Are file uploads restricted?",
    ]

    cryptography = [
        "Are standard algorithms used?",
        "Are keys managed properly?",
        "Is randomness from a secure source?",
        "Is sensitive data encrypted at rest/in transit?",
    ]

    error_handling = [
        "Do error messages leak information?",
        "Are exceptions handled securely?",
        "Does the system fail safely?",
        "Are errors logged appropriately?",
    ]

    data_handling = [
        "What sensitive data is stored?",
        "Is sensitive data in logs?",
        "How is data backup handled?",
        "Is data properly deleted when needed?",
    ]

7. Working with Non-Security People

Communicating Risk

To executives:
- Speak in business terms (risk, cost, impact)
- Use analogies ("This is like leaving the vault unlocked")
- Quantify when possible ("A breach could cost $X million")
- Present options with tradeoffs

To developers:
- Be specific about the vulnerability
- Explain the attack scenario
- Provide concrete fixes
- Don't just say "this is insecure"

To users:
- Explain the "why" not just the "what"
- Make secure behavior easy
- Don't blame for mistakes
- Build security into the product

When to Push Back

Sometimes you need to say no:

Push back when:
- Deadline pressure is overriding security
- "Just this once" exceptions accumulate
- Security is being treated as optional
- Known vulnerabilities aren't being fixed

How to push back:
- Explain the specific risk
- Propose alternatives
- Document the decision
- Escalate if necessary

Document everything:
"On [date], I raised concerns about [issue].
The decision was made to [accept/defer].
Risk owner: [name]."

Building Security Culture

Security is everyone's job:

For developers:
- Include security in code review
- Run security training
- Make secure coding the default
- Celebrate security fixes

For organizations:
- Make reporting vulnerabilities safe
- Reward security contributions
- Include security in planning
- Learn from incidents without blame

For products:
- Security by default settings
- Clear security documentation
- Easy security configuration
- Regular security updates

8. The Judgment Framework

Making Security Decisions

When faced with a security decision:

1. IDENTIFY the asset
   What exactly are we protecting?

2. ASSESS the threats
   Who might attack and how?

3. EVALUATE the risks
   Probability × Impact

4. CONSIDER the options
   What mitigations are available?

5. WEIGH the tradeoffs
   Cost, usability, maintenance

6. DECIDE and document
   Make a choice, record the reasoning

7. REVIEW periodically
   Threats change, reassess regularly

Living with Uncertainty

Security has no finish line:

Accept that:
- Perfect security doesn't exist
- New vulnerabilities will be discovered
- Attackers evolve their techniques
- Your threat model may be wrong

Plan for:
- Regular security reviews
- Incident response
- Continuous improvement
- Learning from failures

Remember:
- Good enough today may not be tomorrow
- Defense in depth provides resilience
- Detection is as important as prevention
- Recovery capability is essential

9. Summary

Three things to remember:

1. Think like an attacker. For every system, ask: “How would I break this?” Consider authentication bypass, data access, trust boundaries, and failure modes. The defender has to be right everywhere; the attacker only needs to be right once.

2. Security is risk management. There’s no “perfectly secure”—only tradeoffs between cost, usability, and protection level. Understand your threat model, assess risks realistically, and invest resources where they matter most.

3. Build judgment through practice. Study breaches, practice offensive techniques, review code with security in mind, and learn from every incident. Security judgment comes from experience, not just knowledge.

10. Series Conclusion

You’ve come a long way:

Part 1: You learned why cryptography matters and the fundamental primitives.

Part 2: You mastered symmetric encryption—AES, modes of operation, and key derivation.

Part 3: You understood asymmetric cryptography—RSA, Diffie-Hellman, and elliptic curves.

Part 4: You explored hashes, MACs, and digital signatures.

Part 5: You saw how these pieces combine in real protocols—TLS, password storage, key management.

Part 6: You learned why good crypto isn’t enough, and how to think about security holistically.

The most important lesson: Cryptography is a tool, not a solution. Use it correctly, but remember that security is a system property that requires ongoing attention to code, operations, and human factors.

Now go build secure systems. And when you’re unsure, remember: the best security decision is often the simplest one that adequately addresses the threat model.

Good luck.