In the last decade, there have been many cyber attacks on industrial control systems (ICSs), some of the most significant of which include the Black Energy attack in 2007 and the Night Dragon campaign of 2011.
Black Energy began as an HTTP-based toolkit used to generate bots to launch distributed denial-of-service attacks, but by 2014, it had evolved into a supervisory control and data acquisition plug-in used to infect organizations in ICS and energy markets around the world.
Night Dragon used a SQL injection attack to enable the installation of malware and remote access Trojans on web servers, which were then used to launch forays against internal targets. Although designed to steal sensitive information from organizations in the global oil, energy, and petrochemical industries, the tools and techniques used in the campaign could be deployed successfully against any industry.
These campaigns and others have something in common. They were all web-based attacks positioned to exploit applications-based vulnerabilities through the injection of malicious code, leading to the compromise of ICS systems, which are used to manage such things as windmills, oil rigs, and pipelines. However, such attacks can also work in IoT environments.
Here's how to apply lessons from application security to your security stance against IoT attacks to achieve cyber resilience.
The background on backbones
The backbone computer architecture for industrial systems is PERA—Purdue Enterprise Reference Architecture—which was developed in the 1990s by Theodore J. Williams, with members of the Purdue University Consortium for computer integrated manufacturing. The framework defines the different levels of critical infrastructure that are used in production lines and the way to secure them.
There are four key levels in PERA. Level 1 covers sensing and manipulation of physical processes. Those processes are controlled in the second, or SCADA, layer. The third layer is the manufacturing layer, where production workflow is managed. The fourth level is the enterprise level, which covers IT operations. It's where the enterprise resource planning (ERP) system resides.
Mind the 'air gap'
Since PERA was first introduced, a layer has been created between levels 3 and 4. Level 3.5, referred to as the "demilitarized zone," is where an organization's security systems, such as firewalls and proxies, reside to "air gap" the information technology and operational technology sides of the business. Because IT and OT converge at this layer, it's also a favorite target of adversaries. Unfortunately, the layer is underdeveloped or non-existent in many organizations.
In this environment, enterprises are leveraging IoT services to bring their products to market faster, hoping those services are free of security risks. The services are mostly based on a loosely coupled architecture involving APIs, services, and third-party artificial intelligence and machine-learning techniques.
Developers are in the hot seat
Major cloud providers, such as Amazon's AWS and Microsoft's Azure, offer IoT solutions based on serverless functions, but business and implementation logic of those IoT services are still left to an organization's developers, which can impact security.
Make no mistake, those developers are being challenged to deliver business functionality on time with the right feature set after rigorous testing. All their attention is focused on the functional requirements of their projects, with little attention directed at non-functional ones, such as security. In addition, many developers are inexperienced with security best practices
While the Night Dragon attack, which began with a vulnerability that opened the door to a malicious code injection, was directed at the application layer of a web server, the technique can poison flawed serverless code used for IoT services, too.
For example, in Lambda—AWS's serverless compute service—a developer could build business logic to consume the inputs from a sensor or IoT hub. The logic might analyze the inputs, convert it to data, and then send it back to core services to process and store. If that business logic contains a vulnerability, malicious code can be injected into it, and it will become a weak link in the IoT platform.
Even if a vulnerability is identified in one version of a build, organizations need to carefully track changes made in code used to interact with their IoT devices. Application security programs must aim to keep vulnerabilities in check and manage them for the entire organization. They need to include static analysis, composition analysis, and dynamic analysis as part of the application release cycle process.
And they need to perform those analyses sooner rather than later in the development process. If a vulnerability is identified that's been present for a long period of time, it will take more time and money to fix it than if it's identified early.
How to keep vulnerable code out of your IoT
In addition, there are some basic precautions you can perform to guard against vulnerable code creeping into your IoT platform.
Here are four of them:
Do a static scan (SAST) of your serverless code to identify security weaknesses in API calls that can directly be mapped to vulnerabilities such as command injection, SQL injection, and so forth. Continue to monitor those specific calls with each new code release.
Download the serverless function as a zip file and do a static scan for security weaknesses.
Do a dynamic scan (DAST) of your code by invoking your serverless function or application and fuzz the event stream with customized payloads.
Analyze log data, as well as the output of the invoked functions, to detect and confirm a vulnerability.
Think good customer relations
As IoT and serverless services become more ubiquitous, keeping them secure will be critical for any organization that wants to be more cyber-resilient to maintain good customer relations and the integrity of its brand.