Cybersecurity Architecture Design

The Cybersecurity Architecture Design requirement under C2M2 v2.1 ARCHITECTURE-1.A mandates that energy sector organizations establish a documented, maintained cybersecurity architecture encompassing both IT and OT environments. This goes beyond simple network diagrams—you need a comprehensive architectural framework that defines security zones, implements network segmentation, and establishes defense-in-depth controls.

For critical infrastructure operators, this requirement forms the foundation of your entire cybersecurity program. Without a well-designed architecture, other security controls become isolated point solutions rather than an integrated defense strategy. The requirement explicitly calls for both establishment AND maintenance, meaning a one-time design exercise won't suffice. You need ongoing processes to keep your architecture current as your infrastructure evolves.

Regulatory text

Per C2M2 v2.1 ARCHITECTURE-1.A: "Cybersecurity architecture of IT and OT assets is established and maintained, including network segmentation and security zones."

This requirement mandates that organizations create and sustain a formal cybersecurity architecture covering all technology assets. The architecture must explicitly define network segments and security zones with appropriate controls at each boundary. The "maintained" aspect requires ongoing updates as infrastructure changes occur.

Who This Applies To

This requirement applies to:

• Energy sector organizations implementing C2M2
• Critical infrastructure operators with mixed IT/OT environments
• Any organization pursuing C2M2 maturity level 1 (MIL1) or higher
• Electric utilities, oil & gas companies, renewable energy operators
• Organizations with industrial control systems or SCADA networks

The requirement covers both Information Technology (enterprise systems, business applications) and Operational Technology (control systems, field devices, industrial networks). If you operate any OT environment, this requirement demands special attention to IT/OT convergence risks.

What You Actually Need to Do

Step 1: Asset Inventory and Mapping

Create a comprehensive inventory of all IT and OT assets. Document:

• Physical and virtual servers
• Network devices (routers, switches, firewalls)
• End-user computing devices
• Industrial control systems and PLCs
• IoT devices and sensors
• Cloud resources and SaaS applications

Step 2: Define Security Zones

Establish logical security zones based on:

• Trust levels (untrusted internet, DMZ, trusted internal)
• Asset criticality (critical infrastructure, standard business systems)
• Data sensitivity (public, internal, confidential, restricted)
• Functional requirements (corporate IT, OT networks, development environments)

Common zone architecture for energy sector:

• Level 0: Physical process (field devices, sensors)
• Level 1: Basic control (PLCs, RTUs)
• Level 2: Supervisory control (SCADA, HMI)
• Level 3: Operations management (historians, MES)
• Level 3.5: DMZ between OT and IT
• Level 4: Business planning (ERP, business systems)
• Level 5: Enterprise network

Step 3: Implement Network Segmentation

Deploy actual network controls to enforce zone boundaries:

• Configure VLANs for logical separation
• Deploy firewalls between zones with explicit rule sets
• Implement jump servers for administrative access
• Use data diodes for one-way communication where appropriate
• Deploy network access control (NAC) for device authentication

Step 4: Document the Architecture

Create formal architecture documentation including:

• High-level architecture diagrams showing all zones
• Detailed network diagrams with IP addressing schemes
• Data flow diagrams showing communication paths
• Security control placement (where firewalls, IDS, etc. are deployed)
• Zone transition rules and permitted protocols

Step 5: Establish Maintenance Processes

Develop procedures to keep architecture current:

• Quarterly architecture review meetings
• Change control process for network modifications
• Annual architecture assessment against threats
• Update triggers (new systems, mergers, incidents)
• Version control for all architecture documents

Required Evidence and Artifacts

Maintain these documents for audit:

1. Architecture Design Document - Comprehensive description of security architecture including design principles, zone definitions, and control placement rationale

2. Network Diagrams - Current, accurate diagrams showing:

   • Physical network topology
   • Logical segmentation and VLANs
   • Firewall placement and rule sets
   • Remote access paths
   • Cloud connectivity

3. Zone Definitions - Document describing:

   • Purpose and criticality of each zone
   • Assets contained in each zone
   • Permitted communications between zones
   • Required security controls per zone

4. Maintenance Records - Evidence of ongoing maintenance:

   • Architecture review meeting minutes
   • Change requests and approvals
   • Update logs showing diagram revisions
   • Annual assessment reports

5. Implementation Evidence - Proof of actual implementation:

   • Firewall configurations
   • VLAN assignments
   • Access control lists
   • Network device configurations

Common Exam/Audit Questions and Hangups

Auditors typically focus on these areas:

"Show me your current network architecture diagram."

• Diagrams must be dated and version-controlled
• All major systems must be represented
• Security controls must be clearly marked

"How do you ensure your architecture stays current?"

• Point to formal review process with defined frequency
• Show evidence of recent updates
• Demonstrate change control integration

