sinapse-ai 1.0.0

package/squad-cybersecurity/tasks/serverless-security-review.md

@@ -0,0 +1,185 @@
+---
+task: serverless-security-review
+responsavel: "cloud-security-engineer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: serverless_platform
+    tipo: enum
+    origem: "user input"
+    obrigatorio: true
+    valores: ["AWS-Lambda", "Azure-Functions", "GCP-CloudFunctions", "Cloudflare-Workers", "multi-platform"]
+  - campo: function_inventory
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+
+Saida:
+  - campo: serverless_security_report
+    tipo: document
+    destino: "dev team, stakeholders"
+
+Checklist:
+  - "[ ] Inventory all serverless functions"
+  - "[ ] Review IAM permissions per function"
+  - "[ ] Assess input validation and injection risks"
+  - "[ ] Check event source security"
+  - "[ ] Review secrets and environment variables"
+  - "[ ] Evaluate monitoring and logging"
+  - "[ ] Assess dependency security"
+  - "[ ] Produce remediation plan"
+---
+
+# Task: Serverless Security Review
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Nimbus (cloud-security-engineer)
+- **Complexity:** Standard
+
+## Objective
+
+Review the security posture of serverless functions and event-driven architectures, covering function permissions, input validation, event source security, secrets management, dependency vulnerabilities, and observability. Address the unique security challenges of serverless computing.
+
+> **AUTHORIZED REVIEW ONLY:** This review requires read access to function configurations and code. No modifications to production functions during the assessment.
+
+## Pre-Conditions
+
+- Read access to serverless function configurations
+- Access to function code or deployment packages
+- Understanding of event sources and triggers
+- Knowledge of function dependencies and integrations
+
+## Inputs
+
+- Serverless platform (AWS Lambda, Azure Functions, GCP Cloud Functions, etc.)
+- Function inventory (names, triggers, purpose)
+- Function code access
+- Event source configurations
+- Related infrastructure (API Gateway, queues, storage)
+
+## Steps
+
+### 1. Function Inventory and Classification
+Catalog all serverless functions:
+| Function | Runtime | Trigger | Data Sensitivity | Internet-Facing | Last Updated |
+|----------|---------|---------|-----------------|-----------------|-------------|
+| | | | | | |
+
+### 2. IAM Permission Review
+Assess each function's execution role:
+- Principle of least privilege adherence
+- Overly broad permissions (Resource: *)
+- Cross-service access scope
+- Temporary credential usage
+- Permission boundaries applied
+- Unused permissions
+
+### 3. Input Validation and Injection Testing
+Review function inputs for security:
+| Input Source | Validation | Injection Risk | Finding |
+|-------------|-----------|---------------|---------|
+| API Gateway | | SQL, command, SSTI | |
+| S3 events | | Path traversal, XXE | |
+| Queue messages | | Deserialization | |
+| Database streams | | Injection | |
+| Direct invocation | | Payload manipulation | |
+
+### 4. Event Source Security
+Assess the security of event triggers:
+- API Gateway authentication and authorization
+- Queue/topic access policies
+- Storage bucket event permissions
+- Database trigger security
+- Schedule trigger (preventing unauthorized invocation)
+- Cross-account event sources
+
+### 5. Environment and Secrets Security
+Review sensitive data handling:
+- Secrets in environment variables (encrypted vs plaintext)
+- Secrets manager integration
+- Encryption key management
+- Temporary file handling (/tmp)
+- Environment variable exposure in logs
+- Function configuration exposure
+
+### 6. Dependency Security
+Analyze function dependencies:
+- Vulnerability scanning of packages (npm, pip, etc.)
+- Outdated dependency detection
+- License compliance
+- Dependency pinning
+- Layer security (shared dependencies)
+- Custom runtime security
+
+### 7. Network Security
+Assess network configuration:
+- VPC configuration (when applicable)
+- Outbound network restrictions
+- Private endpoint access
+- API Gateway WAF configuration
+- DDoS protection
+- IP restriction capabilities
+
+### 8. Monitoring and Observability
+Verify security monitoring:
+| Aspect | Status | Finding |
+|--------|--------|---------|
+| Function logging enabled | | |
+| Log level appropriate | | |
+| Error handling (no sensitive data) | | |
+| Invocation monitoring | | |
+| Performance anomaly detection | | |
+| Cost anomaly alerting | | |
+
+### 9. Configuration Security
+Review function configuration:
+- Timeout settings (prevent runaway execution)
+- Memory allocation (prevent abuse)
+- Concurrency limits (prevent DoS)
+- Dead letter queue configuration
+- Retry policies
+- Versioning and alias management
+
+### 10. Compile Serverless Security Report
+Document findings with serverless-specific remediation guidance.
+
+## Output
+
+```yaml
+serverless_security_report:
+  platform: ""
+  date: ""
+  author: "Nimbus (cloud-security-engineer)"
+
+  functions_reviewed: 0
+  functions_total: 0
+
+  findings_summary:
+    critical: 0
+    high: 0
+    medium: 0
+    low: 0
+
+  findings:
+    - function: ""
+      finding: ""
+      severity: ""
+      category: "[iam/input/event-source/secrets/dependency/network/config]"
+      remediation: ""
+
+  overall_posture: "[strong/adequate/needs-improvement/weak]"
+```
+
+## Quality Criteria
+
+- [ ] All functions inventoried and classified
+- [ ] IAM permissions reviewed for least privilege
+- [ ] Input validation assessed for all event sources
+- [ ] Secrets management evaluated
+- [ ] Dependencies scanned for vulnerabilities
+- [ ] Monitoring and logging verified
+- [ ] Remediation specific to serverless patterns
+- [ ] No production functions modified during review

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

