mirror of
https://github.com/SHOGGOTH-SECTOR/sica-fondt.git
synced 2026-08-01 08:30:20 +00:00
24f816b6a3
Place useful parts of the surrounding repos into sica-fondt by layer, per the
body model (Ada = membrane; brain/endocrine/capabilities/knowledge non-Ada):
- brain/ LLM reasoning + providers (dapr, hermes, MoMoA)
- capabilities/ REPRAG sidecars: hermes tools/skills, dapr tools, parallel
dispatch, A51 channels, and the OSINT cluster
- knowledge/ LORAG corpus: 754 cyber-skills, agency personas, secure-coding,
MITRE ATT&CK data
- reference/ defensive threat-reference (C3, shhbruh doc) + AdaYaml parser
License handling: AGPL sources (worldosint, advanced_evolution, mercury,
Reticulum) and GPL DeTTECT are SPEC-only clean-room/port descriptions — no
copyleft code copied. MIT/Apache/data parts copied as working trees.
Safety: shhbruh escape/persistence material and C3 covert-C2 kept as reference
only, not wired into the running organism. See CONSOLIDATION.md.
https://claude.ai/code/session_01UehUqEXXJJCsHoA4voCU5c
2.7 KiB
2.7 KiB
Workflows - Runtime Security with Tetragon
Deployment Workflow
Phase 1: Observation Mode
- Install Tetragon with default TracingPolicies (no enforcement)
- Collect baseline process execution data for 7-14 days
- Analyze event patterns to identify normal vs anomalous behavior
- Document expected processes per namespace and workload type
Phase 2: Detection Policies
- Create TracingPolicies for known attack patterns (container escape, privilege escalation)
- Configure event export to SIEM (Elasticsearch, Splunk, or Datadog)
- Build alerting rules based on TracingPolicy matches
- Validate detection accuracy with red team exercises
Phase 3: Enforcement
- Enable Sigkill actions for high-confidence threats (known malware binaries)
- Enable Override actions for dangerous syscalls in non-privileged containers
- Implement graduated response -- alert first, block after confirmation
- Monitor enforcement actions for false positives
TracingPolicy Development Workflow
1. Identify Threat -> Map to MITRE ATT&CK technique
2. Determine Kernel Hook -> kprobe, tracepoint, or LSM hook
3. Define Selectors -> Binary, namespace, capability filters
4. Set Action -> Post (observe), Sigkill (block), Override (deny)
5. Test in Staging -> Deploy to non-production namespace first
6. Validate with Attack Simulation -> Confirm detection
7. Deploy to Production -> Apply via GitOps
8. Monitor False Positives -> Tune selectors as needed
Incident Response Integration
When Tetragon Detects a Threat
- Event is generated with full context (pod, namespace, binary, args, capabilities)
- Event exported to SIEM via JSON log export or Prometheus metric
- SOAR platform receives alert and triggers playbook
- Automated actions: isolate pod network (via Cilium NetworkPolicy), capture forensic data
- Security team receives enriched alert with Kubernetes context
Forensic Data Collection
# Export recent events for a specific pod
tetra getevents --namespace <ns> --pod <pod-name> \
--since 1h -o json > /forensics/tetragon-events.json
# Get process tree for suspicious activity
tetra getevents --process-pid <pid> --ancestors 5 -o compact
Operational Runbook
Daily Checks
- Review
tetragon_missed_events_totalmetric for event buffer overflows - Check Tetragon DaemonSet health across all nodes
- Review new TracingPolicy match counts
Weekly Checks
- Analyze top 10 most frequent event types
- Review enforcement action logs for false positives
- Update TracingPolicies based on new threat intelligence
Monthly Checks
- Performance impact assessment (CPU/memory overhead per node)
- TracingPolicy effectiveness review with red team
- Update Tetragon to latest stable release