"Explain your OT/IT segmentation strategy."

• Clear DMZ or air gap between OT and IT
• Defined protocols allowed across boundary
• Jump server or secure remote access solution

"What happens when new systems are added?"

• Architecture review requirement in project process
• Security zone assignment criteria
• Network team involvement gates

"Show me your defense-in-depth implementation."

• Multiple control layers (network, host, application)
• Different control types (preventive, detective, corrective)
• No single point of failure

Common hangups:

• Outdated diagrams that don't reflect reality
• Missing OT networks from documentation
• No formal process for architecture updates
• Overly complex diagrams that obscure security boundaries
• Lack of version control on architecture documents

Frequent Implementation Mistakes

Mistake 1: Documentation Without Implementation

Creating beautiful architecture diagrams without actually implementing the segmentation. Your firewall rules must match your documented zones.

Fix: Validate documentation against actual configurations quarterly. Use automated tools to compare documented architecture against discovered network topology.

Mistake 2: Flat OT Networks

Keeping legacy flat networks in OT environments due to perceived operational constraints.

Fix: Implement incremental segmentation starting with IT/OT boundary. Use transparent firewalls that don't require IP address changes. Start with monitoring mode before enforcement.

Mistake 3: Ignoring Cloud and Remote Access

Focusing only on on-premise architecture while cloud usage expands organically.

Fix: Include cloud environments in architecture from day one. Document API connections, SaaS applications, and remote access paths. Treat cloud as additional zones requiring same rigor.

Mistake 4: Set-and-Forget Mentality

Treating architecture as a one-time project rather than living documentation.

Fix: Integrate architecture reviews into existing processes:

• Project intake requires architecture impact assessment
• Monthly infrastructure changes trigger diagram updates
• Incident response includes architecture review for gaps

Mistake 5: Over-Segmentation

Creating so many zones that operational efficiency suffers and exceptions proliferate.

Fix: Start with essential segmentation (IT/OT, trust levels) and expand based on risk. Each zone should have clear purpose and population. Consolidate where security requirements align.

Practical 30/60/90-Day Execution Plan

Immediate Actions (First 30 Days)

1. Week 1-2: Assemble architecture team including IT, OT, and security representatives
2. Week 2-3: Gather existing documentation (network diagrams, asset inventories, system documentation)
3. Week 3-4: Conduct gap analysis against C2M2 requirement
4. Week 4: Define project charter and resource requirements

Near-Term Goals (Days 31-60)

1. Week 5-6: Complete asset discovery for IT and OT environments
2. Week 6-7: Draft initial security zone definitions based on criticality and trust
3. Week 7-8: Create high-level architecture design with proposed segmentation
4. Week 8: Validate design with operations teams and adjust based on feedback

Ongoing Activities (Days 61-90)

1. Week 9-10: Develop detailed network diagrams and data flows
2. Week 10-11: Document implementation plan for missing controls
3. Week 11-12: Establish maintenance procedures and update cycles
4. Week 12: Conduct initial architecture review board meeting

Beyond 90 Days

• Implement identified segmentation gaps based on risk priority
• Integrate architecture maintenance into BAU processes
• Schedule first annual architecture assessment
• Train operations teams on architecture principles

Frequently Asked Questions

How detailed must our architecture documentation be for C2M2 compliance?

Documentation must be detailed enough to understand security boundaries, implement controls, and troubleshoot issues. Include network addresses, VLAN assignments, firewall rules between zones, and permitted protocols. Think "detailed enough for a new engineer to understand your security posture."

Can we use existing network diagrams or do we need C2M2-specific documentation?

Existing network diagrams can form the foundation, but you'll need to enhance them with security-specific elements: zone boundaries, trust levels, control points, and data flow directions. Standard network documentation rarely includes the security context C2M2 requires.

How do we handle legacy OT systems that can't support modern segmentation?

Implement compensating controls like unidirectional gateways, protocol-aware firewalls, or monitoring-only solutions. Document these systems as exceptions with risk acceptance and migration plans. The key is showing you understand the risk and have a strategy.

What's the difference between network segmentation and security zones?

Security zones are logical groupings based on trust and criticality (e.g., DMZ, internal network). Network segmentation is the technical implementation using VLANs, firewalls, and access controls. You need both: zones define the "why," segmentation implements the "how."

How often must we update our cybersecurity architecture?

C2M2 requires ongoing maintenance but doesn't specify frequency. Best practice is quarterly reviews with updates as needed, plus immediate updates for significant changes (new facilities, major systems, security incidents). Document your chosen frequency and follow it consistently.

Do cloud environments need separate architecture documentation?

Cloud environments must be included in your overall architecture, not documented separately. Show how cloud services integrate with your zones, what controls exist at cloud boundaries, and how data flows between cloud and on-premise systems. Treat cloud as an extension of your architecture, not an exception.