By Katherine Gronberg, Vice President of Government Affairs, Forescout
In June, the cybersecurity company JSOF, with help from Forescout, released some eye-opening research about a set of 19 vulnerabilities, collectively known as Ripple20. The Ripple20 vulnerabilities are found within the TCP-IP protocol code sold by Ohio-based software company, Treck, and are used by a wide range of Internet of Things (IoT) and Operational Technology (OT) devices. An OT device refers to a specific type of computing device that manages, monitors or controls operations that are more physical or industrial in nature, such as an environmental control or security system. The Ripple20 vulnerabilities make these devices susceptible to remote code execution exploits, which is a type of exploit that allows an attacker to take full control of a device. This can allow attackers to disrupt the operations of an organization or to leverage that device as an entry point onto the network to attack other sensitive assets or information.
A TCP-IP stack is an embedded library of code that allows a device to communicate over the internet. Treck’s code was built to handle the TCP-IP protocol that connects devices to networks and the internet and as previously mentioned, is incorporated into a range of IoT and OT devices. Unfortunately, organizations rarely know the component makeup of their IoT devices, as there is currently no requirement for manufacturers to provide customers a bill of materials that describes the specific hardware and software components contained in IoT and OT devices. Common types of devices running Treck include office printers, medical infusion pumps, security cameras, video conferencing tools, and building automation systems, to cite a few examples.
Federal agencies are heavily affected by the Ripple20 vulnerabilities as they increasingly rely on networked IoT and OT to perform their missions. Forescout sees hundreds and in some cases thousands, of smart devices and IoT devices, as well as OT devices, on government networks. We have seen examples of federal agencies that purchase smart appliances for use in kitchens or labs, but which the manufacturer will not warranty unless the appliance is granted an internet connection, which may violate an agency’s policies. Out of a sample of 90,000 devices found running Treck, nearly 6,000 were in use within the government sector. According to Forescout research, devices and equipment for heating/ventilation/air conditioning (HVAC), emergency communications, and IP camera systems (like those used for physical building security monitoring) have emerged as riskiest for government agencies.
The pervasiveness of IoT and OT on government networks, with a significant number of those containing the Ripple20 vulnerability, should signal how important it is that federal agencies have a way to identify and manage the cyber risks of these kinds of devices. Yet, federal agencies have struggled mightily with this problem. This is partly because agencies’ IT security functions haven’t really wanted to address the security of these operating systems and left them largely to the system owners to figure out (e.g. the facilities management people). Further, until now, none of these parties had adequate tools to address the security of these devices. IoT and OT devices are not like traditional computers; they are difficult to detect and can be difficult to identify correctly. They cannot run traditional security software the way a computer can. In our experiences with new federal customers, we have found that most are unaware of how much IoT and OT is actually present on their networks.
At the policy level, government leaders have focused their attention on creating conditions and standards for the manufacturers of IoT and OT to meet, including potentially requiring them to build certain security features into products. But the IoT attack environment is, frankly, too explosive for static feature requirements or point-in-time product or vendor certifications to suffice. Examples of such constructs include IoT product or manufacturer certification processes, the requirement for manufacturers to provide software or hardware bills of materials, and certification-based “device tagging” mechanisms. While these ideas will provide agencies more information about the IoT running on their networks, the overall federal strategy being implemented has to balance these methods with an equal or greater emphasis on augmenting behavior-based, continuous monitoring approaches. These refer to methods that allow agencies to monitor, in real-time, the network access, posture, and behavior of all devices and associated users, and to continuously enforce controls and compliance on these devices.
These methods are currently being implemented within the Department of Defense (DoD) through the Comply-to-Connect (C2C) program. The overarching goal of C2C is to improve the authentication, authorization, compliance assessment, and automated remediation of all devices and systems connecting to a network. Within the C2C framework, IT, IoT, and OT devices and systems are detected instantaneously upon presenting themselves to the network. They are identified, assessed for signs of compromise and other anomalous configurations and behaviors, and finally assessed for their compliance with DoD security policies. Compliant devices and systems gain the desired level of access to the network, while unauthorized ones are held in quarantine until they successfully meet requirements.
C2C allows the DoD to inspect every single device for malicious code, prohibited software, noncompliance and other risks. In responding to the challenges of today, C2C applies to IoT devices as well as systems for industrial control, weapons, medical gear, commercial smart devices and embedded controls. The program has in its scope all devices and systems within a “single pane of glass,” under a singular security architecture, as opposed to the security of different device types and systems being managed by disparate teams within DoD.
The capabilities of C2C will form the foundation of the DoD’s efforts to implement an enterprise Zero Trust architecture, most importantly, by restricting any device’s network access until it has proven itself trustworthy. Once approved, C2C requires the continuous monitoring of an endpoint, enforcing its access to data resources via network segmentation and limited penetration to other networked resources. The National Institute of Standards and Technology (NIST) has published some especially important guidance on both Zero Trust and Continuous Monitoring.
There is no turning back to a pre-IoT/OT world. Agencies are now far too reliant on the devices for mission-critical tasks. IoT must be embraced for its ability to create efficiencies and improve safety in federal missions, but government IT leaders must simultaneously employ frameworks that can secure these devices, the data on them and the critical functions they perform. C2C is this framework within the DoD and it will enable the Department to incorporate IoT innovation into its critical missions while ensuring they don’t introduce mission-impacting risk.
About the Author
Katherine Gronberg is Vice President of Government Affairs at Forescout Technologies, Inc., the leader in Enterprise of Things security. Prior to Forescout, she taught at Georgetown University’s Edmund A. Walsh School of Foreign Service and ran her own government affairs consulting firm. Prior to this, Katherine served as a Staff Director on the Senate Appropriations Committee, handling billions in annual appropriations for federal agencies such as the Departments of State and Commerce.
