sinapse-ai 1.0.0

package/squad-cybersecurity/tasks/alert-triage-workflow.md

@@ -0,0 +1,208 @@
+---
+task: alert-triage-workflow
+responsavel: "soc-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: alert_sources
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+  - campo: soc_maturity
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["initial", "developing", "established", "mature"]
+
+Saida:
+  - campo: triage_workflow_document
+    tipo: document
+    destino: "soc-analyst team, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Map all alert sources and categories"
+  - "[ ] Define severity classification criteria"
+  - "[ ] Design triage decision tree"
+  - "[ ] Create SLA targets per severity"
+  - "[ ] Define escalation procedures"
+  - "[ ] Build automation opportunities"
+  - "[ ] Document analyst procedures"
+  - "[ ] Design quality metrics"
+---
+
+# Task: Alert Triage Workflow Design
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Sentinel (soc-analyst)
+- **Complexity:** Standard
+
+## Objective
+
+Design a structured alert triage workflow that enables SOC analysts to efficiently classify, prioritize, investigate, and resolve security alerts. The workflow includes decision trees, severity classification, SLA targets, escalation procedures, and quality metrics.
+
+> **OPERATIONAL SECURITY:** Alert triage workflows handle sensitive security data. Access to triage procedures and alert details should be restricted to authorized SOC personnel.
+
+## Pre-Conditions
+
+- Alert sources identified and configured
+- SOC team structure defined
+- Incident response plan available for escalation
+- SIEM and SOAR platforms operational
+- Understanding of current alert volume and types
+
+## Inputs
+
+- Alert sources (SIEM, EDR, firewall, cloud, email, custom)
+- SOC maturity level (initial, developing, established, mature)
+- Current alert volume and false positive rates
+- SOC team size and shift coverage
+- Existing triage procedures (if any)
+
+## Steps
+
+### 1. Inventory Alert Sources
+Catalog all alert-generating systems:
+| Source | Alert Types | Daily Volume | Current FP Rate | Priority |
+|--------|-----------|-------------|-----------------|----------|
+| SIEM | Correlation rules | | | |
+| EDR | Endpoint alerts | | | |
+| Firewall | Block/allow anomalies | | | |
+| Cloud | AWS/Azure/GCP alerts | | | |
+| Email | Phishing detections | | | |
+
+### 2. Define Alert Severity Classification
+Establish consistent severity criteria across all sources:
+
+| Severity | Criteria | Examples | SLA |
+|----------|---------|---------|-----|
+| P1 — Critical | Active compromise, data exfiltration | Confirmed C2, ransomware execution | 15 min |
+| P2 — High | Strong indicators of compromise | Suspicious lateral movement, credential dump | 1 hour |
+| P3 — Medium | Anomalous behavior needs investigation | Unusual login patterns, policy violations | 4 hours |
+| P4 — Low | Informational, low-risk anomaly | Failed login below threshold, scan activity | 24 hours |
+
+### 3. Design Triage Decision Tree
+Create a decision tree for each major alert category:
+```
+Alert Received
+├── Is it a known false positive? → Close with FP tag
+├── Is the affected asset critical? → Elevate severity
+├── Is there active threat intelligence match? → Elevate to P1/P2
+├── Can automated enrichment resolve? → Auto-enrich and re-evaluate
+├── Needs manual investigation? → Assign to analyst
+└── Is this part of an existing incident? → Merge with incident
+```
+
+### 4. Define Enrichment Steps
+Specify automatic and manual enrichment for each alert type:
+
+**Automated Enrichment (SOAR):**
+- IP reputation lookup
+- Domain/URL reputation
+- Hash lookup (VirusTotal, malware databases)
+- User context (role, department, recent activity)
+- Asset context (criticality, OS, patch status)
+- Threat intelligence correlation
+
+**Manual Enrichment (Analyst):**
+- User/manager verification
+- Business context assessment
+- Historical alert correlation
+- Network traffic analysis
+
+### 5. Create Investigation Templates
+For each major alert category, provide structured investigation steps:
+```yaml
+investigation_template:
+  alert_type: ""
+  initial_questions:
+    - ""
+  enrichment_queries: []
+  decision_criteria:
+    true_positive: ""
+    false_positive: ""
+    needs_escalation: ""
+  actions:
+    true_positive: ""
+    false_positive: ""
+```
+
+### 6. Define Escalation Procedures
+| Trigger | Escalation Target | Method | SLA |
+|---------|-------------------|--------|-----|
+| P1 alert confirmed | IR team lead | Phone + ticket | Immediate |
+| P2 needs IR | Senior analyst | Ticket + chat | 30 min |
+| Analyst stuck > 30 min | Shift lead | Chat | Immediate |
+| VIP account involved | CISO/management | Phone | 15 min |
+| Data breach suspected | Legal + IR | Phone + email | Immediate |
+
+### 7. Design Automation Opportunities
+Identify alerts suitable for automated handling:
+| Alert Pattern | Automation | Expected Reduction |
+|--------------|-----------|-------------------|
+| Known FP patterns | Auto-close with tag | 20-30% volume |
+| Low-severity IOC match | Auto-enrich + prioritize | Faster triage |
+| Common investigation queries | Auto-run on alert creation | Analyst time savings |
+| Repeated alerts from same source | Auto-aggregate | Reduce noise |
+
+### 8. Establish Quality Metrics
+Define metrics to measure triage effectiveness:
+| Metric | Target | Measurement |
+|--------|--------|-------------|
+| Mean Time to Triage (MTTT) | < 15 min (P1) | Alert creation to first analyst action |
+| False Positive Rate | < 30% | FP closures / total alerts |
+| Escalation Accuracy | > 90% | Valid escalations / total escalations |
+| SLA Compliance | > 95% | Alerts triaged within SLA |
+| Analyst Utilization | 60-80% | Active investigation time / shift time |
+
+### 9. Create Shift Handover Procedure
+Design handover process for shift changes:
+- Open alert summary
+- Active investigations status
+- Pending escalations
+- Key events since last handover
+- Priority focus areas for incoming shift
+
+### 10. Document and Train
+Produce comprehensive documentation and training plan:
+- Triage workflow document with decision trees
+- Investigation template library
+- Quick-reference guides per alert source
+- New analyst onboarding checklist
+- Monthly refresher topics
+
+## Output
+
+```yaml
+alert_triage_workflow:
+  date: ""
+  soc_maturity: ""
+  author: "Sentinel (soc-analyst)"
+
+  alert_sources: []
+  severity_classification: {}
+  decision_trees: []
+  investigation_templates: []
+  escalation_procedures: []
+  automation_opportunities: []
+
+  metrics:
+    mttt_target: ""
+    fp_rate_target: ""
+    sla_targets: {}
+
+  training_plan: []
+```
+
+## Quality Criteria
+
+- [ ] All alert sources cataloged with volume and FP rates
+- [ ] Severity classification consistent across all sources
+- [ ] Decision trees cover all major alert categories
+- [ ] SLA targets defined and achievable for SOC size
+- [ ] Escalation procedures include all severity levels
+- [ ] Automation opportunities identified with expected impact
+- [ ] Quality metrics defined with measurement methodology
+- [ ] Shift handover procedure documented

