Why Testing "Offline" Isn't Secure: Taking Cybersecurity Seriously with CMC 500
For years, an unquestioned assumption defined substation security: “We’re secure because we test offline.” It’s a comforting thought that has guided our procedures and shaped our sense of security. But today, that belief is a dangerous assumption you can make.
That old sense of safety is now a vulnerability because the threats themselves have changed. They are no longer just outside the firewall, trying to get in. They arrive on a USB stick or in a compromised settings file, already inside your trusted perimeter.
When the threat is already in the room, being disconnected from the internet is irrelevant. Your test set is no longer isolated; it becomes the prime target, and potentially the weakest link in your security chain.
This new reality forces a critical choice. Do you rely on procedures alone to protect you from potential vulnerabilities in your tools? For the CMC 500, that choice is the foundation of its design. To see what this means in the real world, let’s follow two people who represent this conflict simplistically.
Cybersecurity is not a feature. It’s a non-negotiable architectural principle.
A Real-World Cyberthreat in the Field:
The Story of John and Jane
Meet John, a meticulous protection technician. His routines are precise, his standards high, and he trusts his tools implicitly. His actions are essential to keep the integrity of the grid.
Meet Jane, a hacker who thrives on exploiting trust and assumptions.
John’s day starts with a routine job at Substation Alpha. He downloads the necessary test files from the file server. On-site, he gets a settings file update from the customer on a USB stick. He follows procedure perfectly: all network connections on his PC are disabled including the office server except the one to his test set.
Nothing can go wrong, right?
But Jane has already made her move. Days ago, she used social engineering to plant malware on the office file server. John’s PC has the latest security patches and an up-to-date virus scanner, but Jane is using a zero-day vulnerability.
Preventing Man-in-the-Middle Attacks with Encrypted Communication
As John begins his test, the malware on his PC activates. Its first goal: to listen. It tries to analyze the communication between the PC and the test set, hoping to sniff out passwords, IP configurations, or firmware details.
The Result: The CMC 500’s communication is encrypted from the very first packet. The data, if captured, is just scrambled noise.
Frustrated, the malware escalates. It positions itself in the middle, impersonating the test set to John’s PC and the PC to the test set. It’s a classic Man-in-the-Middle attack, designed to intercept and manipulate commands.
How the CMC 500 Responds: The CMC 500 assumes nothing. It uses public-key cryptography and digital certificates, so that the PC can prove the identity of the CMC 500. The CMC 500’s unique private key is stored in a hardware-based Trusted Platform Module 2.0 (TPM 2.0), making it physically secure. As Jane’s malware can't produce a valid certificate, the connection is instantly denied. This stands in sharp contrast to legacy practices that rely on the test system to be offline; such a system would assume the connection is trusted and would be completely blind to this type of impersonation attack.
No Certificate, No Connection. No Identity, No Access.
Securing Wi-Fi Connections Against Unauthorized Access
John moves on to primary injection testing. He’s using his multifunctional test set, the CMC 500 to inject primary currents. To move freely and perform measurements efficiently, he connects via Wi-Fi.
Jane doesn’t give up. With her first attempt blocked, she shifts tactics. She takes a ride to the substation and tries to connect directly to the test set in the Wi-Fi network. If successful, she could inject malicious commands, trigger dangerous operations, or even harm personnel in the substation. This is a direct attack on the device's access controls.
How the CMC 500 Responds: This is where simple, procedural security meets hardened design. John isn't just connecting, he's securing. His PC already authenticated the CMC 500 by default. But by adding a password, he enables mutual authentication: now the CMC also checks who's trying to connect. Without the correct credentials or physical access to reset them, Jane is locked out.
No Password, No Access. No Gaps in Defense.
Ensuring Firmware Integrity with Secure and Measured Boot
Thwarted again, Jane shifts her strategy to the most fundamental level of attack. During a moment when John connects to the substation network for a settings update, she tries to push a malicious firmware package to the CMC 500. If successful, this corrupted firmware could start unwanted operations, attack other IEDs on the network, or lie dormant until a critical moment.
This is the moment that separates proactive design from reactive policy. Another test set might load its operating system first, relying on a post-installation scan to find a threat. By then, the door is already open.
How the CMC 500 Responds: The CMC 500’s door never opens to unverified code. It uses Secure and Measured Boot; a process anchored in the hardware of its TPM 2.0. Before the very first instruction of the installation executes, the firmware is validated for its OMICRON signature. During execution, each component of the firmware is cryptographically verified, measured and compared to known checksums.
Jane’s malicious firmware is unsigned. The result? No installation. It remains silent.
No Verification, No Execution.
A Commitment, Not a Checkbox:
Our Approach to Lifecycle Security
The story of John and Jane isn’t a one-time event. As we write this, attackers like Jane work relentlessly to bypass defenses and exploit untreated vulnerabilities. That is why security must be a continuous commitment embedded across the entire product lifecycle, not a one-off checkbox.
We maintain a transparent and proactive vulnerability handling process which you can explore in our OMICRON Magazine article. Whether discovered by our internal teams or reported by users, we address all potential vulnerabilities through
- Regular software updates to patch and harden the system.
- Public disclosures and countermeasures so you are always informed and empowered to protect your assets.
Security isn't just a feature. It's our commitment. Every day, in every CMC 500 device.
A Layered Defense:
How the CMC 500 Secures Testing
Identity Verification and Credential Protection
- Public-Key Cryptography
- End-to-End Encrypted Communication
- Trusted Platform Module (TPM 2.0)
- Mutual Authentication
Firmware Integrity
- Secure and Measured Boot
Security Embedded in Product Lifecycle
- Lifecycle Vulnerability Management
Want to Dive Deeper?
As attackers like Jane evolve, so must our understanding of cybersecurity in field testing.
For more insights, tune into OMICRON's podcast episode: #116: Why Testing Offline Is Not Cyber Secure
In this episode, our experts explore:
- Why “offline” doesn’t mean “secure”
- Real-world attack scenarios in substations
- How built-in security like TPM 2.0 and Secure and Measured Boot protects your test sets
Because security isn’t just a feature, it’s a mindset.
Choose a Test Set That is Ready Before the Threat Arrives
Don't wait for the next breach to reveal the weakest link in your security chain. Reactive measures are no longer enough. It’s time to make trust intrinsic and build your security posture on a foundation of proactive, engineered defense.
Secure your grid with a tool that was designed for the threats of tomorrow, not the assumptions of yesterday.
See Proactive Threat Management in Action
Discover how the CMC 500 can harden your testing procedures and protect your critical infrastructure.
