Claude Sonnet 4.6
dc83336567
New: assessment-templates/assessment-team-guide.md Pre-engagement: access checklist (M365, AD, docs); tool preparation with deployment times; what to do if access is not ready. Day 1 discipline: deploy ASTRAL and PULSAR before workshops start. Step-by-step ASTRAL and PULSAR deployment commands. Passive external scan in background. Microsoft Secure Score baseline. Workshop signals: table of client statements -> likely findings -> what to check on Day 2. Feeds technical assessment planning. Day 2-3 tool runs in sequence: 1. CAExporter (30 min) - CA policy reality check; report-only mode; exclusion groups defeating the purpose 2. BloodHound (1-2h) - 5 required queries; KRBTGT last set check; Domain Admins on workstations; service account attack paths 3. Elysium (2-4h) - privilege requirements noted; privacy model explanation; what to document 4. Purple Knight (30 min) - indicators to focus on; cross-reference with BloodHound 5. Entra ID manual checks (1h) - app registrations, guest accounts, MFA registration status, AD Connect sync account 6. Intune/endpoint check (30 min) - via ASTRAL output 7. External attack surface (30-60 min) - Nmap, Shodan, crt.sh 8. Firewall rule review (30-60 min) - what to look for 9. Backup spot check (30 min) - the 'green tick' test Kill chain synthesis: explicit step-by-step method for tracing from outside to organisational failure. Finding triage: kill chain test table; common priority inflation mistakes. Quick wins: 8-item checklist; three tests a quick win must pass. Report structure: 5 sections, target 15-25 pages, specific guidance per section including what makes a weak vs strong finding. ASERAL/PULSAR handover requirements before leaving site. 9 common assessment mistakes named explicitly. Post-assessment checklist: 10 items before submitting the report. index.md and assessment-templates/README.md updated. Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>
92 lines
4.1 KiB
Markdown
92 lines
4.1 KiB
Markdown
# Assessment Templates
|
|
|
|
> *"What gets measured gets managed. What gets managed honestly becomes antifragile."*
|
|
|
|
This directory contains diagnostic tools, maturity models, and assessment resources for evaluating organizational antifragility.
|
|
|
|
## Production-Ready Templates
|
|
|
|
| Template | Purpose |
|
|
|----------|---------|
|
|
| [Assessment Team Guide](assessment-team-guide.md) | Technical execution guide for the Brownhat Diagnostic: tool sequence (ASTRAL, PULSAR, BloodHound, Elysium, Purple Knight, CAExporter), what to look for, kill chain synthesis, report structure, common mistakes. |
|
|
| [Findings Backlog](findings-backlog.md) | Single source of truth for all findings across every module and diagnostic. The input queue for the housekeeping stream. Pragmatic alternative to a formal risk register for organisations that do not have one. |
|
|
| [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md) | The Brownhat Diagnostic: structured 2-half-day workshop, gap analysis, kill chain identification |
|
|
| [Module Completion Report](module-completion-report.md) | Completion package template for every module; includes backlog update |
|
|
| [Antifragile Risk Register](antifragile-risk-register.md) | Formal risk register template; the backlog feeds into this for organisations with mature risk management |
|
|
| [Risk Register Example](risk-register-example.md) | 8 fully populated entries from a realistic engagement — calibration reference |
|
|
| [M365 Project Risk Register](m365-project-risk-register.md) | M365-specific risk register with phase gates |
|
|
|
|
## Planned Assessments
|
|
|
|
### 1. Antifragile Maturity Model (AF-MM)
|
|
|
|
A five-level maturity model covering:
|
|
|
|
- **Level 1: Fragile** — Reactive, undocumented, dependent on single vendors
|
|
- **Level 2: Robust** — Documented, monitored, but static
|
|
- **Level 3: Resilient** — Automated recovery, tested backups, incident response operational
|
|
- **Level 4: Adaptive** — Chaos engineering, continuous learning, structural improvement from failure
|
|
- **Level 5: Antifragile** — Volatility is exploited for gain, optionality is strategic, intelligence is sovereign
|
|
|
|
### 2. AI Sovereignty Readiness Assessment
|
|
|
|
Evaluates:
|
|
|
|
- Current AI usage inventory completeness
|
|
- Data classification and leakage risk
|
|
- Local infrastructure readiness
|
|
- Vendor dependency and exit feasibility
|
|
- Regulatory compliance posture
|
|
|
|
### 3. T0 Asset Discovery Scanner
|
|
|
|
Planned scripted assessment to:
|
|
|
|
- Enumerate critical assets across on-premises and cloud environments
|
|
- Classify assets by tier based on dependency mapping
|
|
- Identify gaps in protection, monitoring, and recovery
|
|
- Generate prioritized remediation roadmap
|
|
|
|
### 4. Dependency Risk Mapper
|
|
|
|
Planned tool to:
|
|
|
|
- Map vendor and technology dependencies
|
|
- Calculate coupling depth and exit difficulty
|
|
- Identify hidden single points of failure
|
|
- Simulate failure cascades
|
|
|
|
### 5. Incident Learning Index
|
|
|
|
Measures the organization's ability to convert incidents into structural improvements:
|
|
|
|
- Mean time to structural fix
|
|
- Post-mortem completion rate
|
|
- Structural changes implemented per incident
|
|
- Repeat incident rate
|
|
|
|
## Development Roadmap
|
|
|
|
Phases are sequenced by client impact, not calendar quarter. Dates are assigned at the start of each development cycle.
|
|
|
|
| Phase | Deliverable | Format | Status |
|
|
|-------|-------------|--------|--------|
|
|
| 1 | AF-MM v1.0 — Antifragile Maturity Model questionnaire and scoring guide | Markdown + spreadsheet | Planned |
|
|
| 2 | AI Sovereignty Readiness Assessment v1.0 | Interactive web form or CLI tool | Planned |
|
|
| 3 | T0 Asset Discovery Scanner v0.1 — cloud APIs + on-premises enumeration | Python script | Planned |
|
|
| 4 | Dependency Risk Mapper v0.1 — vendor coupling depth and failure cascade simulation | Python + network analysis | Planned |
|
|
|
|
## Contributing
|
|
|
|
When adding new assessments:
|
|
|
|
1. Document the purpose, methodology, and limitations
|
|
2. Include scoring rubrics with clear criteria
|
|
3. Provide sample outputs and interpretation guidance
|
|
4. Version assessments and maintain changelogs
|
|
5. Test on at least two different organizational profiles before release
|
|
|
|
---
|
|
|
|
*Return to [Repository Index](../README.md)*
|