Penetration Testing Best Practices for Critical Infrastructure

Start With Governance, Scope, and Clear Objectives

Effective and safe testing begins long before any packets are sent or payloads are launched. The most important work happens in planning.

Define Objectives Clearly

Be explicit about what the test is trying to achieve, for example:

• Evaluate external exposure of control centers and remote sites.
• Assess how an attacker could move from corporate IT into OT networks.
• Validate effectiveness of network segmentation and access controls.
• Test incident detection and response processes.

Objectives should drive everything else: scope, tools, rules of engagement, and reporting depth.

Scope Only What You Can Safely Test

For critical infrastructure, scoping requires more nuance than “test everything.” Consider:

• In-scope assets: management interfaces, jump hosts, remote access gateways, engineering workstations, corporate systems connected to OT.
• Conditionally in-scope: live PLCs, RTUs, HMIs, safety systems — often only for passive or lab-replicated testing.
• Out-of-scope: systems where any disruption could directly endanger safety or critical service continuity unless a high-fidelity replica is available.

Obtain Executive Sponsorship and Legal Authorization

For critical infrastructure, it is essential to have:

• Formal written authorization (rules of engagement, statement of work, legal approvals).
• Buy-in from leadership, operations, safety, and legal/compliance stakeholders.
• A defined authority who can pause or stop testing immediately if unexpected issues arise.

Set Strict Rules of Engagement (RoE) to Protect Operations

Rules of Engagement define what is allowed, what is off-limits, and how testers behave when things go wrong. In critical infrastructure, RoE are non-negotiable.

Key Elements of Safe Rules of Engagement

• Time windows: Perform intrusive testing only during agreed maintenance windows or low-demand periods.
• Prohibited actions: Disallow denial-of-service attacks, fuzzing on live control systems, or payloads that can affect real-world processes.
• Rate limiting: Limit scan speed, login attempts, and traffic volume to avoid overloading fragile systems.
• Change freezes: Avoid testing during critical operational events or major configuration changes.
• Emergency stop: Define a “stop test” keyword or signal that anyone (tester or operator) can use to immediately halt all activities.

Coordinate With Operations and Safety Teams

Testing cannot be done in a vacuum. Operations staff should:

• Know exactly when and where testing will occur.
• Monitor systems during test windows for anomalies.
• Have clear contact paths to the testing team.
• Be prepared to roll back or fail over if needed.

Use the Right Environment: Production vs. Lab vs. Hybrid

One of the biggest safety decisions is where to test. In critical infrastructure, the best practice is a layered approach.

1. High-Fidelity Lab or Testbed

Ideally, create a lab environment that mirrors the production network and devices:

• Same PLCs, RTUs, HMIs, and firmware versions.
• Similar network segments and routing rules.
• Representative data flows and simulated process values.

Intrusive testing (fuzzing, exploit trials, protocol manipulation) should be performed here first to understand system behavior without risk to real operations.

2. Carefully Limited Production Testing

In many cases some degree of production testing is still necessary to validate exposures and real-world attack paths. To keep this safe:

• Focus on perimeter and IT-facing systems (VPNs, firewalls, remote access portals).
• Use gentle, low-rate scanning for discovery.
• Validate exploits in the lab first, then replicate only low-risk steps in production.
• Avoid direct exploit attempts on live safety systems or critical controllers.

3. Segmentation and Data Diodes

Where possible, use segmentation and one-way gateways to limit blast radius. Pen tests should actively validate:

• That OT networks are genuinely segmented from IT networks.
• That jumping from IT to OT requires multiple, controlled steps.
• That remote access paths (VPN, jump hosts, vendor access) enforce strong authentication and logging.

Build a Methodology Tailored for OT and ICS

While standard penetration testing frameworks are useful, critical infrastructure requires additional OT-specific considerations.

Discovery and Asset Identification

