Arckit Mod Secure

Critical Changes (Post-August 2023)

SbD is now mandatory:

• Cyber security is a licence to operate - cannot be traded out
• Applies to ALL new programmes and systems
• Legacy systems transition when accreditation expires (by 31 March 2024 completed)
• Supplier-owned continuous assurance (not MOD accreditation)
• Suppliers must attest that systems are secure
• Senior Responsible Owners (SROs), capability owners, and delivery teams are accountable

Read the Template

Read the template (with user override support):

• First, check if .arckit/templates/mod-secure-by-design-template.md exists in the project root
• If found: Read the user's customized template (user override takes precedence)
• If not found: Read .arckit/templates/mod-secure-by-design-template.md (default)

Tip: Users can customize templates with $arckit-customize mod-secure

Your Task

Generate a comprehensive Secure by Design assessment document using the continuous risk management approach by:

1. Understanding the project context:

   • Programme/project/capability name
   • MOD organization (Army, Navy, RAF, Defence Digital, Strategic Command, etc.)
   • Data classification level (OFFICIAL, OFFICIAL-SENSITIVE, SECRET, TOP SECRET)
   • Project phase (Discovery, Alpha, Beta, Live, Through-Life)
   • Deployment environment (MOD network, cloud, operational theatre, coalition)
   • Delivery Team Security Lead appointed (Yes/No)
   • Project Security Officer (PSyO) appointed if SECRET+ (Yes/No)
   • Current SbD maturity level (self-assessment score)

2. Read Available Documents:

   Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

   MANDATORY (warn if missing):

   • REQ (Requirements) — Extract: NFR-SEC (security), NFR-A (availability), INT (integration), DR (data) requirements, data classification
     • If missing: warn user to run $arckit-requirements first
   • PRIN (Architecture Principles, in 000-global) — Extract: MOD security standards, approved platforms, classification handling, compliance requirements
     • If missing: warn user to run $arckit-principles first

   RECOMMENDED (read if available, note if missing):

   • RISK (Risk Register) — Extract: Security risks, threat model, risk appetite, mitigations, MOD-specific threats
   • SECD (Secure by Design) — Extract: NCSC CAF findings, Cyber Essentials status, existing security controls

   OPTIONAL (read if available, skip silently if missing):

   • DIAG (Architecture Diagrams, in diagrams/) — Extract: Deployment topology, network boundaries, data flows, trust zones
   • Previous SbD self-assessments (if available in project directory)

3. Assess against the 7 MOD Secure by Design Principles (ISN 2023/09):

   Principle 1: Understand and Define Context

   • Understand the capability's overall context
   • How it will use and manage MOD data
   • How it achieves its primary business/operational outcome
   • Assessment:
     • Context documented (mission, users, data flows)
     • Data classification determined
     • Operational environment understood
     • Stakeholder security requirements captured

   Principle 2: Apply Security from the Start

   • Security embedded in design from inception (not bolt-on)
   • Security requirements defined early
   • Security architecture designed before build
   • Assessment:
     • Security requirements in initial specifications
     • Threat model created in Discovery/Alpha
     • Security architecture reviewed and approved
     • Security expertise involved from start

   Principle 3: Apply Defence in Depth

   • Multiple layers of security controls
   • Fail-safe defaults (secure by default)
   • Assume breach (design for compromise)
   • Assessment:
     • Layered security controls (network, host, application, data)
     • Segmentation and least privilege implemented
     • Monitoring and detection at each layer
     • Containment and recovery capabilities

   Principle 4: Follow Secure Design Patterns

   • Use proven secure architectures
   • Leverage NCSC/NIST guidance
   • Avoid known insecure patterns
   • Assessment:
     • NCSC Secure Design Principles applied
     • NIST CSF controls mapped
     • Common vulnerabilities (OWASP Top 10) mitigated
     • Secure coding standards followed

   Principle 5: Continuously Manage Risk

   • Risk assessment is ongoing (not one-time)
   • Risk register maintained through-life
   • Security testing continuous
   • Assessment:
     • Risk register actively maintained
     • Regular vulnerability scanning and pen testing
     • Security incidents tracked and lessons learned
     • Continuous monitoring and threat intelligence

   Principle 6: Secure the Supply Chain

   • Third-party components assessed
   • Vendor security requirements in contracts
   • Software supply chain protected
   • Assessment:
     • Software Bill of Materials (SBOM) maintained
     • Third-party risk assessments completed
     • Supplier security attestations obtained (ISN 2023/10)
     • Open source software vetted
     • Supply chain attack vectors mitigated

   Principle 7: Enable Through-Life Assurance

   • Security posture maintained post-deployment
   • Regular security reviews
   • Capability to respond to new threats
   • Assessment:
     • Security monitoring operational
     • Incident response capability proven
     • Patching and update process defined
     • Security governance continues through-life
     • Decommissioning process includes secure data deletion

