sinapse-ai 9.2.0 → 9.4.0

package/squads/squad-cybersecurity/knowledge-base/vulnerability-management.md

@@ -0,0 +1,349 @@
+# Vulnerability Management Reference
+
+## Purpose
+
+Reference for the full vulnerability management lifecycle — CVE process, scanning tools, patch management SLAs, and remediation prioritization. Used by Breach (penetration-tester), Sentinel (soc-analyst), and Govern (compliance-officer).
+
+---
+
+## Vulnerability Management Lifecycle
+
+```
+Discovery → Assessment → Prioritization → Remediation → Verification → Reporting
+    ↑                                                                       |
+    └───────────────────── Continuous cycle ───────────────────────────────┘
+```
+
+---
+
+## CVE Process
+
+### The CVE System
+
+**CVE (Common Vulnerabilities and Exposures):** A standardized identifier system for known security vulnerabilities. Managed by MITRE Corporation with support from CISA.
+
+**CVE ID format:** CVE-[YEAR]-[NUMBER] (e.g., CVE-2021-44228 = Log4Shell)
+
+**NVD (National Vulnerability Database):** NIST-maintained database that enriches CVEs with CVSS scores, affected products (CPE), and remediation guidance. Every CVE gets scored in NVD.
+
+**CVSS (Common Vulnerability Scoring System) v3.1:**
+| Score | Severity | Remediation SLA (Production) |
+|-------|---------|------------------------------|
+| 9.0–10.0 | Critical | 24–48 hours |
+| 7.0–8.9 | High | 7 days |
+| 4.0–6.9 | Medium | 30 days |
+| 0.1–3.9 | Low | 90 days |
+| 0.0 | None | Best effort |
+
+**EPSS (Exploit Prediction Scoring System):** Complements CVSS — predicts the probability a vulnerability will be exploited in the wild within the next 30 days. A CVSS 7.0 vulnerability with EPSS > 50% should be treated as critical-urgency. Check at: https://api.first.org/data/v1/epss
+
+---
+
+## Vulnerability Scanning
+
+### Scanning Architecture
+
+```
+Continuous scanning (daily/weekly):
+  SCA (dependencies) → SAST (code) → DAST (running app) → Infrastructure
+
+Point-in-time (pre-deploy, quarterly):
+  Penetration test → Configuration audit → Red team exercise
+```
+
+### Dependency Scanning (SCA)
+
+```bash
+# npm audit (built-in)
+npm audit
+npm audit --audit-level=high  # Exit non-zero only for high+
+npm audit fix  # Auto-fix non-breaking changes
+
+# Snyk (richer data, fixability scoring)
+npx snyk test
+npx snyk monitor  # Track over time
+
+# OWASP Dependency-Check (Java/.NET, also supports npm)
+dependency-check --project "MyProject" --scan ./
+
+# Trivy (containers + filesystems)
+trivy fs --severity HIGH,CRITICAL .
+trivy image --severity HIGH,CRITICAL myapp:latest
+```
+
+### Static Analysis (SAST)
+
+```bash
+# Semgrep -- fast, rules-based
+semgrep --config=auto .
+semgrep --config=p/security-audit .
+semgrep --config=p/owasp-top-ten .
+
+# Custom rules example
+# .semgrep/rules/no-hardcoded-secrets.yaml
+rules:
+  - id: no-hardcoded-api-key
+    patterns:
+      - pattern: $KEY = "sk_live_..."
+      - pattern: $KEY = "AKIA..."
+    message: Potential hardcoded API key detected
+    severity: ERROR
+    languages: [javascript, typescript]
+
+# CodeQL (GitHub Advanced Security)
+# Enable in GitHub repository settings -- free for public repos
+# Runs automatically on PRs
+
+# SonarQube/SonarCloud
+sonar-scanner \
+  -Dsonar.projectKey=my-project \
+  -Dsonar.sources=./src \
+  -Dsonar.host.url=https://sonarcloud.io \
+  -Dsonar.login=$SONAR_TOKEN
+```
+
+### Dynamic Scanning (DAST)
+
+```bash
+# OWASP ZAP -- automated scan
+# Full scan (comprehensive, use in QA/staging)
+docker run -t owasp/zap2docker-stable zap-full-scan.py \
+  -t https://staging.myapp.com \
+  -r zap-report.html
+
+# Baseline scan (passive, safe for production checks)
+docker run -t owasp/zap2docker-stable zap-baseline.py \
+  -t https://myapp.com
+
+# Nuclei -- template-based
+nuclei -u https://staging.myapp.com \
+  -t /opt/nuclei-templates/ \
+  -severity critical,high,medium \
+  -o nuclei-results.json
+```
+
+### Infrastructure Scanning
+
+```bash
+# Nmap -- port and service discovery
+nmap -sV -sC --open -T4 -p 1-65535 target.example.com
+
+# SSL/TLS configuration
+sslyze --regular target.example.com:443
+testssl.sh target.example.com
+
+# Shodan (check what's exposed on the internet)
+shodan host <your-ip>  # Requires Shodan API key
+
+# Check for exposed services using Shodan
+shodan search "org:MyCompany" --fields "ip_str,port,product"
+```
+
+---
+
+## Prioritization Framework
+
+### Risk-Based Prioritization
+
+Not all vulnerabilities are equal. Prioritize based on:
+
+```
+Priority Score = Severity × Exploitability × Business Impact × Exposure
+
+High Priority:
+- CVSS 9.0+ AND EPSS > 20%
+- Any CVE with known public exploit
+- Vulnerability in public-facing system
+- Vulnerability enabling RCE or data exfiltration
+
+Medium Priority:
+- CVSS 7.0–8.9, no public exploit
+- CVSS 9.0+ in internal system only
+- Information disclosure vulnerabilities
+
+Lower Priority:
+- CVSS < 7.0
+- Requires physical access
+- Requires authenticated access in already-trusted context
+```
+
+### Remediation SLA Matrix
+
+| Severity | EPSS > 50% | EPSS < 50% | In Active Exploitation |
+|----------|-----------|-----------|----------------------|
+| Critical | 24 hours | 48 hours | IMMEDIATE — escalate now |
+| High | 48 hours | 7 days | 24 hours |
+| Medium | 7 days | 30 days | 7 days |
+| Low | 30 days | 90 days | 30 days |
+
+### CISA Known Exploited Vulnerabilities (KEV) Catalog
+
+CISA maintains a catalog of vulnerabilities known to be actively exploited. If a CVE appears on this list, treat it as critical regardless of CVSS score.
+
+Check: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
+
+```bash
+# Check if your CVEs are in KEV catalog
+curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
+  jq '.vulnerabilities[] | select(.cveID == "CVE-2021-44228")'
+```
+
+---
+
+## Patch Management
+
+### Patching Process
+
+```
+1. Vulnerability Identified
+   ↓
+2. Asset impact analysis (which systems are affected?)
+   ↓
+3. Risk assessment (CVSS + EPSS + exposure)
+   ↓
+4. Patch availability check (vendor advisory, fix available?)
+   ↓
+5. Testing (test patch in non-production environment)
+   ↓
+6. Approval (change management process)
+   ↓
+7. Deployment (rolling update or maintenance window)
+   ↓
+8. Verification (rescan to confirm vulnerability closed)
+   ↓
+9. Documentation (update vulnerability records)
+```
+
+### Zero-Day Management (No Patch Available)
+
+When a patch is not yet available, implement mitigations:
+
+**Temporary mitigations:**
+- WAF rules to block known exploit patterns
+- Network segmentation to limit blast radius
+- Disable vulnerable feature if not required
+- Enhanced monitoring for exploitation indicators
+- Rate limiting on affected endpoints
+
+**Log4Shell example (December 2021):**
+```
+Day 0 (no patch):
+1. Deployed WAF rules blocking JNDI lookup strings in request headers/body
+2. Disabled JNDI lookups via JVM flag: -Dlog4j2.formatMsgNoLookups=true
+3. Enhanced monitoring for outbound LDAP/DNS to unknown hosts
+4. Isolated affected systems from sensitive data stores
+
+Day 3 (patch available):
+5. Updated to Log4j 2.16.0
+6. Verified across all applications via SBOM scan
+7. Removed temporary WAF rules
+```
+
+---
+
+## Continuous Scanning Pipeline
+
+### GitHub Actions Security Pipeline
+
+```yaml
+name: Security Scanning
+
+on:
+  push:
+    branches: [main, develop]
+  pull_request:
+  schedule:
+    - cron: '0 2 * * 1'  # Weekly Monday 2 AM
+
+jobs:
+  dependency-scan:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: npm audit
+        run: npm audit --audit-level=high
+      
+      - name: Snyk SCA
+        uses: snyk/actions/node@master
+        env:
+          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
+        with:
+          args: --severity-threshold=high
+
+  sast-scan:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Semgrep SAST
+        uses: returntocorp/semgrep-action@v1
+        with:
+          config: >-
+            p/security-audit
+            p/owasp-top-ten
+
+  container-scan:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Build image
+        run: docker build -t myapp:${{ github.sha }} .
+      
+      - name: Trivy container scan
+        uses: aquasecurity/trivy-action@master
+        with:
+          image-ref: myapp:${{ github.sha }}
+          format: sarif
+          exit-code: 1
+          severity: HIGH,CRITICAL
+          output: trivy-results.sarif
+      
+      - name: Upload to GitHub Security
+        uses: github/codeql-action/upload-sarif@v3
+        with:
+          sarif_file: trivy-results.sarif
+```
+
+---
+
+## Vulnerability Metrics and Reporting
+
+### Key Metrics to Track
+
+| Metric | Definition | Target |
+|--------|-----------|--------|
+| MTTD | Mean Time to Detect (from introduction to discovery) | < 24 hours for critical |
+| MTTR | Mean Time to Remediate (from discovery to fix) | Per SLA above |
+| Vulnerability backlog | Open vulns by severity | Critical: 0, High: < 5 |
+| Patch compliance rate | % of systems patched within SLA | > 95% |
+| Vulnerability density | Vulns per 1000 lines of code | Trend down over time |
+
+### Vulnerability Tracking
+
+Every vulnerability should be tracked in your issue tracking system with:
+
+```
+Title: [CVE-ID] Vulnerability description in component X
+Severity: [Critical/High/Medium/Low]
+CVSS Score: X.X
+EPSS Score: XX%
+Affected systems: [list]
+Discovered: [date]
+Due date: [per SLA]
+Owner: [person responsible]
+Status: [Open/In Progress/Remediated/Accepted Risk]
+Mitigation: [if patch not yet available]
+Verification: [rescan result confirming fix]
+```
+
+---
+
+## Sources
+
+- NVD (NIST): https://nvd.nist.gov/
+- FIRST CVSS Calculator: https://www.first.org/cvss/calculator/3.1
+- EPSS API: https://api.first.org/data/v1/epss
+- CISA KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
+- OWASP Dependency-Check: https://owasp.org/www-project-dependency-check/
+- Trivy: https://aquasecurity.github.io/trivy/
+- Semgrep: https://semgrep.dev/docs/

