Security Framework
6 : Permeation of Trust in the IIoT System Lifecycle
The trustworthiness of a technical component is not just defined as the sum of the trustworthiness of its subcomponents . It is the responsibility of the component developer to assure that the subcomponents are working correctly together with their specified capabilities . Weakness of a single subcomponent may lead to the loss of trust into the whole system . For example , one incorrectly selected hardware component with a smaller temperature range than specified for the system may lead to a complete system failure as soon the system temperature exceeds that component ’ s temperature range . Or a single software component with limited security behavior may compromise the security of other software components and finally the entire system .
In operational technology ( OT ), safety certification requires the fulfillment of national and international standards and national law , which generally requires rigorous tests , typically confirmed by authorized independent test laboratories .
In information technology ( IT ), it is less common to implement rigorous safety compliance tests . However , it is becoming more common for components designed for the consumer market to be applied to industrial purposes , but their resilience may not be up to industrial standards . Moreover , the lifespan of products for consumer markets are usually much shorter than required in industrial usage . In either case , any shortcomings in the IT element ’ s trustworthiness may have unacceptable negative effect on the OT process . Industrial-grade products are available , but they must be explicitly sought out .
When software publishers include software subcomponents , a patch may not be available because the publisher of the subcomponent no longer supports it . Even if the source code is available it may be difficult to understand and limited access to the required elements in the code-build environment may inhibit fixing any bugs .
Many software products have application programming interfaces ( APIs ) that other software products depend on . Software publishers and SaaS publishers must keep such interfaces consistent or at least backwards compatible during the lifespan of all IIoT systems that use them .
Many SaaS services are IT-based and human-interaction oriented . Small and frequent changes in user interfaces are easily accepted by must human users , but making such changes in remote API can diminish the trust in the SaaS publisher .
Replacing hardware components or updating software components during the lifetime of a system involves the risk of non-authentic copies , including illegal chips from gray markets or malicious modification of software during the update delivery process . The former can be addressed by adding unique serial numbers , registered with specific production dates , while integrity protection works well in keeping software updates authentic .
6.4 TRUST AT SYSTEM BUILDER ROLES
A component builder can stretch the cost of development and rigorous testing of sold components over time . A system builder , on the other hand , delivers an operation-specific system that must be cost-effective with the first design . As a result , it is common for the system
IIC : PUB : G4 : V1.0 : PB : 20160926 - 42 -