Devices are fraught with cybersecurity challenges, pushing teams to analyze the security status of every component twice. Once as a stand-alone system and again as a part in the greater system that makes up a product.
Yet, increasingly software-defined products harbor exponentially growing code, making reviewing a single product, its systems, and the systems that operate those systems a time consuming and inefficient process. Not only do security teams lack the resources to pull off such a feat, but it’s also an unscalable process that if not conducted properly can put an organization, or even the life of a consumer, at risk.
In today’s product security world, development, architecture, product security, and PSIRT members should have a process that allows vulnerabilities to automatically make themselves known and prioritized, not the other way around. History has shown favor to cybersecurity practitioners who ask key questions, such as ‘Will our system remain secure if we put two components together?’, ‘What kinds of new risks will this connectivity bring?’, ‘What is the potential impact of a vulnerability on the entire device?’, etc.
This approach of viewing a system as part of a greater whole, is what we call a System of Systems approach.
For example, when a team of engineers introduces components into the overall device or product, such as a braking system in a car or body temperature monitor in a medical device, it is no longer stand alone software. The entire device must be reviewed again to understand if the newly introduced software created vulnerabilities or threats.
One reason for this can be that the integration opened a port, allowing for a new flow of information that was not considered during the initial cybersecurity tests. Another can be the introduction of a component from the supply chain into the overall system, that results in new vulnerabilities inadvertently being added.
Whatever the source or the vulnerability, if it is high risk, it needs to be identified and mitigated fast. That’s only going to happen if security teams have the most up-to-date information on which components need attention along with their level of urgency.
System of Systems to streamline development
Until now, traditional alerts have been the go-to standard for many cybersecurity platforms, demanding precious time and resources from various cybersecurity teams, without the promise of high security impact.
Cybellum’s Product Security Platform allows security analysts and system architects to gain a full system view, pinpointing the component that presents the greatest threat to your products along with information about the vulnerability. If one CVE is triggering multiple warnings, practitioners can use the System of Systems features to identify the new vulnerability along with how many products it impacts.
To start, a team member can open the dashboard and be greeted with a quick model of a product’s software components, while also gaining insight into their component’s architecture, security score, vulnerabilities, and the total number of remaining tickets.
With this critical information, they can clearly communicate priorities and remediate problems in a virtual environment before deploying a finalized patch to the development team or directly to devices already in the field.
Zooming in on product architecture
Mitigating a vulnerability can be time consuming, forcing cybersecurity teams to dedicate precious human capital to find a solution for the seemingly never-ending list of problems.
Cybellum begins with a bird’s eye view of the product’s full System-of-System and its cybersecurity overview.
From there, users can adjust, add, and remove their Cyber Digital Twins (CDT) to gain a new simulated perspective on securing their products.
For example, an infotainment system may introduce risk into an otherwise secure system. In response, engineers can use Cybellum’s capabilities to model the introduction of a firewall and see updated risk calculations with the addition and removal of each component. They can then use this new architecture to conduct assessments with various Impact, threat scenarios, and analysis tools.
Finally, this overall ‘System of System’ overview instantly identifies for relevant stakeholders on where they need to drill down into the underlying risk triggers. An example of this is if a certain sub-system or component, such as an infotainment system, introduces new unacceptable risks, which could impact mission critical components such as the brakes, then product security teams can focus their efforts on those.
As components are replaced or updated with newer versions, the SBOM, found under the ‘software’ tab, is automatically updated to inform teams of newly relevant CVEs today as well as keep them up to date in the future.
Protecting cyber-physical systems
It’s no secret that product security teams are under unprecedented pressure to provide more comprehensive security coverage across a growing number of product lines. This stress can be compounded if the implemented security technology lacks the full contextual capabilities necessary to understand the subtleties of cyber-physical systems.
Empowering cooperation with Cybellum’s domain-expertise technology means they can quickly login and get a full rundown of the full system, along with what’s needed to secure each component within it. That means teams can replace noisy alerts that are common throughout the industry with the detailed information needed to secure any software component, from the full system down to a specific firmware packet.
