sinapse-ai 9.3.0 → 9.4.0

package/squads/squad-cybersecurity/knowledge-base/penetration-testing-methodology.md

@@ -0,0 +1,350 @@
+# Penetration Testing Methodology Reference
+
+## Purpose
+
+Complete methodology reference for authorized penetration testing — PTES phases, OWASP Testing Guide, tool selection, and reporting standards. Used exclusively by Breach (penetration-tester). All operations require verified written authorization.
+
+**ETHICAL GATE:** Every engagement starts with written authorization, defined scope, and rules of engagement. No exceptions.
+
+---
+
+## PTES: Penetration Testing Execution Standard
+
+The PTES defines 7 phases for a complete penetration test engagement.
+
+### Phase 1: Pre-Engagement
+
+Define the scope, rules, and legal authorization before any technical work begins.
+
+**Required artifacts before proceeding:**
+- Written authorization (signed scope of work or letter of authorization)
+- Defined in-scope assets (IP ranges, domains, applications, APIs)
+- Out-of-scope assets explicitly listed
+- Rules of engagement (testing windows, contacts, escalation path)
+- Emergency stop procedure (who to call if critical infrastructure affected)
+- Data handling agreement (how findings are stored and transmitted)
+
+**Authorization verification checklist:**
+```
+[ ] Written authorization received and on file
+[ ] Scope document signed by authorized representative
+[ ] Out-of-scope assets documented
+[ ] Testing windows agreed upon
+[ ] Emergency contact available
+[ ] Findings handling agreed (encryption, retention)
+[ ] Legal jurisdiction confirmed
+```
+
+### Phase 2: Intelligence Gathering (Reconnaissance)
+
+Collect information about the target using only authorized, passive techniques unless active recon is explicitly permitted.
+
+**Passive recon (always allowed within scope):**
+```bash
+# DNS enumeration
+dig +short example.com any
+dnsx -d example.com -a -aaaa -mx -ns -cname -txt
+
+# Subdomain discovery (passive, no direct contact)
+subfinder -d example.com -silent
+
+# WHOIS and registration data
+whois example.com
+
+# Certificate transparency logs (public data)
+curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value'
+
+# Google dorking — public info indexed by search engines
+site:example.com filetype:pdf
+site:example.com inurl:admin
+```
+
+**Active recon (requires explicit authorization):**
+```bash
+# Port scanning — only against authorized IPs
+nmap -sV -sC -p 1-65535 --open -T4 target.example.com
+
+# Service version detection
+nmap -sV -p 80,443,8080,8443 target.example.com
+
+# Web technology fingerprinting
+whatweb target.example.com
+```
+
+### Phase 3: Threat Modeling
+
+Map identified attack surface to threat scenarios:
+- Document open ports and services
+- Map application technologies (CMS, frameworks, libraries)
+- Identify authentication mechanisms
+- Note third-party integrations and external dependencies
+- Cross-reference CVEs for identified versions
+
+### Phase 4: Vulnerability Analysis
+
+Systematically identify vulnerabilities using automated tools and manual techniques.
+
+**Automated scanning:**
+```bash
+# Web application scanning (DAST)
+# OWASP ZAP — automated scan
+zap-cli --zap-url http://localhost:8080 quick-scan --self-contained --spider \
+  --ajax-spider -r --output-format json http://target.example.com
+
+# Nuclei — template-based vulnerability scanner
+nuclei -u https://target.example.com -t /opt/nuclei-templates/ -severity critical,high,medium
+
+# SSL/TLS configuration
+sslyze --regular target.example.com:443
+
+# Directory and path discovery
+feroxbuster -u https://target.example.com -w /usr/share/wordlists/dirb/common.txt
+```
+
+**Manual techniques:**
+- Review all input fields for injection opportunities
+- Test authentication flows manually
+- Examine session management (cookie attributes, token entropy)
+- Check access control by testing role boundaries
+- Review security headers in all responses
+
+### Phase 5: Exploitation
+
+Attempt to confirm vulnerabilities by safely exploiting them within scope.
+
+**Exploitation principles:**
+- Confirm vulnerability, do not cause harm
+- Avoid denial of service or data destruction
+- Document every action with timestamps
+- Stop immediately if you exceed scope or find unexpected sensitive data
+- Escalate to client immediately if you find evidence of a pre-existing breach
+
+**Burp Suite Professional workflow:**
+```
+1. Configure browser proxy → Burp Proxy (127.0.0.1:8080)
+2. Spider/crawl target to map attack surface
+3. Run active scanner against scope
+4. Review scanner findings in Burp Dashboard
+5. Manual exploitation via Burp Repeater
+6. Track all requests in Burp Project
+```
+
+### Phase 6: Post-Exploitation
+
+Assess the real-world impact of confirmed vulnerabilities:
+- What data is accessible?
+- Can the compromise spread to other systems (lateral movement risk)?
+- What is the business impact of the vulnerability?
+- Can the attacker persist (would they establish persistence in a real attack)?
+
+**Document for report:**
+- Screenshot of successful exploitation
+- Data accessed (record existence, not full contents)
+- Privilege level achieved
+- Potential blast radius
+
+### Phase 7: Reporting
+
+Produce actionable, audience-appropriate findings.
+
+---
+
+## Reporting Standards
+
+### Finding Severity Classification
+
+Use CVSS v3.1 for consistent scoring:
+
+| Severity | CVSS Score | Remediation SLA | Definition |
+|----------|-----------|----------------|------------|
+| **Critical** | 9.0–10.0 | 24–48 hours | Remote code execution, unauthenticated data breach |
+| **High** | 7.0–8.9 | 7 days | Auth bypass, significant data exposure |
+| **Medium** | 4.0–6.9 | 30 days | Requires auth, limited impact |
+| **Low** | 0.1–3.9 | 90 days | Defense-in-depth issues, information disclosure |
+| **Informational** | 0.0 | Next cycle | Best practice improvements |
+
+### Finding Template
+
+Every finding should contain:
+```
+Title: [Concise description]
+Severity: [Critical/High/Medium/Low/Informational]
+CVSS Score: [X.X]
+CVE Reference: [If applicable]
+
+Description:
+[What the vulnerability is and why it matters]
+
+Affected Systems:
+[Specific URLs, endpoints, or components]
+
+Evidence:
+[Screenshots, request/response, proof of concept]
+
+Impact:
+[Business impact if exploited by a real attacker]
+
+Remediation:
+[Specific, actionable fix instructions]
+
+References:
+[OWASP, CVE, vendor docs]
+```
+
+---
+
+## Tool Reference
+
+### Core Toolchain
+
+| Tool | Category | License | Primary Use |
+|------|----------|---------|-------------|
+| **Burp Suite Pro** | DAST | Commercial | Web app testing, manual exploitation |
+| **OWASP ZAP** | DAST | Free/Open Source | CI/CD automation, budget-constrained tests |
+| **Nmap** | Network | Free/Open Source | Port scanning, service discovery |
+| **Metasploit** | Exploitation | Free/Commercial | Exploit framework, post-exploitation |
+| **Nuclei** | Scanner | Free/Open Source | Template-based vulnerability scanning |
+| **Semgrep** | SAST | Free/Commercial | Static code analysis |
+| **Snyk** | SCA | Free/Commercial | Dependency vulnerability scanning |
+| **SQLmap** | Injection | Free/Open Source | Automated SQL injection |
+| **Hydra / Medusa** | Auth | Free/Open Source | Brute force (authorized tests only) |
+| **Gobuster / Feroxbuster** | Recon | Free/Open Source | Directory and file discovery |
+| **SSLyze** | TLS | Free/Open Source | SSL/TLS configuration testing |
+
+### For Beginners — Progressive Stack
+
+**Phase 1 (Learning):**
+1. OWASP ZAP in automatic mode — spider + active scan
+2. `npm audit` for dependency vulnerabilities
+3. Semgrep for SAST basics
+
+**Phase 2 (Intermediate):**
+4. Burp Suite Community (learn the proxy)
+5. Nmap for infrastructure assessment
+6. Nuclei with community templates
+
+**Phase 3 (Professional):**
+7. Burp Suite Professional (license)
+8. Custom Nuclei templates for client-specific checks
+9. Manual exploitation techniques
+
+---
+
+## OWASP Testing Guide Categories (v4.2)
+
+The OWASP Testing Guide (OTG) provides the most comprehensive methodology for web application testing:
+
+| Category | Key Tests |
+|----------|----------|
+| **OTG-INFO** Information Gathering | Fingerprinting, search engine discovery, web server analysis |
+| **OTG-CONFIG** Configuration | Network/infrastructure config, application platform, HTTP methods |
+| **OTG-IDENT** Identity Management | User registration, account provisioning, username policy |
+| **OTG-AUTHN** Authentication | Credentials over encrypted channel, default credentials, brute force |
+| **OTG-AUTHZ** Authorization | Directory traversal, privilege escalation, IDOR, OAuth testing |
+| **OTG-SESS** Session Management | Cookie attributes, session fixation, CSRF, logout |
+| **OTG-INPVAL** Input Validation | XSS, SQL injection, HTTP injection, XML injection, code injection |
+| **OTG-ERR** Error Handling | Error codes, stack traces |
+| **OTG-CRYPST** Cryptography | Weak SSL, padding oracle, sensitive data in transit |
+| **OTG-BUSLOGIC** Business Logic | Data validation, process flow, file upload |
+| **OTG-CLIENT** Client-Side Testing | DOM-based XSS, PostMessage, clickjacking |
+
+---
+
+## API Security Testing
+
+### REST API Test Checklist
+
+```
+Authentication
+[ ] Endpoints accessible without auth tokens
+[ ] Auth tokens transmitted securely (HTTPS, not URL params)
+[ ] Token expiration enforced
+[ ] Token revocation works (logout invalidates token)
+
+Authorization
+[ ] BOLA: can user A access user B's resources by changing IDs?
+[ ] BFLA: can user access admin functions without admin role?
+[ ] Mass assignment: does API accept undocumented parameters that affect auth?
+
+Input Validation
+[ ] Injection in all string parameters (SQL, NoSQL, command)
+[ ] Path traversal in file-related endpoints
+[ ] XML/JSON deserialization risks
+
+Business Logic
+[ ] Rate limiting on resource-intensive endpoints
+[ ] Can users exceed intended limits (purchase 0-price items, negative quantities)?
+[ ] Workflow enforcement (can user skip required steps?)
+
+Infrastructure
+[ ] Security headers present
+[ ] API version disclosure (avoid version in response if possible)
+[ ] Error messages don't expose internal details
+```
+
+### GraphQL-Specific Tests
+
+```bash
+# Introspection (should be disabled in production)
+curl -X POST https://api.target.com/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{__schema{types{name}}}"}'
+
+# Batch query attack (no rate limiting on batches)
+# [{"query":"query1"},{"query":"query2"},...] x100
+
+# Field suggestion (typos reveal valid field names)
+# GraphQL returns "Did you mean X?" — information disclosure
+```
+
+---
+
+## Cloud Environment Testing
+
+### AWS Security Assessment
+
+Key areas to test with explicit authorization:
+
+```bash
+# IAM privilege analysis (with legitimate credentials)
+# Check for privilege escalation paths
+python3 enumerate_iam.py
+
+# S3 bucket exposure (requires authorization)
+aws s3 ls s3://bucket-name --no-sign-request  # Check for public access
+
+# EC2 metadata service exposure
+# Test if SSRF can reach: http://169.254.169.254/latest/meta-data/
+
+# Lambda function permissions
+aws lambda get-policy --function-name my-function
+
+# Check for IMDSv1 (should be disabled — SSRF risk)
+aws ec2 describe-instances --query "Reservations[].Instances[].MetadataOptions"
+```
+
+### Kubernetes Security Assessment
+
+```bash
+# RBAC analysis
+kubectl auth can-i --list --as=system:serviceaccount:default:myapp
+
+# Check for privileged pods
+kubectl get pods -A -o json | jq '.items[].spec.containers[].securityContext'
+
+# Network policy coverage
+kubectl get networkpolicies -A
+
+# Check for secrets in env vars (common misconfiguration)
+kubectl get pods -A -o json | jq '.items[].spec.containers[].env'
+```
+
+---
+
+## Sources
+
+- PTES: http://www.pentest-standard.org/
+- OWASP Testing Guide v4.2: https://owasp.org/www-project-web-security-testing-guide/
+- OWASP API Security Testing Guide: https://owasp.org/www-project-api-security/
+- OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org/
+- HackTricks: https://book.hacktricks.xyz/ (for methodology reference — authorized tests only)

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/