package/squad-cybersecurity/tasks/api-security-audit.md

@@ -0,0 +1,69 @@
+---
+task: "api-security-audit"
+responsavel: "penetration-tester"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: true
+Entrada:
+  - campo: api_specification
+    tipo: document
+    origem: "user input"
+    obrigatorio: true
+  - campo: authorization
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+Saida:
+  - campo: api_audit_report
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Verify authorization"
+  - "[ ] Review API specification and documentation"
+  - "[ ] Test all OWASP API Top 10 categories"
+  - "[ ] Test authentication mechanisms"
+  - "[ ] Test rate limiting and resource consumption"
+  - "[ ] Test input validation across all endpoints"
+  - "[ ] Assess data exposure in responses"
+  - "[ ] Produce findings report"
+---
+
+# API Security Audit
+
+## Objective
+
+Conduct a comprehensive security audit of an API against the OWASP API Security Top 10 2023. Assess authentication, authorization, input validation, rate limiting, and data exposure. Requires explicit authorization.
+
+## Inputs
+
+- API specification (OpenAPI/Swagger, GraphQL schema, or documentation)
+- Base URL and authentication credentials
+- Written authorization
+- Expected API consumers and use cases
+
+## Steps
+
+1. **Verify authorization** — Confirm testing scope includes all API endpoints. Document authorization.
+
+2. **API mapping** — Enumerate all endpoints, methods, parameters, and response schemas. Identify undocumented endpoints.
+
+3. **Authentication analysis** — Test token mechanisms (JWT, OAuth, API keys), token expiration, refresh flows, and credential handling.
+
+4. **BOLA testing (API1)** — Test every object reference for unauthorized access. Vary user context to test horizontal and vertical access.
+
+5. **Authorization testing (API3, API5)** — Test function-level and property-level authorization. Check mass assignment, response filtering.
+
+6. **Rate limiting (API4)** — Test resource consumption limits, pagination abuse, query complexity (GraphQL), and batch operation abuse.
+
+7. **Input validation** — Test all parameters for injection, type confusion, boundary violations, and unexpected input handling.
+
+8. **Data exposure** — Review all response payloads for excessive data exposure, sensitive field leakage, and verbose error messages.
+
+9. **Inventory and documentation (API9)** — Verify API versioning, deprecated endpoint handling, and documentation accuracy.
+
+## Quality Gates
+
+- All OWASP API Top 10 categories assessed
+- BOLA tested on every object-referencing endpoint
+- Rate limiting verified with measured thresholds
+- Every finding includes specific HTTP request/response evidence

