Thanks to Joe Weiss for his excellent article that attempts to explain and clarify the differences between IT and ICS and the special cybersecurity needs of ICS, and how those needs are not being met by currently deployed cybersecurity technologies. These ICS issues and principles are difficult to understand in terms of their cybersecurity implications and Joe does an excellent job of elucidating this subject. You can see his entire article here: https://www.controlglobal.com/assets/wp_downloads/pdf/2018-01-INSIDER-Joe-Weiss.pdf
Some comments and thoughts about Joe’s article are presented below. Thoughts about how a novel cybersecurity technology, ControlMQ, that is now available can ameliorate the described cybersecurity problems for control systems are also presented. Novel technologies exist to address the control systems cybersecurity problem. Control systems developers and operators need to be willing to look at these new technologies and adopt them into their systems. Selected quotes from the article are followed by comments with the hope of advancing the understanding of control system cybersecurity issues and suggesting actions and technologies that can provide the needed security.
The NIST definition of a cyber incident in FIPS PUB 200 is: “An occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability (CIA) of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies”. “The definition needs to add the letter S (Safety).” This definition describes the effect that is a cyber-incident. It is up to investigators to determine the cause and whether it was malicious or not. The safety of the system, or rather the safety that the system conveys to operators and users, is implied in the CIA attributes of cybersecurity. That is, a system that is operating with confidentiality, integrity, and availability should also be exhibiting the safety behaviors that were engineered into the system. One more letter that is often added is another A for Authentication, where only those commands or functionality that are legitimately authorized are allowed to occur.
The issues and arguments about cybersecurity for ICS go to the heart of good system and software engineering methodologies. A good development process creates a system that should exhibit the desired behaviors, and only the desired behaviors. Most engineers put their effort into creating the desired behaviors, but it is the alternate, or erroneous behaviors, that are the causes of much of the problems in systems. Good software implementations catch and handle such exceptions, but only the ones that are designed into the system. A poor design that does not adequately address the problem to be solved cannot be ameliorated by the software implementation. In this sense, design faults are a greater problem than implementation faults (bugs).
“The additional reason for not using the term malicious is the lack of adequate ICS cyberforensics as well as lack of sufficient ICS cyber security technologies.” Sufficient ICS cybersecurity technology is available today in the form of ControlMQ, which provides comprehensive cybersecurity for control systems communications.
“The IT idea of prevention may not be adequate for the ICS environment and consequently, resilience and recovery become very important.” I couldn't agree more. Prevention is not only inadequate for ICS environments, it is inadequate for IT environments. Hence, the seemingly endless series of data breach event disclosures in the news. The emphasis must be placed on prevention, or hardening of systems to prevent cyberattacks from succeeding.
“An interesting adjunct is the concept of a Cyber Pearl Harbor.” Perhaps. Or perhaps what we’re experiencing today is a form of cyber-detent. That is, nation-state adversaries which are intentionally withholding cyberattacks, that they are perfectly capable of executing, for political reasons. But, when a suitable change in political circumstance occurs, so may the introduction of cyberattacks to follow.
“There are many differences between IT cyber security and ICS cyber security including the basic premise of each. IT is focused on detecting vulnerabilities, generally new, in the network regardless of process system impact. Operations (and safety) focus on what can happen to the process and ask if cyber can cause that problem regardless of the sophistication of the cyber threat...” The goal of both IT and ICS security needs to be full CIA as defined above. This is more of a chart on emphasis, which implies that there are limited cybersecurity resources, so some ranking is needed to guide the expenditures and efforts on each. This is a false choice. What we need to do is implement full CIAA, the technology for which is now available.
“In fact, the far left devices (Level 0,1 in the Purdue Reference Model) have not even been considered for cyber security.” Looking beyond pure industrial control systems to general control systems architectures such as for avionics, military systems, robotics, other computer controlled system may be helpful here. Strictly speaking, the Purdue Reference Model is an organizational model, not a deployment, implementation, networking, or any kind of security model. That is, it does not necessarily specify how the capabilities are instantiated, allocated, integrated, or composed. All of the functionality in the model may be inside a single computing component running in a single process. This would be highly unlikely, but it would still fit the definition of the model. A further model, that maps the Purdue Reference Model to a deployment and networking model is needed. This new model would specify what components implement the Purdue Model functionality and what networks and network interfaces connect these together to form the system. This is an application of system and software modeling from that development world to the ICS environment. Having such a model would allow the ICS engineer to specify components, interfaces, networks, and related elements such as enclaves and gateways to assure the security of the system.
“Other traditional aspects for estimating risk such probabilistic risk assessments don’t work as they cannot account for malicious events.” Exactly! This is the core problem with cyber-risk analysis. It is mainly based on guesses, rather than any kind of model that inspires confidence.
“ICS cyber risk can be temporal and potentially universal. Stuxnet is a good example. Prior to Stuxnet, the probability of changing controller logic without the operator being aware and then modifying operator displays to camouflage the logic change would have had a very low probability.” Another way of saying this is that cyber-risk is a discrete step function. The system either has the vulnerability, in which case the system is at risk, or it doesn’t have the vulnerability, so it has zero risk. Once a new exploit is created, all systems with that particular vulnerability are at risk.
The Triton/Trisis attack exposes additional flaws in the cybersecurity posture of the control systems including the SIS. The real problem is not the immediate vulnerability in the particular system model. Rather, the root of the problem is that the engineering workstation was compromised. Once compromised, any kind of code, data, or behavior could be introduced into the SIS, specifically because that is the purpose of the engineering workstation. Security controls need to be added to the entire system, including all subsystems that touch the SIS, such as the engineering workstation. Control systems need to be treated like secure facilities, just like classified facilities are in the DoD world. They already have some level of physical security, this just raises the level to that which is needed to ensure needed security today. We discuss this in depth on our blog: http://cognoscentisystems.com/blog_triton_trisis_lessons.html
“What is missing, however, is view and understanding of what is happening with Level 0,1 devices BEFORE their data is converted to Ethernet communications via serial-to-Ethernet converters (gateways)” The engineers who design the system must exactly specify what is correct behavior and what limits exist for this behavior. This is exactly what ControlMQ does in its specification of messages and their argument range limits.
“Sensor standards including Namur 43, ISA108, etc. do not appear to adequately address cyber security whereas security standards such as IEC62443-4-2 do not appear to adequately address Level 0,1 devices. Additionally, sensor protocols are cybervulnerable including wired and wireless HART -- Highway Addressable Smart Transducer, Profibus, and Fieldbus.” Agree completely. This is one of the core purposes of ControlMQ. To provide the needed, high level of cybersecurity in a generalized form that can be applied to all control systems.
Solutions to these control system cybersecurity problems are available today. A combination of the use of ControlMQ technology and proper systems engineering and access control would have prevented all of the cybersecurity incidents that have been presented. Sensors and actuators need to be isolated from directly connecting to networks by placing them behind secure controllers that implement both the interface functionality and the necessary cybersecurity. This isolation provides the protection of these Level 0,1 devices from network cyberattack and from accepting invalid range command inputs. Controllers need to have network interfaces that are defended against cyberattack and only send and accept valid, secure controls messages.
ICS systems cannot be made secure by the use of IT cybersecurity techniques. Nor can they be made secure by wrapping, patching, or bolting on cybersecurity elements to existing ICS protocols and technologies. Special purpose, secure control system technologies are needed that integrate the cybersecuirity into the control system functionality. This is precisely what ControlMQ does for control systems. It’s time to step up and address the problems of control systems security directly rather than endlessly looking for quick fixes and magic bullets.
See more about ControlMQ at www.cognoscentisystems.com