@@ -0,0 +1,61 @@
+---
+task: "siem-alert-triage"
+responsavel: "soc-analyst"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: true
+Entrada:
+  - campo: alert_data
+    tipo: text
+    origem: "SIEM or user input"
+    obrigatorio: true
+  - campo: log_sources
+    tipo: list
+    origem: "SIEM"
+    obrigatorio: false
+Saida:
+  - campo: triage_verdict
+    tipo: document
+    destino: "incident-responder or closure"
+Checklist:
+  - "[ ] Contextualize the alert (what triggered, source, target)"
+  - "[ ] Enrich with additional data sources"
+  - "[ ] Correlate with related events"
+  - "[ ] Determine verdict (TP, FP, BTP, Inconclusive)"
+  - "[ ] Document rationale"
+  - "[ ] Escalate or close with appropriate action"
+---
+
+# SIEM Alert Triage
+
+## Objective
+
+Analyze a SIEM alert through the structured triage framework: contextualize, enrich, correlate, verdict. Determine whether the alert represents a true positive requiring response or a false positive requiring tuning.
+
+## Inputs
+
+- Alert data (rule name, severity, source, destination, timestamp, raw event)
+- Available log sources for correlation
+- Asset inventory context (if available)
+- User directory context (if available)
+
+## Steps
+
+1. **Contextualize** — What rule triggered? What is the source system/user? What is the target? When did it occur? Is this asset critical?
+
+2. **Enrich** — Query threat intelligence for source IPs/domains. Check asset inventory for system classification. Check user directory for account status and role.
+
+3. **Correlate** — Search for related events: same source across different log sources, same target from different sources, timeline of surrounding events.
+
+4. **Analyze** — Map observed behavior to known attack patterns (MITRE ATT&CK). Assess whether behavior is consistent with legitimate activity or adversary action.
+
+5. **Verdict** — Classify as: True Positive (confirmed malicious), False Positive (benign trigger), Benign True Positive (real but authorized), or Inconclusive (need more data).
+
+6. **Act** — TP: Escalate to incident response with timeline. FP: Document for rule tuning. BTP: Add exception. Inconclusive: Request additional log sources.
+
+## Quality Gates
+
+- Verdict must be justified with evidence
+- Correlation must include at least 2 data sources
+- Escalations must include complete timeline
+- False positives must include tuning recommendation

package/squad-cybersecurity/tasks/siem-rule-creation.md

