sinapse-ai 1.0.0

package/squad-cybersecurity/tasks/risk-scoring-matrix.md

@@ -0,0 +1,184 @@
+---
+task: risk-scoring-matrix
+responsavel: "threat-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: asset_inventory
+    tipo: list
+    origem: "user input or attack-surface-mapping"
+    obrigatorio: true
+  - campo: risk_framework
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["NIST-CSF", "ISO-27005", "FAIR", "custom"]
+
+Saida:
+  - campo: risk_scoring_matrix
+    tipo: document
+    destino: "stakeholders, compliance-officer, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Define risk scoring methodology"
+  - "[ ] Inventory and classify all assets"
+  - "[ ] Identify threats per asset"
+  - "[ ] Assess vulnerability exposure"
+  - "[ ] Calculate risk scores"
+  - "[ ] Produce prioritized risk register"
+---
+
+# Task: Risk Scoring Matrix
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Shield (threat-analyst)
+- **Complexity:** Standard
+
+## Objective
+
+Create a structured risk scoring matrix that quantifies security risk for organizational assets by combining threat likelihood, vulnerability exposure, asset value, and control effectiveness. The output drives resource allocation and mitigation prioritization.
+
+## Pre-Conditions
+
+- Asset inventory available (from attack-surface-mapping or existing CMDB)
+- Organizational risk appetite defined or to be established
+- Stakeholder alignment on risk framework selection
+- Understanding of existing security controls
+
+## Inputs
+
+- Asset inventory with classification
+- Risk framework preference (NIST CSF, ISO 27005, FAIR, or custom)
+- Existing security controls documentation
+- Business impact analysis (if available)
+- Compliance requirements
+
+## Steps
+
+### 1. Select Risk Scoring Methodology
+Choose and configure the scoring approach:
+| Framework | Best For | Scoring Type |
+|-----------|---------|-------------|
+| NIST CSF | General enterprise | Qualitative (1-5) |
+| ISO 27005 | Compliance-driven orgs | Qualitative/Quantitative |
+| FAIR | Financial quantification | Quantitative ($) |
+| Custom | Specific org needs | Hybrid |
+
+### 2. Define Scoring Dimensions
+Establish the factors that compose the risk score:
+
+**Likelihood Factors (1-5):**
+| Score | Label | Description |
+|-------|-------|------------|
+| 1 | Rare | Less than once per 5 years |
+| 2 | Unlikely | Once per 2-5 years |
+| 3 | Possible | Once per 1-2 years |
+| 4 | Likely | Multiple times per year |
+| 5 | Almost Certain | Monthly or more frequent |
+
+**Impact Factors (1-5):**
+| Score | Label | Financial | Operational | Reputational |
+|-------|-------|----------|-------------|-------------|
+| 1 | Negligible | < $10K | Minutes downtime | No coverage |
+| 2 | Minor | $10K-$100K | Hours downtime | Local coverage |
+| 3 | Moderate | $100K-$1M | Day downtime | Industry coverage |
+| 4 | Major | $1M-$10M | Week downtime | National coverage |
+| 5 | Catastrophic | > $10M | Extended outage | Global coverage |
+
+### 3. Classify Assets
+Categorize each asset by business value:
+| Asset | Type | Data Classification | Business Criticality | Owner |
+|-------|------|-------------------|---------------------|-------|
+
+### 4. Map Threats to Assets
+For each asset, identify applicable threats:
+- External threats (from threat landscape report)
+- Internal threats (insider, accidental)
+- Environmental threats (natural disaster, power failure)
+- Supply chain threats (third-party compromise)
+
+### 5. Assess Vulnerability Exposure
+Rate each asset's vulnerability to identified threats:
+- Known unpatched vulnerabilities (CVE data)
+- Configuration weaknesses
+- Missing security controls
+- Historical incident data
+
+### 6. Evaluate Existing Controls
+Rate the effectiveness of controls already in place:
+| Control Effectiveness | Score | Description |
+|----------------------|-------|------------|
+| Fully effective | 0.2 | Comprehensive, tested, automated |
+| Mostly effective | 0.4 | Good coverage with minor gaps |
+| Partially effective | 0.6 | Significant gaps or untested |
+| Minimally effective | 0.8 | Exists but largely ineffective |
+| No control | 1.0 | No mitigating control in place |
+
+### 7. Calculate Risk Scores
+Apply the scoring formula:
+```
+Risk Score = Likelihood × Impact × Control Gap Factor
+```
+Normalize to a 1-25 scale for the risk heat map.
+
+### 8. Build Risk Heat Map
+| | Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 |
+|---|---------|---------|---------|---------|---------|
+| Likelihood 5 | 5 | 10 | 15 | 20 | **25** |
+| Likelihood 4 | 4 | 8 | 12 | **16** | **20** |
+| Likelihood 3 | 3 | 6 | **9** | **12** | **15** |
+| Likelihood 2 | 2 | 4 | 6 | 8 | 10 |
+| Likelihood 1 | 1 | 2 | 3 | 4 | 5 |
+
+### 9. Produce Risk Register
+Compile the prioritized risk register with treatment recommendations:
+- **Mitigate** — Implement controls to reduce risk
+- **Transfer** — Insurance or contractual transfer
+- **Accept** — Within risk appetite, document acceptance
+- **Avoid** — Eliminate the activity or asset
+
+### 10. Review and Validate
+Present the risk scoring matrix to stakeholders for validation. Ensure alignment between calculated risk levels and business perception.
+
+## Output
+
+```yaml
+risk_scoring_matrix:
+  framework: ""
+  date: ""
+  assessor: "Shield (threat-analyst)"
+
+  risk_register:
+    - asset: ""
+      threat: ""
+      likelihood: 0
+      impact: 0
+      control_effectiveness: 0.0
+      risk_score: 0
+      risk_level: "[critical/high/medium/low]"
+      treatment: "[mitigate/transfer/accept/avoid]"
+      recommended_action: ""
+
+  heat_map_summary:
+    critical: 0
+    high: 0
+    medium: 0
+    low: 0
+
+  risk_appetite_threshold: 0
+  risks_above_appetite: 0
+```
+
+## Quality Criteria
+
+- [ ] Risk framework selected and documented
+- [ ] All assets classified with business criticality
+- [ ] Threats mapped to each asset with evidence
+- [ ] Existing controls evaluated for effectiveness
+- [ ] Risk scores calculated consistently
+- [ ] Risk heat map generated
+- [ ] Treatment recommendations for all high/critical risks
+- [ ] Stakeholder review and validation completed

