--- name: afrexai-cybersecurity-engine description: Complete cybersecurity assessment, threat modeling, and hardening system. Use when conducting security audits, threat modeling, penetration testing, incident response, or building security programs from scratch. Works with any stack — zero external dependencies. metadata: {"openclaw":{"emoji":"🛡️","os":["linux","darwin","win32"]}} ---

Cybersecurity Engine

Complete methodology for security assessment, threat modeling, vulnerability management, incident response, and security program design. No tools required — pure agent knowledge that works with any codebase, infrastructure, or organization.

Phase 1: Security Posture Assessment

Quick Health Check (5 minutes)

Run through these three tiers:

Tier 1 — Critical (fix today):

• [ ] Default credentials in production
• [ ] Secrets in source code or environment files committed to git
• [ ] No authentication on admin endpoints
• [ ] SQL injection in user-facing forms
• [ ] Unencrypted sensitive data at rest
• [ ] Public S3 buckets or cloud storage
• [ ] No HTTPS enforcement
• [ ] Root/admin running application processes

Tier 2 — High (fix this week):

• [ ] Dependencies with known CVEs (CVSS ≥ 7.0)
• [ ] No rate limiting on authentication endpoints
• [ ] Missing CSRF protection on state-changing operations
• [ ] Verbose error messages leaking stack traces
• [ ] No input validation on API endpoints
• [ ] Weak password policy (< 12 chars, no complexity)
• [ ] Session tokens in URL parameters
• [ ] No logging of authentication events

Tier 3 — Medium (fix this sprint):

• [ ] Missing security headers (CSP, HSTS, X-Frame-Options)
• [ ] No automated dependency scanning in CI
• [ ] Overprivileged service accounts
• [ ] No secret rotation policy
• [ ] Missing account lockout after failed attempts
• [ ] No security.txt or responsible disclosure policy
• [ ] Cookies without Secure/HttpOnly/SameSite flags

Score: Count failures. 0-2 = solid. 3-5 = needs work. 6+ = stop shipping features, fix security.

Full Assessment Brief

assessment:
  name: "[Project/Org Name] Security Assessment"
  date: "YYYY-MM-DD"
  assessor: "[Agent/Person]"
  scope:
    applications:
      - name: "[App Name]"
        type: "web|api|mobile|desktop|iot"
        tech_stack: "[languages, frameworks, DBs]"
        hosting: "cloud|on-prem|hybrid"
        cloud_provider: "aws|gcp|azure|other"
        internet_facing: true|false
        handles_pii: true|false
        handles_payments: true|false
        handles_phi: true|false  # health data
    infrastructure:
      - servers: "[count, OS types]"
        containers: true|false
        orchestration: "k8s|ecs|nomad|none"
        cdn: "[provider or none]"
        dns: "[provider]"
    third_parties:
      - name: "[service]"
        data_shared: "[what data]"
        criticality: "high|medium|low"
  compliance_requirements:
    - "SOC 2|ISO 27001|GDPR|HIPAA|PCI DSS|SOX|none"
  previous_incidents:
    - date: "YYYY-MM-DD"
      type: "[breach|vuln|misconfiguration]"
      severity: "critical|high|medium|low"
      resolution: "[what was done]"
  risk_tolerance: "conservative|moderate|aggressive"

Phase 2: Threat Modeling (STRIDE+)

Step 1 — Decompose the System

For each application, draw the data flow:

[User] → [CDN/WAF] → [Load Balancer] → [Web Server] → [App Server] → [Database]
                                                     ↘ [Cache]
                                                     ↘ [Message Queue] → [Worker]
                                                     ↘ [Third-party API]
                                                     ↘ [Object Storage]

Identify trust boundaries — where privilege level changes:

• Internet → DMZ (public-facing services)
• DMZ → Internal network (app servers, DBs)
• App → Database (credential boundary)
• User → Admin (role boundary)
• Service → Service (API key boundary)
• Your infra → Third-party (trust boundary)

