The recent discovery of 19 vulnerabilities in a lightweight TCP/IP library has sent shockwaves across industries as it exposes millions of organizations to potential cyberattacks. Known as Ripple20, these vulnerabilities were found in a library first released back in the 1990s.
The vulnerabilities vary in severity, but some can allow an attacker to control an affected device remotely, or cause availability issues. The number of affected systems was estimated to be in the hundreds of millions, and the affected products include “smart home devices, power grid equipment, healthcare systems, industrial gear, transportation systems, printers, routers, mobile/satellite communications equipment, data center devices, commercial aircraft devices, various enterprise solutions, and many others.”
Quite obviously, everyone wondered aloud how these vulnerabilities could exist in so many products and go unnoticed for over 20 years. However, I am not surprised by the situation. Poor security practices implemented in industrial control systems (ICS) and the Internet of Things (IoT) have contributed to how vulnerabilities like those outlined in the Ripple20 research propagate throughout so many products.
Understanding Risk, Software Quality in ICS
Several ICS manufacturers’ products, including various makes and models of programmable logic controllers (PLCs) and multiple human-machine interface (HMI) manufacturers, are primarily designed with safety and availability in mind. The reliability of PLCs is exceptional—ICS systems can be deployed in production facilities for decades and still function properly.
Safety is engineered into all ICS systems at a physical level, not just a logical level. This leads me to the topic of risk as it relates to the majority of industrial control systems.
While there are certain industries where security can have real-world catastrophic implications, such as the nuclear energy sector and other critical infrastructure, the vast majority of ICS systems do not have these extreme considerations to contend with. The reality for most manufacturing plants is that there is financial risk present with respect to security issues: processes can be interfered with to disrupt production, products can be contaminated if the process is altered in specific ways, or IP can be stolen in the form of recipes, formulae, and proprietary process details.
It is important to properly understand the risks a process could face from potential security issues without overreacting. While production issues that affect product quality can arise, such issues will be identified during the QA process. Manufacturers have processes in place to detect problems, investigate them, scrap contaminated batches, clean out equipment or fix the issue, and then resume production. While this process can be costly, it isn’t necessarily dire.
A common issue faced by systems integrators is being forced to use proprietary software of poor quality. While PLCs themselves are engineered and built to be extremely robust and reliable, the same cannot be said for other software released by these manufacturers. When working with some of the lowest-quality software, it is not uncommon to have multiple crashes per day while using the software as intended.
IT Versus OT
Since availability is critical to ICS systems, and since the systems themselves can be fragile and quirky, these are generally the responsibility of operational technology (OT) teams. The information technology (IT) team usually manages the corporate network. OT employees are familiar with process technology and the systems they manage, but they do not generally know a great deal about information security, which can lead to insecure deployments.
One fairly common situation for manufacturers is a divide, sometimes adversarial, between the IT and OT staff within a company.
OT employees do not want the IT staff to tamper with their systems out of fear of downtime that can cost the company. From what we have seen, these relationships often resemble red team versus blue team attitudes at many organizations. The blue team can resent the efforts of the red team because those efforts create more work for the blue team and can be considered a criticism of their work.
OT employees also often don’t want to consult with their IT counterparts when making arrangements such as remote access, leading to situations such as RDP on control networks commonly being exposed to the public Internet. IT and OT teams are on the same team and need to educate each other and enable each other to achieve their goals and mandates.
Ensuring Product Security in ICS
The ICS/IoT industries face many of the same challenges as traditional software development shops. However, there are unique challenges in ICS/IoT, where devices can be deployed for decades and could need unpatched legacy systems to be in place on the network to support them. Drop-in replacement for a legacy component may not exist, and re-engineering the process to accommodate a more modern component, coupled with the financial losses arising from downtime to complete the upgrades, could be cost-prohibitive.
Similarly, challenges exist with supply chain management. Manufacturers that integrate third-party components into their products may not know whether any of their individual components contain vulnerable libraries. The lack of basic security and secure coding principles in developer education means that they often aren’t aware of security weaknesses. Colleges and universities have a responsibility to train developers to produce secure software in the same way that they need to make sure engineering students can design a structure that won’t collapse.
Each of these issues needs to be addressed systematically if we want to see an increase in the security of the embedded devices that control much of our surroundings, often unnoticed, in the background. While preventing these vulnerabilities in the first place is ideal, having a way to track potentially vulnerable third-party components in products is a must to facilitate patching and other remediation efforts.