4. Read external documents and policies:

   • Read any external documents listed in the project context (external/ files) — extract CAAT assessment results, security clearance requirements, JSP 440 compliance status, IAMM maturity scores
   • Read any vendor security attestations in projects/{project-dir}/vendors/{vendor}/ — extract supplier security clearances, List X status, DEFCON compliance, SC/DV clearance evidence
   • Read any global policies listed in the project context (000-global/policies/) — extract MOD security standards, classification requirements, ITAR restrictions
   • Read any enterprise standards in projects/000-global/external/ — extract enterprise MOD security baselines, accreditation templates, cross-project security assurance evidence
   • If no external MOD security docs found, ask: "Do you have any JSP 440 compliance reports, CAAT assessment results, or supplier security attestations? I can read PDFs directly. Place them in projects/{project-dir}/external/ and re-run, or skip."
   • Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

5. Assess using NIST Cybersecurity Framework (as mandated by SbD):

   Identify:

   • Asset inventory (hardware, software, data, people)
   • Business environment and criticality
   • Governance structure and policies
   • Risk assessment methodology

   Protect:

   • Access control (authentication, authorisation)
   • Data security (encryption at rest/in transit, DLP)
   • Protective technology (firewalls, AV, IDS/IPS)
   • Security awareness training

   Detect:

   • Continuous monitoring (SIEM, SOC integration)
   • Anomaly and event detection
   • Security testing (vulnerability scanning, pen testing)
   • Detection processes and procedures

   Respond:

   • Incident response plan
   • Communications and reporting (to MOD CERT)
   • Analysis and mitigation
   • Improvements from lessons learned

   Recover:

   • Recovery planning (backup, DR, BC)
   • Improvements (post-incident review)
   • Communications and restoration

6. Assess Three Lines of Defence:

   First Line: Delivery team owns security

   • Delivery Team Security Lead appointed
   • Security requirements owned by capability owner
   • Day-to-day security management

   Second Line: Assurance and oversight

   • Technical Coherence Assurance
   • Security policies and standards
   • Independent security reviews

   Third Line: Independent audit

   • Internal audit of security controls
   • Penetration testing by independent teams
   • External audit (NAO, GIAA)

7. For each domain:

   • Assess status: ✅ Compliant / ⚠️ Partially Compliant / ❌ Non-Compliant
   • Gather evidence from project documents
   • Check relevant security controls
   • Identify critical gaps
   • Provide specific remediation actions with owners and timelines

8. Determine overall security posture:

   • Calculate domain compliance scores
   • Identify critical security issues (blockers for deployment)
   • Assess SbD maturity level using CAAT
   • Determine overall risk level (Low/Medium/High/Very High)

9. Generate actionable recommendations:

   • Critical priority (0-30 days) - must resolve before deployment
   • High priority (1-3 months) - significant risk reduction
   • Medium priority (3-6 months) - continuous improvement
   • Assign owners and due dates

CRITICAL - Auto-Populate Document Control Fields:

Before completing the document, populate ALL document control fields in the header:

Construct Document ID:

• Document ID: ARC-{PROJECT_ID}-SECD-MOD-v{VERSION} (e.g., ARC-001-SECD-MOD-v1.0)

Populate Required Fields:

Auto-populated fields (populate these automatically):

• [PROJECT_ID] → Extract from project path (e.g., "001" from "projects/001-project-name")
• [VERSION] → "1.0" (or increment if previous version exists)
• [DATE] / [YYYY-MM-DD] → Current date in YYYY-MM-DD format
• [DOCUMENT_TYPE_NAME] → "MOD Secure by Design Assessment"
• ARC-[PROJECT_ID]-SECD-MOD-v[VERSION] → Construct using format above
• [COMMAND] → "arckit.mod-secure"

User-provided fields (extract from project metadata or user input):

• [PROJECT_NAME] → Full project name from project metadata or user input
• [OWNER_NAME_AND_ROLE] → Document owner (prompt user if not in metadata)
• [CLASSIFICATION] → Default to "OFFICIAL" for UK Gov, "PUBLIC" otherwise (or prompt user)

Calculated fields:

• [YYYY-MM-DD] for Review Date → Current date + 30 days

Pending fields (leave as [PENDING] until manually updated):

• [REVIEWER_NAME] → [PENDING]
• [APPROVER_NAME] → [PENDING]
• [DISTRIBUTION_LIST] → Default to "Project Team, Architecture Team" or [PENDING]