package/squad-cybersecurity/tasks/api-security-testing.md

@@ -0,0 +1,198 @@
+---
+task: api-security-testing
+responsavel: "penetration-tester"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: api_documentation
+    tipo: document
+    origem: "user input"
+    obrigatorio: true
+  - campo: authorization
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: api_type
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["REST", "GraphQL", "gRPC", "SOAP", "WebSocket"]
+
+Saida:
+  - campo: api_security_report
+    tipo: document
+    destino: "stakeholders, dev team"
+
+Checklist:
+  - "[ ] Verify authorization and scope"
+  - "[ ] Map all API endpoints and methods"
+  - "[ ] Test OWASP API Security Top 10"
+  - "[ ] Validate authentication mechanisms"
+  - "[ ] Test rate limiting and abuse prevention"
+  - "[ ] Check data exposure and filtering"
+  - "[ ] Score findings with CVSS"
+  - "[ ] Provide API-specific remediation"
+---
+
+# Task: API Security Testing
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Breach (penetration-tester)
+- **Complexity:** Complex
+
+## Objective
+
+Execute a comprehensive API security assessment following the OWASP API Security Top 10 (2023) methodology. Test authentication, authorization, data exposure, rate limiting, and business logic across REST, GraphQL, gRPC, or SOAP APIs.
+
+> **AUTHORIZED TESTING ONLY:** API security testing must be performed only against APIs you are authorized to test. Written authorization is required. Respect rate limits and avoid denial-of-service conditions.
+
+## Pre-Conditions
+
+- Written authorization from API owner
+- API documentation (OpenAPI/Swagger, GraphQL schema, or equivalent)
+- Valid API credentials for testing
+- Test environment preferred (production testing needs explicit approval)
+
+## Inputs
+
+- API documentation (OpenAPI spec, Postman collection, GraphQL schema)
+- Written authorization
+- API type (REST, GraphQL, gRPC, SOAP, WebSocket)
+- Authentication credentials (API keys, OAuth tokens, JWT)
+- Rate limit information (to avoid accidental DoS)
+
+## Steps
+
+### 1. API Discovery and Mapping
+Enumerate the complete API surface:
+- Parse OpenAPI/Swagger documentation
+- Discover undocumented endpoints (fuzzing with authorization)
+- Map all HTTP methods per endpoint
+- Identify parameters, headers, and request bodies
+- Document authentication requirements per endpoint
+
+### 2. API1:2023 — Broken Object Level Authorization (BOLA)
+Test for:
+- Access to other users' resources by ID manipulation
+- Predictable resource identifiers
+- Missing authorization checks on object access
+- Horizontal privilege escalation via API
+
+### 3. API2:2023 — Broken Authentication
+Assess:
+- Authentication mechanism strength
+- Token generation and validation
+- Session management
+- Credential exposure in URLs or logs
+- Brute force and credential stuffing protection
+- OAuth/OIDC implementation flaws
+
+### 4. API3:2023 — Broken Object Property Level Authorization
+Test for:
+- Mass assignment vulnerabilities
+- Excessive data exposure in responses
+- Ability to modify restricted properties
+- Hidden fields accessible via API
+
+### 5. API4:2023 — Unrestricted Resource Consumption
+Verify:
+- Rate limiting implementation and bypass
+- Request size limits
+- Pagination limits
+- Batch operation limits
+- File upload size restrictions
+- GraphQL query depth and complexity limits
+
+### 6. API5:2023 — Broken Function Level Authorization
+Test:
+- Administrative endpoints accessible to regular users
+- Vertical privilege escalation
+- HTTP method tampering (GET vs POST vs PUT)
+- Missing role-based access control
+
+### 7. API6-API10:2023 — Advanced API Risks
+- **API6: Unrestricted Access to Sensitive Business Flows** — Test for automation abuse, scraping, bot protection
+- **API7: Server-Side Request Forgery** — Test internal resource access via API parameters
+- **API8: Security Misconfiguration** — CORS, error handling, debug modes, unnecessary HTTP methods
+- **API9: Improper Inventory Management** — Old API versions, deprecated endpoints, shadow APIs
+- **API10: Unsafe Consumption of APIs** — Third-party API trust, input validation on API responses
+
+### 8. GraphQL-Specific Testing (if applicable)
+- Introspection query exposure
+- Query depth and complexity attacks
+- Batching attacks
+- Field suggestion enumeration
+- Alias-based rate limit bypass
+
+### 9. Input Validation Testing
+For each endpoint parameter:
+- SQL injection
+- NoSQL injection
+- Command injection
+- Path traversal
+- XXE (XML External Entity)
+- Deserialization attacks
+- Type confusion
+
+### 10. Compile API Security Report
+Document each finding with:
+- OWASP API Security category
+- CVSS v3.1 score
+- Affected endpoint(s) and method(s)
+- Request/response evidence
+- Business impact assessment
+- Specific remediation for the API framework in use
+
+## Output
+
+```yaml
+api_security_report:
+  api_name: ""
+  api_type: ""
+  date: ""
+  authorization: "confirmed"
+
+  endpoints_tested: 0
+  endpoints_total: 0
+
+  findings_summary:
+    critical: 0
+    high: 0
+    medium: 0
+    low: 0
+
+  owasp_api_coverage:
+    API1_BOLA: "[pass/fail/partial]"
+    API2_broken_auth: "[pass/fail/partial]"
+    API3_property_auth: "[pass/fail/partial]"
+    API4_resource_consumption: "[pass/fail/partial]"
+    API5_function_auth: "[pass/fail/partial]"
+    API6_business_flows: "[pass/fail/partial]"
+    API7_SSRF: "[pass/fail/partial]"
+    API8_misconfiguration: "[pass/fail/partial]"
+    API9_inventory: "[pass/fail/partial]"
+    API10_unsafe_consumption: "[pass/fail/partial]"
+
+  findings:
+    - title: ""
+      api_category: ""
+      endpoint: ""
+      method: ""
+      cvss: 0.0
+      evidence: ""
+      remediation: ""
+```
+
+## Quality Criteria
+
+- [ ] Written authorization confirmed before testing
+- [ ] All OWASP API Security Top 10 categories tested
+- [ ] Every endpoint tested for BOLA
+- [ ] Authentication and session management fully assessed
+- [ ] Rate limiting tested without causing service disruption
+- [ ] All findings include request/response evidence
+- [ ] Remediation guidance specific to the API framework
+- [ ] No testing outside authorized scope

