"AppSec Series #12: Threat Modeling, Penetration Testing, Security Monitoring and Compliance"

Series Navigation

← Part 11: DevSecOps — Security in CI/CD Pipelines

Threat Modeling — STRIDE

STRIDE is a systematic way to identify threats. For every component in your architecture, ask all six questions:

S — Spoofing        Can an attacker pretend to be another user/service?
T — Tampering       Can data be modified in transit or at rest?
R — Repudiation     Can actions be denied? Is there an audit trail?
I — Information Disclosure  Can sensitive data be exposed?
D — Denial of Service       Can the service be made unavailable?
E — Elevation of Privilege  Can an attacker gain more permissions?

STRIDE Applied — Login API Example

Component: POST /api/auth/login

S (Spoofing):
  Threat: Credential stuffing — attacker uses leaked username/password lists
  Control: Rate limiting, account lockout, MFA, breach password detection

T (Tampering):
  Threat: MitM attack intercepts login and modifies response
  Control: HTTPS with HSTS, certificate pinning for mobile apps

R (Repudiation):
  Threat: User denies making a purchase — no proof they logged in
  Control: Structured audit log with IP, user agent, timestamp for every login

I (Information Disclosure):
  Threat: Error message reveals whether email exists ("No account with that email")
  Control: Same error for wrong email and wrong password

D (DoS):
  Threat: Attacker floods login with 10,000 requests/second — CPU exhaustion
  Control: Rate limiting per IP, CAPTCHA after failures, WAF

E (Elevation of Privilege):
  Threat: JWT role claim manipulated (alg:none attack, weak secret)
  Control: Strict JWT validation, HS256 with 256-bit random secret or RS256

Threat Modeling Process

Step 1: Define scope
  - What are we threat modeling? (feature, service, system)
  - What is in/out of scope?
  - What are the assets? (data, functionality)

Step 2: Draw the architecture (Data Flow Diagram)
  [User] → HTTPS → [Load Balancer] → [App Server] → [Database]
                                   ↑
                               [Auth Service]
  Mark trust boundaries (internet → DMZ → internal)

Step 3: Enumerate threats (apply STRIDE to each component)

Step 4: Rate each threat (DREAD or CVSS)
  D — Damage potential    (0-10)
  R — Reproducibility     (0-10)
  E — Exploitability      (0-10)
  A — Affected users      (0-10)
  D — Discoverability     (0-10)
  Risk Score = (D+R+E+A+D) / 5

Step 5: Define mitigations for each high-risk threat

Step 6: Validate mitigations are implemented

# Threat modeling as code — track threats in YAML
# threat-model.yaml
threats:
  - id: TM-001
    component: "POST /api/auth/login"
    category: "Spoofing"
    description: "Credential stuffing using leaked passwords"
    severity: HIGH
    likelihood: HIGH
    risk_score: 8.5
    mitigations:
      - "Rate limiting: 5 attempts per minute per IP"
      - "Account lockout: 5 failures → 15 min lock"
      - "MFA: required for admin accounts"
      - "Breach detection: check HaveIBeenPwned API"
    status: MITIGATED
    implemented_by: "auth-service v2.3"
    verified_date: "2024-01-15"

  - id: TM-002
    component: "S3 bucket: customer-data"
    category: "Information Disclosure"
    description: "S3 bucket accidentally made public via misconfiguration"
    severity: CRITICAL
    likelihood: MEDIUM
    risk_score: 9.0
    mitigations:
      - "Block all public access at account level"
      - "Bucket policy denies public access"
      - "AWS Config rule: s3-bucket-public-read-prohibited"
      - "Automated notification if public access enabled"
    status: MITIGATED

Penetration Testing Methodology

Penetration testing is authorised simulation of attacks. The methodology:

PTES (Penetration Testing Execution Standard):

