@oriro/orirocli 0.1.9 → 0.1.11

package/skills/craft/master-architect/references/cyber.md

@@ -1,839 +1,839 @@
-# Cybersecurity Intelligence Reference
-
-# Covers: AppSec, NetSec, CloudSec, DevSecOps, Threat Intel, SIEM, Compliance, Fraud, Incident Response
-
-## DEFENSE IN DEPTH MODEL
-
-Never rely on a single control. Layer security at every level:
-
-```
-Layer 1 — Perimeter:      WAF, DDoS protection, CDN edge rules, geo-blocking
-Layer 2 — Network:        Firewall rules, VPC isolation, private subnets, VPN, zero-trust network access
-Layer 3 — Identity:       MFA, SSO, PAM, least privilege, just-in-time access
-Layer 4 — Application:    Input validation, auth/authz, CSRF, rate limiting, API security
-Layer 5 — Data:           Encryption at rest + transit, tokenization, masking, key management
-Layer 6 — Endpoint:       EDR, patch management, container hardening, OS baselines
-Layer 7 — Detection:      SIEM, anomaly detection, threat intel feeds, behavioral analytics
-Layer 8 — Response:       IR playbooks, forensics capability, backup/restore tested weekly
-
-Principle: Assume every layer will eventually be breached. Design so that one breach ≠ catastrophe.
-```
-
----
-
-## OWASP TOP 10 — WEB (2021) — Fix Every One
-
-### A01: Broken Access Control (Most Common)
-
-```
-Attack:    Access /api/users/456 as user 123. Horizontal privilege escalation.
-Fix:       Always verify ownership: WHERE id = $1 AND org_id = $current_org
-           Row-Level Security in PostgreSQL enforces this at DB level.
-           Never trust user-supplied IDs without authorization check.
-Test:      Authenticated as User A, attempt all User B's resource endpoints.
-
-Code fix:
-// BAD:
-const tx = await db.transaction.findUnique({ where: { id: req.params.id }})
-
-// GOOD:
-const tx = await db.transaction.findUnique({
-  where: { id: req.params.id, userId: req.user.id }  // scope to authenticated user
-})
-if (!tx) throw new NotFoundError()  // same error whether missing or unauthorized
-```
-
-### A02: Cryptographic Failures
-
-```
-Attack:    Sensitive data in plaintext DB, MD5 passwords, HTTP traffic, weak keys.
-Fix:       TLS 1.3 everywhere. AES-256-GCM for data at rest.
-           Passwords: argon2id (winner of PHC). Never MD5/SHA1/bcrypt(cost<12).
-           PII fields: encrypt at application layer (not just disk encryption).
-           No secrets in logs. No PAN/SSN in URLs.
-
-Password hashing:
-import argon2 from 'argon2'
-const hash = await argon2.hash(password, {
-  type: argon2.argon2id,
-  memoryCost: 65536,  // 64MB
-  timeCost: 3,        // 3 iterations
-  parallelism: 4      // 4 threads
-})
-```
-
-### A03: Injection (SQL, NoSQL, LDAP, Command)
-
-```
-Attack:    User inputs: ' OR '1'='1 → dumps entire table.
-Fix:       Parameterized queries. ALWAYS. No string concatenation in queries.
-           ORM query builders (Prisma, SQLAlchemy) are safe by default.
-           Command injection: never exec() user input. Use allowlists.
-
-// NEVER:
-db.query(`SELECT * FROM users WHERE email = '${email}'`)
-
-// ALWAYS:
-db.query('SELECT * FROM users WHERE email = $1', [email])
-```
-
-### A04: Insecure Design
-
-```
-Attack:    Business logic flaws — buy item for $0, skip payment step, replay coupons.
-Fix:       Threat model every feature before coding.
-           State machine validation — enforce valid state transitions server-side.
-           Rate limit sensitive operations (password reset: 3/hour, not 1000/hour).
-           Never trust client-side price/discount calculation.
-```
-
-### A05: Security Misconfiguration
-
-```
-Common:   Default credentials, directory listing, verbose error messages in prod,
-          open S3 buckets, unrestricted CORS, unused ports open, debug mode on.
-Fix:      Infrastructure as Code — configuration is reviewed, version-controlled.
-          CSPM tool (Wiz, Prisma Cloud, or free: CloudSploit) scans continuously.
-          Env diff check: prod config audited against security baseline weekly.
-          Error responses: generic in prod, never stack traces to client.
-```
-
-### A06: Vulnerable and Outdated Components
-
-```
-Fix:      Renovate Bot or Dependabot — auto-PRs for dependency updates weekly.
-          Snyk or OWASP Dependency-Check in CI — block on critical CVEs.
-          Container base image scanning — Trivy on every Docker build.
-          SBOM (Software Bill of Materials) generated on every release.
-          Never use packages with 0 maintenance activity in past 12 months.
-          Pin exact versions in lockfiles (package-lock.json, requirements.txt).
-```
-
-### A07: Identification and Authentication Failures
-
-```
-Attack:   Credential stuffing, brute force, session fixation, weak tokens.
-Fix:      MFA mandatory for admin, recommended for all users.
-          Account lockout: 5 failed attempts → 15min lockout + alert.
-          Secure session: HttpOnly, Secure, SameSite=Strict cookies.
-          Token storage: never localStorage (XSS), always HttpOnly cookies.
-          Password policy: min 12 chars, check against HaveIBeenPwned API.
-          JWT: RS256 (not HS256), short TTL (15min), rotate signing keys quarterly.
-```
-
-### A08: Software and Data Integrity Failures
-
-```
-Attack:   Tampered auto-updates, unsigned packages, CI/CD pipeline compromise.
-Fix:      Verify checksums/signatures on all downloaded artifacts.
-          Sigstore/Cosign for container image signing.
-          SLSA framework for supply chain levels (target SLSA Level 3).
-          CI/CD: separate credentials per environment, audit pipeline configs.
-          npm: use --ignore-scripts flag, audit before install.
-```
-
-### A09: Security Logging and Monitoring Failures
-
-```
-Fix:      Log: every auth event, admin action, failed access, data mutation.
-          Include: timestamp (UTC), user_id, org_id, IP, action, resource, result.
-          Never log: passwords, tokens, PAN, SSN, CVV, full credit card.
-          Alert within 15 minutes on: impossible travel, mass data export,
-                                       admin privilege escalation, >10 auth failures.
-          Log retention: 90 days hot, 1 year cold (PCI DSS requires 1 year).
-          SIEM: ingest all logs, alert on patterns, not just individual events.
-```
-
-### A10: Server-Side Request Forgery (SSRF)
-
-```
-Attack:   User supplies URL → server fetches it → attacker reads internal metadata API.
-          AWS: http://169.254.169.254/latest/meta-data/iam/security-credentials/
-Fix:      Allowlist permitted URL destinations — never arbitrary user-supplied URLs.
-          Block RFC 1918 addresses (10.x, 172.16.x, 192.168.x) and 169.254.x.
-          Use DNS resolution + IP check BEFORE fetching.
-          Disable HTTP redirects or validate redirect target against allowlist.
-```
-
----
-
-## OWASP API SECURITY TOP 10 (2023)
-
-```
-API1:  Broken Object Level Authorization  → Scope every query to authenticated user/org
-API2:  Broken Authentication              → Short-lived tokens, rotate refresh tokens
-API3:  Broken Object Property Auth        → Allowlist response fields, never return full DB row
-API4:  Unrestricted Resource Consumption  → Rate limit, payload size limits, pagination required
-API5:  Broken Function Level Auth         → Admin endpoints on separate auth check, not just UI hide
-API6:  Unrestricted Access to Sensitive Business Flows → Bot detection, device fingerprinting
-API7:  Server-Side Request Forgery        → Same as web SSRF above
-API8:  Security Misconfiguration          → No CORS *, no debug headers, no default paths
-API9:  Improper Inventory Management      → API versioning, decommission old versions with traffic
-API10: Unsafe Consumption of APIs         → Validate all third-party API responses before use
-```
-
----
-
-## THREAT MODELING
-
-### STRIDE Framework (Apply to Every Feature)
-
-```
-S — Spoofing:         Can an attacker impersonate a legitimate user or service?
-                      Mitigate: Strong auth, mutual TLS, digital signatures
-
-T — Tampering:        Can data be modified in transit or at rest without detection?
-                      Mitigate: Integrity checks, signed tokens, audit logs, TLS
-
-R — Repudiation:      Can someone deny performing an action?
-                      Mitigate: Immutable audit logs, signed requests, non-repudiation tokens
-
-I — Information Disclosure: Can sensitive data be exposed to unauthorized parties?
-                      Mitigate: Least privilege, encryption, data classification, masking
-
-D — Denial of Service: Can an attacker disrupt availability?
-                      Mitigate: Rate limiting, auto-scaling, circuit breakers, DDoS protection
-
-E — Elevation of Privilege: Can a user gain more access than they should have?
-                      Mitigate: RBAC, least privilege, privilege validation server-side
-```
-
-### Threat Modeling Process (Per Feature)
-
-```
-Step 1: DECOMPOSE — Draw data flow diagram. Identify trust boundaries, entry points, data stores.
-Step 2: THREATS — For each component, apply STRIDE. List all plausible attacks.
-Step 3: RANK — Severity × Likelihood = Risk score (DREAD or CVSS)
-Step 4: MITIGATE — For each threat: mitigate, transfer, accept, or avoid.
-Step 5: VALIDATE — Write security test for each mitigated threat.
-Step 6: REPEAT — Re-threat-model when architecture changes.
-
-Time required: 2-4 hours per major feature. Non-negotiable for financial features.
-```
-
----
-
-## APPLICATION SECURITY (APPSEC) PIPELINE
-
-### DevSecOps — Shift Left
-
-```
-Pre-commit:     git-secrets / detect-secrets / Gitleaks — block secret commits
-                IDE plugins: Snyk IntelliJ, SonarLint VSCode (real-time SAST)
-
-PR / CI:        SAST — Static analysis (Semgrep, SonarQube, CodeQL)
-                SCA  — Dependency check (Snyk, OWASP DC, npm audit)
-                Secrets scan — Gitleaks, TruffleHog
-                IaC scan — Checkov, tfsec (Terraform misconfigs)
-                Container scan — Trivy (image CVEs)
-
-Pre-deploy:     DAST — Dynamic scan against staging (OWASP ZAP, Burp Suite)
-                API fuzzing — Schemathesis, restler-fuzzer
-
-Production:     RASP — Runtime application self-protection (contrast, sqreen)
-                WAF — Cloudflare WAF / AWS WAF / Cloud Armor (rules updated weekly)
-                Dependency monitor — Snyk monitor / Dependabot alerts
-```
-
-### SAST Tool Selection
-
-```
-Semgrep:        Fast, open source, custom rules, CI-native. Best first choice.
-SonarQube:      Comprehensive, CI integration, tracks debt over time. Self-hosted or cloud.
-CodeQL:         GitHub-native, deep semantic analysis, best for complex vulnerability patterns.
-Checkmarx:      Enterprise, expensive, deep analysis.
-Veracode:       Enterprise SaaS, compliance-oriented.
-
-Run Semgrep + SonarQube minimum. CodeQL for GitHub repos (free for public).
-```
-
-### Penetration Testing Methodology
-
-```
-Phase 1 — Reconnaissance:
-  Passive: Shodan, Censys, Google dorks, LinkedIn (OSINT)
-  Active:  nmap port scan, service fingerprinting, SSL/TLS scan (testssl.sh)
-
-Phase 2 — Enumeration:
-  Web: Dirb/ffuf (directory brute-force), nikto (web scanner)
-  API: Postman collection analysis, OpenAPI spec review, parameter fuzzing
-  Auth: JWT inspection, session token analysis, OAuth flow review
-
-Phase 3 — Exploitation:
-  Automated: OWASP ZAP active scan, SQLmap (SQL injection), Nuclei templates
-  Manual: Business logic testing, auth bypass, IDOR, race conditions
-
-Phase 4 — Post-Exploitation:
-  Lateral movement (if scoped), privilege escalation, persistence mechanisms
-
-Phase 5 — Reporting:
-  CVSS scores for each finding, reproduction steps, remediation guidance, risk rating
-
-Cadence: Annual third-party pentest + quarterly internal. Before major releases.
-Tools: Burp Suite Pro, OWASP ZAP, Metasploit, Nmap, Nikto, SQLmap, Nuclei, Amass
-```
-
----
-
-## ZERO TRUST ARCHITECTURE
-
-```
-Core Principles:
-  1. Never trust, always verify — network location grants zero trust
-  2. Least privilege access — time-limited, just enough, just-in-time
-  3. Assume breach — segment everything, monitor everything, limit blast radius
-  4. Verify explicitly — authenticate and authorize every request, every time
-
-Implementation:
-  Identity:      Every user + device verified before access (MFA + device health check)
-  Device:        Managed devices only for admin access. MDM enrolled.
-  Network:       Micro-segmentation. Services can't talk unless explicitly allowed.
-                 Replace VPN with identity-aware proxy (Google BeyondCorp, Cloudflare Access)
-  Application:   Each app verifies identity independently. No "trusted" internal networks.
-  Data:          Classify data. Apply policy per classification. Encrypt in use.
-
-GCP Implementation:
-  Identity-Aware Proxy (IAP) → protects internal apps without VPN
-  VPC Service Controls → data perimeter, prevents data exfil from GCP services
-  Organization Policy → org-wide guardrails (no public IPs, require CMEK, etc.)
-  Access Context Manager → attribute-based access (IP, device, user)
-```
-
----
-
-## CLOUD SECURITY (CSPM + CWPP)
-
-### Cloud Security Posture Management (CSPM)
-
-```
-What it does:   Continuously scans cloud config for misconfigurations and compliance violations
-Tools:
-  Wiz:          Best coverage, agentless, fast. $15K+/yr
-  Prisma Cloud: Palo Alto, comprehensive, expensive
-  Lacework:     Behavioral analysis + CSPM combo
-  CloudSploit:  Open source, GCP/AWS/Azure. Free.
-  ScoutSuite:   Open source audit tool. Run quarterly.
-
-Must-catch misconfigs:
-  □ Public S3/GCS buckets
-  □ Unrestricted security group rules (0.0.0.0/0 inbound)
-  □ Unencrypted database instances
-  □ MFA not enabled on root/admin accounts
-  □ Logging disabled (CloudTrail/Cloud Audit Logs)
-  □ Old IAM access keys (>90 days)
-  □ Public SSH/RDP ports exposed (22, 3389)
-  □ Default VPC in use for production
-```
-
-### Container & Kubernetes Security
-
-```
-Image security:
-  □ Base image: use distroless or alpine (minimal attack surface)
-  □ Never run as root (USER nobody in Dockerfile)
-  □ No secrets in image layers (check with Trivy --secret)
-  □ Sign images with Cosign (Sigstore)
-  □ Image pull policy: Always (never cached stale images in prod)
-
-Kubernetes:
-  □ RBAC: no cluster-admin for workloads. Namespace-scoped roles only.
-  □ Network Policies: default deny all, explicit allow per service pair
-  □ Pod Security Standards: Restricted profile in production
-  □ Secrets: use External Secrets Operator (GCP Secret Manager → K8s Secret)
-  □ No privileged containers. No hostPID/hostNetwork.
-  □ Resource limits on every container (prevents noisy neighbor + DoS)
-  □ Admission controllers: OPA/Gatekeeper or Kyverno policy engine
-  □ Runtime: Falco (detects anomalous container behavior in real-time)
-
-Runtime security:
-  Falco rules to alert on:
-    - Shell spawned in container (exec into running container)
-    - Unexpected outbound connections from container
-    - Sensitive file read (/etc/shadow, /proc/*/mem)
-    - Privilege escalation attempts
-```
-
-### GCP Security Hardening Checklist
-
-```
-Organization level:
-  □ Organization Policy: Restrict public IPs on Cloud SQL
-  □ Organization Policy: Require OS Login for Compute Engine
-  □ Organization Policy: Restrict allowed APIs per project
-  □ Cloud Audit Logs: DATA_READ + DATA_WRITE + ADMIN_WRITE on all services
-  □ SCC (Security Command Center) Premium enabled
-
-Project level:
-  □ Default service accounts not used (create custom, least privilege)
-  □ Service account keys: rotate quarterly or use Workload Identity instead
-  □ Cloud SQL: private IP only, no public IP, SSL required
-  □ GCS: uniform bucket-level access, no legacy ACLs
-  □ Cloud Run: no unauthenticated invocations (except public endpoints)
-  □ Secret Manager: audit access log enabled, rotation schedule set
-  □ VPC: Private Google Access enabled, no default firewall rules
-```
-
----
-
-## SECURITY MONITORING & SIEM
-
-### What to Log (Mandatory)
-
-```
-Authentication events:
-  login_success, login_failure, logout, mfa_challenge, mfa_success, mfa_failure,
-  password_reset_requested, password_changed, token_refreshed, token_revoked,
-  session_expired, account_locked, account_unlocked
-
-Authorization events:
-  access_denied, privilege_escalation_attempt, role_assigned, role_revoked,
-  admin_action (any), api_key_created, api_key_deleted
-
-Data events:
-  record_created, record_updated, record_deleted (with before/after for sensitive fields),
-  bulk_export, bulk_delete, pii_accessed (who accessed whose data)
-
-Infrastructure events:
-  deploy_started, deploy_completed, deploy_failed, config_changed,
-  secret_accessed (who, when, which secret), IAM_policy_changed
-
-Format (every log line must have all fields):
-{
-  "timestamp": "2024-01-15T10:30:00.000Z",  // UTC always
-  "trace_id": "abc-123",                     // correlate across services
-  "user_id": "usr_xyz",                      // who did it
-  "org_id": "org_abc",                       // tenant context
-  "ip": "1.2.3.4",                           // source IP
-  "user_agent": "...",                       // client context
-  "action": "transaction.created",           // what happened
-  "resource_id": "tx_123",                   // on what
-  "result": "success",                       // success/failure/denied
-  "duration_ms": 45                          // performance context
-}
-```
-
-### SIEM Architecture
-
-```
-Sources:           App logs, Cloud Audit Logs, WAF logs, VPC Flow Logs, DNS logs
-Ingestion:         Pub/Sub (GCP) or Kafka → log pipeline
-Normalization:     Parse into common schema (CEF or ECS — Elastic Common Schema)
-Storage:           BigQuery (GCP) or Elasticsearch — index for fast search
-Correlation:       Detection rules — alert on patterns, not single events
-Alerting:          PagerDuty / OpsGenie → on-call rotation
-Response:          SOAR (Security Orchestration) — auto-remediate known patterns
-
-Tools:
-  Managed:        Google Chronicle, Microsoft Sentinel, Splunk, Sumo Logic
-  Open source:    ELK Stack (Elasticsearch + Logstash + Kibana) + Sigma rules
-  Lightweight:    Grafana + Loki + alert rules (good for small teams, low cost)
-  GCP-native:     Chronicle SIEM (Google's) — best GCP log integration
-```
-
-### Detection Rules (Critical Alerts — PagerDuty Immediately)
-
-```
-Brute force:       >10 auth failures from same IP in 5 minutes
-Credential stuffing: >5 failed logins across different accounts from same IP
-Impossible travel: Login from country A, then country B within 2 hours
-Mass data export:  Single user exports >1000 records in 10 minutes
-Privilege escalation: Role change granting admin-level access
-New admin account: Any new user assigned admin/owner role
-Off-hours admin:   Admin action between 10PM-6AM (tune per org)
-API key abuse:     Single API key >10,000 requests in 1 hour
-Secret access:     Service accessing secrets it has never accessed before
-Public resource:   Cloud storage bucket or DB made publicly accessible
-New external IP:   Cloud Run service starts communicating with unknown external IP
-```
-
-### Threat Intelligence Integration
-
-```
-Feeds to consume:
-  MITRE ATT&CK:   Adversary tactics, techniques, procedures (TTPs) — map detections to ATT&CK
-  CISA KEV:       Known Exploited Vulnerabilities — patch these IMMEDIATELY (cisa.gov/kev)
-  NVD CVE:        National Vulnerability Database — monitor for new critical CVEs
-  AlienVault OTX: Open threat intelligence — IP/domain/hash reputation
-  Shodan:         Monitor your own external attack surface
-  PhishTank:      Phishing URL feeds
-
-Integration pattern:
-  Enrich every inbound IP in logs against threat intel feed (check reputation score)
-  Block known-bad IPs at WAF level automatically
-  Alert when traffic matches known malicious patterns (IoCs)
-
-Tools: MISP (open source threat intel platform), OpenCTI, ThreatConnect
-```
-
----
-
-## CRYPTOGRAPHY STANDARDS
-
-### What to Use (2024)
-
-```
-Symmetric encryption:  AES-256-GCM (authenticated encryption — integrity + confidentiality)
-                       ChaCha20-Poly1305 (faster on mobile/embedded, same security)
-                       Never: DES, 3DES, AES-ECB, RC4
-
-Asymmetric:            RSA-4096 (key exchange/signing) — prefer Ed25519 for new systems
-                       Ed25519 / ECDSA P-256 (digital signatures — faster, smaller keys)
-                       ECDH P-256 (key agreement)
-                       Never: RSA < 2048, DSA, MD5/SHA1 for signing
-
-Hashing:               SHA-256 / SHA-3 for data integrity
-                       BLAKE3 for performance-critical hashing
-                       argon2id for password storage (never SHA/MD5 for passwords)
-                       Never: MD5, SHA1 for security purposes
-
-TLS:                   TLS 1.3 required. TLS 1.2 acceptable with restricted ciphers.
-                       Never: SSL, TLS 1.0, TLS 1.1
-                       Cipher suites: ECDHE + AES-128-GCM, ECDHE + AES-256-GCM, ECDHE + ChaCha20
-
-Key management:        GCP Cloud KMS or AWS KMS or HashiCorp Vault
-                       Rotate encryption keys annually
-                       Key hierarchy: Master Key → Data Encryption Keys → Data
-                       FIPS 140-2 Level 3 HSM for financial/regulated workloads
-
-JWT signing:           RS256 (RSA) or ES256 (ECDSA) — never HS256 in multi-service arch
-                       Key rotation: quarterly, with overlap period
-```
-
-### Envelope Encryption Pattern
-
-```python
-# Google Cloud KMS envelope encryption
-from google.cloud import kms
-
-def encrypt_sensitive_field(plaintext: str, key_name: str) -> dict:
-    # 1. Generate a data encryption key (DEK) locally
-    import os
-    dek = os.urandom(32)  # 256-bit AES key
-
-    # 2. Encrypt your data with the DEK
-    ciphertext = aes_gcm_encrypt(plaintext.encode(), dek)
-
-    # 3. Wrap (encrypt) the DEK with Cloud KMS master key
-    kms_client = kms.KeyManagementServiceClient()
-    wrapped_dek = kms_client.encrypt(name=key_name, plaintext=dek).ciphertext
-
-    # 4. Store: ciphertext + wrapped DEK (KMS key never leaves KMS)
-    return {"ciphertext": ciphertext.hex(), "wrapped_dek": wrapped_dek.hex()}
-    # Decrypt: unwrap DEK via KMS → decrypt ciphertext with DEK
-```
-
----
-
-## IDENTITY & ACCESS MANAGEMENT
-
-### Privileged Access Management (PAM)
-
-```
-Just-In-Time (JIT) access:
-  Engineers request elevated access for specific task + timeframe
-  Auto-approved for standard ops, human approval for sensitive data access
-  Access expires automatically (1-8 hours, not permanent)
-  All actions logged with business justification
-  Tools: CyberArk, BeyondTrust, HashiCorp Boundary, GCP PAM (preview)
-
-Service-to-service auth:
-  GCP: Workload Identity Federation (no service account keys)
-  AWS: IAM Roles for Service Accounts (IRSA)
-  On-prem: SPIFFE/SPIRE for workload identity
-  Never: long-lived service account keys stored in config
-
-MFA Requirements (enforce in code, not just policy):
-  Admin access: FIDO2/Passkeys or hardware token (YubiKey) — TOTP not sufficient
-  Standard users: TOTP app minimum (Google Authenticator, Authy)
-  API access: API keys + IP allowlist + request signing
-  Never: SMS-based MFA for high-value accounts (SIM swap vulnerable)
-```
-
-### IAM Audit (Run Monthly)
-
-```
-Find over-privileged roles:
-  GCP: gcloud projects get-iam-policy PROJECT --format=json | analyze
-  AWS: IAM Access Analyzer + unused access findings
-
-Check for:
-  □ Roles with * on resources (over-broad)
-  □ Service accounts with owner/editor (should be specific roles)
-  □ IAM access keys older than 90 days
-  □ Unused service accounts (no API activity >30 days → delete)
-  □ Users with direct permissions (should be via groups/roles)
-  □ Cross-account trust relationships (any unexpected?)
-```
-
----
-
-## INCIDENT RESPONSE
-
-### Severity Classification
-
-```
-P0 — Critical:   Active breach, data exfil in progress, ransomware, service down
-                 Response: 5min. War room immediately. CEO + Legal notified.
-
-P1 — High:       Suspected breach, critical vuln exploited, auth system compromised
-                 Response: 15min. Security lead + engineering lead.
-
-P2 — Medium:     Anomalous behavior, failed exploitation attempt, compliance gap found
-                 Response: 1 hour. Security team + affected service owner.
-
-P3 — Low:        Policy violation, low-severity CVE, config drift
-                 Response: Next business day. Assigned owner.
-```
-
-### NIST Incident Response Framework
-
-```
-1. PREPARE:
-   □ IR plan documented + tested quarterly
-   □ Contact list: security team, legal, PR, executives, regulators
-   □ Forensic tools pre-installed (not scrambling to install during incident)
-   □ Evidence preservation procedures known to all engineers
-   □ Cyber insurance policy in place
-
-2. IDENTIFY:
-   □ What happened? When did it start? (look for earliest indicator)
-   □ What systems are affected? (blast radius assessment)
-   □ Is it still ongoing? (contain before investigating)
-   □ Log preservation: export logs to isolated read-only bucket immediately
-
-3. CONTAIN:
-   Short-term: Block attacker (IP ban, revoke credentials, isolate instance)
-   Long-term: Patch, fix configuration, rebuild if necessary
-   Do NOT shut everything down immediately — preserve evidence first
-
-4. ERADICATE:
-   Remove all attacker persistence (backdoors, new user accounts, cron jobs)
-   Scan ALL systems — attackers often pivot from initial compromise
-   Reset all credentials that may have been exposed
-   Rotate all secrets (assume all secrets compromised)
-
-5. RECOVER:
-   Restore from clean backups (verify backups are clean — attackers may have been in months)
-   Deploy patched/clean systems
-   Monitor intensively for 30 days post-recovery
-   Gradual return to service — don't rush
-
-6. LESSONS LEARNED:
-   Blameless post-mortem within 72 hours
-   Root cause analysis (5 Whys)
-   Detection gap: why didn't we catch this sooner?
-   Prevention: specific fixes with owners and deadlines
-   Update runbooks + detection rules
-```
-
-### Breach Notification Requirements
-
-```
-GDPR:          72 hours to supervisory authority if personal data affected
-CCPA:          Reasonable notice to affected California residents
-PCI DSS:       Immediate notification to card brands (Visa, Mastercard) + acquiring bank
-HIPAA:         60 days to HHS, affected individuals, and media (if >500 in a state)
-India PDPB:    72 hours to Data Protection Board (when enacted)
-SEC (US):      4 business days for material cybersecurity incidents (Rule 8-K)
-RBI (India):   Immediate to RBI CSITE + NPCI for payment system incidents
-
-Prepare breach notification templates in advance. Legal review annually.
-```
-
----
-
-## VULNERABILITY MANAGEMENT
-
-### CVE Tracking & Patch SLAs
-
-```
-CVSS Score → Patch Timeline:
-  Critical (9.0-10.0): Patch within 24 hours. Emergency change if needed.
-  High (7.0-8.9):      Patch within 7 days.
-  Medium (4.0-6.9):    Patch within 30 days.
-  Low (0.1-3.9):       Patch within 90 days.
-
-CISA KEV overrides: Patch within 2 weeks regardless of CVSS (these are actively exploited).
-
-Automation:
-  Renovate Bot:  Auto-PRs for dependency updates (better than Dependabot — more flexible)
-  Trivy:         Scan container images in CI, block critical CVEs
-  Snyk:          Monitor production containers + code continuously
-  Grafeas:       Artifact metadata and attestation (GCP-native)
-```
-
-### SBOM (Software Bill of Materials)
-
-```
-Generate on every release:
-  Node.js:  cyclonedx-node-npm --output-file sbom.json
-  Python:   cyclonedx-py -p -e -o sbom.json
-  Java:     CycloneDX Maven/Gradle plugin
-  Docker:   syft image:tag -o cyclonedx-json=sbom.json
-
-Store in artifact registry alongside each release.
-Required by: US Executive Order 14028, EU Cyber Resilience Act, PCI DSS 4.0.
-Enables: rapid "do we use Log4j?" type queries during zero-day events.
-```
-
----
-
-## COMPLIANCE FRAMEWORKS
-
-### SOC 2 Type II (Most Important for SaaS)
-
-```
-Trust Services Criteria:
-  Security:       CC6 — Logical access, CC7 — System operations, CC8 — Change management
-  Availability:   Uptime SLAs, disaster recovery, capacity planning
-  Confidentiality: Data classification, encryption, access controls
-  Processing Integrity: Complete, accurate, timely processing
-  Privacy:        GDPR/CCPA alignment, consent management
-
-Controls required (sample):
-  □ All access requires MFA
-  □ Background checks for all employees with system access
-  □ Annual security training for all staff
-  □ Penetration test annually
-  □ Business continuity plan tested annually
-  □ Incident response tested quarterly
-  □ Vendor security assessments for critical vendors
-  □ Encryption at rest and in transit
-  □ Change management process documented
-  □ Vulnerability management program with SLAs
-
-Tools:
-  Vanta:   Best automated SOC2 prep (<user> already using). ~$15K/yr. Gets to audit-ready fastest.
-  Drata:   Vanta competitor, good integrations.
-  Secureframe: Strong for early-stage.
-  Manual: Feasible but 10x more work.
-
-Timeline: SOC2 Type I in 3 months (controls exist). Type II in 12 months (controls operated for period).
-```
-
-### PCI DSS 4.0 (If Handling Card Data)
-
-```
-Key requirements for SaaS (Level 4 — <20K transactions):
-  □ Never store raw PANs, CVV, or full magnetic stripe
-  □ Tokenize: use Stripe.js/Elements — card data never touches your server
-  □ WAF protecting all web-facing systems
-  □ Vulnerability scanning quarterly (ASV scan)
-  □ Penetration test annually
-  □ Maintain audit logs 12 months
-  □ MFA for all non-consumer access
-  □ Encrypt cardholder data in transit (TLS 1.2+)
-  □ Self-Assessment Questionnaire (SAQ A or SAQ A-EP for most SaaS)
-
-Best advice: Use Stripe.js + Stripe Elements. Never touch raw card data. Reduces scope to SAQ A.
-```
-
-### GDPR / Data Privacy
-
-```
-Core requirements:
-  □ Lawful basis for processing (consent, contract, legitimate interest, etc.)
-  □ Data subject rights: access, rectification, erasure ("right to be forgotten"), portability
-  □ Privacy by design: collect minimum data, purpose limitation
-  □ Data Processing Agreements (DPAs) with all sub-processors
-  □ Records of Processing Activities (ROPA) — document what you process and why
-  □ 72-hour breach notification to supervisory authority
-  □ DPIA (Data Protection Impact Assessment) for high-risk processing
-  □ Cookie consent — real consent, not dark patterns
-
-Technical implementation:
-  Data inventory:   Every field of every table — classify: PII / sensitive / public
-  Erasure:          User delete → anonymize or delete all PII across all tables + backups
-  Portability:      Export user data as machine-readable JSON/CSV on request
-  Data residency:   EU personal data must stay in EU (or adequate third country)
-  Consent logging:  Timestamp, IP, consent text version for every consent collected
-```
-
----
-
-## FRAUD DETECTION & FINANCIAL CRIME (<project>-Specific)
-
-### Real-Time Fraud Signal Architecture
-
-```
-Transaction Event → Feature Extraction → Risk Scoring → Decision → Action
-                          ↓                    ↓
-                   [Feature Store]      [ML Model + Rules]
-                          ↓
-              velocity, device, IP, behavior, history
-
-Signal categories:
-  Velocity:      transactions per hour/day, amount per period, new payee frequency
-  Device:        device fingerprint, new device, rooted/jailbroken, emulator detected
-  Location:      IP geolocation, distance from last transaction, impossible travel
-  Behavior:      typing speed, session duration, navigation pattern (vs baseline)
-  Network:       VPN/proxy/Tor detected, datacenter IP, known fraud IP
-  Identity:      name/address/phone mismatch, synthetic identity signals
-  Transaction:   unusual amount (vs history), unusual merchant, round amounts, split transactions
-```
-
-### Fraud Rule Engine Design
-
-```
-Priority execution:
-  P0 Hard Block:   Stolen card list, OFAC sanctions match, known fraud device → instant deny
-  P1 Hard Block:   Velocity limit exceeded, impossible travel, known fraud IP → instant deny
-  P2 Soft Block:   ML score > 0.9 → step-up auth (OTP required)
-  P3 Review:       ML score 0.7-0.9 → human review queue
-  P4 Monitor:      ML score 0.4-0.7 → flag for pattern analysis
-  P5 Allow:        ML score < 0.4 → approve (standard risk)
-
-Rule governance:
-  Every rule: owner, creation date, last review date, hit rate, precision/recall
-  Rules reviewed monthly — prune low-precision rules, add new patterns
-  A/B test rule changes — never deploy blind
-  False positive rate target: <0.5% (every false positive = lost revenue + angry customer)
-```
-
-### AML (Anti-Money Laundering) Technical Controls
-
-```
-Structuring detection:    Transactions just below reporting thresholds (e.g., $9,900)
-                          Alert: 3+ transactions in 24h summing to >$10K per user
-
-Layering detection:       Rapid fund movement across multiple accounts
-                          Alert: Money in → out to different account within 1 hour
-
-Round-tripping:           Funds leaving and returning to same source
-                          Graph analysis: detect cycles in transaction graph
-
-SAR filing:               Automated SAR (Suspicious Activity Report) generation
-                          File with FinCEN within 30 days of detection (US requirement)
-                          Store SAR data with 5-year retention
-
-KYC integration:          Identity verification at onboarding (Jumio, Onfido, Persona)
-                          Enhanced due diligence for high-risk users (PEPs, high-volume)
-                          Ongoing monitoring: re-verify on behavior change triggers
-```
-
----
-
-## SECURITY METRICS (MEASURE THESE)
-
-```
-Detection:
-  MTTD:          Mean Time to Detect — target <1 hour for critical events
-  Alert fidelity: True positive rate of security alerts — target >30% (tune to reduce noise)
-  Coverage:       % of attack surface with detection rules
-
-Response:
-  MTTR:          Mean Time to Respond — target <4 hours for P0/P1
-  MTTC:          Mean Time to Contain — stop ongoing attack — target <30 min for P0
-
-Prevention:
-  Patch compliance: % of critical CVEs patched within SLA — target 100% for critical
-  Vuln backlog:   Open vulnerabilities by severity — track weekly, trending down
-  Security debt:  Security findings in code — track like technical debt
-
-Posture:
-  Cloud compliance score: CSPM findings — target 0 critical, <10 high
-  Pen test findings:      Track findings year-over-year — should decrease
-  Security training:      % staff completed annual training — target 100%
-
-Report to leadership: Monthly 1-page security scorecard. Executives must see these numbers.
-```
+# Cybersecurity Intelligence Reference
+
+# Covers: AppSec, NetSec, CloudSec, DevSecOps, Threat Intel, SIEM, Compliance, Fraud, Incident Response
+
+## DEFENSE IN DEPTH MODEL
+
+Never rely on a single control. Layer security at every level:
+
+```
+Layer 1 — Perimeter:      WAF, DDoS protection, CDN edge rules, geo-blocking
+Layer 2 — Network:        Firewall rules, VPC isolation, private subnets, VPN, zero-trust network access
+Layer 3 — Identity:       MFA, SSO, PAM, least privilege, just-in-time access
+Layer 4 — Application:    Input validation, auth/authz, CSRF, rate limiting, API security
+Layer 5 — Data:           Encryption at rest + transit, tokenization, masking, key management
+Layer 6 — Endpoint:       EDR, patch management, container hardening, OS baselines
+Layer 7 — Detection:      SIEM, anomaly detection, threat intel feeds, behavioral analytics
+Layer 8 — Response:       IR playbooks, forensics capability, backup/restore tested weekly
+
+Principle: Assume every layer will eventually be breached. Design so that one breach ≠ catastrophe.
+```
+
+---
+
+## OWASP TOP 10 — WEB (2021) — Fix Every One
+
+### A01: Broken Access Control (Most Common)
+
+```
+Attack:    Access /api/users/456 as user 123. Horizontal privilege escalation.
+Fix:       Always verify ownership: WHERE id = $1 AND org_id = $current_org
+           Row-Level Security in PostgreSQL enforces this at DB level.
+           Never trust user-supplied IDs without authorization check.
+Test:      Authenticated as User A, attempt all User B's resource endpoints.
+
+Code fix:
+// BAD:
+const tx = await db.transaction.findUnique({ where: { id: req.params.id }})
+
+// GOOD:
+const tx = await db.transaction.findUnique({
+  where: { id: req.params.id, userId: req.user.id }  // scope to authenticated user
+})
+if (!tx) throw new NotFoundError()  // same error whether missing or unauthorized
+```
+
+### A02: Cryptographic Failures
+
+```
+Attack:    Sensitive data in plaintext DB, MD5 passwords, HTTP traffic, weak keys.
+Fix:       TLS 1.3 everywhere. AES-256-GCM for data at rest.
+           Passwords: argon2id (winner of PHC). Never MD5/SHA1/bcrypt(cost<12).
+           PII fields: encrypt at application layer (not just disk encryption).
+           No secrets in logs. No PAN/SSN in URLs.
+
+Password hashing:
+import argon2 from 'argon2'
+const hash = await argon2.hash(password, {
+  type: argon2.argon2id,
+  memoryCost: 65536,  // 64MB
+  timeCost: 3,        // 3 iterations
+  parallelism: 4      // 4 threads
+})
+```
+
+### A03: Injection (SQL, NoSQL, LDAP, Command)
+
+```
+Attack:    User inputs: ' OR '1'='1 → dumps entire table.
+Fix:       Parameterized queries. ALWAYS. No string concatenation in queries.
+           ORM query builders (Prisma, SQLAlchemy) are safe by default.
+           Command injection: never exec() user input. Use allowlists.
+
+// NEVER:
+db.query(`SELECT * FROM users WHERE email = '${email}'`)
+
+// ALWAYS:
+db.query('SELECT * FROM users WHERE email = $1', [email])
+```
+
+### A04: Insecure Design
+
+```
+Attack:    Business logic flaws — buy item for $0, skip payment step, replay coupons.
+Fix:       Threat model every feature before coding.
+           State machine validation — enforce valid state transitions server-side.
+           Rate limit sensitive operations (password reset: 3/hour, not 1000/hour).
+           Never trust client-side price/discount calculation.
+```
+
+### A05: Security Misconfiguration
+
+```
+Common:   Default credentials, directory listing, verbose error messages in prod,
+          open S3 buckets, unrestricted CORS, unused ports open, debug mode on.
+Fix:      Infrastructure as Code — configuration is reviewed, version-controlled.
+          CSPM tool (Wiz, Prisma Cloud, or free: CloudSploit) scans continuously.
+          Env diff check: prod config audited against security baseline weekly.
+          Error responses: generic in prod, never stack traces to client.
+```
+
+### A06: Vulnerable and Outdated Components
+
+```
+Fix:      Renovate Bot or Dependabot — auto-PRs for dependency updates weekly.
+          Snyk or OWASP Dependency-Check in CI — block on critical CVEs.
+          Container base image scanning — Trivy on every Docker build.
+          SBOM (Software Bill of Materials) generated on every release.
+          Never use packages with 0 maintenance activity in past 12 months.
+          Pin exact versions in lockfiles (package-lock.json, requirements.txt).
+```
+
+### A07: Identification and Authentication Failures
+
+```
+Attack:   Credential stuffing, brute force, session fixation, weak tokens.
+Fix:      MFA mandatory for admin, recommended for all users.
+          Account lockout: 5 failed attempts → 15min lockout + alert.
+          Secure session: HttpOnly, Secure, SameSite=Strict cookies.
+          Token storage: never localStorage (XSS), always HttpOnly cookies.
+          Password policy: min 12 chars, check against HaveIBeenPwned API.
+          JWT: RS256 (not HS256), short TTL (15min), rotate signing keys quarterly.
+```
+
+### A08: Software and Data Integrity Failures
+
+```
+Attack:   Tampered auto-updates, unsigned packages, CI/CD pipeline compromise.
+Fix:      Verify checksums/signatures on all downloaded artifacts.
+          Sigstore/Cosign for container image signing.
+          SLSA framework for supply chain levels (target SLSA Level 3).
+          CI/CD: separate credentials per environment, audit pipeline configs.
+          npm: use --ignore-scripts flag, audit before install.
+```
+
+### A09: Security Logging and Monitoring Failures
+
+```
+Fix:      Log: every auth event, admin action, failed access, data mutation.
+          Include: timestamp (UTC), user_id, org_id, IP, action, resource, result.
+          Never log: passwords, tokens, PAN, SSN, CVV, full credit card.
+          Alert within 15 minutes on: impossible travel, mass data export,
+                                       admin privilege escalation, >10 auth failures.
+          Log retention: 90 days hot, 1 year cold (PCI DSS requires 1 year).
+          SIEM: ingest all logs, alert on patterns, not just individual events.
+```
+
+### A10: Server-Side Request Forgery (SSRF)
+
+```
+Attack:   User supplies URL → server fetches it → attacker reads internal metadata API.
+          AWS: http://169.254.169.254/latest/meta-data/iam/security-credentials/
+Fix:      Allowlist permitted URL destinations — never arbitrary user-supplied URLs.
+          Block RFC 1918 addresses (10.x, 172.16.x, 192.168.x) and 169.254.x.
+          Use DNS resolution + IP check BEFORE fetching.
+          Disable HTTP redirects or validate redirect target against allowlist.
+```
+
+---
+
+## OWASP API SECURITY TOP 10 (2023)
+
+```
+API1:  Broken Object Level Authorization  → Scope every query to authenticated user/org
+API2:  Broken Authentication              → Short-lived tokens, rotate refresh tokens
+API3:  Broken Object Property Auth        → Allowlist response fields, never return full DB row
+API4:  Unrestricted Resource Consumption  → Rate limit, payload size limits, pagination required
+API5:  Broken Function Level Auth         → Admin endpoints on separate auth check, not just UI hide
+API6:  Unrestricted Access to Sensitive Business Flows → Bot detection, device fingerprinting
+API7:  Server-Side Request Forgery        → Same as web SSRF above
+API8:  Security Misconfiguration          → No CORS *, no debug headers, no default paths
+API9:  Improper Inventory Management      → API versioning, decommission old versions with traffic
+API10: Unsafe Consumption of APIs         → Validate all third-party API responses before use
+```
+
+---
+
+## THREAT MODELING
+
+### STRIDE Framework (Apply to Every Feature)
+
+```
+S — Spoofing:         Can an attacker impersonate a legitimate user or service?
+                      Mitigate: Strong auth, mutual TLS, digital signatures
+
+T — Tampering:        Can data be modified in transit or at rest without detection?
+                      Mitigate: Integrity checks, signed tokens, audit logs, TLS
+
+R — Repudiation:      Can someone deny performing an action?
+                      Mitigate: Immutable audit logs, signed requests, non-repudiation tokens
+
+I — Information Disclosure: Can sensitive data be exposed to unauthorized parties?
+                      Mitigate: Least privilege, encryption, data classification, masking
+
+D — Denial of Service: Can an attacker disrupt availability?
+                      Mitigate: Rate limiting, auto-scaling, circuit breakers, DDoS protection
+
+E — Elevation of Privilege: Can a user gain more access than they should have?
+                      Mitigate: RBAC, least privilege, privilege validation server-side
+```
+
+### Threat Modeling Process (Per Feature)
+
+```
+Step 1: DECOMPOSE — Draw data flow diagram. Identify trust boundaries, entry points, data stores.
+Step 2: THREATS — For each component, apply STRIDE. List all plausible attacks.
+Step 3: RANK — Severity × Likelihood = Risk score (DREAD or CVSS)
+Step 4: MITIGATE — For each threat: mitigate, transfer, accept, or avoid.
+Step 5: VALIDATE — Write security test for each mitigated threat.
+Step 6: REPEAT — Re-threat-model when architecture changes.
+
+Time required: 2-4 hours per major feature. Non-negotiable for financial features.
+```
+
+---
+
+## APPLICATION SECURITY (APPSEC) PIPELINE
+
+### DevSecOps — Shift Left
+
+```
+Pre-commit:     git-secrets / detect-secrets / Gitleaks — block secret commits
+                IDE plugins: Snyk IntelliJ, SonarLint VSCode (real-time SAST)
+
+PR / CI:        SAST — Static analysis (Semgrep, SonarQube, CodeQL)
+                SCA  — Dependency check (Snyk, OWASP DC, npm audit)
+                Secrets scan — Gitleaks, TruffleHog
+                IaC scan — Checkov, tfsec (Terraform misconfigs)
+                Container scan — Trivy (image CVEs)
+
+Pre-deploy:     DAST — Dynamic scan against staging (OWASP ZAP, Burp Suite)
+                API fuzzing — Schemathesis, restler-fuzzer
+
+Production:     RASP — Runtime application self-protection (contrast, sqreen)
+                WAF — Cloudflare WAF / AWS WAF / Cloud Armor (rules updated weekly)
+                Dependency monitor — Snyk monitor / Dependabot alerts
+```
+
+### SAST Tool Selection
+
+```
+Semgrep:        Fast, open source, custom rules, CI-native. Best first choice.
+SonarQube:      Comprehensive, CI integration, tracks debt over time. Self-hosted or cloud.
+CodeQL:         GitHub-native, deep semantic analysis, best for complex vulnerability patterns.
+Checkmarx:      Enterprise, expensive, deep analysis.
+Veracode:       Enterprise SaaS, compliance-oriented.
+
+Run Semgrep + SonarQube minimum. CodeQL for GitHub repos (free for public).
+```
+
+### Penetration Testing Methodology
+
+```
+Phase 1 — Reconnaissance:
+  Passive: Shodan, Censys, Google dorks, LinkedIn (OSINT)
+  Active:  nmap port scan, service fingerprinting, SSL/TLS scan (testssl.sh)
+
+Phase 2 — Enumeration:
+  Web: Dirb/ffuf (directory brute-force), nikto (web scanner)
+  API: Postman collection analysis, OpenAPI spec review, parameter fuzzing
+  Auth: JWT inspection, session token analysis, OAuth flow review
+
+Phase 3 — Exploitation:
+  Automated: OWASP ZAP active scan, SQLmap (SQL injection), Nuclei templates
+  Manual: Business logic testing, auth bypass, IDOR, race conditions
+
+Phase 4 — Post-Exploitation:
+  Lateral movement (if scoped), privilege escalation, persistence mechanisms
+
+Phase 5 — Reporting:
+  CVSS scores for each finding, reproduction steps, remediation guidance, risk rating
+
+Cadence: Annual third-party pentest + quarterly internal. Before major releases.
+Tools: Burp Suite Pro, OWASP ZAP, Metasploit, Nmap, Nikto, SQLmap, Nuclei, Amass
+```
+
+---
+
+## ZERO TRUST ARCHITECTURE
+
+```
+Core Principles:
+  1. Never trust, always verify — network location grants zero trust
+  2. Least privilege access — time-limited, just enough, just-in-time
+  3. Assume breach — segment everything, monitor everything, limit blast radius
+  4. Verify explicitly — authenticate and authorize every request, every time
+
+Implementation:
+  Identity:      Every user + device verified before access (MFA + device health check)
+  Device:        Managed devices only for admin access. MDM enrolled.
+  Network:       Micro-segmentation. Services can't talk unless explicitly allowed.
+                 Replace VPN with identity-aware proxy (Google BeyondCorp, Cloudflare Access)
+  Application:   Each app verifies identity independently. No "trusted" internal networks.
+  Data:          Classify data. Apply policy per classification. Encrypt in use.
+
+GCP Implementation:
+  Identity-Aware Proxy (IAP) → protects internal apps without VPN
+  VPC Service Controls → data perimeter, prevents data exfil from GCP services
+  Organization Policy → org-wide guardrails (no public IPs, require CMEK, etc.)
+  Access Context Manager → attribute-based access (IP, device, user)
+```
+
+---
+
+## CLOUD SECURITY (CSPM + CWPP)
+
+### Cloud Security Posture Management (CSPM)
+
+```
+What it does:   Continuously scans cloud config for misconfigurations and compliance violations
+Tools:
+  Wiz:          Best coverage, agentless, fast. $15K+/yr
+  Prisma Cloud: Palo Alto, comprehensive, expensive
+  Lacework:     Behavioral analysis + CSPM combo
+  CloudSploit:  Open source, GCP/AWS/Azure. Free.
+  ScoutSuite:   Open source audit tool. Run quarterly.
+
+Must-catch misconfigs:
+  □ Public S3/GCS buckets
+  □ Unrestricted security group rules (0.0.0.0/0 inbound)
+  □ Unencrypted database instances
+  □ MFA not enabled on root/admin accounts
+  □ Logging disabled (CloudTrail/Cloud Audit Logs)
+  □ Old IAM access keys (>90 days)
+  □ Public SSH/RDP ports exposed (22, 3389)
+  □ Default VPC in use for production
+```
+
+### Container & Kubernetes Security
+
+```
+Image security:
+  □ Base image: use distroless or alpine (minimal attack surface)
+  □ Never run as root (USER nobody in Dockerfile)
+  □ No secrets in image layers (check with Trivy --secret)
+  □ Sign images with Cosign (Sigstore)
+  □ Image pull policy: Always (never cached stale images in prod)
+
+Kubernetes:
+  □ RBAC: no cluster-admin for workloads. Namespace-scoped roles only.
+  □ Network Policies: default deny all, explicit allow per service pair
+  □ Pod Security Standards: Restricted profile in production
+  □ Secrets: use External Secrets Operator (GCP Secret Manager → K8s Secret)
+  □ No privileged containers. No hostPID/hostNetwork.
+  □ Resource limits on every container (prevents noisy neighbor + DoS)
+  □ Admission controllers: OPA/Gatekeeper or Kyverno policy engine
+  □ Runtime: Falco (detects anomalous container behavior in real-time)
+
+Runtime security:
+  Falco rules to alert on:
+    - Shell spawned in container (exec into running container)
+    - Unexpected outbound connections from container
+    - Sensitive file read (/etc/shadow, /proc/*/mem)
+    - Privilege escalation attempts
+```
+
+### GCP Security Hardening Checklist
+
+```
+Organization level:
+  □ Organization Policy: Restrict public IPs on Cloud SQL
+  □ Organization Policy: Require OS Login for Compute Engine
+  □ Organization Policy: Restrict allowed APIs per project
+  □ Cloud Audit Logs: DATA_READ + DATA_WRITE + ADMIN_WRITE on all services
+  □ SCC (Security Command Center) Premium enabled
+
+Project level:
+  □ Default service accounts not used (create custom, least privilege)
+  □ Service account keys: rotate quarterly or use Workload Identity instead
+  □ Cloud SQL: private IP only, no public IP, SSL required
+  □ GCS: uniform bucket-level access, no legacy ACLs
+  □ Cloud Run: no unauthenticated invocations (except public endpoints)
+  □ Secret Manager: audit access log enabled, rotation schedule set
+  □ VPC: Private Google Access enabled, no default firewall rules
+```
+
+---
+
+## SECURITY MONITORING & SIEM
+
+### What to Log (Mandatory)
+
+```
+Authentication events:
+  login_success, login_failure, logout, mfa_challenge, mfa_success, mfa_failure,
+  password_reset_requested, password_changed, token_refreshed, token_revoked,
+  session_expired, account_locked, account_unlocked
+
+Authorization events:
+  access_denied, privilege_escalation_attempt, role_assigned, role_revoked,
+  admin_action (any), api_key_created, api_key_deleted
+
+Data events:
+  record_created, record_updated, record_deleted (with before/after for sensitive fields),
+  bulk_export, bulk_delete, pii_accessed (who accessed whose data)
+
+Infrastructure events:
+  deploy_started, deploy_completed, deploy_failed, config_changed,
+  secret_accessed (who, when, which secret), IAM_policy_changed
+
+Format (every log line must have all fields):
+{
+  "timestamp": "2024-01-15T10:30:00.000Z",  // UTC always
+  "trace_id": "abc-123",                     // correlate across services
+  "user_id": "usr_xyz",                      // who did it
+  "org_id": "org_abc",                       // tenant context
+  "ip": "1.2.3.4",                           // source IP
+  "user_agent": "...",                       // client context
+  "action": "transaction.created",           // what happened
+  "resource_id": "tx_123",                   // on what
+  "result": "success",                       // success/failure/denied
+  "duration_ms": 45                          // performance context
+}
+```
+
+### SIEM Architecture
+
+```
+Sources:           App logs, Cloud Audit Logs, WAF logs, VPC Flow Logs, DNS logs
+Ingestion:         Pub/Sub (GCP) or Kafka → log pipeline
+Normalization:     Parse into common schema (CEF or ECS — Elastic Common Schema)
+Storage:           BigQuery (GCP) or Elasticsearch — index for fast search
+Correlation:       Detection rules — alert on patterns, not single events
+Alerting:          PagerDuty / OpsGenie → on-call rotation
+Response:          SOAR (Security Orchestration) — auto-remediate known patterns
+
+Tools:
+  Managed:        Google Chronicle, Microsoft Sentinel, Splunk, Sumo Logic
+  Open source:    ELK Stack (Elasticsearch + Logstash + Kibana) + Sigma rules
+  Lightweight:    Grafana + Loki + alert rules (good for small teams, low cost)
+  GCP-native:     Chronicle SIEM (Google's) — best GCP log integration
+```
+
+### Detection Rules (Critical Alerts — PagerDuty Immediately)
+
+```
+Brute force:       >10 auth failures from same IP in 5 minutes
+Credential stuffing: >5 failed logins across different accounts from same IP
+Impossible travel: Login from country A, then country B within 2 hours
+Mass data export:  Single user exports >1000 records in 10 minutes
+Privilege escalation: Role change granting admin-level access
+New admin account: Any new user assigned admin/owner role
+Off-hours admin:   Admin action between 10PM-6AM (tune per org)
+API key abuse:     Single API key >10,000 requests in 1 hour
+Secret access:     Service accessing secrets it has never accessed before
+Public resource:   Cloud storage bucket or DB made publicly accessible
+New external IP:   Cloud Run service starts communicating with unknown external IP
+```
+
+### Threat Intelligence Integration
+
+```
+Feeds to consume:
+  MITRE ATT&CK:   Adversary tactics, techniques, procedures (TTPs) — map detections to ATT&CK
+  CISA KEV:       Known Exploited Vulnerabilities — patch these IMMEDIATELY (cisa.gov/kev)
+  NVD CVE:        National Vulnerability Database — monitor for new critical CVEs
+  AlienVault OTX: Open threat intelligence — IP/domain/hash reputation
+  Shodan:         Monitor your own external attack surface
+  PhishTank:      Phishing URL feeds
+
+Integration pattern:
+  Enrich every inbound IP in logs against threat intel feed (check reputation score)
+  Block known-bad IPs at WAF level automatically
+  Alert when traffic matches known malicious patterns (IoCs)
+
+Tools: MISP (open source threat intel platform), OpenCTI, ThreatConnect
+```
+
+---
+
+## CRYPTOGRAPHY STANDARDS
+
+### What to Use (2024)
+
+```
+Symmetric encryption:  AES-256-GCM (authenticated encryption — integrity + confidentiality)
+                       ChaCha20-Poly1305 (faster on mobile/embedded, same security)
+                       Never: DES, 3DES, AES-ECB, RC4
+
+Asymmetric:            RSA-4096 (key exchange/signing) — prefer Ed25519 for new systems
+                       Ed25519 / ECDSA P-256 (digital signatures — faster, smaller keys)
+                       ECDH P-256 (key agreement)
+                       Never: RSA < 2048, DSA, MD5/SHA1 for signing
+
+Hashing:               SHA-256 / SHA-3 for data integrity
+                       BLAKE3 for performance-critical hashing
+                       argon2id for password storage (never SHA/MD5 for passwords)
+                       Never: MD5, SHA1 for security purposes
+
+TLS:                   TLS 1.3 required. TLS 1.2 acceptable with restricted ciphers.
+                       Never: SSL, TLS 1.0, TLS 1.1
+                       Cipher suites: ECDHE + AES-128-GCM, ECDHE + AES-256-GCM, ECDHE + ChaCha20
+
+Key management:        GCP Cloud KMS or AWS KMS or HashiCorp Vault
+                       Rotate encryption keys annually
+                       Key hierarchy: Master Key → Data Encryption Keys → Data
+                       FIPS 140-2 Level 3 HSM for financial/regulated workloads
+
+JWT signing:           RS256 (RSA) or ES256 (ECDSA) — never HS256 in multi-service arch
+                       Key rotation: quarterly, with overlap period
+```
+
+### Envelope Encryption Pattern
+
+```python
+# Google Cloud KMS envelope encryption
+from google.cloud import kms
+
+def encrypt_sensitive_field(plaintext: str, key_name: str) -> dict:
+    # 1. Generate a data encryption key (DEK) locally
+    import os
+    dek = os.urandom(32)  # 256-bit AES key
+
+    # 2. Encrypt your data with the DEK
+    ciphertext = aes_gcm_encrypt(plaintext.encode(), dek)
+
+    # 3. Wrap (encrypt) the DEK with Cloud KMS master key
+    kms_client = kms.KeyManagementServiceClient()
+    wrapped_dek = kms_client.encrypt(name=key_name, plaintext=dek).ciphertext
+
+    # 4. Store: ciphertext + wrapped DEK (KMS key never leaves KMS)
+    return {"ciphertext": ciphertext.hex(), "wrapped_dek": wrapped_dek.hex()}
+    # Decrypt: unwrap DEK via KMS → decrypt ciphertext with DEK
+```
+
+---
+
+## IDENTITY & ACCESS MANAGEMENT
+
+### Privileged Access Management (PAM)
+
+```
+Just-In-Time (JIT) access:
+  Engineers request elevated access for specific task + timeframe
+  Auto-approved for standard ops, human approval for sensitive data access
+  Access expires automatically (1-8 hours, not permanent)
+  All actions logged with business justification
+  Tools: CyberArk, BeyondTrust, HashiCorp Boundary, GCP PAM (preview)
+
+Service-to-service auth:
+  GCP: Workload Identity Federation (no service account keys)
+  AWS: IAM Roles for Service Accounts (IRSA)
+  On-prem: SPIFFE/SPIRE for workload identity
+  Never: long-lived service account keys stored in config
+
+MFA Requirements (enforce in code, not just policy):
+  Admin access: FIDO2/Passkeys or hardware token (YubiKey) — TOTP not sufficient
+  Standard users: TOTP app minimum (Google Authenticator, Authy)
+  API access: API keys + IP allowlist + request signing
+  Never: SMS-based MFA for high-value accounts (SIM swap vulnerable)
+```
+
+### IAM Audit (Run Monthly)
+
+```
+Find over-privileged roles:
+  GCP: gcloud projects get-iam-policy PROJECT --format=json | analyze
+  AWS: IAM Access Analyzer + unused access findings
+
+Check for:
+  □ Roles with * on resources (over-broad)
+  □ Service accounts with owner/editor (should be specific roles)
+  □ IAM access keys older than 90 days
+  □ Unused service accounts (no API activity >30 days → delete)
+  □ Users with direct permissions (should be via groups/roles)
+  □ Cross-account trust relationships (any unexpected?)
+```
+
+---
+
+## INCIDENT RESPONSE
+
+### Severity Classification
+
+```
+P0 — Critical:   Active breach, data exfil in progress, ransomware, service down
+                 Response: 5min. War room immediately. CEO + Legal notified.
+
+P1 — High:       Suspected breach, critical vuln exploited, auth system compromised
+                 Response: 15min. Security lead + engineering lead.
+
+P2 — Medium:     Anomalous behavior, failed exploitation attempt, compliance gap found
+                 Response: 1 hour. Security team + affected service owner.
+
+P3 — Low:        Policy violation, low-severity CVE, config drift
+                 Response: Next business day. Assigned owner.
+```
+
+### NIST Incident Response Framework
+
+```
+1. PREPARE:
+   □ IR plan documented + tested quarterly
+   □ Contact list: security team, legal, PR, executives, regulators
+   □ Forensic tools pre-installed (not scrambling to install during incident)
+   □ Evidence preservation procedures known to all engineers
+   □ Cyber insurance policy in place
+
+2. IDENTIFY:
+   □ What happened? When did it start? (look for earliest indicator)
+   □ What systems are affected? (blast radius assessment)
+   □ Is it still ongoing? (contain before investigating)
+   □ Log preservation: export logs to isolated read-only bucket immediately
+
+3. CONTAIN:
+   Short-term: Block attacker (IP ban, revoke credentials, isolate instance)
+   Long-term: Patch, fix configuration, rebuild if necessary
+   Do NOT shut everything down immediately — preserve evidence first
+
+4. ERADICATE:
+   Remove all attacker persistence (backdoors, new user accounts, cron jobs)
+   Scan ALL systems — attackers often pivot from initial compromise
+   Reset all credentials that may have been exposed
+   Rotate all secrets (assume all secrets compromised)
+
+5. RECOVER:
+   Restore from clean backups (verify backups are clean — attackers may have been in months)
+   Deploy patched/clean systems
+   Monitor intensively for 30 days post-recovery
+   Gradual return to service — don't rush
+
+6. LESSONS LEARNED:
+   Blameless post-mortem within 72 hours
+   Root cause analysis (5 Whys)
+   Detection gap: why didn't we catch this sooner?
+   Prevention: specific fixes with owners and deadlines
+   Update runbooks + detection rules
+```
+
+### Breach Notification Requirements
+
+```
+GDPR:          72 hours to supervisory authority if personal data affected
+CCPA:          Reasonable notice to affected California residents
+PCI DSS:       Immediate notification to card brands (Visa, Mastercard) + acquiring bank
+HIPAA:         60 days to HHS, affected individuals, and media (if >500 in a state)
+India PDPB:    72 hours to Data Protection Board (when enacted)
+SEC (US):      4 business days for material cybersecurity incidents (Rule 8-K)
+RBI (India):   Immediate to RBI CSITE + NPCI for payment system incidents
+
+Prepare breach notification templates in advance. Legal review annually.
+```
+
+---
+
+## VULNERABILITY MANAGEMENT
+
+### CVE Tracking & Patch SLAs
+
+```
+CVSS Score → Patch Timeline:
+  Critical (9.0-10.0): Patch within 24 hours. Emergency change if needed.
+  High (7.0-8.9):      Patch within 7 days.
+  Medium (4.0-6.9):    Patch within 30 days.
+  Low (0.1-3.9):       Patch within 90 days.
+
+CISA KEV overrides: Patch within 2 weeks regardless of CVSS (these are actively exploited).
+
+Automation:
+  Renovate Bot:  Auto-PRs for dependency updates (better than Dependabot — more flexible)
+  Trivy:         Scan container images in CI, block critical CVEs
+  Snyk:          Monitor production containers + code continuously
+  Grafeas:       Artifact metadata and attestation (GCP-native)
+```
+
+### SBOM (Software Bill of Materials)
+
+```
+Generate on every release:
+  Node.js:  cyclonedx-node-npm --output-file sbom.json
+  Python:   cyclonedx-py -p -e -o sbom.json
+  Java:     CycloneDX Maven/Gradle plugin
+  Docker:   syft image:tag -o cyclonedx-json=sbom.json
+
+Store in artifact registry alongside each release.
+Required by: US Executive Order 14028, EU Cyber Resilience Act, PCI DSS 4.0.
+Enables: rapid "do we use Log4j?" type queries during zero-day events.
+```
+
+---
+
+## COMPLIANCE FRAMEWORKS
+
+### SOC 2 Type II (Most Important for SaaS)
+
+```
+Trust Services Criteria:
+  Security:       CC6 — Logical access, CC7 — System operations, CC8 — Change management
+  Availability:   Uptime SLAs, disaster recovery, capacity planning
+  Confidentiality: Data classification, encryption, access controls
+  Processing Integrity: Complete, accurate, timely processing
+  Privacy:        GDPR/CCPA alignment, consent management
+
+Controls required (sample):
+  □ All access requires MFA
+  □ Background checks for all employees with system access
+  □ Annual security training for all staff
+  □ Penetration test annually
+  □ Business continuity plan tested annually
+  □ Incident response tested quarterly
+  □ Vendor security assessments for critical vendors
+  □ Encryption at rest and in transit
+  □ Change management process documented
+  □ Vulnerability management program with SLAs
+
+Tools:
+  Vanta:   Best automated SOC2 prep (<user> already using). ~$15K/yr. Gets to audit-ready fastest.
+  Drata:   Vanta competitor, good integrations.
+  Secureframe: Strong for early-stage.
+  Manual: Feasible but 10x more work.
+
+Timeline: SOC2 Type I in 3 months (controls exist). Type II in 12 months (controls operated for period).
+```
+
+### PCI DSS 4.0 (If Handling Card Data)
+
+```
+Key requirements for SaaS (Level 4 — <20K transactions):
+  □ Never store raw PANs, CVV, or full magnetic stripe
+  □ Tokenize: use Stripe.js/Elements — card data never touches your server
+  □ WAF protecting all web-facing systems
+  □ Vulnerability scanning quarterly (ASV scan)
+  □ Penetration test annually
+  □ Maintain audit logs 12 months
+  □ MFA for all non-consumer access
+  □ Encrypt cardholder data in transit (TLS 1.2+)
+  □ Self-Assessment Questionnaire (SAQ A or SAQ A-EP for most SaaS)
+
+Best advice: Use Stripe.js + Stripe Elements. Never touch raw card data. Reduces scope to SAQ A.
+```
+
+### GDPR / Data Privacy
+
+```
+Core requirements:
+  □ Lawful basis for processing (consent, contract, legitimate interest, etc.)
+  □ Data subject rights: access, rectification, erasure ("right to be forgotten"), portability
+  □ Privacy by design: collect minimum data, purpose limitation
+  □ Data Processing Agreements (DPAs) with all sub-processors
+  □ Records of Processing Activities (ROPA) — document what you process and why
+  □ 72-hour breach notification to supervisory authority
+  □ DPIA (Data Protection Impact Assessment) for high-risk processing
+  □ Cookie consent — real consent, not dark patterns
+
+Technical implementation:
+  Data inventory:   Every field of every table — classify: PII / sensitive / public
+  Erasure:          User delete → anonymize or delete all PII across all tables + backups
+  Portability:      Export user data as machine-readable JSON/CSV on request
+  Data residency:   EU personal data must stay in EU (or adequate third country)
+  Consent logging:  Timestamp, IP, consent text version for every consent collected
+```
+
+---
+
+## FRAUD DETECTION & FINANCIAL CRIME (<project>-Specific)
+
+### Real-Time Fraud Signal Architecture
+
+```
+Transaction Event → Feature Extraction → Risk Scoring → Decision → Action
+                          ↓                    ↓
+                   [Feature Store]      [ML Model + Rules]
+                          ↓
+              velocity, device, IP, behavior, history
+
+Signal categories:
+  Velocity:      transactions per hour/day, amount per period, new payee frequency
+  Device:        device fingerprint, new device, rooted/jailbroken, emulator detected
+  Location:      IP geolocation, distance from last transaction, impossible travel
+  Behavior:      typing speed, session duration, navigation pattern (vs baseline)
+  Network:       VPN/proxy/Tor detected, datacenter IP, known fraud IP
+  Identity:      name/address/phone mismatch, synthetic identity signals
+  Transaction:   unusual amount (vs history), unusual merchant, round amounts, split transactions
+```
+
+### Fraud Rule Engine Design
+
+```
+Priority execution:
+  P0 Hard Block:   Stolen card list, OFAC sanctions match, known fraud device → instant deny
+  P1 Hard Block:   Velocity limit exceeded, impossible travel, known fraud IP → instant deny
+  P2 Soft Block:   ML score > 0.9 → step-up auth (OTP required)
+  P3 Review:       ML score 0.7-0.9 → human review queue
+  P4 Monitor:      ML score 0.4-0.7 → flag for pattern analysis
+  P5 Allow:        ML score < 0.4 → approve (standard risk)
+
+Rule governance:
+  Every rule: owner, creation date, last review date, hit rate, precision/recall
+  Rules reviewed monthly — prune low-precision rules, add new patterns
+  A/B test rule changes — never deploy blind
+  False positive rate target: <0.5% (every false positive = lost revenue + angry customer)
+```
+
+### AML (Anti-Money Laundering) Technical Controls
+
+```
+Structuring detection:    Transactions just below reporting thresholds (e.g., $9,900)
+                          Alert: 3+ transactions in 24h summing to >$10K per user
+
+Layering detection:       Rapid fund movement across multiple accounts
+                          Alert: Money in → out to different account within 1 hour
+
+Round-tripping:           Funds leaving and returning to same source
+                          Graph analysis: detect cycles in transaction graph
+
+SAR filing:               Automated SAR (Suspicious Activity Report) generation
+                          File with FinCEN within 30 days of detection (US requirement)
+                          Store SAR data with 5-year retention
+
+KYC integration:          Identity verification at onboarding (Jumio, Onfido, Persona)
+                          Enhanced due diligence for high-risk users (PEPs, high-volume)
+                          Ongoing monitoring: re-verify on behavior change triggers
+```
+
+---
+
+## SECURITY METRICS (MEASURE THESE)
+
+```
+Detection:
+  MTTD:          Mean Time to Detect — target <1 hour for critical events
+  Alert fidelity: True positive rate of security alerts — target >30% (tune to reduce noise)
+  Coverage:       % of attack surface with detection rules
+
+Response:
+  MTTR:          Mean Time to Respond — target <4 hours for P0/P1
+  MTTC:          Mean Time to Contain — stop ongoing attack — target <30 min for P0
+
+Prevention:
+  Patch compliance: % of critical CVEs patched within SLA — target 100% for critical
+  Vuln backlog:   Open vulnerabilities by severity — track weekly, trending down
+  Security debt:  Security findings in code — track like technical debt
+
+Posture:
+  Cloud compliance score: CSPM findings — target 0 critical, <10 high
+  Pen test findings:      Track findings year-over-year — should decrease
+  Security training:      % staff completed annual training — target 100%
+
+Report to leadership: Monthly 1-page security scorecard. Executives must see these numbers.
+```