• Use passive discovery where possible (SPAN ports, network taps, log analysis).
• When active scanning is necessary, use ICS-aware tools with conservative settings and whitelisting.
• Map critical paths: from external entry points to control centers and field sites.

Threat Modeling and Attack Path Analysis

Before launching attacks, understand how a real adversary would target the environment:

• Identify high-value targets: control rooms, gateways, engineering workstations.
• Analyze how compromise of IT systems could pivot into OT (phishing, VPN abuse, stolen credentials).
• Document realistic attacker goals: disruption, unauthorized control, data manipulation, or stealthy persistence.

Exploitation With Safety Controls

Exploitation in critical infrastructure should be performed with strict guardrails:

• Validate exploits against lab systems first to observe impact on services, CPU load, and stability.
• Use non-destructive payloads that demonstrate control (e.g., reading parameters) rather than altering live process values.
• Avoid rapid automated attack frameworks on sensitive assets; prefer manual, stepwise testing.
• Maintain real-time communication with operators during any high-risk action.

Privilege Escalation and Lateral Movement

When exploring lateral movement:

• Focus on credential theft, misconfigurations, and weak access boundaries.
• Demonstrate potential impact using screenshots, read-only access, and proof-of-concept commands, rather than fully executing dangerous sequences.
• Log every step, making it easy to replay, explain, or roll back if required.

Monitor Safety and Performance Throughout the Test

Continuous monitoring is critical to ensure that testing does not unintentionally destabilize operations.

• System monitoring: Track CPU, memory, network throughput, and error logs on critical devices during testing.
• Process monitoring: For industrial systems, keep an eye on process variables, alarms, and trends.
• Incident channel: Maintain a dedicated channel (phone bridge, chat room) between testers and operators.
• Rollback procedures: Have tested, documented rollback and failover plans ready before you start.

Handle Sensitive Data and Findings Responsibly

Penetration tests against critical infrastructure often expose highly sensitive information: credentials, network diagrams, engineering configurations, and safety-relevant logic.

• Store test data securely, with encryption and strict access controls for logs, captures, screenshots, and exploit code.
• Minimize retention: keep only what you need to support the report and remediation work.
• Use clear classification labels (e.g., confidential, restricted) on all deliverables.
• Avoid including exploit code in reports; instead, describe techniques, impact, and remediation.

The goal is to improve security, not to create new risks through the testing artifacts themselves.

Reporting and Remediation: Focus on Risk and Practical Fixes

A penetration test is only valuable if the findings lead to meaningful improvements. For critical infrastructure, reporting should be:

• Risk-based: Emphasize operational impact, safety implications, and likelihood of real-world exploitation.
• Layered: Provide executive summaries, technical detail for engineers, and actionable steps for operations teams.
• Prioritized: Clearly distinguish between critical, high, medium, and low issues, with timelines for remediation.
• Context-aware: Reflect regulatory requirements and industry standards relevant to the infrastructure.

Where possible, link findings to specific mitigations such as improved segmentation, hardening of remote access, enhanced monitoring, or changes to vendor and maintenance practices.

Make Testing Part of a Continuous Security Program

One-off penetration tests are not enough for critical infrastructure. Best practice is to build a repeatable, evolving program:

• Schedule regular testing cycles aligned with major system upgrades or redesigns.
• Integrate pen test findings into vulnerability management, change management, and training programs.
• Combine penetration testing with other activities: architecture reviews, tabletop exercises, red-teaming, and incident response drills.
• Use lessons learned to refine your rules of engagement, lab environments, and monitoring strategies over time.

Conclusion

Penetration testing for critical infrastructure demands a different mindset than traditional IT testing. The mission is to uncover real security weaknesses while protecting people, services, and physical systems.

By investing in careful scoping, strict rules of engagement, realistic lab environments, OT-aware methodologies, continuous monitoring, and responsible reporting, organizations can gain deep insight into their true cyber risk — without disrupting operations or compromising safety.