package/squad-cybersecurity/tasks/security-dashboard-design.md

@@ -0,0 +1,213 @@
+---
+task: security-dashboard-design
+responsavel: "soc-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: audience
+    tipo: enum
+    origem: "user input"
+    obrigatorio: true
+    valores: ["soc-analysts", "management", "executive", "multi-tier"]
+  - campo: data_sources
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+  - campo: platform
+    tipo: text
+    origem: "user input"
+    obrigatorio: false
+
+Saida:
+  - campo: dashboard_specification
+    tipo: document
+    destino: "soc-analyst team, stakeholders"
+
+Checklist:
+  - "[ ] Define audience and key questions"
+  - "[ ] Identify data sources and metrics"
+  - "[ ] Design layout and visualizations"
+  - "[ ] Define refresh rates and alerting"
+  - "[ ] Create drill-down paths"
+  - "[ ] Document KPIs and thresholds"
+  - "[ ] Validate with target audience"
+  - "[ ] Plan maintenance and updates"
+---
+
+# Task: Security Monitoring Dashboard Design
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Sentinel (soc-analyst)
+- **Complexity:** Standard
+
+## Objective
+
+Design security monitoring dashboards tailored to specific audiences (SOC analysts, management, executives) that provide actionable visibility into security posture, threat activity, and operational metrics. Each dashboard answers key security questions at the appropriate abstraction level.
+
+## Pre-Conditions
+
+- Data sources available and ingested into analytics platform
+- Understanding of audience information needs
+- Visualization platform selected (Splunk, Grafana, Kibana, Power BI)
+- Security metrics framework defined
+
+## Inputs
+
+- Target audience (SOC analysts, management, executive, multi-tier)
+- Available data sources (SIEM, EDR, vulnerability scanner, cloud, identity)
+- Visualization platform
+- Key questions the dashboard must answer
+- Refresh rate requirements
+
+## Steps
+
+### 1. Define Audience and Key Questions
+Map each audience to their critical questions:
+
+**SOC Analysts:**
+- What alerts need immediate attention?
+- What is the current threat activity level?
+- Are there any active incidents?
+- Which assets are most at risk right now?
+
+**Management:**
+- What is our security posture trend?
+- Are we meeting SLA targets?
+- Where are our biggest risk gaps?
+- How efficient is our SOC operation?
+
+**Executives:**
+- Are we secure? (overall risk score)
+- What has changed since last report?
+- How do we compare to industry benchmarks?
+- Where should we invest next?
+
+### 2. Select Key Performance Indicators (KPIs)
+Define metrics for each audience tier:
+
+| KPI | Audience | Source | Threshold |
+|-----|----------|--------|-----------|
+| Open Critical Alerts | SOC | SIEM | Red if > 0 |
+| Mean Time to Detect (MTTD) | Management | SIEM/SOAR | < 1 hour |
+| Mean Time to Respond (MTTR) | Management | SOAR/tickets | < 4 hours |
+| Vulnerability Coverage | Management | Scanner | > 95% |
+| Overall Risk Score | Executive | Composite | Trending down |
+| Compliance Posture | Executive | GRC tool | > 90% |
+| Incidents This Month | Executive | Incident tracker | Trending down |
+
+### 3. Design SOC Operational Dashboard
+Real-time dashboard for daily operations:
+
+**Panel Layout:**
+| Position | Panel | Visualization | Refresh |
+|----------|-------|--------------|---------|
+| Top banner | Active incidents count | Counter | Real-time |
+| Top left | Alert queue by severity | Stacked bar | 1 min |
+| Top right | Alerts trend (24h) | Time series | 5 min |
+| Middle left | Top triggered rules | Table | 5 min |
+| Middle right | Geographic threat map | Map | 5 min |
+| Bottom left | Asset risk heatmap | Heatmap | 15 min |
+| Bottom right | Analyst workload | Bar chart | 5 min |
+
+### 4. Design Management Dashboard
+Weekly/monthly operational overview:
+
+**Panel Layout:**
+| Position | Panel | Visualization |
+|----------|-------|--------------|
+| Top | Security posture score | Gauge |
+| Row 1 | MTTD/MTTR trends | Line chart |
+| Row 2 | Alert volume and FP rate | Combo chart |
+| Row 2 | SLA compliance | Progress bar |
+| Row 3 | Vulnerability status | Donut chart |
+| Row 3 | Top risk areas | Horizontal bar |
+| Bottom | Key incidents summary | Table |
+
+### 5. Design Executive Dashboard
+High-level monthly/quarterly view:
+
+**Panel Layout:**
+| Position | Panel | Visualization |
+|----------|-------|--------------|
+| Top | Overall risk score with trend | Large gauge + sparkline |
+| Row 1 | Incidents by category | Pie chart |
+| Row 1 | Year-over-year comparison | Comparison chart |
+| Row 2 | Compliance status by framework | Multi-gauge |
+| Row 2 | Investment impact | Before/after |
+| Bottom | Strategic recommendations | Text/Table |
+
+### 6. Define Drill-Down Paths
+Create interactive navigation between dashboard levels:
+```
+Executive Risk Score → Management Risk Breakdown → SOC Alert Details
+Executive Incident Count → Management Incident List → SOC Investigation View
+```
+
+### 7. Configure Alerting and Thresholds
+Set visual alerting thresholds:
+| Metric | Green | Yellow | Red |
+|--------|-------|--------|-----|
+| Open Critical Alerts | 0 | 1-2 | 3+ |
+| MTTR | < 2h | 2-4h | > 4h |
+| FP Rate | < 20% | 20-40% | > 40% |
+| Patch Compliance | > 95% | 80-95% | < 80% |
+
+### 8. Define Data Refresh Strategy
+| Dashboard | Refresh Rate | Data Range | Caching |
+|-----------|-------------|-----------|---------|
+| SOC Operational | 1-5 minutes | 24-72 hours | Minimal |
+| Management | 15-60 minutes | 30 days | Moderate |
+| Executive | Daily | 90 days - 1 year | Heavy |
+
+### 9. Create Dashboard Specification Document
+Produce detailed specification for implementation:
+- Panel definitions with exact queries
+- Color schemes and visual standards
+- Access control requirements per dashboard
+- Mobile/responsive considerations
+- Export and reporting capabilities
+
+### 10. Validate and Iterate
+Present mock-ups to target audiences:
+- SOC team validates operational usefulness
+- Management confirms strategic visibility
+- Executives confirm clarity and actionability
+- Incorporate feedback before implementation
+
+## Output
+
+```yaml
+dashboard_specification:
+  date: ""
+  author: "Sentinel (soc-analyst)"
+
+  dashboards:
+    - name: ""
+      audience: ""
+      refresh_rate: ""
+      panels:
+        - title: ""
+          visualization: ""
+          data_source: ""
+          query: ""
+          thresholds: {}
+
+  kpis: []
+  drill_down_paths: []
+  alerting_thresholds: {}
+  access_control: {}
+```
+
+## Quality Criteria
+
+- [ ] Dashboard designed for each target audience
+- [ ] KPIs mapped to specific data sources
+- [ ] Visual alerting thresholds defined
+- [ ] Drill-down paths connect dashboard tiers
+- [ ] Refresh rates appropriate for each audience
+- [ ] Access control requirements specified
+- [ ] Mock-ups validated with target audience
+- [ ] Specification complete enough for implementation