@@ -0,0 +1,217 @@
+---
+task: siem-rule-creation
+responsavel: "soc-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: detection_requirement
+    tipo: text
+    origem: "user input or threat-analyst"
+    obrigatorio: true
+  - campo: siem_platform
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["Splunk", "Sentinel", "Elastic", "QRadar", "Chronicle", "generic-sigma"]
+  - campo: log_sources
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+
+Saida:
+  - campo: siem_rules
+    tipo: document
+    destino: "soc-analyst, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Define detection objective and threat mapping"
+  - "[ ] Identify required log sources"
+  - "[ ] Write detection logic"
+  - "[ ] Define alert severity and context"
+  - "[ ] Test against known-good and known-bad data"
+  - "[ ] Tune for false positive reduction"
+  - "[ ] Document rule and create runbook"
+  - "[ ] Deploy with monitoring period"
+---
+
+# Task: SIEM Rule Creation
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Sentinel (soc-analyst)
+- **Complexity:** Standard
+
+## Objective
+
+Create, test, and deploy SIEM detection rules that identify security threats, suspicious behaviors, and policy violations. Rules should be precise enough to minimize false positives while maintaining detection coverage. Each rule includes a MITRE ATT&CK mapping and an analyst runbook.
+
+> **DEFENSIVE DETECTION ONLY:** SIEM rules are created exclusively for defensive monitoring and threat detection. All rules must be tested in a controlled environment before production deployment.
+
+## Pre-Conditions
+
+- SIEM platform operational with log ingestion
+- Required log sources available and indexed
+- Understanding of normal baseline activity
+- MITRE ATT&CK mapping for the detection objective
+- Test environment or historical data for validation
+
+## Inputs
+
+- Detection requirement (what threat/behavior to detect)
+- SIEM platform (Splunk, Sentinel, Elastic, QRadar, Chronicle, or Sigma)
+- Available log sources
+- MITRE ATT&CK technique(s) to detect
+- Known false positive patterns (if available)
+- Threat intelligence context
+
+## Steps
+
+### 1. Define Detection Objective
+Map the detection requirement to specific observables:
+| Field | Value |
+|-------|-------|
+| Threat | What are we detecting? |
+| ATT&CK Technique | T-code(s) |
+| ATT&CK Tactic | Tactic phase |
+| Data Sources | Required log types |
+| Observable | What event pattern indicates the threat? |
+| Priority | Detection urgency |
+
+### 2. Identify and Validate Log Sources
+Confirm required data is available:
+| Log Source | Fields Needed | Availability | Latency |
+|-----------|--------------|-------------|---------|
+| | | | |
+
+### 3. Analyze Normal Baseline
+Before writing detection logic, understand the baseline:
+- What does normal activity look like for this data source?
+- What are common benign events that match the pattern?
+- What exclusions will be needed?
+- What volume of events is expected?
+
+### 4. Write Detection Logic
+Create the detection rule in the target SIEM query language:
+
+**Sigma Rule (platform-agnostic):**
+```yaml
+title: ""
+id: ""
+status: experimental
+description: ""
+references: []
+author: "Sentinel (soc-analyst)"
+date: ""
+tags:
+  - attack.technique_id
+logsource:
+  category: ""
+  product: ""
+detection:
+  selection:
+    field: value
+  condition: selection
+falsepositives:
+  - ""
+level: ""
+```
+
+### 5. Define Alert Context and Enrichment
+Specify what context to include in the alert:
+- Source and destination details
+- User and process information
+- Historical count of similar events
+- Threat intelligence matches
+- Asset criticality information
+- Related alerts in the last 24 hours
+
+### 6. Implement Severity Classification
+| Severity | Criteria | Response SLA |
+|----------|---------|-------------|
+| Critical | Confirmed compromise indicator | Immediate |
+| High | Strong suspicious activity | 1 hour |
+| Medium | Anomalous behavior, needs investigation | 4 hours |
+| Low | Policy violation, informational | 24 hours |
+
+### 7. Test with Known-Good Data
+Run the rule against historical data:
+- Verify expected false positive rate
+- Confirm no critical true positives are missed
+- Measure alert volume against SOC capacity
+- Validate enrichment fields populate correctly
+
+### 8. Test with Known-Bad Data
+Validate detection against known attack patterns:
+- Replay or simulate the target attack technique
+- Confirm the rule fires correctly
+- Verify alert contains sufficient context for triage
+- Test edge cases and evasion variants
+
+### 9. Tune for Production
+Refine the rule based on testing:
+- Add exclusions for known benign patterns
+- Adjust thresholds for acceptable alert volume
+- Add correlation with other rules if applicable
+- Set appropriate alert aggregation windows
+
+### 10. Create Analyst Runbook
+Document the response procedure for this alert:
+```yaml
+runbook:
+  alert_name: ""
+  description: ""
+  severity: ""
+  investigation_steps:
+    - step: ""
+      tool: ""
+      expected: ""
+  true_positive_actions: []
+  false_positive_handling: ""
+  escalation_criteria: ""
+```
+
+### 11. Deploy and Monitor
+Deploy to production with a monitoring period:
+- Enable rule in alerting mode (or silent mode for initial period)
+- Monitor false positive rate for first 7 days
+- Adjust thresholds as needed
+- Confirm with SOC team after monitoring period
+
+## Output
+
+```yaml
+siem_rule_package:
+  rule_name: ""
+  platform: ""
+  date_created: ""
+  author: "Sentinel (soc-analyst)"
+
+  detection:
+    attack_technique: ""
+    attack_tactic: ""
+    log_sources: []
+    query: ""
+    sigma_rule: ""
+
+  testing:
+    true_positive_rate: ""
+    false_positive_rate: ""
+    alert_volume_daily: ""
+    test_date: ""
+
+  runbook: {}
+  deployment_status: "[testing/silent/active]"
+```
+
+## Quality Criteria
+
+- [ ] Detection objective clearly mapped to MITRE ATT&CK
+- [ ] Rule tested against both known-good and known-bad data
+- [ ] False positive rate acceptable for SOC capacity
+- [ ] Alert includes sufficient context for triage
+- [ ] Analyst runbook documented
+- [ ] Sigma format available for portability
+- [ ] Monitoring period planned after deployment
+- [ ] Rule documented in detection rule inventory