Populate Revision History:

| 1.0 | {DATE} | ArcKit AI | Initial creation from `$arckit-mod-secure` command | [PENDING] | [PENDING] |

Populate Generation Metadata Footer:

The footer should be populated with:

**Generated by**: ArcKit `$arckit-mod-secure` command
**Generated on**: {DATE} {TIME} GMT
**ArcKit Version**: {ARCKIT_VERSION}
**Project**: {PROJECT_NAME} (Project {PROJECT_ID})
**AI Model**: [Use actual model name, e.g., "claude-sonnet-4-5-20250929"]
**Generation Context**: [Brief note about source documents used]

Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the SECD-MOD per-type checks pass. Fix any failures before proceeding.

10. Save the document: Write to projects/[project-folder]/ARC-{PROJECT_ID}-SECD-MOD-v1.0.md

Assessment Guidelines

Status Indicators

• ✅ Compliant: All security controls implemented and effective, no significant gaps
• ⚠️ Partially Compliant: Some controls in place but significant gaps remain
• ❌ Non-Compliant: Controls not implemented or ineffective, critical gaps exist

Critical Security Issues (Deployment Blockers)

Mark as CRITICAL if:

• Data classified SECRET or above without appropriate controls
• No encryption for data at rest or in transit
• Personnel lacking required security clearances
• No threat model or risk assessment
• Critical vulnerabilities unpatched
• No incident response capability
• No backup/recovery capability
• Non-compliance with JSP 440 mandatory controls

Classification-Specific Requirements

OFFICIAL:

• Cyber Essentials baseline
• Basic access controls and encryption
• Standard MOD security policies

OFFICIAL-SENSITIVE:

• Cyber Essentials Plus
• MFA required
• Enhanced logging and monitoring
• DPIA if processing personal data

SECRET:

• Security Cleared (SC) personnel minimum
• CESG-approved cryptography
• Air-gapped or assured network connectivity
• Enhanced physical security
• CAAT assessment and security governance review before deployment

TOP SECRET:

• Developed Vetting (DV) personnel
• Compartmented security
• Strictly controlled access
• Enhanced OPSEC measures

Project Phase Considerations

Discovery/Alpha:

• Initial threat model
• Classification determination
• Preliminary risk assessment
• Security architecture design
• CAAT registration and initial self-assessment
• Delivery Team Security Lead (DTSL) appointed

Beta:

• Comprehensive threat model
• Full risk assessment
• Security controls implemented
• Penetration testing completed
• CAAT self-assessment completed
• Security governance review

Live:

• All security controls operational
• CAAT continuously updated
• Continuous monitoring active
• Regular security reviews
• Incident response capability proven

MOD-Specific Context

JSP 440 Information Assurance Maturity Model (IAMM)

Assess maturity across 8 domains (0-5 scale):

• Level 0: Non-existent
• Level 1: Initial/Ad hoc
• Level 2: Repeatable
• Level 3: Defined
• Level 4: Managed
• Level 5: Optimized

Target Level 3+ for operational systems.

Continuous Assurance Process (Replaced RMADS in August 2023)

SbD replaces point-in-time accreditation with continuous assurance:

1. Register on CAAT (Cyber Activity and Assurance Tracker)

   • Every programme must register on CAAT in Discovery/Alpha
   • CAAT is the self-assessment tool for cyber security maturity
   • Available through MOD Secure by Design portal (DefenceGateway account required)

2. Appoint Delivery Team Security Lead (DTSL)

   • DTSL owns security for the delivery team (First Line of Defence)
   • May also appoint Security Assurance Coordinator (SAC)
   • Project Security Officer (PSyO) still required for SECRET+ systems

3. Complete CAAT self-assessment question sets

   • Based on the 7 MOD Secure by Design Principles
   • Assess cyber security maturity throughout lifecycle
   • Regular updates required (not one-time submission)

4. Complete Business Impact Assessment (BIA)

   • Understand criticality and impact of compromise
   • Informs risk assessment and security controls

5. Implement security controls

   • Based on NIST CSF, NCSC guidance, and JSP 440 requirements
   • Defence in depth approach
   • Continuous improvement throughout lifecycle

6. Conduct continuous security testing

   • Vulnerability scanning (regular, automated)
   • Penetration testing (at key milestones)
   • Security audits by Third Line of Defence

7. Maintain continuous risk management

   • Risk register actively maintained
   • Threats and vulnerabilities continuously monitored
   • Security incidents tracked and lessons learned applied

8. Supplier attestation (for systems delivered by suppliers)

   • Suppliers must attest that systems are secure (ISN 2023/10)
   • Supplier-owned continuous assurance (not MOD accreditation)
   • Supplier security requirements in contracts

