sinapse-ai 1.0.0

package/squad-cybersecurity/tasks/supply-chain-risk-assessment.md

@@ -0,0 +1,189 @@
+---
+task: supply-chain-risk-assessment
+responsavel: "threat-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: vendor_list
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+  - campo: assessment_depth
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["quick-scan", "standard", "deep-dive"]
+
+Saida:
+  - campo: supply_chain_risk_report
+    tipo: document
+    destino: "stakeholders, compliance-officer, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Inventory all third-party vendors and dependencies"
+  - "[ ] Classify vendors by data access and criticality"
+  - "[ ] Assess vendor security posture"
+  - "[ ] Evaluate software dependency risks"
+  - "[ ] Identify single points of failure"
+  - "[ ] Produce risk-ranked vendor report"
+---
+
+# Task: Supply Chain Risk Assessment
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Shield (threat-analyst)
+- **Complexity:** Complex
+
+## Objective
+
+Assess security risks across the organization's supply chain — including software vendors, SaaS providers, open-source dependencies, and service partners. Identify concentration risks, evaluate vendor security postures, and produce a prioritized risk report with mitigation strategies.
+
+> **ETHICAL ASSESSMENT:** This assessment relies on publicly available information, vendor-provided documentation, and authorized questionnaires. No unauthorized testing of vendor systems is performed.
+
+## Pre-Conditions
+
+- Vendor inventory or procurement records available
+- Software Bill of Materials (SBOM) for key applications
+- Authorization to conduct vendor assessments
+- Risk appetite defined for third-party risk
+
+## Inputs
+
+- List of vendors, SaaS providers, and service partners
+- Software dependency manifests (package.json, requirements.txt, etc.)
+- Existing vendor contracts and SLAs
+- Previous vendor assessments (if available)
+- Assessment depth (quick-scan, standard, deep-dive)
+
+## Steps
+
+### 1. Inventory Supply Chain Components
+Catalog all third-party relationships:
+| Category | Examples | Risk Factor |
+|----------|---------|------------|
+| SaaS providers | CRM, email, collaboration | Data access |
+| Infrastructure | Cloud, CDN, DNS | Availability |
+| Software libraries | npm, PyPI, Maven packages | Code execution |
+| Service partners | MSP, consultants, contractors | Access privileges |
+| Hardware vendors | Servers, network equipment | Firmware integrity |
+
+### 2. Classify Vendors by Risk Tier
+| Tier | Data Access | Business Impact | Assessment Depth |
+|------|-----------|----------------|-----------------|
+| Critical | PII, financial, secrets | Service-stopping | Deep-dive |
+| High | Business data, config | Degraded service | Standard |
+| Medium | Non-sensitive data | Minor impact | Quick-scan |
+| Low | No data access | Negligible impact | Periodic review |
+
+### 3. Assess Vendor Security Posture
+For each vendor (depth based on tier):
+- Security certifications (SOC 2, ISO 27001, PCI DSS)
+- Incident history and disclosure practices
+- Security questionnaire responses (SIG, CAIQ)
+- Public breach history and vulnerability record
+- Security team maturity indicators
+
+### 4. Analyze Software Dependencies
+Review open-source and third-party library risks:
+- Generate or review SBOM for critical applications
+- Check for known vulnerabilities (CVE databases)
+- Assess maintenance status (last update, contributor count)
+- Identify transitive dependency risks
+- Check for license compliance issues
+
+### 5. Identify Concentration Risks
+Map dependencies to identify single points of failure:
+- Multiple services depending on one vendor
+- Single-source dependencies with no alternatives
+- Geographic concentration of vendors
+- Shared infrastructure across vendors
+
+### 6. Evaluate Data Flow Risks
+For each vendor handling organization data:
+- What data is shared and in what form
+- Data residency and sovereignty implications
+- Encryption in transit and at rest
+- Data retention and deletion practices
+- Subprocessor chains
+
+### 7. Assess Contractual Protections
+Review contracts for security provisions:
+- Right-to-audit clauses
+- Breach notification timelines
+- Data processing agreements
+- Liability and indemnification
+- Exit and data portability provisions
+
+### 8. Score and Rank Risks
+Apply a consistent scoring model:
+| Factor | Weight | Score (1-5) |
+|--------|--------|------------|
+| Data sensitivity | 25% | |
+| Business criticality | 25% | |
+| Security posture | 20% | |
+| Concentration risk | 15% | |
+| Contractual protection | 15% | |
+
+### 9. Develop Mitigation Strategies
+For high-risk vendors:
+- Require security improvements with timelines
+- Implement compensating controls
+- Develop contingency/exit plans
+- Increase monitoring and review frequency
+- Consider alternative vendors
+
+### 10. Compile Supply Chain Risk Report
+Produce a comprehensive report with executive summary, vendor scorecards, risk rankings, and mitigation roadmap.
+
+## Output
+
+```yaml
+supply_chain_assessment:
+  date: ""
+  total_vendors_assessed: 0
+
+  vendor_risk_summary:
+    critical_risk: 0
+    high_risk: 0
+    medium_risk: 0
+    low_risk: 0
+
+  vendors:
+    - name: ""
+      tier: "[critical/high/medium/low]"
+      risk_score: 0
+      certifications: []
+      data_access: ""
+      key_findings: []
+      mitigation: ""
+
+  software_dependencies:
+    total_packages: 0
+    vulnerable: 0
+    unmaintained: 0
+    critical_cves: []
+
+  concentration_risks:
+    - description: ""
+      affected_services: []
+      mitigation: ""
+
+  recommendations:
+    - action: ""
+      vendor: ""
+      priority: "[immediate/short-term/long-term]"
+```
+
+## Quality Criteria
+
+- [ ] All critical and high-tier vendors assessed
+- [ ] Software dependencies analyzed for vulnerabilities
+- [ ] Concentration risks identified with impact analysis
+- [ ] Vendor risk scores calculated consistently
+- [ ] Data flow risks documented for data-handling vendors
+- [ ] Mitigation strategies provided for high-risk findings
+- [ ] Report includes both technical and business perspectives
+- [ ] No unauthorized testing of vendor infrastructure

