Direct co-operation with customers is necessary to ensure taking their perspectives into account from early stages, and to document all risks together, when possible. Co-operation enables continuous monitoring of the progress of implementation of controls to reduce risks to acceptable levels for the clients. Certainly, producers may not be able to co-operate directly with all customers (particularly for mainstream products) – which is where security by default plays a particularly important role. Challenges However, it is not possible to address all possible threats, otherwise it becomes impossible to allocate resources effectively. Quantifying risks and creating a heat map of aggregated threat actor tactics, techniques, and procedures (TTPs) – such as by applying MITRE ATT&CK and MITRE Shield frameworks, as well as the CVSS model - enables prioritisation of risk in product development or during the product life cycle. It enables the producer to see what the ‘low hanging fruits’ for adversaries are and address them, and then move to addressing vulnerabilities that are harder to exploit.4 Threat modelling requires observing the context in which a product or service will be used. This requires the involvement of customers, who often lack necessary insight of the process flow of the application, its ‘ingredients’, system architecture, and third party components. This calls for greater transparency from producers. The Software Bill of Materials (SBOM) may be a model to follow and contribute to, as a process that aims (through white papers for the industry) to address transparency in software, and clarity on how to address threats and supply chain risks. On the other hand, in most cases clients (particularly customers) do not have the necessary resources, capacity, or capability to continuously perform threat modelling, and producers may assist them through capacity building activities. Producers of widely used products face a particular challenge in threat modelling based on the context in which the product will be used. One current approach is to put a clause in the contract about what kind of services can be run on certain products. This puts the expectation on customers to do their own risk management, risk analysis, and risk prioritisation exercises for particular applications of a product. It has become increasingly important to clarify mutual roles and responsibilities with clients and customers. This can be done by appreciating the RACI (responsible, accountable, consulted, and informed) responsibility assignment matrix, such as the Shared Responsibility Model advocated in Cloud Service Providers. 3.2 Supply chain and third party security A common industry practice is to incorporate both proprietary and open source third party5 components (TPC) into product offerings - whether it’s software, cloud services, devices, or integrated systems. Poor implementation of security standards throughout the supply chain can create vulnerabilities to the broader ecosystem. Therefore, third parties constitute one of the leading cybersecurity risks. Protecting product development processes from unintended or malicious third party interference (whether from other producers supplying vulnerable components or adversaries interfering with updates or patches) requires a whole-of-sector, multi-actor approach to supply chain risk management (SCRM). The ‘Common risk-based approach for the Digital Supply Chain’ of the Charter of Trust’s second principle ‘Responsibility through the digital supply chain’; suggests that one of the basic standards for supply chain – besides identity and access management, and encryption – needs to be continuous protection: ‘companies must offer updates, upgrades, and patches throughout a reasonable life cycle for their products, systems, and services via a secure update mechanism’. Discussion The concept of ‘duty of care’ for supply chain is increasingly being discussed in various fora. It suggests producers need to ensure that their own components are safe and up-to-date. In addition, suppliers should be transparent about what third party components they use in their products, and provide information about security assurance of third party components. Not all vulnerabilities need to be exploited by adversaries: some may cause faults in operations, or present risks in other ways. The term ‘third party’ is used to denote a party of the supply chain that may or may not be in a direct relationship with the producer, and which contributes to the criticality of the function or essential service of products, regardless of whether it is a third party in the literal sense, or a fourth, fifth or further down the line. 4 5
10
Security of digital products and services: Reducing vulnerabilities and secure design