package/squads/squad-cybersecurity/knowledge-base/zero-trust-architecture.md

@@ -0,0 +1,225 @@
+# Zero Trust Architecture Reference
+
+## Purpose
+
+Reference for implementing Zero Trust Architecture (ZTA) based on NIST SP 800-207 and NIST SP 800-207A (2025). Used by Wire (network-security-engineer) and Nimbus (cloud-security-engineer) for architecture decisions and hardening recommendations.
+
+---
+
+## Foundational Document: NIST SP 800-207
+
+Published August 2020. The definitive US government standard for Zero Trust. In June 2025, NIST published SP 800-207A with 19 concrete architecture examples using commercial technologies.
+
+**Core premise:** "Never trust, always verify" — no machine, user, or service is implicitly trusted, even inside the corporate network. Contrasts with the traditional "castle and moat" model where passing the firewall grants broad internal access.
+
+---
+
+## The 7 Zero Trust Tenets (NIST SP 800-207)
+
+1. **All data sources and computing services are resources** — applies to personal devices, IoT, cloud services
+2. **All communication is secured regardless of network location** — no "trusted internal network"
+3. **Access to resources is granted per-session** — no persistent access grants
+4. **Access is determined by dynamic policy** — identity, device health, posture, behavioral context
+5. **Enterprise monitors and measures integrity of all assets** — continuous validation
+6. **Authentication and authorization are dynamic and strictly enforced before access** — re-verify as context changes
+7. **Enterprise collects information about assets and uses it to improve security posture** — telemetry-driven
+
+---
+
+## Zero Trust vs. Traditional Perimeter Security
+
+| Aspect | Traditional (Castle & Moat) | Zero Trust |
+|--------|----------------------------|------------|
+| Trust model | Trust everything inside the network | Trust nothing by default |
+| Network location | Inside = trusted | Location is irrelevant |
+| Access control | VPN grants broad access | Per-resource, per-session access |
+| Lateral movement | Easy — flat internal network | Difficult — microsegmentation |
+| Identity | Static roles, rarely reviewed | Continuous verification with context |
+| Devices | Corporate-managed = trusted | Device posture checked every session |
+| Detection | Perimeter-focused | Assume breach, detect everywhere |
+
+---
+
+## The Three Pillars of Zero Trust
+
+### Pillar 1: Identity
+
+Every entity (user, service, device) must have a verified identity. Identity is the new perimeter.
+
+**Identity controls:**
+- Multi-Factor Authentication (MFA) — mandatory for all users, especially privileged access
+- Conditional Access — access depends on user risk score, device compliance, location
+- Privileged Identity Management (PIM) — just-in-time (JIT) access elevation for admins
+- Service-to-service identity — machine identities via SPIFFE/SPIRE or cloud IAM roles
+- Identity governance — regular access reviews, separation of duties
+
+**Commercial identity providers (NIST SP 800-207A examples):**
+- Microsoft Entra ID (formerly Azure AD) — enterprise standard, integrates with most SaaS
+- Okta — multi-cloud identity platform
+- Google Cloud Identity — strong for GCP-native environments
+- HashiCorp Vault — service-to-service identity and secrets management
+
+### Pillar 2: Devices
+
+Device health and compliance as a factor in access decisions.
+
+**Device controls:**
+- Device compliance enforcement — OS version, patches, security software required
+- Endpoint Detection and Response (EDR) — CrowdStrike, SentinelOne, Microsoft Defender
+- Mobile Device Management (MDM) for BYOD — Intune, Jamf
+- Device certificates — cryptographic device identity bound to hardware
+- Continuous posture assessment — device health re-checked during session
+
+### Pillar 3: Microsegmentation
+
+Replace flat networks with fine-grained, software-defined segments where each workload can only communicate with exactly what it needs.
+
+**Network controls:**
+- Software-defined perimeter (SDP) — replace VPN with encrypted, identity-authenticated tunnels
+- Microsegmentation — Illumio, Guardicore, Zscaler, Cilium (Kubernetes)
+- Service mesh mTLS — Istio, Linkerd enforce mutual TLS between services
+- Network policy — Kubernetes NetworkPolicy, AWS Security Groups, GCP Firewall Rules
+- DNS filtering — block malicious domains at the resolver layer
+
+---
+
+## Zero Trust Implementation Roadmap (NIST 5-Phase Approach)
+
+NIST recommends gradual adoption over big-bang deployment:
+
+### Phase 1: Asset Discovery
+- Complete inventory of all assets (hardware, software, data, services)
+- Map all communication flows — who talks to whom
+- Identify crown jewel assets — data and systems requiring highest protection
+- Assess current identity and access management maturity
+
+### Phase 2: Define Trust Zones
+- Group assets by sensitivity and function
+- Define which communication flows are allowed between zones
+- Identify implicit trust relationships that need to be eliminated
+- Document current network topology against desired Zero Trust model
+
+### Phase 3: Policy Modeling
+- Define access policies for each resource (who, what, when, from where, on what device)
+- Model policies using least-privilege principle
+- Define conditional access rules (location, device health, risk score thresholds)
+- Validate policies don't break legitimate workflows
+
+### Phase 4: Pilot Small Environment
+- Select a contained environment (one application, one team)
+- Deploy identity enforcement, device compliance, and microsegmentation for pilot scope
+- Measure impact on productivity and security
+- Iterate on policy before broader rollout
+
+### Phase 5: Monitor, Adjust, and Expand
+- Deploy monitoring and telemetry across the pilot
+- Tune policies based on observed access patterns
+- Expand to next scope incrementally
+- Maintain continuous improvement cycle
+
+---
+
+## Practical Implementation: Cloud-Native Zero Trust
+
+### AWS Zero Trust Pattern
+
+```
+IAM Identity Center (SSO) → Conditional Access → Resources
+    ↑                              ↑
+Device Compliance              VPC Endpoint
+(AWS Verified Access)          (no internet exposure)
+```
+
+**Key AWS services:**
+- **AWS IAM Identity Center** — centralized SSO across all AWS accounts
+- **AWS Verified Access** — application-level zero trust without VPN
+- **VPC Endpoints** — private connectivity to AWS services without internet traversal
+- **AWS PrivateLink** — service mesh private communication
+- **Service Control Policies (SCPs)** — organization-wide guardrails
+- **IMDSv2** — prevent SSRF from accessing EC2 metadata (mandatory)
+
+### Kubernetes Zero Trust Pattern
+
+```
+SPIFFE/SPIRE (workload identity)
+    → Istio/Linkerd mTLS (service mesh)
+    → Network Policies (microsegmentation)
+    → RBAC + OPA/Gatekeeper (authorization)
+    → Falco (runtime detection)
+```
+
+**Key Kubernetes controls:**
+- **RBAC** — role-based access for every service account, no cluster-admin in production
+- **Pod Security Standards** — enforce restricted pod configurations (no privileged containers)
+- **Network Policies** — deny-all default, explicit allow rules per namespace
+- **User namespaces** — isolate container UIDs from host (beta, on by default in K8s 1.32+)
+- **mTLS via service mesh** — Istio or Linkerd for automatic mutual TLS between pods
+- **Admission control** — Kyverno or OPA/Gatekeeper for policy enforcement
+
+### Identity-First Access for SaaS Apps
+
+For organizations using Supabase, the zero trust pattern at the application layer:
+
+```sql
+-- Row Level Security = zero trust at data layer
+-- No row is accessible without explicit policy authorization
+ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;
+
+-- Policy: identity-based access, per-row
+CREATE POLICY "zero_trust_data_access"
+ON sensitive_data
+FOR ALL
+TO authenticated
+USING (
+  user_id = (SELECT auth.uid())
+  AND (SELECT auth.jwt() -> 'app_metadata' ->> 'clearance_level')::int >= required_clearance
+);
+```
+
+---
+
+## Common Zero Trust Anti-Patterns
+
+| Anti-Pattern | Why It Fails |
+|-------------|-------------|
+| VPN as Zero Trust | VPN still grants broad network access after auth — not zero trust |
+| Identity-only Zero Trust | Without device compliance and microsegmentation, identity alone is insufficient |
+| "We have MFA so we're zero trust" | MFA is table stakes, not ZTA |
+| Big bang ZTA deployment | Creates productivity disruption, typically fails — use phased approach |
+| Treating cloud as trusted | Cloud workloads need the same zero trust controls as on-prem |
+| Over-relying on network perimeter | Assumes breach never happens inside — incorrect assumption |
+
+---
+
+## Zero Trust for Brazilian/LGPD Context
+
+Zero Trust architecture directly supports LGPD compliance:
+
+| LGPD Article | Zero Trust Control |
+|-------------|-------------------|
+| Art. 46 — Technical security measures | Identity verification, encryption in transit (mTLS), access control |
+| Art. 38 — DPIA | Zero trust access logs enable privacy impact analysis |
+| Art. 48 — Breach notification | Detailed telemetry enables faster breach detection and scoping |
+| Art. 7 — Lawful basis for processing | Access logs prove data was only accessed per authorized purpose |
+| Principle of data minimization | Microsegmentation prevents services accessing data they don't need |
+
+---
+
+## Key Metrics for Zero Trust Maturity
+
+| Metric | Immature | Mature |
+|--------|---------|--------|
+| % of resources requiring MFA | < 50% | 100% |
+| % of services using mutual TLS | 0% | > 80% |
+| Mean time to detect lateral movement | Days | Minutes |
+| % of network with microsegmentation | < 20% | > 90% |
+| % of access with just-in-time privileged access | 0% | 100% of privileged |
+| % of devices with compliance enforcement | < 30% | 100% |
+
+---
+
+## Sources
+
+- NIST SP 800-207 (Zero Trust Architecture): https://csrc.nist.gov/pubs/sp/800/207/final
+- NIST SP 800-207A (19 ZTA examples): https://www.nist.gov/news-events/news/2025/06/nist-offers-19-ways-build-zero-trust-architectures
+- CISA Zero Trust Maturity Model: https://www.cisa.gov/zero-trust-maturity-model