“With great power comes great responsibility”. Internet connectivity in devices, combined with more powerful software capabilities, introduces cyber risks that are inherent to the IoT world.
As 2021 starts, with 2020 behind us, it is time to reflect on the journey taken by our customers – the device manufacturers – in the ever-changing cyber threat landscape: from the initial realization that adding connectivity means addressing cybersecurity, until the point at which they can supply a certified, protected product which the end user can trust.
Organizations look at three basic ingredients when building a product security practice (a new domain for most, even those with an established IT security operation):
- People
- Program
- Budget
Product Security’s People Evolution
The journey normally starts with an R&D architect, or someone in IT security, who takes on the additional role of owning product security specifics. Initial steps towards the Product Security Program are observed.
These people soon realize that there are distinct differences between IT Security and Product Security; To learn more, read about it in this blog from research we concluded in May 2020.
Product Security professionals are much closer to R&D, involved in product definitions, testing and monitoring for security events, while the IT security team are normally focused on the company network and deployment of off-the-shelf products. The security event impact can go far beyond just negative brand impact and into business disruption.
As the role expands, dedicated personnel are usually assigned on the corporate level: small teams, maybe 1-3 people, look to align various product lines and activities into a single Product Security Program.
With this in place, and product security requirements starting to formalize, the business unit’s R&D leads – those responsible for the specific product – assign dedicated individuals to make sure product security is embedded into the development process, and the actual code, of their devices. These product-security champions have a good understanding of security, as well as of the specific of the products, the roadmap, and R&D capabilities. Organization-wide training for security, and even certification, is usually the way to get everyone on board on this new path.
At the most advanced level – normally in larger organizations that have significant concerns – the product security team expands to include practitioners who not only run the program at the corporate and business-unit level, but perform internal functions such as Product Threat Analysis and Risk Assessment (TARA), Penetration Testing, Product Security Incident Response Team (PSIRT), definition and implementation of security technology measures, etc. In some cases, we saw product security teams of over 100 people, spanning multiple business units, functions and geographic locations.
Establishing the Program
The Product Security Programs we meet in our customer base – in medical, energy, automotive, industrial IoT and surveillance – usually start small and grow as the program gain top management visibility and establishes clear internal processes.
There are number of distinct parts of the Product Security Program which can define its maturity:
- Security culture – on-boarding the engineers and management, including governance documents and defined responsibilities
- Secure development – from design to test, inserting security practices and tools into the development pipeline, and achieving the famous “shift to the left” for an SDLC (Secure Development Lifecycle)
- Security controls – the definition, technology selection (make/buy) and embedding of security measures into the device software, to assure the product is as a secured as needed in order to address customer expectations and reduce organization risk
- Security operations – the organization’s process and tools used to monitor and react to security events and to manage vulnerabilities, from bug bounty, active monitoring, and PSIRT to vulnerability patching OTA
The mix of the above four elements, and how much is invested in each, varies by company and by product. Some activities are better handled on a corporate level (such as a PSIRT process/tool that covers all product lines) and some are product-specific (prioritizing high cyber-risk products or the ones that are more significant for the company’s future).
Defining the Right Budget
The key driver of the journey is the amount (expenditure) that the product management and executives assign to the goals of Product Security. This dictates the scope and professional level of the people the organization has chosen to run the program, as well as the tools and technologies to embed within the product and the SDLC.
With Product Security being a new domain for all connected devices, and dependent on and correlated with the overall development of the industry, we see a wide range in the size of budgets assigned to product security. Criteria for such investment and top management (even board level) attention to the subject usually related to:
- Defined regulation and standards published for your industry (NIST, IEC, ISO, ETSI, FDA, local orgs etc.)
- Attention from hackers (White Hat exposing product vulnerabilities publicly and Black Hat ones in actual attacks for money or damage)
- End customer security demand/concerns as represented by RFPs and other official and unofficial communication channels
- Competitive activity (related to the above demand, making security a differentiator) *
* Some organizations are now utilizing product security as a differentiating feature. While adherence to emerging standards is becoming a key inhibitor from winning contracts and customers’ budgets, some companies, such as HP Printers, are showing how product security can be a marketing tool, used to differentiate their product and set it apart, beyond functional excellence.
Normally however, like in IT security budgets, the investment in Product Security is not generating new revenues. Customers don’t yet buy security features as such. Product Managers and Product Planning are looking to understand the business case for the investment, and the budgets will be eventually associated with overall R&D budget for the product and IT budget for the company. These business leaders should also expect a constant and well-planned increase in product-security budgets over time since with the great new opportunities of the internet connectivity comes the costs of product security.
Conclusions
Over the last four years, we’ve seen tremendous progress in the product security journey. The needed role has evolved from an almost unknown function, with little impact on the organization, to Chief Product Security Officers in key companies.
Companies now dedicate many more professionals to Product Security positions, to define and operate elaborate programs. In those programs they impact product development processes, introduce embedded security controls to the code, and oversee continuous monitoring and patching of vulnerabilities.
While some are still in the early stages of the product security journey, many IoT manufacturers are stepping forward to block IoT attack vectors and assure a cyber-secure product to their customers.
Proficiency in this journey can take 2-3 years. Cybersecurity is here to stay and will be part of every IoT device within the next five years. Companies are taking active steps to protect their customers, their own brand, and the innovation business potential.
Update: Following the increase of supply chain attacks, Karamba has recently started to provide free analysis of software binaries, to list in-use open-source libraries, and also suggest free CVEs monitoring.
