Defining Product Security: History, Challenges, and Solutions

As hacking techniques mature, so does cybersecurity. So, how can we use the same lessons learned in IT and OT cybersecurity for our embedded systems?

Product security focuses on cyber-physical devices that are mission critical, such as medical devices, industrial equipment, or modern connected vehicles. Having secure facilities is critical, but so is securing the devices that run on them. They contain embedded devices running various software components, each of which must function as intended without vulnerabilities that may give threat actors unauthorized access.

All three of these example sectors demand that operators focus on both safety and security. While the danger of poor safety practices are clear, security risks include privacy, information leakage, IP theft, and more. 

Now that we understand the importance of Product Security, how can we define it? Let’s break it down:

Cars

Vehicles rely on a highly complex software supply chain that includes both custom and open source software, much of which is structured within the AUTOSAR architecture. In addition, much of this software is capable of remote access, opening it up to potential vulnerabilities.
OEMs and their suppliers work tirelessly to scan their code and find any potential for threat-related manipulation. However, with millions of lines of code per vehicle (some more than a modern fighter jet), it’s a daunting task that can’t be achieved with manual combing.

A full product security approach is needed, including threat modeling, vulnerability management, and implementation of a cybersecurity management system (CSMS) to generate reports and comply with regulations. Once these are completed, companies can comply with WP.29 and begin building their product security incident response team (PSIRT).

Medical devices

Patient care relies on accurate, secure, and uninterrupted service from machines that operate in facilities and in patient homes. The safety risk for medical devices range from risk to life or limb to a diminished quality of care, resulting from inaccurate readings. 

The high reliance on these devices also makes them a prized target for threat actors to hold a person or facility at ransom, potentially denying them the life-saving services they rely on. The problem becomes increasingly complex when considering that these devices are made up of potentially hundreds of embedded components, each with their own vulnerabilities. 

While inaccurate readings may seem like an inconvenience, it can be the difference between life and death considering that today’s connected devices include MRI machines, infusion pumps, insulin pumps, and homecare devices that allow for a higher quality of life with remote monitoring.

Industrial manufacturing and critical infrastructure

Industrial equipment and critical infrastructure have increasingly become software-defined devices. This mixing of potentially legacy devices fixed upon even older non-connected devices leaves these highly prized targets exposed to safety and security concerns which can impact large regions and population centers. These connected products are prone to attacks by malicious state-sponsored groups or prize-seeking hacking groups who can hold entire utilities for ransom.

Product security addresses these by understanding the unique mosaic of tools that operate on both critical infrastructure and manufacturing systems. At the same time, the US government is enhancing its reporting capabilities with CISA’s RVWP initiative and by implementing SBOM & VEX minimums.

Debates on the definition of what is an IoT device has been raging for years since they are independent, often simple, devices that require connectivity to function. They are independent products that are embedded into an existing network.

In industrial settings, they can serve as sensors, cameras, thermostats, and more. They can also potentially act to support larger projects when used collectively. However, IoT’s scattered nature of manufacturers and a lack of standardization across the industry makes them inherently limited and at times challenging to integrate into existing systems. 

These challenges, along with a lack of standardized security requirements, make them a hazard for security teams that may struggle to identify the device on their network, let alone secure it. For this reason it’s important to distinguish between standard home or office IoT devices and safety critical devices, which are developed to operate securely in mission critical environments. Safety critical devices also need to operate in line with local regulations, requiring them to be continuously hardened through updates.

As connected products increasingly demonstrate their capabilities in the field, manufacturers are adding more functionality with more interdependent embedded systems. Conducting security scans and assessments on these products relies on manual processes made of multiple disjointed tools, which were intended for IT, OT, or different cybersecurity disciplines.

Shifting to a Product Security-first platform, teams can generate Software Bills of Material (SBOMs) and manage them over time, always identifying all the latest components that make up a product. Once that information is approved, companies can rely on that information as a source of truth, assisting teams with identifying and prioritizing vulnerabilities, conduct threat modeling activities to prevent future breaches, and preparing PSIRT teams to rapidly address a breach.

The discipline of full lifecycle product security was created to help the teams who secure these machines from the beginning of development to the end of a system’s life.

A present risk from the beginning of development is the challenge of securing the software supply chain. 

