Annex A Controls

A.8.23 through A.8.25 — Network Segregation Cryptography and Secure Development

Alex Fuerst

26 Oct 2025 — 8 min read

Executive Summary
• Network segregation (A.8.21), cryptographic controls (A.8.24), and secure development (A.8.25) form an interconnected security architecture that must be designed holistically
• Effective web filtering requires SSL/TLS inspection and threat intelligence integration, not just blocking social media sites
• Cryptography succeeds or fails on key management practices — algorithm selection is less critical than key lifecycle controls
• These controls map directly to NIST CSF categories PR.AC (Access Control), PR.DS (Data Security), and PR.IP (Information Protection)

These three controls represent the architectural spine of mature information security programs. I've audited organizations that spent millions implementing each control in isolation, only to discover their expensive web filtering couldn't inspect encrypted traffic, their "enterprise-grade" encryption stored keys alongside encrypted data, and their secure development practices produced applications that ran in flat networks where lateral movement was trivial. The controls aren't independent checkboxes—they're interdependent components of a unified security architecture.

A.8.23 — Web Filtering: Threat Intelligence, Not HR Policy Enforcement

Most organizations implement web filtering as productivity theater. They proudly block Facebook and YouTube while allowing unfettered access to newly registered domains, uncategorized sites, and encrypted traffic that bypasses their entire filtering infrastructure. This fundamentally misunderstands the control's purpose.

Control A.8.23 requires managing access to external websites to reduce exposure to malicious content. The key threats this addresses include:

Drive-by downloads from compromised legitimate websites
Watering hole attacks targeting industry-specific resources
Command and control infrastructure using domain generation algorithms
Data exfiltration through cloud storage and file-sharing platforms
Phishing infrastructure leveraging newly registered domains
Cryptocurrency mining through malicious JavaScript execution

I recently audited a financial services firm with sophisticated web filtering technology configured purely for HR compliance. They blocked social media meticulously but had no controls for newly registered domains, allowed unrestricted access to cloud storage providers, and exempted their executive team from all filtering. Meanwhile, their threat intelligence showed active campaigns targeting their industry through compromised supplier websites that remained fully accessible.

Technical Implementation Requirements

Effective web filtering for ISO 27001:2022 compliance requires several technical capabilities that most organizations overlook:

SSL/TLS Inspection

Modern web traffic is approximately 80% encrypted. Web filtering that cannot inspect HTTPS traffic is security theater. Your implementation must include:

Certificate authority infrastructure for internal traffic inspection
Policy-based SSL inspection with appropriate privacy controls
Handling of certificate pinning and other anti-inspection techniques
Clear documentation of what traffic is inspected versus bypassed

Real-Time Threat Intelligence Integration

Static category-based filtering catches yesterday's threats. Effective filtering requires:

Integration with commercial and open-source threat intelligence feeds
Automatic blocking of newly identified malicious domains
Reputation-based scoring for uncategorized domains
Industry-specific threat intelligence relevant to your risk profile

Uncategorized Domain Handling

This is where most implementations fail. The only defensible position for uncategorized domains is block-by-default with explicit allow-listing for business requirements. Organizations that allow uncategorized domains by default are essentially running unfiltered internet access with extra steps.

Cross-Framework Mappings

Web filtering maps to several other frameworks you may be implementing simultaneously:

NIST Cybersecurity Framework: PR.AC-3 (Remote access), PR.DS-5 (Protections against data leaks)
CMMC 2.0: AC.L2-3.1.12 (Control information system use), SC.L2-3.13.1 (Boundary protection)
TISAX: Control questions around network security and data protection
SOC 2: CC6.1 (Logical access security measures), CC6.6 (Data transmission protection)

A.8.24 — Use of Cryptography: Beyond Algorithm Selection

When I ask organizations about their cryptographic controls, the response is predictable: "We use AES-256 encryption everywhere." This tells me almost nothing about their actual security posture. Algorithm selection is the least important aspect of cryptographic implementation—key management is everything.

Control A.8.24 requires established rules for effective cryptographic use, including cryptographic key management. The emphasis on effective is crucial. Encryption that can be trivially bypassed isn't effective, regardless of algorithm strength.

The Key Management Lifecycle

Cryptographic maturity is measured by key management practices, not algorithm choices. Your implementation must demonstrate control over the complete key lifecycle:

Key Generation

Entropy sources: Hardware random number generators or cryptographically secure pseudo-random number generators
Generation environment: Dedicated key management infrastructure, preferably Hardware Security Modules (HSMs)
Algorithm parameters: Appropriate key lengths, elliptic curve selections, and parameter validation
Documentation: Procedures for key generation, including roles, responsibilities, and technical specifications

Key Distribution and Storage

Secure channels: Keys transmitted through authenticated, encrypted channels separate from protected data
Storage separation: Keys stored separately from encrypted data, never co-located on the same systems
Access controls: Role-based access to key material with strong authentication requirements
Backup and recovery: Secure backup procedures that maintain confidentiality and integrity

Key Usage and Rotation

Usage logging: All cryptographic operations logged with appropriate detail for security monitoring
Rotation schedules: Defined rotation periods based on risk assessment and industry best practices
Cryptoperiod management: Clear policies on how long keys remain active for different use cases
Emergency procedures: Processes for emergency key replacement when compromise is suspected

Key Destruction

Secure deletion: Cryptographically secure wiping of key material from all storage locations
Verification: Confirmation that keys have been successfully destroyed and cannot be recovered
Documentation: Records of key destruction for compliance and audit purposes

Common Implementation Failures

I've encountered several patterns of cryptographic failure that demonstrate compliant-on-paper implementations with zero security value:

The Healthcare Co-Location Disaster

A healthcare organization implemented full database encryption using AES-256, storing encryption keys in configuration files on the database server. Anyone who compromised the server had immediate access to both encrypted data and decryption keys. Their compliance audit showed "encryption at rest implemented" while providing no actual protection.

The Manufacturing Key Escrow Confusion

A manufacturing company implemented encryption for intellectual property protection but stored all encryption keys in a shared network drive "for backup purposes." The keys were more accessible than the original unencrypted data.

The Financial Services Rotation Theater

A financial services firm had detailed key rotation procedures that generated new keys monthly but never actually retired old keys. After three years, they had 36 valid encryption keys for the same data, making key compromise recovery impossible.

Network Segregation Integration

Cryptographic infrastructure should reside in dedicated network segments with enhanced monitoring and access controls. Key management systems represent high-value targets and should be protected accordingly:

Dedicated network segments for HSMs and key management infrastructure
Encrypted channels for all key management traffic with mutual authentication
Network-level monitoring for cryptographic operations and key access
Segregated backup networks for cryptographic material recovery

A.8.25 — Secure Development: Architecture Before Code

Secure development lifecycle implementation typically focuses on developer training and code scanning tools. While important, this misses the architectural foundations that determine whether secure code can actually provide security value. The most secure application is worthless if deployed in an environment where attackers can bypass it entirely.

Control A.8.25 requires established and applied rules for secure development of software and systems. Note "systems"—this isn't just about application code but the entire ecosystem where applications operate.

Foundational Requirements

Environment Segregation (Reference to A.8.31)

Development, testing, and production environments must be appropriately segregated to prevent development artifacts from reaching production and production data from contaminating development environments. This requires:

Network-level segregation between development, staging, and production networks
Separate credential stores and authentication systems for each environment
Data masking and anonymization for non-production environments
Promotion procedures that maintain segregation while enabling deployments

Security in Development Methodology

Security considerations must be integrated throughout the development lifecycle, not bolted on at the end:

Requirements phase: Security requirements defined alongside functional requirements
Design phase: Threat modeling and security architecture review
Implementation phase: Secure coding standards and peer review processes
Testing phase: Security testing including static analysis, dynamic analysis, and penetration testing
Deployment phase: Security configuration validation and runtime protection

Secure Coding Guidelines

Language-specific secure coding standards that address common vulnerability classes:

Input validation and output encoding procedures
Authentication and session management requirements
Cryptographic implementation standards
Error handling and logging specifications
Third-party component management and vulnerability tracking

Cross-Standard Integration Patterns

Secure development integrates with multiple other ISO 27001 controls and external frameworks:

ISO 27001 Internal Dependencies

A.5.8 (Information security in project management): Security checkpoints throughout development projects
A.8.27 (Secure system architecture): Architectural security principles applied to application design
A.8.29 (Security testing): Testing procedures integrated into development workflows
A.8.31 (Separation of environments): Infrastructure supporting secure development practices

