Software Trustworthiness in the IIoT

Software trustworthiness – what does it mean for developers, owner-operators and decision makers in Industrial Internet of Things (IIoT) systems? The Industrial Internet Consortium (IIC) recently published a white paper, Software Trustworthiness Best Practices, that delved into the complete software lifecycle process, including such practical issues as software updates and end-of-life strategies, as well as among many other issues, considering vulnerabilities in the system environment and the consequences of failure in such environments. The overall objective of the white paper was to take a comprehensive look at all of the elements involved in achieving the ultimate goal of trustworthy software and protection mechanisms that produce predictable and desirable business and operational outcomes in the IIoT.

The white paper referenced a hypothetical example of a “smart” refrigerated cargo truck throughout to illustrate the effects of many of the factors that could impact the operation of the truck and how architectural design principles could be incorporated in the software to protect the truck and its cargo from malicious activities.

Let’s first understand how the truck model was described in the white paper:

A refrigerated truck that has a smart air conditioning system for its cargo, controlled by sophisticated software that reduces energy consumption by predicting the outdoor temperature along the route, can be susceptible to attacks and hazards. The software receives the temperature of the cargo area and outdoor temperature readings from different sensors on the truck. UV sensors on all sides of the semi-trailer provide the intensity of the sun. The software is responsible for the safety of the load. It ensures that the cargo remains within a specified temperature range and warns the driver if it is not, in order to prevent health issues with food. The goal is to reduce the energy for cooling or heating optimized by the weather forecast along the route. The software receives the weather forecast for the planned route from the navigation system and the Internet. All components use the truck’s Controller Area Network (CAN) bus.

Now, what were some of the design goals that could be employed to ensure trustworthiness of the software controlling the truck operations?

Software protection needs to be planned at the design stage as the design and structure of the software affects the levels of protection that can be achieved:

The software architecture must be easy to verify and test that the safety of the cargo has a higher priority than energy reduction and that measures are taken to keep the temperature within permissible maxima and minima constraints. There must be clear mechanisms to raise timely early warning alarms to enable the truck operator to take remedial actions as well as mechanisms and methods to log and record measurement, decisions, and remedial actions. The design needs to articulate clearly the rationale and reasons why certain design decisions were made, such as the number of temperature sensors and their location. To enable independent testing of software modules the design needs to allow different modules to accept input from the same temperature sensors. Software protection techniques need to be applied from an early point in the cycle to ensure that the design is protectable, to allow early validation of performance metrics, and to enable for early validation of the achieved level of protection.

Dynamic testing should be run continuously as the system evolves, including deployment and maintenance:

Efficient testing requires the ability to input sensors and to monitor control output values or any commands sent to other pieces of equipment. A design and test methodology that allows for the development of test sets and software algorithms in a virtual (or modeled) environment allows for the rapid debugging and validation of both. System level tests can be reused to validate the final hardware product. The analysis of test results should be automated as the quality of repetitive human evaluation degrades over time.

While functional testing is focused on the correct operation on the system, security testing is focused on trying to subvert the system by misusing it and abusing the functionality in an attempt to get the software to do something it was not intended to do.

System modeling greatly aids security testing as one can now disturb a model more invasively than a real device on a system. Plus, any additional test functionality inserted into the design is never used in a production build. Predictive tests need to be developed that can accurately predict the expected resultant actions of the systems allowed with a set of acceptable tolerances. For the truck, we should generate various combinations of temperature measurements and alter incoming weather data and door position sensors. Where these input devices are external to the main electronic control unit, the communication links between them need to be stress tested.

Software protection seeks to ensure software is not the target of an attack. Software protection is implemented to add specific well-defined defensive properties and should be applied after all the ‘software lifecycle management’ processes and techniques have been executed.

During the design process, designers need to identify data, calculations, decisions, and configurations that require protection and determine how to harden the code. For example, using software protection to harden the algorithm that ensures the safety of the cargo has a higher priority than energy reduction hardens a vulnerable and critical decision-making function. Using data to protect variables in use and then entangling that with the decision-making sequence makes it harder to alter. Binaries must be pen tested to validate defensive techniques that have been implemented. It is not economic to pen test every build. As weaknesses will be remedied subsequent to pen testing, any software protection techniques need to be automated and repeatable to ensure incremental and repeatable levels of achieved security.

This is just a brief snippet of the plethora of considerations for the trustworthiness of software and protection mechanisms for systems in an IIoT environment addressed in the white paper. If this is an area of your interest and concern, I highly recommend you read the complete document, Software Trustworthiness Best Practices, which was co-authored by IIC members Mark Hermeling (GrammaTech), Frederick Hirsch (Fujitsu), Bob Martin (MITRE), Simon Rix (Irdeto), and me, along with several other contributors and editors from IIC.