Product security has been driving major changes throughout the automotive, medical, and industrial sectors. However, just a few short years ago, it was a term few knew and even less considered its own discipline.
Slava Bronfman, Co-Founder & CEO of Cybellum discusses his experience in watching the product security sector mature over the last decade in the recent episode of Left to our Own Devices podcast.
Bronfman has been an active member and contributor to the product security community since his military service. Serving in the Israel Defense Forces (IDF) he learned about cybersecurity and product security as it was done back then– manually. “There are a lot of places where you actually have to deal with product security in the military– equipment, industrial IoT, etc.”
Back then securing physical devices was mostly manual, meaning that vulnerability research, vulnerability management, and all the actions that go with them were tedious and time-consuming. There was no public threat database to help them understand a threat’s impact or priority level. Each discovery leads down its own resource-draining rabbit hole.
It was here that Slava met Cybellum’s CTO & Co-Founder, Michael Engstler.
Upon being discharged, they took it upon themselves to automate the entire process of securing physical devices, what’s now known as ‘product security’. After meeting up with Ronen Lago, former head of security at Daimler AG and current Cybellum advisor, they got to learn about the cybersecurity landscape in automotive. Upon reviewing security practices for manufacturers, suppliers, and how vulnerable the supply chain was, they decided to focus on that industry to start.
Maturity of product security
Since those earlier days, manufacturers’ mindsets have shifted relatively quickly to address the threats that continuously emerge against software-defined vehicles. “You know that the last few years in the product security world was like watching a baby grow up from practically nothing,” said Bronfman. “We didn’t even have the term product security five or six years ago. It was general.”
Back then there was the head of car security, who would usually report to the CISO, who would then retool IT security methods for physical products. Product security was not yet a defined discipline, leading to some of the early challenges in the field. “Looking at it today, one of the biggest changes is that we understand that product security is a practice with its own people, its own budgets, and so on. These teams are usually made of those who view themselves as peers to IT security teams within the organization.”
Going from being under-equipped to having full teams that report to a Chief Product Security Officer (CPSO) who answers directly to the board of directors is a welcome change.
Regulation
Much of the regulation we are seeing today, especially around SBOMs and the automotive push for ISO/SAE 21434 began as an idea to increase transparency through SBOMs.
“I met Allan Friedman about six years ago at Escar in Michigan. There was still no SBOM group, no NTIA group, or anything similar. Alan worked for the US government and said that there is a new initiative to start with SBOMs, and he was leading this activity.” It caught on with SBOMs being adopted by multiple industries, helping both private industries as well as the US Government.
When Slava joined ISO, some people believed that ISO 21434 should be a subsection of functional safety (ISO26262) because they believed it was one and the same. “This is a example of good collaboration between the European ISO and the American SAE,” said Bronfman. “I think that most of the OEMs in the world and the tier ones in the world combine forces and joined up with those organizations to really drive this standard forward”. This was achieved by ISO and SAE coming together and setting out to recruit OEMs for their input and participation in this global product security initiative.
Takeaways from working with manufacturers
While every company is unique, much of what they need and how they protect their devices are the same. Slava shared three things he has learned over the years:
1. Huge companies have commonalities across verticals and industries regarding processes, methodologies, and workflows. All need processes for vulnerability management during pre-production.
2. Where they differ is their frameworks, types of devices, and stages. “So I think a lesson that we learned is that we need to build a product that will cover the product security aspects that are common across industries with the right processes, the right reports, the right dashboards, and the right workflows. That will be the same pretty much across all verticals. On the other hand, we also understand that each customer is a project unto itself. You need to understand each customer’s proprietary bill of materials because every customer has different ones. You need to understand the architecture of specific devices and how to recognize specific stages in their lifecycle.”
3. While there are commonalities, as mentioned above, the differences appear when drilling down into implementation, so an off-the-shelf option doesn’t and can’t exist to meet every customer’s unique needs.
Managing product security vs. Doing product security
Just like in the IT world, product security needs to understand that vulnerabilities take you down a rabbit hole, generating more urgent tasks as you discover new details.
Detecting new vulnerabilities one at a time and researching them is part of ‘doing’ product security. You are going through the steps necessary to build a strong foundation, but what do you do with this information? How do you manage all of it to make it useful?
“Once you understand the risks, you need to mitigate them by releasing a patch. That worked five years ago when you had one connected vehicle and there were very few known threats to this ecosystem. Today the issue is that you really need to scale across so many devices and versions, some of them in the field, some of them in development, some of them in design.”
Looking back at what the IT security industry went through in the last 20 to 30 years, we can begin to understand the trajectory of product security. They too began by detecting issues, but today the IT security teams are not really just detecting, they’re actually managing it in the form of orchestration.
Just like IT, companies need to manage what they detect– including following up, rolling out patches, communication with customers, etc.
A big part of that is SBOMs
Slava shared that it has been great seeing people generate SBOMs as a critical piece towards impactful product security. However, without the management of these SBOMs, they can’t be synced to vulnerability management solutions. “Now we hear more and more people saying, “Okay we have all these SBOMs. We generated them, we created them, now how do we actually maintain them, keep them up to date? How can we actually confirm the SBOMs that we created, or the SBOM that our suppliers approved?”, and so on.” said Bronfman.
Ultimately, product security as a discipline has come a long way from a decade ago and it also has a lot of exciting, yet unknown opportunities that lie ahead. What’s important is for security teams to consider the unknowns by creating processes and workflows, which allow for the mitigation of vulnerabilities today and into the future.