A New Approach to Mitigating Risk in Connected Critical Infrastructure

By Natali Tshuva, CEO & co-founder of Sternum

 

As we transition into Industry 4.0, connecting older operational technology systems with information technology networks, we are beginning to benefit from better information flows and feedback loops, leading to better efficiency and revenue outcomes.

However, with the benefits have also come new risks as these previously air-gapped devices in our critical infrastructure can now be accessed by malicious actors. This has led to a growing realization that the inability to secure our devices is hampering our progress into the connected future.

So how should organizations think about securing their Internet of Things devices and mitigating the risks?

Why Securing IoT is Different

When manufacturers began designing smart medical equipment, sensors for factories, or one of a million other uses for connected devices, their primary goal was to provide value to their users or enhance their productivity and revenues. What they did not have in mind was how to protect their devices from hacking because frankly it was not an issue at the time.

To be fair to the manufacturers, there were no tools that could be baked into the devices to secure them, leaving these devices in critical infrastructure vulnerable. The idea of including security as a part of the device’s design only came later when the risks of leaving them exposed became apparent.

We often forget that the makers of computers, networks, and applications have had a lot of experience over the years in learning how to defend themselves. Tools like RASP or endpoint protection that have made security significantly better in other fields simply have not existed in the connected space where device manufacturers are still playing a lot of catch up.

As the importance of security has grown in recent years, manufacturers have stepped up their mitigation efforts aimed at making their devices more secure.

Software Vulnerabilities are Inevitable

All software has vulnerabilities in it. Google, Apple, Microsoft each have numerous significant vulnerabilities found in their code every month, despite huge amounts of money being invested in security and tools to identify vulnerabilities.

Given this reality, it is fair to define the method of vulnerability discovery and patching as an endless race. In case of device manufacturers in critical infrastructure, it is also a very expensive procedure. The work of crawling for new issues, investigating multiple new CVEs and potential vulnerabilities found by static analysis tools, all just to understand whether they affect your devices. Manufacturers then have to create a mitigation solution and initiate a costly update procedure. Now imagine doing all of this, with the third-party supply chain risk flowing above your head, creating even more work and costs to handle vulnerabilities like Ripple20 for example.

Testing software before it is released is generally the preferred practice, catching bugs before they can be exploited in the wild. We know that other vulnerabilities will only be discovered after the products are deployed, with new zero-day vulnerabilities being discovered all the time.

While some of these vulnerabilities will be in your own proprietary code, third-party code poses an even larger significant risk to critical infrastructure operators. Third-party supply chain risk is so significant that it is now being addressed by regulators, including the latest update from ENISA just this week.

Many of these third-party libraries are closed-source, and even when they are open-source, static analysis tools and firmware analysis — sophisticated as they may be — fails time after time to identify third-party vulnerabilities.

An example of that can be found in many examples from the past year alone: Ripple20, Blueborne, Urgent11, and Zephyr vulnerabilities just to name a few. These third-party libraries can be reused in many different products, making them a sweet spot for hackers. Finding a vulnerability in third-party code can give him or her an entry point to millions, and sometimes billions, of devices.

On the opposite side of the spectrum, R&D and security teams also face a significant challenge when they are overwhelmed with huge numbers of vulnerabilities that show up when they manage to test their software with binary analysis tools. This forces them to strike a risky balance in identifying which vulnerabilities are high priorities and which are not, expending plenty of resources with a questionable amount of security as a result. Updating is a costly venture unto itself that manufacturers have to take into account as well.

Everyone knows that security is Sysaphean, but there are degrees of how rough it should be.

Location Matters

Relying on our network security tools is not enough because they lack the insights into what is happening on the device itself and are unable to prevent the exploitation in time. Not least because they are inapplicable for distributed environments.

In order to receive the real-time intelligence that an attempted breach on one of our devices might mean that a larger assault may be underway and to stop the exploitation in its tracks before it can do harm, we need to move our tooling out to sit on the devices themselves. Adding a layer of endpoint security, or RASP to protect applications from within, is a widely used security concept in the cybersecurity industry. But until recently, they have not been available for critical infrastructure manufacturers, despite yielding strong and sustainable security that saves money and shows direct ROI.

On-device solutions hold a powerful opportunity as well for gaining data from within the device’s operation in real-time, supporting full visibility and data-driven decision making.

Along with changing where we put our security tools, we need to reconsider where we focus to most effectively prevent exploitations.

Changing Our Approach from Vulnerabilities to Exploitations

Fixing vulnerabilities in deployed devices is challenging and can be quite expensive to carry out. In some cases, it is simply not possible as many devices that have already been deployed are impractical to update. The risk is even more significant when the vulnerabilities are unknown and your devices remain completely vulnerable, with no way for OEM’s to be alerted that something malicious or faulty may be occurring.

It is time to stop playing cat and mouse by chasing after an infinite number of vulnerabilities. Relying on patching after-the-fact leaves us exposed to new threats and zero-day vulnerabilities, Instead, we should be thinking about how a more sustainable way to handle both known and unknown threats in real-time, while alerting and providing visibility from within the device to any potential breach.

Bringing RASP concepts and endpoint security to critical infrastructure devices offers us a much more sustainable way to mitigate our risk as we move forward into our more connected future.

ABOUT STERNUM

Realizing that truly moving forward to a fully connected and smarter future requires that critical, high-impact IoT devices be sufficiently secured and visible — be it a device which is part of a managed network or a smart and unmanaged insulin pump — Sternum has built the first on-device self-protection security and monitoring solution that supports all operating systems, works for extremely resource-constrained devices, requires no changes to existing code, platforms or hardware and integrates in a manner of hours to existing devices. Once deployed, EIV and ADS proactively prevents both advanced and common attack attempts while unlocking hidden data-points from within the devices’ operation and third-party code to provide full visibility and in-field insights.