package/squad-cybersecurity/tasks/tabletop-exercise-design.md

@@ -0,0 +1,218 @@
+---
+task: tabletop-exercise-design
+responsavel: "incident-responder"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: scenario_type
+    tipo: enum
+    origem: "user input"
+    obrigatorio: true
+    valores: ["ransomware", "data-breach", "insider-threat", "supply-chain", "ddos", "custom"]
+  - campo: participants
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+  - campo: duration
+    tipo: text
+    origem: "user input"
+    obrigatorio: false
+
+Saida:
+  - campo: exercise_package
+    tipo: document
+    destino: "IR team, stakeholders"
+
+Checklist:
+  - "[ ] Define exercise objectives and scope"
+  - "[ ] Design realistic scenario with injects"
+  - "[ ] Create facilitator guide"
+  - "[ ] Prepare participant materials"
+  - "[ ] Plan observation and evaluation criteria"
+  - "[ ] Design debrief structure"
+  - "[ ] Create after-action report template"
+  - "[ ] Schedule and communicate exercise"
+---
+
+# Task: Tabletop Exercise Design
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Rapid (incident-responder)
+- **Complexity:** Standard
+
+## Objective
+
+Design and produce a complete tabletop exercise package that tests the organization's incident response capabilities through a realistic, discussion-based scenario. The exercise validates decision-making, communication, and coordination without impacting production systems.
+
+## Pre-Conditions
+
+- Incident response plan exists (or is being developed)
+- Participants identified and availability confirmed
+- Executive support for exercise
+- Facilitator identified
+- Previous exercise results available (if any)
+
+## Inputs
+
+- Scenario type (ransomware, data breach, insider threat, supply chain, DDoS, custom)
+- Participant list and roles
+- Duration (typically 2-4 hours)
+- Specific areas to test (communication, technical response, decision-making)
+- Compliance drivers (if exercise is required by regulation)
+
+## Steps
+
+### 1. Define Exercise Objectives
+Establish measurable objectives:
+| Objective | What It Tests | Success Criteria |
+|-----------|-------------|-----------------|
+| Decision-making speed | Can leaders make timely decisions? | Key decisions within expected timeframes |
+| Communication flow | Do the right people get notified? | All required notifications identified |
+| Role clarity | Does everyone know their role? | No gaps or overlaps in responsibilities |
+| Plan effectiveness | Does the IR plan work? | Plan covers the scenario adequately |
+| Escalation procedures | Are escalation paths clear? | Correct escalation at each decision point |
+
+### 2. Design the Scenario
+Create a realistic, multi-phase scenario:
+
+**Scenario Framework:**
+```yaml
+scenario:
+  title: ""
+  type: ""
+  threat_actor: ""
+  attack_vector: ""
+  target: ""
+  business_context: ""
+  timeline:
+    phase_1: "Initial detection"
+    phase_2: "Escalation and assessment"
+    phase_3: "Containment decisions"
+    phase_4: "Communication challenges"
+    phase_5: "Recovery and aftermath"
+```
+
+### 3. Create Scenario Injects
+Design timed information releases that drive the exercise:
+
+| Time | Inject | Information Revealed | Expected Response |
+|------|--------|---------------------|-------------------|
+| T+0 | Alert notification | Initial detection details | Triage and assessment |
+| T+15 | Scope expands | Additional affected systems found | Containment decision |
+| T+30 | Business impact | Customer data potentially affected | Executive notification |
+| T+45 | Media inquiry | Reporter calls about the incident | Communications response |
+| T+60 | Regulatory question | Regulator asks for status update | Legal/compliance response |
+| T+75 | Recovery option | Clean backup available but 24h old | Recovery decision |
+
+### 4. Prepare Facilitator Guide
+Create detailed guidance for the exercise facilitator:
+- Opening remarks and ground rules
+- Inject delivery timing and method
+- Discussion questions per inject
+- Expected responses (to guide discussion if stuck)
+- Time management guidelines
+- How to handle derailed discussions
+- Key teaching points to emphasize
+
+### 5. Create Participant Materials
+Prepare materials for each participant:
+- Exercise overview and objectives
+- Role card (their specific role during the exercise)
+- Reference materials (IR plan excerpts, contact lists)
+- Note-taking template
+- Rules of engagement (no real-world actions, safe space)
+
+### 6. Design Discussion Questions
+For each inject, prepare probing questions:
+- What is your first action upon receiving this information?
+- Who needs to be notified and in what order?
+- What information do you need to make a decision?
+- What are the risks of each option?
+- How does this change your communication plan?
+- What resources do you need?
+
+### 7. Plan Observation and Evaluation
+Define what observers will track:
+| Evaluation Area | Criteria | Rating Scale |
+|----------------|---------|-------------|
+| Timeliness | Decisions made within expected timeframes | 1-5 |
+| Communication | Right people notified, clear messages | 1-5 |
+| Coordination | Teams working together effectively | 1-5 |
+| Plan adherence | IR plan followed appropriately | 1-5 |
+| Decision quality | Decisions logical and well-reasoned | 1-5 |
+
+### 8. Design Debrief Structure
+Plan the post-exercise debrief (typically 30-60 minutes):
+- Hot wash: Immediate reactions (what went well, what was challenging)
+- Gap identification: Where did the plan fall short?
+- Surprise findings: What was unexpected?
+- Action items: What needs to change?
+- Positive reinforcement: Recognize good decisions and teamwork
+
+### 9. Create After-Action Report Template
+```yaml
+after_action_report:
+  exercise_date: ""
+  scenario: ""
+  participants: []
+
+  objectives_assessment:
+    - objective: ""
+      met: "[yes/partially/no]"
+      evidence: ""
+
+  strengths: []
+  gaps: []
+  action_items:
+    - item: ""
+      owner: ""
+      due_date: ""
+      priority: ""
+
+  ir_plan_updates_needed: []
+  next_exercise_recommendation: ""
+```
+
+### 10. Finalize and Package
+Assemble the complete exercise package:
+- Facilitator guide
+- Participant handouts
+- Inject cards (sealed or timed)
+- Observation worksheets
+- Debrief agenda
+- After-action report template
+- Calendar invitation with logistics
+
+## Output
+
+```yaml
+tabletop_exercise:
+  title: ""
+  scenario_type: ""
+  duration: ""
+  date: ""
+  author: "Rapid (incident-responder)"
+
+  objectives: []
+  scenario_summary: ""
+  injects: []
+  facilitator_guide: ""
+  participant_materials: ""
+  evaluation_criteria: []
+  debrief_structure: ""
+  aar_template: ""
+```
+
+## Quality Criteria
+
+- [ ] Exercise objectives are measurable
+- [ ] Scenario is realistic for the organization's industry
+- [ ] Injects progressively increase complexity
+- [ ] Facilitator guide comprehensive enough for any facilitator
+- [ ] Participant materials include role-specific information
+- [ ] Evaluation criteria aligned with objectives
+- [ ] Debrief structure encourages constructive discussion
+- [ ] After-action report template captures actionable findings

