iron-edge 1.0.0

package/squads/squad-cybersecurity/knowledge-base/zero-trust-architecture.md

@@ -0,0 +1,225 @@
+# Zero Trust Architecture Reference
+
+## Purpose
+
+Reference for implementing Zero Trust Architecture (ZTA) based on NIST SP 800-207 and NIST SP 800-207A (2025). Used by Wire (network-security-engineer) and Nimbus (cloud-security-engineer) for architecture decisions and hardening recommendations.
+
+---
+
+## Foundational Document: NIST SP 800-207
+
+Published August 2020. The definitive US government standard for Zero Trust. In June 2025, NIST published SP 800-207A with 19 concrete architecture examples using commercial technologies.
+
+**Core premise:** "Never trust, always verify" — no machine, user, or service is implicitly trusted, even inside the corporate network. Contrasts with the traditional "castle and moat" model where passing the firewall grants broad internal access.
+
+---
+
+## The 7 Zero Trust Tenets (NIST SP 800-207)
+
+1. **All data sources and computing services are resources** — applies to personal devices, IoT, cloud services
+2. **All communication is secured regardless of network location** — no "trusted internal network"
+3. **Access to resources is granted per-session** — no persistent access grants
+4. **Access is determined by dynamic policy** — identity, device health, posture, behavioral context
+5. **Enterprise monitors and measures integrity of all assets** — continuous validation
+6. **Authentication and authorization are dynamic and strictly enforced before access** — re-verify as context changes
+7. **Enterprise collects information about assets and uses it to improve security posture** — telemetry-driven
+
+---
+
+## Zero Trust vs. Traditional Perimeter Security
+
+| Aspect | Traditional (Castle & Moat) | Zero Trust |
+|--------|----------------------------|------------|
+| Trust model | Trust everything inside the network | Trust nothing by default |
+| Network location | Inside = trusted | Location is irrelevant |
+| Access control | VPN grants broad access | Per-resource, per-session access |
+| Lateral movement | Easy — flat internal network | Difficult — microsegmentation |
+| Identity | Static roles, rarely reviewed | Continuous verification with context |
+| Devices | Corporate-managed = trusted | Device posture checked every session |
+| Detection | Perimeter-focused | Assume breach, detect everywhere |
+
+---
+
+## The Three Pillars of Zero Trust
+
+### Pillar 1: Identity
+
+Every entity (user, service, device) must have a verified identity. Identity is the new perimeter.
+
+**Identity controls:**
+- Multi-Factor Authentication (MFA) — mandatory for all users, especially privileged access
+- Conditional Access — access depends on user risk score, device compliance, location
+- Privileged Identity Management (PIM) — just-in-time (JIT) access elevation for admins
+- Service-to-service identity — machine identities via SPIFFE/SPIRE or cloud IAM roles
+- Identity governance — regular access reviews, separation of duties
+
+**Commercial identity providers (NIST SP 800-207A examples):**
+- Microsoft Entra ID (formerly Azure AD) — enterprise standard, integrates with most SaaS
+- Okta — multi-cloud identity platform
+- Google Cloud Identity — strong for GCP-native environments
+- HashiCorp Vault — service-to-service identity and secrets management
+
+### Pillar 2: Devices
+
+Device health and compliance as a factor in access decisions.
+
+**Device controls:**
+- Device compliance enforcement — OS version, patches, security software required
+- Endpoint Detection and Response (EDR) — CrowdStrike, SentinelOne, Microsoft Defender
+- Mobile Device Management (MDM) for BYOD — Intune, Jamf
+- Device certificates — cryptographic device identity bound to hardware
+- Continuous posture assessment — device health re-checked during session
+
+### Pillar 3: Microsegmentation
+
+Replace flat networks with fine-grained, software-defined segments where each workload can only communicate with exactly what it needs.
+
+**Network controls:**
+- Software-defined perimeter (SDP) — replace VPN with encrypted, identity-authenticated tunnels
+- Microsegmentation — Illumio, Guardicore, Zscaler, Cilium (Kubernetes)
+- Service mesh mTLS — Istio, Linkerd enforce mutual TLS between services
+- Network policy — Kubernetes NetworkPolicy, AWS Security Groups, GCP Firewall Rules
+- DNS filtering — block malicious domains at the resolver layer
+
+---
+
+## Zero Trust Implementation Roadmap (NIST 5-Phase Approach)
+
+NIST recommends gradual adoption over big-bang deployment:
+
+### Phase 1: Asset Discovery
+- Complete inventory of all assets (hardware, software, data, services)
+- Map all communication flows — who talks to whom
+- Identify crown jewel assets — data and systems requiring highest protection
+- Assess current identity and access management maturity
+
+### Phase 2: Define Trust Zones
+- Group assets by sensitivity and function
+- Define which communication flows are allowed between zones
+- Identify implicit trust relationships that need to be eliminated
+- Document current network topology against desired Zero Trust model
+
+### Phase 3: Policy Modeling
+- Define access policies for each resource (who, what, when, from where, on what device)
+- Model policies using least-privilege principle
+- Define conditional access rules (location, device health, risk score thresholds)
+- Validate policies don't break legitimate workflows
+
+### Phase 4: Pilot Small Environment
+- Select a contained environment (one application, one team)
+- Deploy identity enforcement, device compliance, and microsegmentation for pilot scope
+- Measure impact on productivity and security
+- Iterate on policy before broader rollout
+
+### Phase 5: Monitor, Adjust, and Expand
+- Deploy monitoring and telemetry across the pilot
+- Tune policies based on observed access patterns
+- Expand to next scope incrementally
+- Maintain continuous improvement cycle
+
+---
+
+## Practical Implementation: Cloud-Native Zero Trust
+
+### AWS Zero Trust Pattern
+
+```
+IAM Identity Center (SSO) → Conditional Access → Resources
+    ↑                              ↑
+Device Compliance              VPC Endpoint
+(AWS Verified Access)          (no internet exposure)
+```
+
+**Key AWS services:**
+- **AWS IAM Identity Center** — centralized SSO across all AWS accounts
+- **AWS Verified Access** — application-level zero trust without VPN
+- **VPC Endpoints** — private connectivity to AWS services without internet traversal
+- **AWS PrivateLink** — service mesh private communication
+- **Service Control Policies (SCPs)** — organization-wide guardrails
+- **IMDSv2** — prevent SSRF from accessing EC2 metadata (mandatory)
+
+### Kubernetes Zero Trust Pattern
+
+```
+SPIFFE/SPIRE (workload identity)
+    → Istio/Linkerd mTLS (service mesh)
+    → Network Policies (microsegmentation)
+    → RBAC + OPA/Gatekeeper (authorization)
+    → Falco (runtime detection)
+```
+
+**Key Kubernetes controls:**
+- **RBAC** — role-based access for every service account, no cluster-admin in production
+- **Pod Security Standards** — enforce restricted pod configurations (no privileged containers)
+- **Network Policies** — deny-all default, explicit allow rules per namespace
+- **User namespaces** — isolate container UIDs from host (beta, on by default in K8s 1.32+)
+- **mTLS via service mesh** — Istio or Linkerd for automatic mutual TLS between pods
+- **Admission control** — Kyverno or OPA/Gatekeeper for policy enforcement
+
+### Identity-First Access for SaaS Apps
+
+For organizations using Supabase, the zero trust pattern at the application layer:
+
+```sql
+-- Row Level Security = zero trust at data layer
+-- No row is accessible without explicit policy authorization
+ALTER TABLE sensitive_data ENABLE ROW LEVEL SECURITY;
+
+-- Policy: identity-based access, per-row
+CREATE POLICY "zero_trust_data_access"
+ON sensitive_data
+FOR ALL
+TO authenticated
+USING (
+  user_id = (SELECT auth.uid())
+  AND (SELECT auth.jwt() -> 'app_metadata' ->> 'clearance_level')::int >= required_clearance
+);
+```
+
+---
+
+## Common Zero Trust Anti-Patterns
+
+| Anti-Pattern | Why It Fails |
+|-------------|-------------|
+| VPN as Zero Trust | VPN still grants broad network access after auth — not zero trust |
+| Identity-only Zero Trust | Without device compliance and microsegmentation, identity alone is insufficient |
+| "We have MFA so we're zero trust" | MFA is table stakes, not ZTA |
+| Big bang ZTA deployment | Creates productivity disruption, typically fails — use phased approach |
+| Treating cloud as trusted | Cloud workloads need the same zero trust controls as on-prem |
+| Over-relying on network perimeter | Assumes breach never happens inside — incorrect assumption |
+
+---
+
+## Zero Trust for Brazilian/LGPD Context
+
+Zero Trust architecture directly supports LGPD compliance:
+
+| LGPD Article | Zero Trust Control |
+|-------------|-------------------|
+| Art. 46 — Technical security measures | Identity verification, encryption in transit (mTLS), access control |
+| Art. 38 — DPIA | Zero trust access logs enable privacy impact analysis |
+| Art. 48 — Breach notification | Detailed telemetry enables faster breach detection and scoping |
+| Art. 7 — Lawful basis for processing | Access logs prove data was only accessed per authorized purpose |
+| Principle of data minimization | Microsegmentation prevents services accessing data they don't need |
+
+---
+
+## Key Metrics for Zero Trust Maturity
+
+| Metric | Immature | Mature |
+|--------|---------|--------|
+| % of resources requiring MFA | < 50% | 100% |
+| % of services using mutual TLS | 0% | > 80% |
+| Mean time to detect lateral movement | Days | Minutes |
+| % of network with microsegmentation | < 20% | > 90% |
+| % of access with just-in-time privileged access | 0% | 100% of privileged |
+| % of devices with compliance enforcement | < 30% | 100% |
+
+---
+
+## Sources
+
+- NIST SP 800-207 (Zero Trust Architecture): https://csrc.nist.gov/pubs/sp/800/207/final
+- NIST SP 800-207A (19 ZTA examples): https://www.nist.gov/news-events/news/2025/06/nist-offers-19-ways-build-zero-trust-architectures
+- CISA Zero Trust Maturity Model: https://www.cisa.gov/zero-trust-maturity-model