9. Security governance reviews

   • Regular reviews by Second Line (Technical Coherence)
   • No single "accreditation approval" - ongoing assurance
   • SROs and capability owners accountable for security posture

Common MOD Security Requirements

Cryptography:

• CESG-approved algorithms (AES-256, SHA-256, RSA-2048+)
• Hardware Security Modules (HSMs) for key management
• FIPS 140-2 compliant modules

Network Security:

• Segmentation by security domain
• Firewalls at trust boundaries
• IDS/IPS for threat detection
• Air-gap for SECRET and above (or assured connectivity)

Authentication:

• Smart card (CAC/MOD Form 90) for OFFICIAL-SENSITIVE and above
• Multi-factor authentication (MFA) mandatory
• Privileged Access Management (PAM) for admin access

Monitoring:

• Integration with MOD Cyber Defence Operations
• 24/7 security monitoring
• SIEM with correlation rules
• Incident escalation to MOD CERT

Example Output Structure

# MOD Secure by Design Assessment

**Project**: MOD Personnel Management System
**Classification**: OFFICIAL-SENSITIVE
**Overall Security Posture**: Adequate (with gaps to address)

## Domain 1: Security Classification
**Status**: ✅ Compliant
**Evidence**: System handles personnel records (OFFICIAL-SENSITIVE), classification confirmed by IAO...

## Domain 5: Technical Security Controls

### 5.1 Cryptography
**Status**: ⚠️ Partially Compliant
**Evidence**: AES-256 encryption at rest, TLS 1.3 in transit, but key rotation not automated...
**Gaps**:
- Automated key rotation required (HIGH PRIORITY)
- HSM not yet deployed (MEDIUM PRIORITY)

### 5.3 Network Security
**Status**: ❌ Non-Compliant
**Evidence**: Network segmentation incomplete, no IDS/IPS deployed...
**Gaps**:
- Deploy network segmentation (CRITICAL - deployment blocker)
- Implement IDS/IPS (HIGH PRIORITY)

## Critical Issues
1. Network segmentation incomplete (Domain 5) - BLOCKER for deployment
2. Penetration test not completed (Domain 5) - Required before Beta

## Recommendations
**Critical** (0-30 days):
- Complete network segmentation - Security Architect - 30 days
- Schedule penetration test - DTSL - 15 days

Important Notes

• Continuous assurance is mandatory for MOD systems throughout their lifecycle (replaced point-in-time accreditation August 2023)

• CAAT registration required for all programmes from Discovery/Alpha phase

• Non-compliance can block project progression, funding, and deployment

• Delivery Team Security Lead (DTSL) engagement required from Discovery phase

• Regular security reviews required (quarterly during development, annually in Live)

• SROs and capability owners are accountable for security posture (not delegated to accreditation authority)

• Classification determines security control requirements

• Supplier attestation required for supplier-delivered systems (ISN 2023/10)

• Insider threat is a primary concern for MOD - emphasize personnel security

• Supply chain security critical due to foreign adversary threats

• Operational security (OPSEC) essential for operational systems

• Cyber security is a "licence to operate" - cannot be traded out or descoped

• Markdown escaping: When writing less-than or greater-than comparisons, always include a space after < or > (e.g., < 3 seconds, > 99.9% uptime) to prevent markdown renderers from interpreting them as HTML tags or emoji

Related MOD Standards

• JSP 440: Defence Information Assurance Policy
• JSP 441: Security Policy
• Defence Digital Security Strategy
• NCSC Cloud Security Principles
• HMG Security Policy Framework
• CESG Cryptographic Mechanisms

Resources

• MOD Secure by Design: https://www.digital.mod.uk/policy-rules-standards-and-guidance/secure-by-design
• MOD Secure by Design Portal: Requires DefenceGateway account for industry partners
• CAAT (Cyber Activity and Assurance Tracker): Self-assessment tool available through SbD portal
• JSP 440: https://www.gov.uk/government/publications/jsp-440-defence-information-assurance
• JSP 453 (Digital Policies): https://www.digital.mod.uk/policy-rules-standards-and-guidance
• ISN 2023/09: Industry Security Notice - Secure by Design Requirements
• ISN 2023/10: Industry Security Notice - Supplier attestation
• NCSC CAF: https://www.ncsc.gov.uk/collection/caf
• NCSC Secure Design Principles: https://www.ncsc.gov.uk/collection/cyber-security-design-principles
• Defence Digital: https://www.gov.uk/government/organisations/defence-digital

Generate the MOD Secure by Design assessment now based on the project information provided.