Additionally, paste this code immediately after the openingtag:
The President’s Executive Order signed on May 12th to improve the nation’s cybersecurity directly relates to the trustworthiness and transparency in ALL digital infrastructure (IT, OT, IoT, IIoT). Anything that runs software is in scope – cloud services, on-prem application servers and connected things – all systems that provide critical functions.
The modern approach to cybersecurity is Zero Trust – don’t place all faith into a single component, ensure you have a backup, spread risk and authenticate often. Typical IoT solutions & devices rely on standard approaches to authentication, such as PKI certificates, which offers a way to verify device identity for network systems & applications.
However, many other systemic issues such as firmware bugs, cloning, or missed maintenance SLAs can mean the device and its data is not trustworthy.
A device with a legitimate certificate can still pose serious security and compliance risks to an organization since rogue software or malfunctioning equipment will have privileged access to the network and enterprise resources.
Rogue or malfunctioning software is difficult to spot, and often stems from the lack of transparency in development of commercial software. A one-shot security evaluation or pentest is not enough – proof of security and safety must accompany any software throughout its useful lifespan. The Executive Order calls to equip federal users with a new defense that will deliver trust through transparency: the SBOM.
The Software Bill of Materials (SBOM)
The SBOM is a living document that accompanies any software either directly or through a public website to help identify and mitigate risk on a recurring basis for any and all software components in use.
If you consider the wider implications in a deployment of 10,000 connected devices, tracking SBOMs quickly becomes daunting: Organizations will need to track the SBOM for each device, which is especially challenging in a mixed estate of proprietary and open-source software from different vendors with vastly differing technologies and different operational priorities.
The issues to overcome are:
· Assuring integrity, provenance, and transparency of SBOM data to build trust
· Governing the complex sharing and privacy rules of data assets between multiple organizations
· Continuous tracking and automated reporting of compliance to policies
· Connectivity to operational security systems that can automatically act on SBOM data
Read on to find out how Device Authority and Jitsuin solve these SBOM challenges to deliver real-time Zero Trust defense with assured SBOMs at scale.
Identity Access Management platforms provide a framework of policies and technologies for ensuring that the right users and IoT Devices have the appropriate access to technology resources. Device Authority’s KeyScaler IoT IAM platform provides trust for IoT devices and the IoT ecosystem to address the challenges of securing the Internet of Things. Delivering simplicity and trust to IoT devices for automated device provisioning, authentication, credential management, policy-based end-to-end data security/encryption and secure updates.
Jitsuin’s RKVST Data Assurance Hub is built on distributed ledger technology specifically to automate trustworthy metadata sharing, compliance and provenance for any critical asset, for all to use through simple APIs. RKVST tracks SBOM assets and events performed by all parties involved in the software lifecycle, from package creation and deployment to vulnerability notification and mitigation.
Integrating Key Scaler and RKVST improves cybersecurity by reducing the risk of compromised device data from entering critical enterprise data and analytics systems. Automated and compliant zero-trust decisions are underpinned by transparent checks on all SBOM events.
How does it work?
The following diagram outlines the KeyScaler and RKVST combined Zero Trust SBOM solution:
Sideband checking with Jitsuin RKVST verifies the device posture against supply-chain wide risks and returns a compliance check along with traceable reasoning for a decision.
If the device is running a previous known good version of software, that may be adequate – for now – since operational function may take precedence over potential risk.
If validity check fails on step 7, KeyScaler can place the device in quarantine with a provisional PKI certificate or credential. Throughout the lifespan of the device, it will check in to KeyScaler and perform step 5. If compliance fails then KeyScaler can be configured through policy to automatically quarantine a devices’ certificate, meaning it can be placed onto a remedial pathway. This is just one of many potential implementation options.
As a bonus for Device Makers: Since SBOMs must be made available, Device Authority can help you by also recording its KeyScaler Agent SBOM in RKVST to efficiently communicate component package updates.
Please wait while you are redirected to the right page...