package/squad-cybersecurity/tasks/social-engineering-assessment.md

@@ -0,0 +1,197 @@
+---
+task: social-engineering-assessment
+responsavel: "penetration-tester"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: organization_name
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: authorization
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: assessment_type
+    tipo: enum
+    origem: "user input"
+    obrigatorio: false
+    valores: ["awareness-audit", "phishing-simulation", "pretexting-review", "full-assessment"]
+
+Saida:
+  - campo: se_assessment_report
+    tipo: document
+    destino: "stakeholders, HR, cyber-orchestrator"
+
+Checklist:
+  - "[ ] Verify authorization and legal review"
+  - "[ ] Define assessment scope and boundaries"
+  - "[ ] Evaluate current awareness program"
+  - "[ ] Design assessment scenarios"
+  - "[ ] Assess organizational exposure"
+  - "[ ] Analyze results with empathy"
+  - "[ ] Provide training recommendations"
+  - "[ ] Produce blameless report"
+---
+
+# Task: Social Engineering Awareness Assessment
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Breach (penetration-tester)
+- **Complexity:** Standard
+
+## Objective
+
+Assess the organization's resilience to social engineering attacks by evaluating security awareness programs, identifying human-factor vulnerabilities, and designing improvement recommendations. This is an awareness-focused assessment, not an adversarial attack.
+
+> **ETHICAL AND AUTHORIZED USE ONLY:** This assessment is designed to IMPROVE organizational awareness, NOT to shame or punish individuals. All activities require explicit authorization from organizational leadership AND legal/HR review. Results must be reported in aggregate — never identify individual employees by name. The goal is to strengthen the human layer of defense.
+
+## Pre-Conditions
+
+- Executive authorization for assessment
+- Legal and HR review of assessment plan
+- Clear communication to management about assessment purpose
+- Agreement on reporting format (aggregate, no individual naming)
+- Employee privacy protections confirmed
+
+## Inputs
+
+- Organization name and size
+- Written authorization (including legal/HR sign-off)
+- Assessment type (awareness audit, phishing simulation, pretexting review, full)
+- Current security awareness program documentation
+- Previous assessment results (if available)
+- Industry-specific social engineering threat intelligence
+
+## Steps
+
+### 1. Authorization and Ethical Framework
+Document and confirm:
+- Executive authorization received
+- Legal review completed (employment law compliance)
+- HR review completed (employee privacy protections)
+- Assessment boundaries defined (what is explicitly NOT allowed)
+- Blameless reporting agreement signed
+- Escalation procedures for unexpected findings
+
+### 2. Review Current Awareness Program
+Evaluate the existing security awareness program:
+| Component | Status | Quality |
+|-----------|--------|---------|
+| New hire security training | | |
+| Annual refresher training | | |
+| Phishing simulation program | | |
+| Reporting mechanisms (phish button) | | |
+| Security champions program | | |
+| Incident reporting culture | | |
+| Executive security briefings | | |
+
+### 3. Assess Information Exposure
+Review publicly available information that could be used in social engineering:
+- Employee information on LinkedIn, social media
+- Organization details on website (team pages, org charts)
+- Technology stack exposure (job postings, GitHub)
+- Physical location details
+- Vendor and partner relationships visible publicly
+
+### 4. Evaluate Technical Controls Against Social Engineering
+Assess controls designed to mitigate social engineering:
+- Email filtering and anti-phishing
+- URL rewriting and sandboxing
+- DMARC/DKIM/SPF configuration
+- Browser isolation for risky URLs
+- USB and removable media policies
+- Phone system caller ID validation
+
+### 5. Design Assessment Scenarios
+Create realistic but ethical scenarios to evaluate awareness:
+| Scenario | Vector | Difficulty | What It Tests |
+|----------|--------|-----------|--------------|
+| Phishing email | Email | Low | Link click, credential entry |
+| Spear phishing | Email | Medium | Targeted info gathering |
+| Pretexting call | Phone | Medium | Information disclosure |
+| Tailgating awareness | Physical | Low | Physical security awareness |
+| USB drop | Physical | Low | Device trust |
+
+### 6. Analyze Organizational Culture Factors
+Assess cultural factors that influence social engineering resilience:
+- Authority compliance tendencies
+- Urgency response patterns
+- Helpfulness exploitation risk
+- Fear-based compliance risk
+- Reporting culture (fear of blame vs. encouraged)
+
+### 7. Benchmark Against Industry Standards
+Compare organizational awareness against:
+- Industry phishing click-rate benchmarks
+- NIST SP 800-50 (security awareness training)
+- SANS Security Awareness Maturity Model
+- Sector-specific requirements (HIPAA, PCI DSS)
+
+### 8. Develop Improvement Recommendations
+Provide actionable recommendations:
+- Training program improvements (content, frequency, delivery)
+- Technical control enhancements
+- Policy updates
+- Culture change initiatives
+- Metrics and KPIs for measuring progress
+
+### 9. Design Ongoing Measurement Program
+Create a sustainable measurement framework:
+- Quarterly phishing simulation cadence
+- Annual awareness assessment
+- Reporting rate tracking
+- Time-to-report metrics
+- Training completion metrics
+
+### 10. Compile Assessment Report
+Produce a blameless, aggregate report focused on organizational improvement — never individual blame.
+
+## Output
+
+```yaml
+se_assessment:
+  organization: ""
+  date: ""
+  type: ""
+  authorization: "confirmed (exec + legal + HR)"
+
+  awareness_maturity: "[1-5 SANS model]"
+
+  current_program:
+    training_coverage: ""
+    simulation_frequency: ""
+    reporting_mechanism: "[exists/missing]"
+    culture_assessment: "[strong/adequate/weak]"
+
+  exposure_assessment:
+    public_info_risk: "[high/medium/low]"
+    technical_controls: "[strong/adequate/weak]"
+
+  recommendations:
+    - area: ""
+      current_state: ""
+      recommendation: ""
+      priority: "[high/medium/low]"
+      effort: ""
+
+  improvement_metrics:
+    - metric: ""
+      current_baseline: ""
+      target: ""
+      measurement_method: ""
+```
+
+## Quality Criteria
+
+- [ ] Authorization confirmed including legal and HR
+- [ ] Current awareness program thoroughly evaluated
+- [ ] Public information exposure assessed
+- [ ] Technical controls evaluated
+- [ ] Recommendations are constructive and actionable
+- [ ] Report is blameless — no individual identification
+- [ ] Industry benchmarks referenced
+- [ ] Ongoing measurement program designed