package/squad-cybersecurity/tasks/threat-hunting-campaign.md

@@ -0,0 +1,64 @@
+---
+task: "threat-hunting-campaign"
+responsavel: "soc-analyst"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: true
+Entrada:
+  - campo: hypothesis
+    tipo: text
+    origem: "user input or threat intelligence"
+    obrigatorio: true
+  - campo: data_sources
+    tipo: list
+    origem: "environment"
+    obrigatorio: true
+Saida:
+  - campo: hunt_report
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Define testable hypothesis"
+  - "[ ] Identify required data sources"
+  - "[ ] Develop hunt queries"
+  - "[ ] Execute queries and analyze results"
+  - "[ ] Document findings or validated negatives"
+  - "[ ] Convert findings into detection rules"
+---
+
+# Threat Hunting Campaign
+
+## Objective
+
+Execute a hypothesis-driven threat hunting campaign to proactively search for threats that evade existing detections. Produce either confirmed findings or validated negatives, and convert results into detection rules.
+
+## Inputs
+
+- Hunting hypothesis (what adversary behavior we are looking for)
+- Available data sources (logs, telemetry)
+- Relevant threat intelligence (IOCs, TTPs)
+- Timeframe for the hunt
+
+## Steps
+
+1. **Formulate hypothesis** — Based on threat intelligence, recent incidents, or detection gap analysis. The hypothesis must be specific and testable: "Adversaries may be using [technique] to [objective] in our [environment]."
+
+2. **Identify data sources** — Map required data sources to the hypothesis. Assess data quality and coverage. Document gaps.
+
+3. **Develop queries** — Write search queries for each data source. Include both exact IOC matches and behavioral patterns.
+
+4. **Execute and analyze** — Run queries across the specified timeframe. Analyze results for anomalies. Filter noise from signal.
+
+5. **Investigate leads** — For each potential finding, perform deep analysis. Build timeline. Determine if activity is malicious, suspicious, or benign.
+
+6. **Document results** — Whether the hunt found threats or validated their absence, document: hypothesis, methodology, queries used, results, and conclusions.
+
+7. **Create detections** — Convert confirmed findings into Sigma detection rules. For validated negatives, document as evidence of control effectiveness.
+
+## Quality Gates
+
+- Hypothesis must be specific and linked to a MITRE ATT&CK technique
+- At least 2 data sources must be queried
+- All queries must be documented for reproducibility
+- Findings must include evidence and timeline
+- Validated negatives are valid outcomes (not failures)

