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.5 KiB
2.5 KiB
Workflows: AWS Verified Access ZTNA Configuration
Workflow 1: Initial Setup
Step 1: Create Verified Access Instance
- Deploy instance in target AWS region
- Tag with environment and ownership information
Step 2: Configure Trust Providers
- Set up identity trust provider (IAM Identity Center or OIDC)
- Set up device trust provider (CrowdStrike, Jamf, JumpCloud)
- Attach both providers to the Verified Access instance
Step 3: Create Access Groups
- Define groups based on application tiers or teams
- Write group-level Cedar policies
- Set baseline identity and device requirements
Step 4: Create Endpoints
- Map each application to a Verified Access endpoint
- Configure ALB or ENI attachment
- Set application domain and certificate
- Write endpoint-specific Cedar policies
Step 5: Configure DNS and Certificates
- Create ACM certificate for application domain
- Configure Route 53 CNAME to endpoint domain
- Validate certificate and DNS resolution
Workflow 2: Cedar Policy Development
Step 1: Define Access Requirements
- Map user groups to application access needs
- Define device compliance requirements
- Identify time-based or context-based restrictions
Step 2: Write and Test Policies
- Start with permit policies for known good access
- Add forbid policies for explicit denials
- Test with various identity and device contexts
- Validate in non-production environment
Step 3: Deploy Policies
- Apply group-level policies first
- Add endpoint-specific policies for sensitive apps
- Monitor access logs for false denials
- Iterate based on user feedback
Step 4: Ongoing Maintenance
- Review policies quarterly
- Update device trust thresholds
- Add new groups as teams change
- Remove deprecated application endpoints
Workflow 3: Multi-Account Deployment
Step 1: Design Architecture
- Deploy Verified Access in dedicated networking account
- Plan group sharing via AWS RAM
- Define organizational unit boundaries
Step 2: Share Resources
- Create RAM resource shares
- Associate Verified Access groups
- Share with target OUs or accounts
Step 3: Create Endpoints in Workload Accounts
- Accept RAM shares in workload accounts
- Create endpoints using shared groups
- Configure application-specific settings
Step 4: Centralized Monitoring
- Aggregate access logs to central S3 bucket
- Configure cross-account CloudWatch dashboards
- Set up centralized alerting for policy violations