Step 2 — STRIDE Analysis Per Component

For EACH component crossing a trust boundary:

| Threat | Question | Example Attack | |--------|----------|----------------| | Spoofing | Can an attacker pretend to be someone else? | Stolen JWT, session hijacking, credential stuffing | | Tampering | Can data be modified in transit or at rest? | Man-in-the-middle, SQL injection, parameter manipulation | | Repudiation | Can someone deny they did something? | Missing audit logs, unsigned transactions | | Information Disclosure | Can sensitive data leak? | Error messages, API over-fetching, side channels | | Denial of Service | Can the service be overwhelmed? | DDoS, resource exhaustion, regex DoS | | Elevation of Privilege | Can someone gain unauthorized access? | IDOR, broken access control, privilege escalation |

Step 3 — Threat Register

threats:
  - id: "T-001"
    component: "[affected component]"
    category: "S|T|R|I|D|E"
    description: "[specific attack scenario]"
    attacker_profile: "external-unauthenticated|external-authenticated|internal|insider"
    likelihood: 1-5  # 1=rare, 5=almost certain
    impact: 1-5      # 1=negligible, 5=catastrophic
    risk_score: 0     # likelihood × impact
    existing_controls: "[what's already in place]"
    residual_risk: "accept|mitigate|transfer|avoid"
    mitigation: "[specific fix]"
    priority: "P0|P1|P2|P3"
    owner: "[person/team]"
    status: "open|in-progress|mitigated|accepted"

Priority Rules

• P0 (risk ≥ 20): Fix immediately, stop other work
• P1 (risk 12-19): Fix within 1 week
• P2 (risk 6-11): Fix within 1 sprint
• P3 (risk ≤ 5): Track, fix when convenient

Phase 3: Application Security (OWASP Top 10 + Beyond)

A01: Broken Access Control

Test checklist:

• [ ] Can user A access user B's resources by changing ID? (IDOR)
• [ ] Can non-admin access admin endpoints?
• [ ] Do API endpoints enforce authorization, not just authentication?
• [ ] Are directory listings disabled?
• [ ] Is CORS properly configured (not * with credentials)?
• [ ] Can JWT be tampered with (alg=none, key confusion)?
• [ ] Is rate limiting applied to sensitive endpoints?
• [ ] Do file uploads validate type server-side?

Fix patterns:

# Authorization check pattern (every endpoint)
1. Authenticate → verify identity
2. Authorize → verify permission for THIS resource
3. Validate → verify input is within allowed bounds
4. Execute → perform the action
5. Audit → log who did what

# IDOR prevention
- NEVER use sequential IDs in URLs — use UUIDs
- ALWAYS verify resource ownership server-side
- Use middleware that auto-checks resource.owner === request.user

A02: Cryptographic Failures

Decision tree:

Need to store passwords?
  → bcrypt (cost 12+) or Argon2id
  → NEVER: MD5, SHA1, SHA256 without salt

Need to encrypt data at rest?
  → AES-256-GCM (authenticated encryption)
  → NEVER: ECB mode, DES, RC4

Need to encrypt in transit?
  → TLS 1.2+ (prefer 1.3)
  → HSTS with includeSubDomains
  → Certificate pinning for mobile apps

Need to generate random values?
  → crypto.randomBytes() / secrets.token_bytes()
  → NEVER: Math.random(), random.random()

Need to sign/verify?
  → HMAC-SHA256 for symmetric
  → Ed25519 or RSA-PSS (2048+ bits) for asymmetric
  → NEVER: RSA PKCS#1 v1.5 for new systems

A03: Injection

SQL Injection prevention:

# ALWAYS use parameterized queries
✅ db.query("SELECT * FROM users WHERE id = $1", [userId])
❌ db.query("SELECT * FROM users WHERE id = " + userId)

# Test payloads (for YOUR code, during testing):
' OR '1'='1
'; DROP TABLE users;--
' UNION SELECT password FROM users--
1; WAITFOR DELAY '0:0:5'--

...