This supply chain, just like ones developed for physical goods, are fed by third-party suppliers whose code is embedded into a greater system. If a supplier fails to follow best security practices, rushes a project, or just overlooks a present vulnerability before delivery, that danger risks hitching a ride all the way into the field where it can be exploited.

The impact of this cannot be understated.

However, steps are being taken by private and public entities to prevent these vulnerabilities from ever entering a device in the first place. 

An example of this is through regulation. Executive Order 14208 demands greater transparency into coding practices, open source software (OSS) usage, and other vulnerability management steps. Drilling down into sectors:

• Automotive follows WP. 29 R155 & R156, ISO/SAE 21434
• Medical device manufacturers follow new FDA standards + Omnibus, IMDF, and CRA in the EU. All place tighter boundaries on what information can be collected, stored, and shared.

Industrial equipment manufacturers fall under CISA’s SBOM, VEX, RVWP, NIS2, and other guidelines.

Despite the varying challenges faced by each sector, each has a common goal– securing the entire product lifecycle across teams , product lines, and business units for any device that contains software.

Since product security touches upon multiple disciplines, from regulatory compliance to product quality assurance, incident response and more, the person responsible for product security can vary from company to company. For companies still early on in their product security journey, they may assign responsibilities to their quality control team, compliance team, or other executives within the organization.

The reality on the ground shows us that ownership can vary based on industry. Our Medical Survey found that product security owners are placed in more senior roles while our Critical Infrastructure survey found the owner varies on a company by company basis.

However, the Chief Product Security Officer (CPSO) function is more and more common, allowing for the introduction of a product security management center and dedicated Product Security managers.

Generating Software bills of materials is crucial for identifying vulnerabilities. However, the software components within each product are continuously going through change. Whether to improve functionality or prevent threats to a device, the SBOM created during development will vary greatly from the one on the production floor or the one in the field. 

To keep all stakeholders up to date on their product’s current security posture, product security teams are adopting the notion of a dynamic SBOM. With each software update or adjustment, an automated workflow is triggered to scan, update, and send out each bill for approval, allowing for life-long management of each device’s individual SBOM.

This continuous updating, allows for better vulnerability management across the entire organization.

Quality testing includes security testing. Teams relying on outdated SBOMs are unable to ensure the most up-to-date quality reports, costing companies time and resources while greatly increasing their risk exposure.

Whether looking to begin a new project or build upon an existing device, development teams need to understand what’s happening today in order to plan for tomorrow. 

Dynamic SBOMs allow them to see what has been changed, how vulnerabilities have been mitigated, and review VEX reports that ensure previously addressed vulnerabilities aren’t reactivated when embedded in a new device. 

With Cybellum’s Product Security Platform, managers can keep track of security, risk, and SBOM management activities. A dashboard that breaks down activity and standing ensures greater efficiency while allowing for better risk management.

Vulnerability management

Think of vulnerability management as a way to keep an eye on potential weak spots in our products and fix them before bad things happen. It’s like checking your house for open windows and doors to make sure burglars can’t get in.

To make sure our products are all buttoned up and secure, product security teams focus on:

• Understanding real risk impact – With modern tools, we can figure out how risky a problem is. We look at all the nooks and crannies of a product’s software and see which problems are the most urgent to fix and which ones can wait.
• Reducing noise – Sometimes, the security tools make too much noise by alerting us about minor issues. New tools can help filter out the noise and show us only what’s relevant.
• Industry relevance: Different products have different needs. Tools can understand these needs and give advice based on what kind of product it is. 
• End-to-end management – Fixing problems in a product can be complicated. Tools can help with everything, from finding the issue to fixing it, making sure the product stays safe.
• Repeating the process: After we’ve fixed the problems, we need to keep checking to make sure nothing new comes up. It’s like going to the doctor for regular check-ups to stay healthy.

Threat Modeling

Imagine you’re building a strong, secure house. You’d want to plan for all the ways someone might try to break in and take precautions. This is what threat modeling is all about. Product security teams face this challenge head on by:

• Scrutinizing each component – When building a secure product, we need to think about every piece of it. We consider the security level of both good and bad parts to make sure we’re safe.
• System of systems – Sometimes, a product is like a puzzle, with many pieces that work together. We need to understand how they all fit and work to protect the whole thing.
• Staying secure at scale – If we make changes to a product, we should check if it’s still safe. It’s like double-checking your work to make sure you didn’t make any mistakes.
• Lifecycle security – Security isn’t a one-time thing. We need to keep it in mind from the start of an idea to the end of a product’s life.

Incident Response

Let’s talk about incident response, which is what we do if something goes wrong. It’s like having a plan for when you get a flat tire or lose your keys. Product security teams know that once the device is sent out to a customer, it’s entering a dangerous environment where hackers take advantage of its vulnerabilities for financial gain. 

To avoid this, specific teams put automated processes in place based on the work done during vulnerability management threat modeling. Comparing it against an up to date SBOM, smart tools allows teams to:

• Make sense of an incident – Investigating problems is like solving a puzzle. Tools can help organize the pieces and make it easier for us.
• Fix problems faster – The faster we can identify the root cause of the problem, the faster we can work on remediating the threat. 

Follow the rules – Just like driving safely to follow the rules of the road, we need to follow the rules for product security and report them back to industry-specific agencies. A product security platform helps Chief Product Security Officers (CPSOs) stay on the right path.

While product security may be an emerging field to some, governments, industry groups, and individual companies are proactively adopting a purpose-built product security solution. 

A security-first mindset for all teams, along with proper product security workflows, are enabling efficiencies that were not possible before. These include complete oversight over your product risk – from finding the riskiest supplier, to identifying the most impactful vulnerabilities to tracking the SBOM validation process across different business units.

To learn more about how the Product Security Platform can work for you, click here.

What is an SBOM and how can our organization begin our SBOM management journey?

A Software Bill of Materials (SBOM) is a list of ‘ingredients’, identifying each software component that was used to develop a device. Without giving away proprietary information, Product Security teams can use this bill of materials as a baseline to run vulnerability scans, manage risk, and ensure that their device retains a strong security posture years after it’s initial deployment.
The challenge for many organizations is updating these SBOMs throughout the development and full lifecycle of a product. Since they give a current snapshot of the state of a device from the perspective of it’s embedded software components, SBOMs must be updated with every new patch, software version update, or any other software-related update.
Maintaining this updated database allows for companies to react quickly to emerging threats while ensuring customers that their device will perform as intended regardless of where it is housed.
To learn more, read our guide SBOMs for Connected Devices- Getting it Right.

How can our organization begin encompassing rolling regulations into our product security workflow? 

CPSOs struggle to build secure products with minimum vulnerabilities when every day, 100s of new ones are discovered. Given the scope of changes regulations have brought with them, the approach of playing whack-a-mole with each new regulation or finding product security loopholes is untenable. It doesn’t hold up from a business perspective or operational necessity.
The key to strong and future-ready product security is to create robust, comprehensive, and foundational documentation that can be relied on for compliance as well as a source of truth. This documentation should be designed to measure KPIs, meet current compliance demands, monitor internal policies, and accommodate new regulations as they are rolled out. 

Building a strong foundation starts with reviewing current policies, understanding their strengths and weaknesses, and determining how they can be bolstered to withstand future changes. Building a managed product security workflow- one that is focused on future-proofing and safety by design- makes it easier to incorporate new regulations while maintaining a high level of product security. 

To learn more, read Rolling Regulations: Embrace them Don’t Chase Them

How mature is the discipline of product security?

Over the last few years, product security has gone from being rolled into an IT practice to becoming a discipline of cybersecurity unto itself. 

Previously, security teams relied on IT tools to identify vulnerabilities and mitigate risk, however they lacked the dedicated solutions needed to digest and mitigate vulnerabilities in a way that doesn’t impact functionality. Addressing this challenge demanded that organizations find a way to scan, manage, and secure their connected mission-critical devices without taking them offline.

Today, the Product Security Platform allows teams to incorporate dedicated workflows that automatically extract embedded software packages, scan for vulnerabilities, and recommend mitigations allowing teams to rely on automation to secure their products and reduce the cumbersome manual tasks of days past.

Listen to what our CEO, Slava Bronfman has to say about Product Security maturity in his interview Watching Product Security Mature or read the blog.