External Framework Alignment

NIST Secure Software Development Framework (SSDF): Direct alignment with practices PO, PS, PW, and RV
OWASP SAMM (Software Assurance Maturity Model): Maturity assessment and improvement roadmap
BSIMM (Building Security In Maturity Model): Benchmarking against industry practices
CMMC AC.L2-3.1.13, SC.L2-3.13.11: Application security and secure development requirements

The Network Segregation Connection

Secure development without proper network boundaries is security theater. Applications may be developed securely but deployed in environments where network-level attacks bypass application security entirely:

Lateral movement prevention: Network segments limit blast radius when applications are compromised
Data flow controls: Network-level enforcement of data flow policies between application tiers
Monitoring and detection: Network monitoring provides visibility into application behavior and potential compromise
Cryptographic enforcement: Network-level encryption ensures secure communication between application components

Common Audit Findings

After conducting dozens of ISO 27001 audits focusing on these controls, several patterns emerge consistently:

Web Filtering Findings

Policy misalignment: Web filtering policies focused on productivity rather than security threats
SSL bypass: Encrypted traffic exempted from filtering, creating massive security gaps
Uncategorized handling: Allow-by-default policies for uncategorized domains
Executive exemptions: Senior management exempted from filtering policies
Monitoring gaps: Web filtering logs not integrated into security monitoring programs

Cryptography Findings

Key co-location: Encryption keys stored with encrypted data
Rotation theater: Key rotation procedures that don't actually retire old keys
Access controls: Weak or nonexistent access controls on cryptographic material
Backup vulnerabilities: Cryptographic material exposed in backup systems
Algorithm obsession: Focus on algorithm selection while ignoring implementation vulnerabilities

Secure Development Findings

Environment bleeding: Production data in development environments
Security as afterthought: Security testing only at final stages of development
Training gaps: Developer security training focused on generic topics rather than language-specific vulnerabilities
Third-party risks: No processes for managing security vulnerabilities in third-party components
Network dependency: Secure applications deployed in insecure network environments

Implementation Roadmap for Integrated Controls

Phase 1: Foundation (Months 1-3)

Network topology documentation and risk assessment
Cryptographic inventory and key management gap analysis
Development environment audit and segregation planning
Web filtering baseline assessment and threat intelligence integration planning

Phase 2: Technical Implementation (Months 4-9)

Network segregation implementation with monitoring capabilities
Key management infrastructure deployment (HSM or equivalent)
SSL inspection deployment with appropriate privacy controls
Development environment segregation and security integration

Phase 3: Process Integration (Months 10-12)

Security operations integration across all three control areas
Incident response procedures incorporating network, cryptographic, and application security
Continuous monitoring and improvement processes
Cross-framework compliance verification and gap remediation

Measuring Success

Success metrics for these integrated controls should focus on risk reduction rather than compliance checkboxes:

Quantitative Metrics

Web filtering effectiveness: Percentage of malicious domains blocked before user access
Cryptographic coverage: Percentage of sensitive data protected by properly managed encryption
Development security: Reduction in security vulnerabilities discovered post-deployment
Network containment: Reduction in lateral movement during security incidents

Qualitative Indicators

Incident response time improvements due to network monitoring
Reduced false positives in security monitoring due to proper baseline establishment
Developer confidence in security processes without productivity impact
Stakeholder confidence in data protection capabilities

These three controls represent more than technical implementations—they're organizational capabilities that demonstrate security maturity. Organizations that implement them as interconnected components create defensible security architectures. Those that treat them as isolated checkboxes create expensive security theater that provides minimal protection against determined adversaries.

The key to success lies in recognizing these controls as architectural decisions that must be made holistically, with clear understanding of how network boundaries, cryptographic protection, and application security work together to create layered defense. Master this integration, and you've built the foundation for a genuinely resilient information security program.

Book a consultation to discuss your specific implementation challenges or explore our related deep-dive articles on network security architecture, cryptographic control implementation, and secure development lifecycle management.

💬 Got ISO 27001 Questions?

Our AI-powered ISO 27001 expert is available 24/7 in 12 languages. Get instant, accurate answers about implementation, controls, audits, and certification.

→ Talk to the ISO 27001 Info Hub Bot on Telegram

→ Contact our team: ix@isegrim-x.com