Penetration Testing Documentation

Purpose

This document describes Cirius Group's three-layer penetration testing programme — scope, tools, schedule, operational parameters, and how to interpret results. The programme satisfies HIPAA §164.308(a)(8) (periodic technical security evaluation) and SOC2 CC7.1/CC7.2 (vulnerability detection and management).

For results and monthly evidence log: compliance/pentest-results-log.md.

---

Programme Overview

Layer	Name	Cadence	Scope	Perspective
1	Vonahi vPenTest	Monthly	Internal — PROD (10.20.0.0/16) + Identity (10.10.0.0/16)	Inside the network
2	attack-teams purple team	Weekly	External recon + Azure config audit + detection validation	Attacker + blue team
3	bedrock-soc external surface scan	Monthly	All public-facing domains + AWS ELBs	External internet

Together these three layers cover internal exploitation paths, continuous external surface monitoring, Azure misconfiguration, detection coverage validation, and external vulnerability scanning from an attacker's perspective.

---

Layer 1 — Vonahi vPenTest (Monthly Internal Scan)

Product: Vonahi vPenTest SaaS (app.vpentest.io) — commercial automated penetration testing appliance.

Infrastructure: Ubuntu 22.04 VM deployed in Azure hub VNet (snet-vpentest 10.99.8.0/24, firewall subscription). Terraform: azure-infra/firewall/svr_vpentest.tf. Also deployed in AWS: aws-infra/firewall/svr_vpentest.tf.

Network reach:

• 10.20.0.0/16 (PROD) via PrivateFW untrust hairpin
• 10.10.0.0/16 (Identity) via PrivateFW untrust hairpin
• Internet egress via public Palo Alto NVA

Cadence: Monthly automated scans triggered from the vpentest.io console.

What It Scans

vPenTest runs a comprehensive internal network penetration test from inside the network, mimicking a threat actor who has already gained internal access. Coverage includes:

• Active Directory attack surface (Kerberoasting candidates, AS-REP roasting, unconstrained delegation)
• SMB vulnerabilities and exposed shares
• Windows hosts — missing patches, exposed services, credential hygiene issues
• Internal web services accessible from the production subnet
• Network-level vulnerabilities reachable from the scanner's position

Evidence and Reporting

Reports are available in the vpentest.io portal. Download PDF exports for each monthly scan. These PDFs are the primary Layer 1 evidence artifact for SOC2 fieldwork.

Operational Notes

• Palo Alto SSL decryption: A no-decrypt rule for *.vpentest.io is required on the Azure Palo Alto (Panorama) to prevent TLS decryption breaking the agent's connection to the vpentest.io SaaS.
• KV access: Agent UUID is stored out-of-band in cirius-fw-keyvault. The subnet has a KeyVault service endpoint for boot-time secret read.

---

Layer 2 — attack-teams Autonomous Purple Team (Weekly)

Repo: bedrock-attack | Live UI: attack.bedrockcybersecurity.org | Authorization: bedrock-attack/AUTHORIZATION.md (signed Rory Garshol 2026-04-20, expires 2027-04-20)

Cadence: Every Monday 06:00 UTC via campaign-runner.yml GitHub Actions workflow.

Agent Architecture

Five cooperating agents run sequentially in ECS Fargate (AWS Prod account 807267566999, us-west-2):

Agent	Role	What It Does
REDTEAM_BLACK	External black-box attacker	DNS enumeration, TLS inspection, subdomain discovery, public threat intel, GitHub supply-chain checks — no internal credentials
REDTEAM_GREY	Insider-threat / misconfiguration auditor	Read-only Azure queries via sp-purple-auditor service principal — misconfiguration, role assignments, NSG auditing, storage policy
BLUETEAM	Detection validator	After each Red campaign, checks whether Red activity triggered alerts in LAW, Cortex XDR, and Arctic Wolf. Produces detection_gap findings for undetected actions
PURPLE_TEAM	Correlation	Synthesizes Black + Grey + Blue findings into unified attack-path gap reports
REMEDIATION	Automation	Creates/updates/deduplicates stories in SecOps; sends campaign summary emails

Campaign pipeline: checkin → grey → blueteam-grey → black → blueteam-black → referee → remediation

Scope Constraints (Non-Negotiable)

Scope is defined in SCOPE.yaml at the bedrock-attack repo root. Constraints enforced in both code and SCOPE.yaml:

• No exploitation — the system identifies vulnerabilities, it does not exploit them
• No credential use — a found credential is a finding to report, not to authenticate with
• No PHI or PII access — agents operate on configuration metadata and public surface data only
• No brute force, credential stuffing, or availability impact
• Rate limits enforced on all external activity
• Kill switch and check-in timer always active

Evidence

Campaign history: attack.bedrockcybersecurity.org → Campaigns tab. Correlated findings: SecOps → Purple Team project (epic a1f62f95). Campaign summary emails: sent to Rory after each weekly run.

---

Layer 3 — bedrock-soc External Surface Scan (Monthly)

Repo: Bedrock-Cybersecurity/bedrock-soc | Workflow: .github/workflows/monthly-pentest.yml

