Scrolls
5 min read
On this page

Security Mindset

Think Like an Attacker

Security engineering starts with a mental shift. Most developers ask "how do I make this work?" A security-minded engineer asks "how can this be abused?" Every feature you ship is something an attacker can probe, twist, and exploit.

This does not mean paranoia. It means systematic skepticism. When you design a file upload feature, you think about malware. When you build a search endpoint, you think about injection. When you add an admin panel, you think about who else might find it.

Attackers do not follow your intended user flow. They read your JavaScript, intercept your API calls, fuzz your inputs, and look for the one path you did not test. The security mindset means considering those paths before they do.

The Defender's Disadvantage

Defenders must protect every entry point. Attackers only need to find one weakness. This asymmetry is fundamental. You can get 99 things right and still get breached because of the one endpoint you forgot to authenticate.

This is why security cannot be bolted on at the end. It must be considered at every design decision, every code review, every deployment.

The CIA Triad

The CIA triad is the foundational model for thinking about security properties. Every security control exists to protect one or more of these.

Confidentiality

Information is accessible only to those authorized to see it.

Breach example: 2017 Equifax breach
- 147 million Americans' SSNs, birth dates, addresses exposed
- Attackers exploited Apache Struts vulnerability (CVE-2017-5638)
- Data was not encrypted at rest
- Confidentiality failure at multiple layers

Confidentiality controls include encryption, access controls, data classification, and network segmentation.

Integrity

Information is accurate and has not been tampered with.

Breach example: 2020 SolarWinds supply chain attack
- Attackers inserted malicious code into SolarWinds Orion build process
- 18,000 organizations installed compromised updates
- Integrity of the software supply chain was violated
- Signed updates were technically valid but contained malware

Integrity controls include hashing, digital signatures, audit logs, and code signing.

Availability

Systems and data are accessible when needed.

Breach example: 2016 Dyn DDoS attack
- Mirai botnet launched massive DDoS against DNS provider Dyn
- Took down Twitter, Netflix, Reddit, GitHub for hours
- Availability failure cascaded across the internet
- Attack used IoT devices with default credentials

Availability controls include redundancy, load balancing, DDoS mitigation, and disaster recovery.

Using the Triad in Practice

When evaluating a security decision, ask which leg of the triad is at risk:

Scenario: Should we encrypt database backups?
- Confidentiality: Yes. Unencrypted backups expose all data.
- Integrity: Encryption alone does not guarantee integrity. Add checksums.
- Availability: Encryption adds complexity. What if you lose the key?
  Store keys separately with documented recovery procedures.

Defense in Depth

No single security control is sufficient. Defense in depth means layering multiple controls so that if one fails, others still protect you.

Layers of Defense

Layer 1: Network — firewalls, network segmentation, IDS/IPS
Layer 2: Infrastructure — patched OS, hardened configs, minimal services
Layer 3: Application — input validation, authentication, authorization
Layer 4: Data — encryption at rest, encryption in transit, access controls
Layer 5: Monitoring — logging, alerting, incident response

Each layer operates independently. A WAF (web application firewall) might catch a SQL injection attempt, but your application should also use parameterized queries. If the WAF is bypassed or misconfigured, the application-level defense still holds.

Real-World Example

The 2013 Target breach illustrates defense in depth failure:
1. Attackers compromised an HVAC vendor's credentials (Layer 1 bypassed)
2. Network was not segmented — HVAC network reached POS systems (Layer 2 failed)
3. POS malware scraped credit cards from memory (Layer 3 absent)
4. Data was exfiltrated without detection (Layer 5 failed)
5. FireEye alerts were generated but ignored by the security team

Any single working layer could have prevented or contained the breach.

Threat Modeling

Threat modeling is the structured process of identifying what you are protecting, who might attack it, and what the consequences are. It should happen during design, not after deployment.

STRIDE Framework

Microsoft's STRIDE provides a systematic way to identify threats:

S — Spoofing:       Can an attacker pretend to be someone else?
T — Tampering:      Can an attacker modify data or code?
R — Repudiation:    Can an attacker deny their actions?
I — Information Disclosure: Can an attacker access unauthorized data?
D — Denial of Service:     Can an attacker make the system unavailable?
E — Elevation of Privilege: Can an attacker gain higher access?