Phase 1: Pre-engagement
  - Written authorization (CRITICAL — without this it's illegal)
  - Define scope (IP ranges, domains, excluded systems)
  - Define rules of engagement (no DoS, no data exfil)
  - Emergency contacts

Phase 2: Reconnaissance
  - Passive: OSINT, DNS, public information
  - Active: port scanning, service enumeration

Phase 3: Vulnerability Assessment
  - Identify vulnerabilities in discovered services
  - Map attack surface

Phase 4: Exploitation
  - Attempt to exploit vulnerabilities
  - Achieve objectives (read sensitive data, escalate privileges)

Phase 5: Post-Exploitation
  - Lateral movement
  - Persistence
  - Data exfiltration simulation

Phase 6: Reporting
  - Executive summary (for management)
  - Technical findings (for developers)
  - Remediation guidance
  - Risk ratings (CVSS scores)

Reconnaissance Tools

# Passive reconnaissance — no traffic to target
# OSINT: discover emails, subdomains, employees
theHarvester -d target-company.com -b all

# Find subdomains
subfinder -d target-company.com -o subdomains.txt
amass enum -d target-company.com

# Check certificate transparency logs (passive subdomain enum)
curl "https://crt.sh/?q=%25.target-company.com&output=json" | \
  python3 -c "import json,sys; [print(x['name_value']) for x in json.load(sys.stdin)]" | \
  sort -u

# Find exposed secrets in GitHub
# GitHub search: org:target-company "API_KEY" OR "password" OR "secret"

# Active reconnaissance
# Port scan
nmap -sV -sC -T4 -oN scan-results.txt target.example.com

# Web enumeration
nikto -h https://target.example.com
gobuster dir -u https://target.example.com -w /usr/share/wordlists/dirb/common.txt

Common Exploitation Techniques (for testing your own systems)

# SQL Injection testing
sqlmap -u "https://app.example.com/search?q=test" \
       --cookie "session=your-session-cookie" \
       --level 3 --risk 2 \
       --dbs

# XSS testing with XSStrike
python3 xsstrike.py -u "https://app.example.com/search?q=test"

# JWT manipulation
# Tool: jwt_tool
python3 jwt_tool.py TOKEN -T  # tamper mode
python3 jwt_tool.py TOKEN -X a  # none algorithm attack
python3 jwt_tool.py TOKEN -C -d wordlist.txt  # crack HS256

# SSRF testing
curl "https://app.example.com/fetch?url=http://169.254.169.254/latest/meta-data/"
curl "https://app.example.com/fetch?url=http://localhost:8080/admin"

# Directory traversal
curl "https://app.example.com/files?path=../../../../etc/passwd"
curl "https://app.example.com/files?path=..%2F..%2F..%2Fetc%2Fpasswd"

# IDOR testing
# Login as User A, note your user ID in API responses
# Change ID to User B's and see if you get their data
curl -H "Cookie: session=USER_A_SESSION" \
     https://app.example.com/api/users/USER_B_ID/profile

Security Monitoring and Incident Response

Security Logging Architecture

Logging Architecture:
│
├── Application Logs    → CloudWatch Logs → Splunk/ELK
├── AWS CloudTrail      → S3 → Athena queries
├── VPC Flow Logs       → S3 → GuardDuty
├── WAF Logs            → Kinesis → OpenSearch
└── OS/Container Logs   → Fluent Bit → SIEM

Alert pipeline:
  Finding → SNS → Lambda → PagerDuty → On-call Engineer

# Security events you MUST alert on immediately:

CRITICAL_ALERTS = [
    # Authentication
    "Multiple failed logins from same IP (>10 in 5 min)",
    "Login from new country for privileged account",
    "Root account used for anything",
    "MFA disabled on privileged account",

    # Authorization
    "Access denied to admin endpoint by non-admin",
    "Unusual time access (2am-5am for non-ops accounts)",

    # Data
    "Bulk data export (>1000 records) outside business hours",
    "PII fields accessed en masse",

    # Infrastructure
    "Security group 0.0.0.0/0 rule added",
    "S3 bucket made public",
    "KMS key scheduled for deletion",
    "CloudTrail logging disabled",
    "GuardDuty finding severity >= 7",
]

# CloudWatch metric filter for failed logins
import boto3
logs = boto3.client('logs')

logs.put_metric_filter(
    logGroupName='/app/security',
    filterName='FailedLogins',
    filterPattern='{ $.event = "auth.login.failure" }',
    metricTransformations=[{
        'metricName': 'FailedLoginCount',
        'metricNamespace': 'AppSecurity',
        'metricValue': '1',
        'unit': 'Count'
    }]
)

# CloudWatch alarm for brute force
cloudwatch = boto3.client('cloudwatch')
cloudwatch.put_metric_alarm(
    AlarmName='BruteForceDetection',
    MetricName='FailedLoginCount',
    Namespace='AppSecurity',
    Statistic='Sum',
    Period=300,          # 5 minutes
    EvaluationPeriods=1,
    Threshold=50,        # 50 failed logins in 5 minutes
    ComparisonOperator='GreaterThanThreshold',
    AlarmActions=['arn:aws:sns:us-east-1:123456789:security-alerts'],
    TreatMissingData='notBreaching'
)

Incident Response Playbook — Compromised Credentials

PLAYBOOK: Compromised AWS Access Keys

Trigger: CloudTrail shows API calls from unusual location/time,
         or credentials found in public repository.

CONTAIN (< 5 minutes):
  1. Immediately deactivate the access key
     aws iam update-access-key --access-key-id AKIAXXXXXXXX --status Inactive
     aws iam delete-access-key --access-key-id AKIAXXXXXXXX

  2. If root account: change password immediately

  3. Check CloudTrail for all actions taken with this key (last 90 days)
     aws cloudtrail lookup-events \
       --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAXXXXXXXX

ASSESS (< 30 minutes):
  4. What did the attacker do?
     - IAM changes (new users, policies, access keys)
     - EC2 launches (crypto mining, C2 servers)
     - S3 access (data exfiltration)
     - Data deletion

  5. What data was accessed or exfiltrated?

ERADICATE (< 2 hours):
  6. Remove any backdoors the attacker created
     - IAM users, roles, policies, access keys
     - EC2 instances, Lambda functions
     - S3 bucket policy changes

  7. Rotate ALL credentials that may have been exposed

RECOVER:
  8. Restore from clean backups if needed
  9. Implement new controls to prevent recurrence

LESSONS LEARNED:
  10. Root cause analysis
  11. Update controls, monitoring, documentation

Compliance Frameworks

SOC 2 Type II

SOC 2 Trust Services Criteria relevant to AppSec:

CC6 — Logical and Physical Access Controls
  → IAM least privilege, MFA, access reviews
  → Evidence: IAM policies, access logs, quarterly reviews

CC7 — System Operations
  → Vulnerability scanning, patching, incident response
  → Evidence: Scan results, patch records, incident tickets

CC8 — Change Management
  → Code reviews, security testing before deploy
  → Evidence: PR approvals, CI/CD scan results, change records

CC9 — Risk Mitigation
  → Threat modeling, vendor risk
  → Evidence: Threat models, vendor assessments

PCI-DSS (Payment Card Industry)

Key PCI-DSS Requirements for AppSec:

Req 1: Firewall controls (Security Groups, NACLs, WAF)
Req 2: No vendor-supplied defaults (change default passwords)
Req 3: Protect stored cardholder data (encryption at rest)
Req 4: Encrypt transmission (TLS 1.2+ only)
Req 6: Develop secure systems (OWASP, SAST, patch management)
  6.2 — Maintain an inventory of software components (SBOM)
  6.3 — Protect web apps (WAF or code review)
  6.4 — Protect public-facing web apps against attacks
Req 7: Restrict access (least privilege IAM)
Req 8: Identify and authenticate (MFA for all admin access)
Req 10: Log and monitor (CloudTrail, SIEM)
Req 11: Test security (pen test annually, vuln scan quarterly)
Req 12: Information security policy

The Complete Interview Preparation Guide

You should be able to answer all of these:

OWASP & Vulnerabilities:
□ Explain all OWASP Top 10 with an example attack for each
□ What is the difference between XSS and CSRF?
□ How does SQL injection work? What prevents it?
□ What is SSRF? Give a cloud attack example.
□ What is the difference between authentication and authorization?

Cryptography:
□ Why use bcrypt over SHA-256 for passwords?
□ What is the difference between symmetric and asymmetric encryption?
□ What is Perfect Forward Secrecy?
□ How does TLS 1.3 work?
□ What is envelope encryption?

Cloud Security:
□ Explain AWS shared responsibility model
□ What makes S3 buckets publicly accessible and how do you prevent it?
□ How do you securely provide credentials to an EC2 instance / Lambda / ECS?
□ What is GuardDuty and what does it detect?
□ What is the difference between IAM roles, users, and groups?

Container Security:
□ What is the risk of running containers as root?
□ What is a Kubernetes Network Policy?
□ How do you store secrets in Kubernetes securely?
□ What is image signing and why does it matter?

Secure Design:
□ How would you design a secure password reset flow?
□ How would you design a multi-tenant API where users can't see each other's data?
□ What is zero-trust architecture?
□ How would you prevent secrets from being committed to git?

Process:
□ What is threat modeling? Walk me through STRIDE.
□ What is the difference between SAST and DAST?
□ How would you integrate security into a CI/CD pipeline?
□ What would you do if you found an AWS access key in a public GitHub repo?
□ How do you prioritise which vulnerabilities to fix first?

Congratulations — What You've Learned

Across this 12-post series you went from security fundamentals to interview-ready Application Security Engineer:

1. ✅ Security mindset, CIA triad, and attack surface thinking
2. ✅ Secure coding — input validation, output encoding, error handling
3. ✅ Every OWASP Top 10 vulnerability with attack code and secure fix
4. ✅ Authentication — passwords, JWT, OAuth 2.0, MFA
5. ✅ Cryptography — hashing, encryption, TLS, key management
6. ✅ API security — REST, GraphQL, gRPC attack surfaces
7. ✅ Cloud security — AWS IAM, shared responsibility, misconfigurations
8. ✅ AWS security services — KMS, CloudTrail, GuardDuty, WAF
9. ✅ Container security — Docker hardening, Kubernetes RBAC, Falco
10. ✅ Automated security — SAST, DAST, SCA, secrets management
11. ✅ DevSecOps — full CI/CD security pipeline
12. ✅ Threat modeling, penetration testing, incident response, compliance

You are now equipped to secure cloud applications, review code for vulnerabilities, build security into pipelines, and answer any application security interview question.

The field moves fast. Stay current: follow OWASP, HackerNews, Krebs on Security, AWS Security Blog, and practice on HackTheBox, TryHackMe, and PortSwigger Web Security Academy.