I visited a water treatment plant last week as part of a security assessment. The facility manager walked me through the control room and pointed out the SCADA system running on a Windows XP workstation that had not been patched since it was installed in 2004. The system controls the chemical treatment process for a water supply that serves 200,000 people. It is connected to the corporate network for reporting purposes. There is no firewall between the control network and the business network. The default passwords on the PLCs have never been changed.

This is not an unusual situation. It is typical.

The Invisible Computer Problem

We have reached a point where computers are embedded in virtually every piece of critical infrastructure, industrial equipment, and increasingly in consumer products. Power grids run on SCADA systems. Traffic lights are networked. Medical devices communicate over IP. Building management systems control HVAC, lighting, and physical access. Your car has more computing power than the Apollo spacecraft.

The security implications of this proliferation are staggering, and the security industry has been slow to address them. Our models, our tools, and our training are still overwhelmingly focused on traditional IT infrastructure - servers, workstations, network devices. The embedded systems that control physical processes operate in a different universe with different constraints, different lifecycles, and different risk profiles.

Why Traditional Security Does Not Apply

Consider the patching problem. In traditional IT, we accept that systems need regular updates and we build processes to deliver them. In industrial control environments, patching is often impossible or prohibitively risky. A SCADA system controlling a manufacturing process cannot be taken offline for a patch cycle without stopping production. The vendor may not even provide patches for the embedded operating system. And the validation required to ensure that a patch does not affect the control process can take months - during which the vulnerability remains open.

Network segmentation helps, but it is not a complete solution. The trend toward IP-based control protocols and integration between operational technology and business networks means that the air gaps that once protected control systems are disappearing. The business wants real-time data from the plant floor for analytics and reporting. That data flow creates a bridge that an attacker can potentially traverse in the opposite direction.

Authentication on embedded systems is frequently weak or nonexistent. Default credentials are common. Many industrial protocols - Modbus, DNP3, some OPC variants - have no authentication mechanism at all. If you can reach the device on the network, you can send it commands. The protocol was designed for reliability in a closed network, not security in a connected one.

Real World Consequences

The security research community has been demonstrating attacks against SCADA and industrial control systems with increasing frequency. The Idaho National Laboratory's Aurora test in 2007 showed that a cyberattack could cause physical destruction of a power generator. Researchers have demonstrated attacks against traffic control systems, building management systems, and medical devices.

So far, we have not seen a major publicly attributed cyberattack on critical infrastructure in the West. But the capability exists, the vulnerabilities are known, and the trend toward connectivity is accelerating. It is a matter of when, not if.

What Needs to Change

First, the security industry needs to stop treating operational technology as someone else's problem. The IT security team and the process control engineers need to be in the same room, having the same conversation about risk. In most organizations, these groups barely know each other exists.

Second, we need security standards for embedded and control systems that reflect their operational reality. You cannot apply PCI DSS to a PLC. The constraints are fundamentally different. Organizations like the ISA and NIST are working on this, but adoption is slow and compliance pressure is minimal compared to what exists for traditional IT.

Third, vendors of industrial control systems need to build security into their products rather than treating it as an afterthought. This means secure defaults, authentication, encrypted communications, and update mechanisms that do not require taking the system offline.

Fourth, and perhaps most importantly, we need to start thinking about computing security more broadly than we do today. The era where "computer security" meant protecting servers and workstations is ending. Computers are everywhere now - in our infrastructure, in our vehicles, in our homes. Our security thinking needs to expand to match.

The water treatment plant I visited last week is one of thousands of similar facilities. Each one is a computer that most people do not think of as a computer, controlling a process that most people take entirely for granted, protected by security measures that most security professionals would find inadequate for a branch office network.

That should concern all of us.