Cadence: Cron 1st of each month, 06:00 UTC. First run: 2026-07-01.

Perspective: External internet — no internal network access, no credentials. Pure attacker-perspective external assessment.

Endpoints in Scope

• ciriusgroup.com, soc.bedrockcybersecurity.org, grc.bedrockcybersecurity.org, dashboard.ciriusgroup.com, hub.ciriusgroup.com
• ciriusdde.com, dashboard.ciriusdde.com
• AWS internet-facing ELBs auto-discovered at run time via AWS API

Pipeline Architecture

GitHub Actions (cron: monthly, 06:00 UTC 1st of month)
         │
         ├── Pre-scan notification email via ACS
         │
         ├── AWS endpoint discovery (public ELBs via AWS API — OIDC auth)
         │
         ├── Nmap — port scan all in-scope endpoints
         │
         └── Nuclei — template-based vulnerability scan
                    │
              Findings emailed via ACS to roryg@ciriusgroup.com
              HIGH/CRITICAL findings posted to SecOps
              Raw files stored as GitHub Actions artifacts (365-day retention)

No IP whitelisting — mirrors real attacker perspective. A pre-scan notification email provides context so Arctic Wolf alerts from the scan can be recognized rather than escalated as a real incident.

Tools

Nuclei (ProjectDiscovery) — template-based scanner covering CVEs, OWASP Top 10, misconfigurations (exposed admin panels, default credentials, directory listings), security headers, SSL/TLS issues. 7,000+ community templates.

Nmap — port discovery: open ports beyond expected services, unexpected service exposure, service version detection.

Retrieving Evidence

# List recent runs
gh run list --repo Bedrock-Cybersecurity/bedrock-soc --workflow "monthly-pentest.yml" --limit 24

# Download artifacts from a specific run
gh run download <run-id> --repo Bedrock-Cybersecurity/bedrock-soc --dir ./pentest-artifacts/

Artifacts (nmap-results.xml, nuclei-results.jsonl, summary.json) retained 365 days.

Interpreting Results

Nuclei Severity	Response SLA
Critical	Same day
High	Within 1 week
Medium	Within 1 month
Low / Informational	Next review cycle

Nmap unexpected open ports: identify the service, determine if intentional (document if so), or close via NSG/security group rule and confirm resolved on rescan.

False positives: document template ID and reasoning in compliance/pentest-results-log.md Layer 3 false positive log. Do not suppress without confirming.

---

Compliance Relevance

Requirement	How the Programme Addresses It
HIPAA §164.308(a)(1)(i) — Risk analysis	All three layers identify risks across internal, configuration, and external surfaces
HIPAA §164.308(a)(8) — Periodic evaluation	Monthly internal (Layer 1), weekly external/config (Layer 2), monthly external surface (Layer 3)
SOC2 CC7.1 — Vulnerability detection	Automated scanning across all attack surfaces, weekly–monthly cadence
SOC2 CC7.2 — Vulnerability management	Findings written to SecOps, tracked to resolution, 365-day artifact retention

---

Monthly Canary Verification Checklist

As part of each monthly Layer 3 scan cycle, verify the deception layer is operational. This is separate from the scan — it confirms internal tripwires are in place.

Canary verification steps (run before or after monthly Layer 3 scan):

• [ ] Check SecOps: no open CRITICAL incidents with source_agents=["canary_agent"] from last 30 days
  • If incidents exist — investigate before continuing; do not dismiss
• [ ] Verify canary_agent ran in the last orchestrator cycle (check job-orchestrator-cirius in Azure Portal)
• [ ] Confirm all canaries in security/canary-token-inventory.md show status "ACTIVE"
• [ ] Manually verify at least one canary token via canarytokens.org management dashboard (confirm not expired)
• [ ] Confirm CANARY_WEBHOOK_SECRET KV secret is still present in cirius-openai-kv-prod
• [ ] Test webhook endpoint: curl -s -o /dev/null -w "%{http_code}" -X POST "https://soc.bedrockcybersecurity.org/webhooks/canary?secret=wrong-secret" should return 401
• [ ] Update "Last verified" dates in security/canary-token-inventory.md after verification

Why: Attackers who discover canaries may delete them to remove tripwires. Monthly verification confirms the deception layer remains intact. A missing canary file is itself a CRITICAL indicator.

---

Related Documentation

• Pentest Results Log — monthly evidence log for all three layers
• bedrock-attack/AUTHORIZATION.md — signed authorization for Layer 2 (separate repo)
• Vulnerability Management
• HIPAA Controls Matrix
• Canary Token Inventory

---

Document History

Date	Change	Author
March 2026	Initial draft — Layer 3 external surface scan operational	Rory
April 2026	Added monthly canary verification checklist (DECP-007)	Kobe
June 2026	Rewritten to document full three-layer programme: Layer 1 Vonahi vPenTest (monthly internal), Layer 2 attack-teams purple team (weekly, authorized 2026-04-20), Layer 3 bedrock-soc external scan (monthly). ops-automation references removed (archived June 2026).	Kobe