red and black metal tower during sunset — Photo by Maria Lupan on Unsplash

In the world of industrial infrastructure, there is a common saying: “If it ain’t broke, don’t fix it.” This philosophy often leads to a dangerous reality: proprietary Industrial Control Systems (ICS) running mission-critical tasks on software that hasn’t seen a security patch in half a decade.

While these systems might be stable, they are “cryptographically brittle” and full of known vulnerabilities. The danger escalates exponentially when organizations attempt to integrate these legacy environments into a modern, internet-connected corporate network.

The Two Distinct Risks of “Merging” Worlds

When you connect a five-year-old, unpatched ICS to a modern IT network, you aren’t just adding a device; you are adding a permanent “beachhead” for attackers. There are two primary risks associated with this integration:

1. Targeted Exploitation (The Weakest Link)

Modern operating systems have advanced protections like ASLR, DEP, and automated patching. Legacy ICS software usually does not. An attacker doesn’t need to find a sophisticated zero-day exploit for your modern Windows 11 machines; they only need to find a five-year-old, public exploit for the ICS. Because the software is proprietary and unpatched, it represents a “static target.” Once an attacker identifies the software version, the exploit is often as simple as a single script found on a public repository.

2. Lateral Movement (The Pivot Point)

The most severe risk isn’t just the compromise of the ICS itself, but what happens next. In a typical corporate network, devices often “trust” one another. If an attacker gains a foothold on the vulnerable ICS, they can use it as a launching pad to move laterally across the network. From the ICS, they can sniff traffic, scan for vulnerabilities in the modern corporate servers, or attempt to steal administrative credentials. The legacy system becomes a “cloak” that allows the attacker to operate from inside your perimeter.

The Problem: You Can’t Patch It

In a perfect world, we would simply update the software. However, with proprietary ICS, the original vendor may no longer exist, or the update might require a complete hardware overhaul costing millions. When “fixing” the vulnerability is impossible, we must change the environment around the vulnerability.

The Mandatory Solution: Network Segmentation

Since we cannot eliminate the vulnerability, we must implement a Mandatory Compensating Control. The gold standard for legacy ICS is Network Segmentation via a “Demilitarized Zone” (DMZ) or VLAN.

How it Works:

Instead of allowing the ICS to sit on the same flat network as the accounting department and the mail server, it is placed in its own isolated “sandbox” (a separate VLAN).

The Implementation Details:

Zero-Trust Connectivity: A firewall sits between the ICS segment and the rest of the corporate network. By default, all traffic is blocked. * The “Jumpbox” Pattern: If an engineer needs to access the ICS, they must first log into a highly secured, multi-factor authenticated “Jumpbox.” Only the Jumpbox is permitted to talk to the ICS, and only over a specific, monitored port.
Protocol Filtering: The firewall should use Deep Packet Inspection (DPI) to ensure that only legitimate industrial protocols (like Modbus or OPC) are flowing, blocking any attempt at standard web traffic or file transfers that could indicate a breach.

Conclusion

Legacy ICS is a reality for many industries, from manufacturing to energy. You cannot always patch the software, but you can control the network. By treating your legacy systems as “untrusted” and isolating them through strict network segmentation, you ensure that a vulnerability in a five-year-old piece of software doesn’t lead to a total compromise of your modern enterprise.

In the age of interconnected systems, isolation is often the best form of protection.

Exploit Mitigations: ASLR and DEP

Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP) are “exploit mitigation” technologies. They do not fix underlying code vulnerabilities (like buffer overflows), but they make it significantly harder for an attacker to successfully turn a bug into a working exploit.

1. ASLR (Address Space Layout Randomization)

The Concept: Imagine a thief trying to rob a house who knows exactly where the safe is located in every home in the neighborhood. ASLR is the equivalent of randomly rearranging the floor plan of every house so the thief doesn’t know where the safe is.

How it Works:

Randomization: Every time an application or the operating system boots, ASLR randomly arranges the address space positions of key data areas. This includes the base of the executable, as well as the positions of libraries (DLLs), the heap, and the stack.
The Defense: In a classic “buffer overflow” attack, an attacker needs to point the CPU to a specific memory address where their malicious code is hidden. If the memory addresses change every time the program runs, the attacker’s hard-coded address will point to empty space or invalid memory, causing the application to crash rather than execute the payload.

2. DEP (Data Execution Prevention)

The Concept: DEP marks specific areas of memory as “non-executable.” It enforces a strict rule: a memory page can either hold data (like a document or a user’s input) or it can hold instructions (code), but it should rarely do both.

How it Works:

The “NX” Bit: DEP leverages hardware support (the “No-Execute” bit in modern CPUs). The operating system marks memory regions used for data (the stack and heap) as non-executable.
The Defense: In many attacks, a hacker tries to “inject” code into a data field (like a username box) and then trick the computer into running that code. With DEP enabled, even if the attacker successfully places code in the memory, the CPU will refuse to execute it because that section of memory is flagged for “Data Only.”

How They Work Together

ASLR and DEP are most effective when used in tandem:

DEP stops the attacker from running code they’ve placed in data regions.
ASLR stops the attacker from reliably finding existing, “safe” code snippets within the system (like system libraries) that they might try to stitch together to bypass DEP (an attack known as Return-Oriented Programming or ROP).

In the context of your Legacy ICS software, these systems often lack these protections. This means an attacker doesn’t have to “guess” where memory is located, and they can execute code directly from the stack, making the system a “sitting duck” compared to a modern Windows or Linux machine.