package/squad-cybersecurity/tasks/threat-intelligence-feed-setup.md

@@ -0,0 +1,191 @@
+---
+task: threat-intelligence-feed-setup
+responsavel: "threat-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: organization_profile
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: existing_tools
+    tipo: list
+    origem: "user input"
+    obrigatorio: false
+  - campo: budget_tier
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["free-only", "moderate", "enterprise"]
+
+Saida:
+  - campo: ti_feed_plan
+    tipo: document
+    destino: "soc-analyst, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Assess intelligence requirements"
+  - "[ ] Select appropriate feed sources"
+  - "[ ] Define ingestion architecture"
+  - "[ ] Configure feed normalization"
+  - "[ ] Establish enrichment pipeline"
+  - "[ ] Define retention and sharing policies"
+---
+
+# Task: Threat Intelligence Feed Setup
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Shield (threat-analyst)
+- **Complexity:** Standard
+
+## Objective
+
+Design and configure a threat intelligence feed infrastructure that aggregates, normalizes, and enriches indicators of compromise (IOCs) and tactical intelligence from multiple sources. Enable automated correlation with internal security events.
+
+> **DEFENSIVE USE ONLY:** Threat intelligence feeds are consumed exclusively for defensive detection, hunting, and situational awareness. All feeds must be sourced from legitimate, authorized providers.
+
+## Pre-Conditions
+
+- Organization's industry and threat profile defined
+- SIEM or security platform available for feed ingestion
+- Understanding of current detection capabilities
+- Budget parameters for commercial feeds (if applicable)
+
+## Inputs
+
+- Organization profile (industry, size, technology stack)
+- Existing security tooling (SIEM, SOAR, EDR)
+- Budget tier (free-only, moderate, enterprise)
+- Priority Intelligence Requirements (PIRs)
+- Compliance requirements for data handling
+
+## Steps
+
+### 1. Define Intelligence Requirements
+Map business objectives to intelligence needs:
+| PIR | Threat Category | Required IOC Types | Timeliness |
+|-----|----------------|-------------------|-----------|
+| Detect ransomware campaigns | Cybercrime | IPs, domains, hashes, TTPs | Real-time |
+| Monitor supply chain risks | APT/Supply chain | CVEs, vendor advisories | Daily |
+| Track industry-specific threats | Sector-specific | Actor profiles, campaigns | Weekly |
+
+### 2. Select Feed Sources
+Curate feeds based on requirements and budget:
+
+**Free/Open Sources:**
+- MISP communities (sector-specific ISACs)
+- AlienVault OTX
+- Abuse.ch (URLhaus, MalwareBazaar, ThreatFox)
+- CISA KEV catalog
+- PhishTank
+
+**Commercial Sources (if budget allows):**
+- Recorded Future, Mandiant, CrowdStrike
+- Industry-specific ISAC premium feeds
+- Vendor-specific threat feeds (firewall, EDR)
+
+### 3. Design Ingestion Architecture
+Define how feeds flow into the security stack:
+```
+Sources → Collector → Normalizer → Enricher → SIEM/SOAR
+                                      ↓
+                                  TIP (Threat Intel Platform)
+```
+
+### 4. Configure Feed Normalization
+Standardize all feeds to a common format:
+- Adopt STIX 2.1 as the canonical format
+- Map vendor-specific formats to STIX objects
+- Normalize confidence scores to a unified scale (0-100)
+- Deduplicate indicators across sources
+
+### 5. Implement Enrichment Pipeline
+Enrich raw IOCs with additional context:
+- GeoIP data for IP indicators
+- WHOIS data for domain indicators
+- Malware family classification for hash indicators
+- MITRE ATT&CK technique mapping
+- Historical sighting data
+
+### 6. Configure Automated Correlation
+Set up automated matching of feed indicators against internal telemetry:
+- SIEM correlation rules for IOC matches
+- EDR watchlists for file hashes
+- Firewall/proxy block lists for malicious IPs/domains
+- Email gateway rules for phishing indicators
+
+### 7. Define Scoring and Prioritization
+Establish scoring criteria to avoid alert fatigue:
+| Factor | Weight | Description |
+|--------|--------|------------|
+| Source reliability | 30% | Track record of the feed |
+| Indicator freshness | 25% | Age of the indicator |
+| Relevance | 25% | Match to organization's attack surface |
+| Confidence | 20% | Source's stated confidence level |
+
+### 8. Establish Retention and Sharing Policies
+Define data lifecycle:
+- IOC retention periods by type (IPs: 30 days, hashes: 90 days, TTPs: 1 year)
+- Traffic Light Protocol (TLP) compliance for shared intelligence
+- Data sharing agreements with ISACs and partners
+- GDPR/privacy considerations for PII in feeds
+
+### 9. Create Operational Procedures
+Document procedures for the SOC team:
+- Feed health monitoring and alerting
+- False positive handling and feed quality tracking
+- Escalation procedures for high-confidence matches
+- Feed review cadence (monthly quality assessment)
+
+### 10. Test and Validate
+Validate the complete pipeline:
+- Inject known-good test indicators
+- Verify correlation with synthetic events
+- Measure end-to-end latency
+- Confirm alerting and escalation paths work
+
+## Output
+
+```yaml
+ti_feed_setup:
+  organization: ""
+  date: ""
+
+  feeds_configured:
+    - name: ""
+      type: "[osint/commercial/isac/vendor]"
+      format: ""
+      refresh_rate: ""
+      ioc_types: []
+      cost: ""
+
+  architecture:
+    collector: ""
+    normalizer: ""
+    enricher: ""
+    tip: ""
+    siem_integration: ""
+
+  correlation_rules: []
+  scoring_weights: {}
+  retention_policy: {}
+
+  validation_results:
+    feeds_active: 0
+    latency_p95: ""
+    test_indicators_matched: true
+```
+
+## Quality Criteria
+
+- [ ] Intelligence requirements mapped to business objectives
+- [ ] Minimum 5 feed sources configured and validated
+- [ ] Normalization pipeline producing STIX 2.1 output
+- [ ] Enrichment pipeline operational
+- [ ] Automated correlation with SIEM verified
+- [ ] Scoring and prioritization criteria documented
+- [ ] Retention and TLP policies defined
+- [ ] SOC operational procedures documented