package/squad-cybersecurity/tasks/security-policy-creation.md

@@ -0,0 +1,209 @@
+---
+task: security-policy-creation
+responsavel: "compliance-officer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: policy_type
+    tipo: enum
+    origem: "user input"
+    obrigatorio: true
+    valores: ["information-security", "acceptable-use", "access-control", "incident-response", "data-protection", "remote-work", "vendor-management", "full-suite"]
+  - campo: compliance_frameworks
+    tipo: list
+    origem: "user input"
+    obrigatorio: false
+  - campo: organization_size
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["startup", "smb", "enterprise"]
+
+Saida:
+  - campo: security_policies
+    tipo: document
+    destino: "stakeholders, all-agents"
+
+Checklist:
+  - "[ ] Assess organization's policy needs"
+  - "[ ] Select appropriate policy framework"
+  - "[ ] Draft policies with organization context"
+  - "[ ] Align to compliance requirements"
+  - "[ ] Include enforcement and exception procedures"
+  - "[ ] Create supporting standards and procedures"
+  - "[ ] Plan review and approval cycle"
+  - "[ ] Design communication and training plan"
+---
+
+# Task: Security Policy Creation
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Govern (compliance-officer)
+- **Complexity:** Complex
+
+## Objective
+
+Create comprehensive security policies from scratch, tailored to the organization's size, industry, and compliance requirements. Policies provide the governance foundation for the entire security program and must be practical, enforceable, and aligned with business objectives.
+
+## Pre-Conditions
+
+- Organization profile and industry understood
+- Compliance requirements identified
+- Executive sponsorship for security program
+- Understanding of current security maturity
+- Legal review available for policy approval
+
+## Inputs
+
+- Policy type(s) to create
+- Applicable compliance frameworks (SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR)
+- Organization size (startup, SMB, enterprise)
+- Industry-specific requirements
+- Existing policies (if any, for gap analysis)
+
+## Steps
+
+### 1. Assess Policy Needs
+Determine required policies based on compliance and business needs:
+| Policy | SOC 2 | ISO 27001 | HIPAA | PCI DSS | Priority |
+|--------|-------|-----------|-------|---------|----------|
+| Information Security | Required | Required | Required | Required | P1 |
+| Acceptable Use | Required | A.5.10 | Recommended | Required | P1 |
+| Access Control | Required | A.5.15-18 | 164.312(a) | 7.1-7.3 | P1 |
+| Incident Response | Required | A.5.24-28 | 164.308(a)(6) | 12.10 | P1 |
+| Data Classification | Required | A.5.12-13 | Required | 9.6 | P2 |
+| Remote Work | Recommended | A.6.7 | Recommended | — | P2 |
+| Vendor Management | Required | A.5.19-22 | Required | 12.8 | P2 |
+| Change Management | Required | A.8.32 | Required | 6.4 | P2 |
+| Encryption | Required | A.8.24 | 164.312(a)(2) | 3.4, 4.1 | P2 |
+
+### 2. Define Policy Framework Structure
+Establish a consistent hierarchy:
+```
+Policy (what and why) → Approved by executive
+  ↓
+Standard (specific requirements) → Approved by CISO
+  ↓
+Procedure (how to do it) → Approved by team lead
+  ↓
+Guideline (recommendations) → Informational
+```
+
+### 3. Draft Information Security Policy
+The master policy that governs all others:
+- Purpose and scope
+- Information security objectives
+- Roles and responsibilities
+- Risk management approach
+- Compliance requirements
+- Policy enforcement
+- Exception process
+- Review cycle
+
+### 4. Draft Operational Policies
+For each required policy, include:
+| Section | Content |
+|---------|---------|
+| Purpose | Why this policy exists |
+| Scope | Who and what it covers |
+| Policy Statements | Clear, enforceable requirements |
+| Roles & Responsibilities | Who does what |
+| Compliance | How compliance is measured |
+| Enforcement | Consequences of non-compliance |
+| Exceptions | How to request exceptions |
+| Definitions | Key terms |
+| Related Policies | Cross-references |
+| Revision History | Version tracking |
+
+### 5. Align to Compliance Frameworks
+Map each policy statement to compliance controls:
+| Policy Statement | SOC 2 Ref | ISO 27001 Ref | Compliance Status |
+|-----------------|-----------|--------------|-------------------|
+| "All users must use MFA" | CC6.1 | A.8.5 | Compliant |
+| "Data must be encrypted at rest" | CC6.1 | A.8.24 | Partial |
+
+### 6. Define Enforcement and Exception Procedures
+Create practical enforcement:
+- Violation severity classification
+- Progressive discipline approach
+- Exception request process
+- Exception approval authority
+- Exception tracking and review
+- Time-limited exceptions only
+
+### 7. Create Supporting Standards and Procedures
+For each policy, develop operational guidance:
+
+**Example for Access Control Policy:**
+- Standard: Password length >= 14 characters, MFA required
+- Procedure: How to request access, approval workflow
+- Guideline: Password manager recommendations
+
+### 8. Plan Review and Approval Cycle
+Define governance:
+| Activity | Frequency | Responsible | Approver |
+|----------|-----------|------------|---------|
+| Policy review | Annual | Policy owner | CISO |
+| Major updates | As needed | Policy owner | Executive |
+| New policy creation | As needed | Security team | CISO + Legal |
+| Exception review | Quarterly | CISO | Risk committee |
+
+### 9. Design Communication and Training Plan
+Ensure policies are known and understood:
+| Audience | Communication | Training | Acknowledgment |
+|----------|-------------|---------|---------------|
+| All employees | Email + intranet | Annual security training | Digital signature |
+| IT staff | Team meeting | Role-specific training | Signed acknowledgment |
+| Executives | Board presentation | Executive briefing | Meeting minutes |
+| New hires | Onboarding | Day-1 security training | HR onboarding checklist |
+
+### 10. Finalize and Publish
+Complete the policy package:
+- Final legal review
+- Executive approval signatures
+- Version control setup
+- Publication on policy portal
+- Acknowledgment tracking system
+- Calendar reminders for review dates
+
+## Output
+
+```yaml
+security_policies:
+  date: ""
+  author: "Govern (compliance-officer)"
+  organization: ""
+
+  policies_created:
+    - name: ""
+      type: ""
+      version: ""
+      compliance_mapping: []
+      approval_status: ""
+      review_date: ""
+
+  standards_created: []
+  procedures_created: []
+
+  governance:
+    review_cycle: ""
+    exception_process: ""
+    enforcement_model: ""
+
+  communication_plan: {}
+  training_requirements: []
+```
+
+## Quality Criteria
+
+- [ ] Policies cover all compliance-required areas
+- [ ] Each policy mapped to compliance framework controls
+- [ ] Policies are practical and enforceable (not just aspirational)
+- [ ] Exception process defined and practical
+- [ ] Supporting standards and procedures created
+- [ ] Legal review included in approval process
+- [ ] Communication and training plan defined
+- [ ] Review cycle and versioning established

