Industrial control systems need security ICs

Industrial systems need security ICs--Page 2.

Threats to Industrial Control Systems

One cannot rely on the custom architecture of ICSs to protect them from electronic threats. Historically cyber attacks were not considered serious threats to control and automation systems because ICS networks were either isolated or not following IT standards. We can make three important observations about this.

Control and automation networks are more and more connected to standard and open networks because they need to interface with other systems. In industry a proprietary protocol can easily be reverse engineered at a reasonable cost.

The danger here is that any weaknesses in that protocol may never have been studied, understood, or remedied. It is dangerous to think that a proprietary protocol offers security just because its knowledge is not in the public domain. This risk has been proven to be a wrong and misguided approach; it is the “security through obscurity” concept.¹ This vulnerability of insecure protocols contrasts markedly with publicly known and trusted protocols for which threats and responses are well understood.

Networks are not the only paths for cyber attacks. Consequently, an isolated infrastructure in an ICS might be vulnerable to other attack media such as USB keys or maintenance consoles.

Just as when industrial networks do not follow documented and well-known protocols, so too the proprietary architecture of PLCs does not normally offer security protection either. The Stuxnet is unfortunately a very good demonstration of this. Admittedly, Stuxnet did only harm proprietary software and PLCs with a specific configuration. This malware could not have been designed without an understanding of the intimacy of the specific systems it was targeting. “System security should not depend on the secrecy of the implementation or its components.”² Indeed, that approach makes the hardware, the PLC in this context, too vulnerable. So, again this cannot be stated too often: one cannot rely on the custom architecture of ICSs to act as a protection against electronic threats.

While ICSs have a different architecture from the typical IT infrastructure and fulfill different requirements, nonetheless, most of the threats to generic IT infrastructures can also affect ICSs. Unfortunately, the list of those threats is long and troubling: malware injection such as worms or viruses; software or hardware configuration changes; fake messages or orders from an attacker; identity theft; and unauthorized observation.

In summary, we are in an extremely challenging situation. ICS security threats are similar to the ones harassing IT infrastructure, but all too often the specific requirements for ICS operation do not allow reuse of well-known security countermeasures!

Put the Highest Level of Countermeasures Inside the ICS

With security a pervasive concern for industrial and automation applications, countermeasures and mitigation actions are being implemented. Until now, most of these defensive measures have included security procedures, environment physical protection, and staff education. The ICS itself remains vulnerable. Before we leap to criticize the industrial community for these minimal precautions, we should recall that this is how security started in the traditional IT domain. This is really the first level of protection, a foundation that must be the start.

These traditional defensive tactics do not, in any way, provide the ultimate level of protection needed for an ICS. Procedures, even if audited on a regular basis, are never 100% followed; physical protection like locking doors can be bypassed and cannot be applied everywhere. Most important, defensive manual procedures do not cover attacks performed by highly skilled people with the time and budget to elaborate the most sophisticated scenarios. Even worse, there are examples where bribery led ICS operators to bypass procedures.

The security answer is embedded. It is in the ICS hardware. The upper-level hierarchy of security countermeasures involves generic IT security countermeasures such as cryptography and hardware security (See Figure 1).

Figure 1. The hierarchy of security countermeasures.

Generic IT security solutions are sometimes already there in the software. Some infrastructures are already protected by firewalls; some secure protocols over IP such as TLS/SSL are also implemented. While again, all stages of the pyramid are necessary, we are now going to describe how hardware-based security brings the ultimate level of protection.

Protect the ICS with Embedded Cryptography

Generic IT policies cannot be systematically applied to the broad range of ICSs at work in industry. However, there is one technology used universally in the IT world that can be implemented: cryptography.

Cryptography answers most of the threats listed above. Still, it is not a magic wand and the approach cannot be as simple as, “I’ll add crypto to my ICS and all of sudden it becomes secure.” Crypto algorithms and protocols are building blocks that should be implemented on a case-by-case basis after a thorough analysis of the threats to each subsystem. Restated simply, cryptography is a tool common to ICSs and IT infrastructure, but its implementation in an ICS must be tailored to the specific system. Within the broad range of cryptographic techniques, two are very important for an ICS: digital signature and encryption. We shall examine the merits of both processes for an ICS.