How to Threat Model

Step 1: What are you building?
  Draw the system. Identify components, data flows, trust boundaries.

Step 2: What can go wrong?
  Walk through each component with STRIDE. Be specific.

Step 3: What are you going to do about it?
  For each threat: mitigate, accept, transfer, or avoid.

Step 4: Did you do a good job?
  Review with the team. Revisit when the system changes.

Practical Example

System: User authentication service
Trust boundary: Internet <-> API gateway <-> Auth service <-> Database

Threats identified:
- Spoofing: Attacker uses stolen credentials -> Mitigate with MFA
- Tampering: Attacker modifies JWT in transit -> Mitigate with signature verification
- Info Disclosure: Error messages reveal stack traces -> Mitigate with generic errors
- DoS: Brute force login attempts -> Mitigate with rate limiting
- Elevation: Regular user accesses admin endpoints -> Mitigate with RBAC checks

The "Assume Breach" Mentality

Traditional security focused on preventing breaches. Modern security assumes they will happen and designs for containment and recovery.

This is not defeatism. It is realism. Every major organization has been breached or will be. The question is not "will we be breached?" but "when we are breached, how bad will it be?"

What Assume Breach Looks Like in Practice

- Encrypt data at rest (not just in transit)
- Segment networks so a breach in one area does not compromise everything
- Log everything and monitor for anomalies
- Have an incident response plan before you need one
- Practice the plan with tabletop exercises
- Limit blast radius: principle of least privilege, short-lived credentials
- Rotate secrets regularly, not just when compromised

The SolarWinds Lesson

The SolarWinds attackers had access to thousands of networks for months.
Organizations that practiced assume-breach principles fared better:
- Those with network segmentation limited lateral movement
- Those with robust logging detected anomalies sooner
- Those with least-privilege access limited what attackers could reach
- Those without these controls suffered complete compromise

Security is Not a Feature

Security is not a checkbox on a Jira ticket. It is a property of the entire system, like performance or reliability. You cannot "add security" to a finished product any more than you can "add performance" to a slow one.

Wrong: "We'll add security in the next sprint."
Right: "Security is part of every sprint."

Wrong: "The security team will review it before launch."
Right: "Every engineer considers security in every code review."

Wrong: "We passed the pentest, so we're secure."
Right: "The pentest found issues we fixed. We'll test again next quarter."

Security is everyone's responsibility. Security teams set standards, build tooling, and respond to incidents — but every engineer who writes code, configures infrastructure, or reviews a pull request is making security decisions.

Common Pitfalls

  • Security through obscurity: Hiding your source code or using non-standard ports is not security. Assume attackers will find everything. Kerckhoffs's principle: a system should be secure even if everything about it is public knowledge, except the key.

  • Checklist mentality: Following a compliance checklist does not mean you are secure. PCI DSS compliance did not prevent the Target breach. Checklists are a floor, not a ceiling.

  • Ignoring the human element: The most sophisticated technical controls fail when an employee clicks a phishing link. Social engineering is consistently the easiest attack vector. Training matters.

  • One-time security: A pentest is a snapshot. Your attack surface changes with every deployment. Security must be continuous — scanning, monitoring, reviewing, updating.

  • Assuming trusted environments: Internal networks are not safe. The 2021 Colonial Pipeline attack started with a single compromised VPN password. Zero trust means verifying every request regardless of network location.

  • Over-engineering low-risk systems: Not everything needs the same level of protection. A public blog does not need the same controls as a payment system. Spend your security budget where the risk is highest.

Key Takeaways

  • Think like an attacker: every feature is attack surface, every input is suspect, every assumption is a potential vulnerability.
  • The CIA triad (confidentiality, integrity, availability) provides the framework for evaluating security decisions.
  • Defense in depth means layering controls so no single failure compromises the system.
  • Threat modeling should happen during design using structured frameworks like STRIDE.
  • Assume breach: design for containment and recovery, not just prevention.
  • Security is a property of the system, not a feature to be added later. It is every engineer's responsibility, not just the security team's.