Currently, within the IoT market today, device security provisioning is considered a ‘one-time’ event, and little is being done to solve the need for ongoing validation and integrity verification of devices.
This lack of continuous authentication ultimately leads to credential theft, and further compromise of other systems within the network.
With upcoming legislation such as EO 14028B, part related to Software Bill of Materials (‘SBOM’) requirements, customers need a more proactive approach to ensure that their devices are compliant and validated throughout the entire device lifecycle.
Recently, The European Union announced their intention to enact the Cyber Resilience Act, similar legislation to that of the US.
Software vulnerabilities are both the by product of the human process of developing software and the increasingly frequent target of attacks into the software supply chain. If users do not know what components are in their software, then they do not know when they need to patch during the change management process. They have no way to know if their software is potentially vulnerable to an exploit due to an included component – or even know if their software contains a component that comes directly from a malicious actor.
In May 2021 an executive order was signed by President Joe Biden, introducing the Software Bill of Materials (SBOM), but what is a Software Bill of Materials?
A Software Bill of Materials (SBOM) is a “formal record containing the details and supply chain relationships of various components used in building software”.
Effectively, an SBOM lists software components, information about those components, and the relationships between them. By listing this information, SBOM’s provide increased transparency, shows the source of the components, and increases the speed at which vulnerabilities can be identified and remediated by federal departments and agencies.
Developers, product managers, and security officers must ensure the secure design and ongoing function of any software product, including code embedded in various hardware devices
Company executives who want to thoroughly understand the risks inherent in their software products and future costs for maintenance
Any entity that sells or plans to sell software products, equipment, or devices with embedded software to the U.S. military or a U.S. government agency (compliance with Executive Order 14028)
Enterprise organizations and government agencies that utilize software from external vendors
Medical device manufacturers and healthcare delivery organizations like hospitals whose patients use life-saving devices with embedded software
Anyone who makes use of a software supply chain that isn’t under their full control Target industries includes Medical/Healthcare, Department of Defense/Military Industrial, Government
A further timeline has now been released
Utilizing SBOMs and Identity Management to reduce risk in supply chains
The device maker and software provider publishes the defined SBOM to a SBOM Data Hub, an example here could be RKVST SBOM Data Hub. SBOMs are published according to SPDX, Cyclone DX or SWID formats.
As part of the firmware installation on the IoT Device, the KeyScaler software agent is enabled. This can either be done by building in the software through the standard production processes before the device has been deployed or the KeyScaler software could be deployed as part of the next upgrade cycle i.e. through a retrofit / brownfield deployment model to support legacy devices.
Once the device has powered on and in operation, it can now authenticate, register and connect to KeyScaler. Through policy KeyScaler can automate the provision identities, tokens and keys to the device and IoT Application e.g. provision and manage PKI x.509 Certs to Azure IoT Hub.
Throughout the lifetime of the device, every time the device “checks in” and authenticates to KeyScaler, KeyScaler can request the devices to provide its current SBOM data (as set out in policy), this can then be used to validate against authorized published SBOM data i.e. what’s been published and assessed through the Data Hub.
Validating the current IoT Device SBOM data, through a Rest API call to the SBOM Data Hub
The final step here is to perform some level of remediation if required.
For more information about SBOM’s we have several resources that you may find useful.
