Why industrial systems need continuous delivery

Mission-critical systems have a very different risk appetite than the latest mobile game or business application. The principle is simple: Code in mission-critical systems such as airplanes, cars, medical devices, and smart factories can’t have bugs. It’s simply not worth the risk.

That appetite for little or no risk has led to a development workflow that is rigorous and process-driven. Waterfall remains the foundation of these testing-heavy workflows. But the time has come to ask: Can the free-flowing, agile continuous integration and delivery (CI/CD) pipeline be used to modify the current approach to mission-critical systems?

The best mobile and IoT conferences of 2017

Connectivity changes everything

In today’s environment, the methods used to guarantee that there are no bugs in critical systems are starting to crack. Part of the difficulty is that planes, cars, and factories are maintained on a completely different timeline than most technologies.

Smartphones cycle on a one-to-two-year basis. Tablets and laptops last slightly longer, being replaced every three to five years. But it’s not uncommon for a plane to be in service for 20 years. Meanwhile, the malicious side of technology moves fast; 390,000 or more new malware samples are found every day.

How can equipment designed years ago cope with the threats and changing environment that exist today, when even planes and cars are connected to the Internet? The threat model that the mission-critical workflow was designed around no longer holds true. 

Does that put these systems at higher risk?

This is the question raised by recent research from Politecnico di Milano university and Trend Micro (my employer). Researchers from both organizations looked into the state of cybersecurity for connected industrial devices (IIoT).

IIoT cybersecurity

Mission-critical systems rely primarily on three things: physical safety, reliability, and accuracy.

In the case of industrial robots, they cannot harm the humans working around them, they need to work reliably, and they cannot make a mistake in their work. These robots build cars and planes, and they manufacture and package food products and medicines. There is zero margin for error.

Today, though, industrial robots, once purely isolated systems, are being connected to internal networks and, inevitably, the Internet.

Given the massive number of cybersecurity issues seen with systems connected to the Internet (WannaCry is a perfect if unfortunate example), it’s not surprising that industrial robots have very real cybersecurity challenges.

Open communications, memory exploits, insecure architectures, and other security gaps were found in IIoT devices. The mission-critical development workflow makes fixing these issues quickly a challenge. With advancements in attack methods, that delay increases the risk to these systems well beyond safety limits.

It should be noted that ABB, which manufactured the robot that was compromised in a case study in the report, responded extremely quickly when notified about the results of the research. It worked with the researchers to ensure the issue was addressed, and it made a patch available to its customers. 

But can the CI/CD pipeline help reduce the risk to mission-critical systems?

The CI/CD difference

Nothing has sped up development workflows more than the advancement of CI/CD systems. The idea is simple: By automating the entire pipeline from code commitment through deployment, innovation can happen faster.

To make these pipelines work, developers have started to push smaller and smaller incremental changes to their software. This makes it easier to spot problems and reduces the overall risk to these systems.

Testing is the key stage in any CI/CD pipeline. For most software, this means setting up mock objects and other simulations in order to isolate tests and segments of code. That is the main challenge in applying CI/CD to mission-critical systems.

Simulations only provide some of the needed assurance. At some point the code will have to run on the physical device. But as interesting (and fun) as it would be to have an airplane or MRI machine in the development team’s space, it is cost-prohibitive and won’t scale. 

Compartmentalizing both the code and physical systems will let developers improve testing and integrate those tests into a CI/CD pipeline. Looking at industrial robots as an example, you can test the actuators and the grip attachments without the entire arm assembly.

Physical test harness should be the last stage in a CI/CD pipeline for these systems, and only some of the tests (such as pre-deployment) should use them. This allows the team to write code in a highly iterative manner but to ship it only after the high level of assurance has been met.

That balances the speed required to react to today’s environment with the assurances needed for mission-critical systems. A smart approach to this problem will ensure that code exiting the pipeline is valid and of high quality.

Cultural change is needed

Significant technical hurdles are slowing the adoption of CI/CD pipelines in mission-critical systems. Those challenges will take time given the lifecycle of these systems.

Of more concern is the cultural shift required to adopt these development methods. Mission-critical systems have to be resilient and continually change to match their operating environment. That environment has now changed. 

Connectivity means that the growing number of cyberthreats can impact these systems. This is driving a requirement for rapid updates that can only be addressed by moving to newer techniques such as CI/CD pipelines.

The best mobile and IoT conferences of 2017
Topics: Security