package/squad-cybersecurity/tasks/attack-surface-mapping.md

@@ -0,0 +1,180 @@
+---
+task: attack-surface-mapping
+responsavel: "threat-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: organization_name
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: known_assets
+    tipo: list
+    origem: "user input"
+    obrigatorio: false
+  - campo: scope
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["external", "internal", "full"]
+
+Saida:
+  - campo: attack_surface_map
+    tipo: document
+    destino: "stakeholders, penetration-tester, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Enumerate all external-facing assets"
+  - "[ ] Discover shadow IT and unknown assets"
+  - "[ ] Map exposed services and ports"
+  - "[ ] Identify third-party integrations"
+  - "[ ] Classify assets by risk exposure"
+  - "[ ] Document findings with remediation priorities"
+---
+
+# Task: Attack Surface Mapping
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Shield (threat-analyst)
+- **Complexity:** Complex
+
+## Objective
+
+Map and document the complete attack surface of an organization, including external-facing assets, exposed services, shadow IT, third-party integrations, and internal high-value targets. The output enables prioritized hardening and informs penetration testing scope.
+
+> **AUTHORIZED USE ONLY:** Attack surface mapping must be performed only on assets owned or explicitly authorized by the organization. Never enumerate or probe third-party assets without written authorization.
+
+## Pre-Conditions
+
+- Written authorization to perform asset discovery
+- Organization name and known domain names
+- Network ranges (if internal scope included)
+- Access to DNS records and cloud account inventories
+
+## Inputs
+
+- Organization name and primary domains
+- Known assets and IP ranges
+- Scope: external-only, internal-only, or full
+- Cloud provider account details (for cloud asset discovery)
+- Previous asset inventories (if available)
+
+## Steps
+
+### 1. Passive Reconnaissance
+Gather information without directly probing targets:
+- DNS records (A, AAAA, MX, TXT, CNAME, NS)
+- Certificate transparency logs (crt.sh, Censys)
+- WHOIS and registrar data
+- Public code repositories (accidental exposure)
+- Job postings (technology stack hints)
+- Social media and public documents
+
+### 2. Subdomain Enumeration
+Discover subdomains through multiple methods:
+- DNS brute-forcing with targeted wordlists
+- Certificate transparency log analysis
+- Search engine dorking
+- Historical DNS data
+
+### 3. Service and Port Discovery
+For each discovered asset, identify exposed services:
+| Asset | IP | Open Ports | Services | Version | Risk Level |
+|-------|-----|-----------|----------|---------|-----------|
+
+### 4. Cloud Asset Discovery
+Enumerate cloud-hosted assets across providers:
+- AWS: S3 buckets, EC2 instances, Lambda functions, API Gateways
+- Azure: Blob storage, App Services, Functions
+- GCP: Cloud Storage, Compute Engine, Cloud Functions
+- SaaS integrations (OAuth apps, API keys)
+
+### 5. Shadow IT Identification
+Discover unauthorized or unmanaged assets:
+- Unregistered domains and subdomains
+- Personal cloud accounts used for work
+- Unauthorized SaaS applications
+- Development/staging environments exposed to internet
+
+### 6. Third-Party Integration Mapping
+Document all third-party connections:
+- API integrations and data flows
+- OAuth authorizations
+- Embedded widgets and scripts
+- Supply chain software dependencies
+
+### 7. Technology Stack Fingerprinting
+Identify technology stacks per asset:
+- Web frameworks and CMS
+- Server software and versions
+- Client-side libraries
+- API technologies
+
+### 8. Risk Classification
+Classify each asset by exposure risk:
+| Risk Level | Criteria | Example |
+|-----------|---------|---------|
+| Critical | Internet-facing, sensitive data, unpatched | Production database with public IP |
+| High | Internet-facing, business-critical | Customer-facing web application |
+| Medium | Internal, moderate sensitivity | Internal admin panels |
+| Low | Internal, non-sensitive | Development documentation |
+
+### 9. Gap Analysis
+Compare discovered assets against known asset inventory. Identify:
+- Assets not in inventory (shadow IT)
+- Decommissioned assets still running
+- Assets missing security controls
+- Misconfigured cloud resources
+
+### 10. Generate Attack Surface Report
+Compile findings into a structured report with visualizations, risk ratings, and remediation priorities.
+
+## Output
+
+```yaml
+attack_surface_map:
+  organization: ""
+  scope: "[external/internal/full]"
+  date: ""
+
+  asset_summary:
+    total_discovered: 0
+    external_facing: 0
+    shadow_it: 0
+    critical_risk: 0
+
+  assets:
+    - hostname: ""
+      ip: ""
+      type: "[web/api/database/storage/other]"
+      services: []
+      technology_stack: []
+      risk_level: "[critical/high/medium/low]"
+      in_inventory: true
+      notes: ""
+
+  third_party_integrations:
+    - name: ""
+      type: "[api/oauth/widget/dependency]"
+      data_shared: ""
+      risk: ""
+
+  recommendations:
+    - action: ""
+      priority: "[immediate/short-term/long-term]"
+      assets_affected: []
+```
+
+## Quality Criteria
+
+- [ ] All known domains and IP ranges enumerated
+- [ ] Shadow IT assets identified and flagged
+- [ ] Every discovered asset has a risk classification
+- [ ] Third-party integrations documented with data flow
+- [ ] Gap analysis completed against known inventory
+- [ ] Recommendations are prioritized and actionable
+- [ ] Report suitable for both technical and management audiences
+- [ ] No unauthorized probing of third-party assets