package/squad-cybersecurity/tasks/security-policy-draft.md

@@ -0,0 +1,71 @@
+---
+task: "security-policy-draft"
+responsavel: "compliance-officer"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: true
+Entrada:
+  - campo: policy_type
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: applicable_frameworks
+    tipo: list
+    origem: "user input"
+    obrigatorio: false
+  - campo: organization_context
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+Saida:
+  - campo: policy_document
+    tipo: document
+    destino: "management, legal"
+Checklist:
+  - "[ ] Define policy scope and applicability"
+  - "[ ] Draft policy statements aligned with frameworks"
+  - "[ ] Include roles and responsibilities"
+  - "[ ] Define enforcement mechanisms"
+  - "[ ] Include exception process"
+  - "[ ] Set review schedule"
+  - "[ ] Map to applicable regulatory requirements"
+---
+
+# Security Policy Draft
+
+## Objective
+
+Draft a security policy document that is clear, enforceable, and aligned with applicable regulatory frameworks. Policies must be actionable, not aspirational.
+
+## Inputs
+
+- Policy type (Information Security, Access Control, Incident Response, Acceptable Use, Data Classification, etc.)
+- Applicable frameworks (SOC 2, ISO 27001, GDPR, etc.)
+- Organization context (size, industry, risk appetite)
+- Existing policies (if updating)
+
+## Steps
+
+1. **Define scope** — Who does this policy apply to? What systems, data, or processes does it cover? What are the exclusions?
+
+2. **State the purpose** — Why does this policy exist? What risk does it address? What compliance requirements does it satisfy?
+
+3. **Draft policy statements** — Clear, measurable requirements. Use "MUST" for mandatory, "SHOULD" for recommended, "MAY" for optional. Avoid ambiguous language.
+
+4. **Define roles** — Who is responsible for implementation? Who enforces? Who approves exceptions? Who reviews?
+
+5. **Enforcement** — What are the consequences of non-compliance? How is compliance monitored?
+
+6. **Exception process** — How are exceptions requested, reviewed, approved, documented, and time-limited?
+
+7. **Framework mapping** — Map each policy statement to the specific framework control it satisfies.
+
+8. **Review schedule** — Define annual review cycle, triggered review conditions, and approval authority for changes.
+
+## Quality Gates
+
+- Policy language must be unambiguous and measurable
+- Every statement must use MUST/SHOULD/MAY consistently
+- Framework mapping must reference specific control IDs
+- Exception process must be defined
+- Review schedule must be specified