ControlMQ™ provides the secure foundation for defending controls against network attack by applying a combination of cybersecurity principles into a single solution. This includes methods to encrypt and anonymize message packets on the wire, a hardware root-of-trust based on the NIC, a mechanism to prevent bypass of security processing, and a unique specification language and validation method for control messages. These techniques are combined with traditional cryptography, authentication, and error checking to produce a comprehensive and robust controls messaging mechanism.
Originally developed at Johns Hopkins University Applied Physics Lab for military control systems, this technology is now being made available to the commercial market to provide network cybersecurity for critical infrastructure and controls applications.
Secure Controls Middleware protects distributed control systems and related system components against network cyberattack. To achieve this secure middleware for controls must implement six basic properties and achieve robust implementation.
Enabling secure middleware for controls requires an absence of vulnerabilities to cyberattack in the implementation itself. No software is perfect, but the quality and robustness of secure middleware can be greatly increased by applying a number of methods and principles.
ControlMQ™ is the Secure Controls Middleware solution. Only ControlMQ™ satisfies all the of the six required properties for secure middleware for controls. ControlMQ™ enables a vulnerability free implementation by following the development methods described above. ControlMQ™ specifies the most simple, one step protocol where a message is placed on the wire by the sender and pulled from the wire by the receiver. All interactions are configured prior to use in all participating components. ControlMQ™ consists of two elements: a daemon process broker that runs on each component and a development package used to build control applications. ControlMQ™ has been developed using extensive unit and system testing of each feature. Each of the two components has less than 10,000 lines of application code, which is small by modern software standards. Thus, the likelihood of a vulnerability in ControlMQ™ is quite low.
ControlMQ™ is constructed using a set of cybersecurity principles that results in the highest level of cybersecurity for controls. Central to these are the integration of the cybersecurity mechanism into the communications middleware to realize the advantages of built-in security.
Traditional IT/Data cybersecurity methods do not map well to the specialized needs of controls systems. IT/Data security methods were developed to provide one-size-fits-all cybersecurity to protect general purpose computing. This requires protecting a wide variety of uses like email, web browsing, financial systems, and multimedia. The result is an enormous attack surface that encompasses all the interfaces of all possible O/S, service and applications that are running. This is a daunting task to say the least, and one that hasn’t been completely successful. But, unlike general-purpose computers, controls are highly specialized systems. So, why not use that constraint as an advantage in protecting control systems?
Control systems use a wide variety of protocols that have been developed over decades, each for a particular use. Many who use these protocols would like to continue to do so, so efforts have been made to patch on cybersecurity to these existing protocols. The results have been very helpful, but never completely successful. Inevitably patching leaves some attack paths unprotected. Only comprehensive security, designed in from the start can provide the high level of security for controls applications.
The result of applying the above principles is that control system components are hardened against cyberattack. They keep the attack from succeeding in disrupting the functionality of the control system. This is a change in cybersecurity posture for control systems that puts the integrated defense of the components as the primary security mechanism; leaving the cybersecurity watch floor, network surveillance systems to do situational awareness as a backing system, as shown in the diagram below. Contrast this with the standard IT/data cybersecurity method of "detect and remediate", which allows the attack to succeed, but then detects it and tries to restore the system to a good state after the fact. Control systems need hardening to prevent attacks from succeeding. The method of "detect and remediate" will not suffice, as the operational systems under control cannot be put back to a good state after a successful attack.
The architecture for the control systems components is shown in the diagram below. The core element is a security broker, called the SecureSieve™ broker, which runs as a daemon process on the component. NB. This broker runs locally on the component only, not on the network intermediating among components. The broker guards and manages the protected network interface, which is dedicated to transmit and receive ControlMQ™ messages with other components of the control system. The broker performs all the core security functions like crypto, authentication, and integrity checks, and takes advantage of standard crypto and hashing technologies such as RSA, AES, and SHA, which allows the technology to take advantage of hardware acceleration built into most modern CPUs to boost performance. The broker communicates with controls processes through a UNIX socket on the component. Controls applications are developed using the ControlMQ™ Application Framework with messages specified using the SIDL language described below. The Application Framework provides an API to register for messages by type, and send and receive messages with other components.
The initial implementation of ControlMQ™ is for the Linux platform. The kernel works with the NIC to use it as a H/W root-of-trust to ensure that an attacker does not bypass the security processing of the broker. The Linux kernel Netfilter functionality is used to limit the messages sent and received to those of the ControlMQ™ protocol, and the broker does higher-level packet processing.
The ControlMQ™ protocol is designed to run over Ethernet/IP networks. It uses a novel network stack called the Security stack to ensure proper application of the cybersecurity principles described above. The Security stack is shown below next to the traditional OSI network stack. Levels 1-3 and 7 are the same so that packets can be switched and routed over Ethernet/IP networks. The protocol makes use the IP network protocol 99, which is for “any private encryption”, to avoid using UDP or TCP, which both leak information. Each level of the stack performs a different function starting with level four crypto, level five authentication, which are self explanatory. At level six is representation, which is how the actual message data are constructed by the SIDL language, and enforced by the Framework in the application.
The Secure Interface Definition Language, is a simple, yet powerful language to specify platform independent application interfaces and messages. Messages are one-way datagrams that are sent from one peer to another. Messages are grouped into interfaces, which are given globally unique names. A peer signs up to receive an Interface in order to receive all associated messages. A particular message is then specified by the combination of interface name and message name.
A message specification contains a series of arguments much like a function declaration. The argument types are specified as user defined sidl_types. A sidl_type is a user-defined type based on three parameters: the bit length, the base primitive type, and the allowed range or ranges of values. A simple example will make this clear. In the file myinterface.sidl we have:
Here a sidl_type named int16type is defined that is 16 bits in size, is a signed integer primitive type signedint, and has a range of valid values from -1 to 65000, inclusive. An interface named myinterface id defined with two messages: messageA has a single argument intarg1 of the type int16Atype defined above, and messageB with two arguments intarg1 and intarg2 both also of type int16Atype. The SIDL™ compiler compiles this file into both client and server side code that is then compiled and linked with the user application code along with the framework libraries.