package/squads/squad-cybersecurity/preferences/README.md

@@ -0,0 +1,15 @@
+# Preferences Directory
+
+> Diretorio para logs de preferencias por projeto/cliente.
+> Atualizado automaticamente pelos agentes do squad apos cada ciclo de entrega.
+
+## Como usar
+
+1. Para cada novo projeto, criar `{projeto}-preferences.md`
+2. Agentes consultam antes de iniciar nova entrega
+3. Atualizar apos cada ciclo de aprovacao
+
+## Arquivos
+
+- `README.md` — Este arquivo
+- `{projeto}-preferences.md` — Um arquivo por projeto ativo

package/squads/squad-cybersecurity/squad.yaml

@@ -0,0 +1,110 @@
+name: squad-cybersecurity
+version: "1.0.0"
+short-title: "Cyber Defense Squad"
+description: "Squad de 8 especialistas em seguranca cibernetica. Threat analysis, pentesting, SOC operations, incident response, cloud security, network security e compliance."
+author: "Sinapse"
+license: MIT
+slashPrefix: IRON
+
+metadata:
+  total_files: 79
+  created_at: "2026-03-16"
+  updated_at: "2026-04-01"
+  created_by: "squad-creator (Craft)"
+  agents_count: 9
+  tasks_count: 53
+  knowledge_bases_count: 15
+  workflows_count: 2
+  templates_count: 0
+  checklists_count: 0
+  quality_target: "5.0/5.0 em todas as dimensoes"
+
+tags:
+  - cybersecurity
+  - security
+  - pentesting
+  - compliance
+  - incident-response
+  - threat-intelligence
+  - cloud-security
+  - network-security
+
+components:
+  agents:
+    - cyber-orqx.md
+    - threat-analyst.md
+    - penetration-tester.md
+    - soc-analyst.md
+    - incident-responder.md
+    - cloud-security-engineer.md
+    - network-security-engineer.md
+    - compliance-officer.md
+  tasks:
+    # Orchestrator
+    - triage-security-request.md
+    # Threat Analyst (Shield)
+    - threat-model.md
+    - threat-intelligence-report.md
+    - threat-landscape-report.md
+    - attack-surface-mapping.md
+    - threat-intelligence-feed-setup.md
+    - risk-scoring-matrix.md
+    - supply-chain-risk-assessment.md
+    - risk-assessment.md
+    # Penetration Tester (Breach)
+    - vulnerability-assessment.md
+    - web-app-pentest.md
+    - web-app-security-audit.md
+    - api-security-audit.md
+    - api-security-testing.md
+    - authentication-security-review.md
+    - social-engineering-assessment.md
+    - mobile-app-security-review.md
+    - code-security-review.md
+    # SOC Analyst (Sentinel)
+    - siem-alert-triage.md
+    - siem-rule-creation.md
+    - threat-hunting-campaign.md
+    - detection-rule-engineering.md
+    - log-analysis-playbook.md
+    - alert-triage-workflow.md
+    - security-dashboard-design.md
+    # Incident Responder (Rapid)
+    - incident-triage.md
+    - incident-containment.md
+    - incident-response-plan.md
+    - tabletop-exercise-design.md
+    - forensic-analysis.md
+    - forensic-analysis-workflow.md
+    - communication-plan-incident.md
+    - post-incident-review.md
+    # Cloud Security Engineer (Nimbus)
+    - cloud-security-assessment.md
+    - cloud-security-posture-review.md
+    - iam-audit.md
+    - iam-policy-audit.md
+    - container-security-review.md
+    - container-security-hardening.md
+    - serverless-security-review.md
+    - cloud-compliance-mapping.md
+    # Network Security Engineer (Wire)
+    - network-segmentation-review.md
+    - network-segmentation-design.md
+    - firewall-rule-audit.md
+    - zero-trust-architecture-plan.md
+    - wireless-security-assessment.md
+    - dns-security-hardening.md
+    # Compliance Officer (Govern)
+    - compliance-gap-analysis.md
+    - security-policy-draft.md
+    - security-policy-creation.md
+    - vendor-security-assessment.md
+    - data-classification-framework.md
+    - privacy-impact-assessment.md
+  workflows:
+    - incident-response-cycle.yaml
+    - security-audit-workflow.yaml
+  knowledge-base:
+    - routing-catalog.md
+    - security-frameworks-catalog.md
+    - threat-intelligence-reference.md

package/squads/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-orqx"
+
+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/squads/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