All modern critical infrastructures rely on digital supply chains to a greater or lesser extent. Somebody needs to acquire the digital goods and services that keep the critical infrastructure running, but how can one ensure that this is done in a manner that guarantees security? The NIS2 directive (Recital 56) identifies small and medium-sized enterprises as particularly vulnerable to supply-chain attacks, but acknowledges that cascading effects have the potential to affect even large enterprises.
Ensuring that people involved with buying goods and services have sufficient procurement competence (which includes knowledge about the organization, security, integration aspects, procurement rules and regulations, and legal aspects) is a core element in supply-chain security, but it is difficult to formulate concrete requirements that cover it. Big operators are naturally better at this than the small ones, so procurement alliances may be the answer for smaller actors. All critical infrastructure operators need to have a complete overview of their supply chain/value chain, and by implication so do their vendors, in a recursive manner.
The critical infrastructure operator (or customer) needs to perform a periodic risk assessment of vendors; this implies that vendors need to agree to assist in such assessments. Such assistance may be in the form of providing access to third-party evaluation/certification reports; it will be up to the customer to decide whether this is sufficient. The NIS2 directive (Recital 90) encourages performing coordinated risk assessments for specific critical supply chains.
Some smaller operators are very dependent on their IT services vendor, therefore, it is paramount to establish how a vendor can assist in a crisis such as a cyber attack. This must be included into the contingency planning, and it is clear that if the contingency plan assumes a certain level of support from the vendor, this assumption must be verified and documented. Furthermore, these vendors must be included in any contingency exercises that involve their services as an additional way of verifying these assumptions.
Moreover, it is recommended that operators ensure redundancy between vendors, so that if one suddenly becomes unavailable, an alternative is accessible. However, it must be carefully evaluated what is practical/possible, and what is the acceptable delay when switching between providers. Few operators will be able to afford two live providers ("hot spare"), so this will have to be a trade-off between cost and performance.
When procuring services supplied by a vendor, a critical infrastructure operator needs to consider the physical location of servers. When personal sensitive information is involved (i.e., covered by the GDPR), all servers should be located in EU/EEA countries (up until recently, Schrems II has been making it difficult to use US servers, and even though the new EU-US Data Privacy Framework is set to resolve this, the same was thought about the previous Privacy Shield and Safe Harbor agreements). Servers processing/storing information related to national security may have stronger/other requirements, and these may be non-overlapping with the GDPR requirements. Location of employees with access to sensitive information should have similar restrictions (servers in EU/EEA should not be accessible from other locations).
When procuring complex hosted services such as cloud services, it must be ensured that the operator retains ownership of both the data input to the service and the results of any processing. Furthermore, it must be contractually defined how this data can be transferred in case the operator wants to change vendor, or simply in-source the service, and any costs involved must be defined upfront. This should form a part of a defined exit strategy.
When buying software, operators must be aware that nowadays software vendors rarely write all their software from scratch; the vast majority use different software libraries to a greater or lesser extent. The NIS2 directive explicitly encourages member states to use open source security software, which will include open source software libraries. The various components that form part of a given piece of software should be documented in a Software Bill of Materials according to a recognized standard. This will enable the operator to independently verify whether the software is susceptible to any newly discovered vulnerabilities in such libraries, without having to rely on the vendor, as well as to be better placed to implement mitigating actions while waiting for a patch or an update.
A vendor should have a documented Information Security Management System according to accepted standards; an ISO/IEC 27001 certification would be a plus, but "walking the talk" is just as important. There are other frameworks that provide similar benefits, such as the US NIST CyberSecurity Framework. Beyond this, however, is the ability for the vendor to demonstrate systematic adherence to recognized secure software development practices. There are a number of such frameworks, and each may have their advantages and disadvantages, so choosing one or multiple is up to the individual organization. However, the maturity of any secure software development lifecycle can be assessed with schemes such as the OWASP Software Assurance Maturity Model (SAMM) or the Building Security in Maturity Model (BSIMM), providing the customer with a way to choose a more mature development organization.
Once software solutions have been developed, they should be hardened as part of deployment – all unnecessary services should be removed, and all unused ports should be closed. This is an obvious requirement when a server is running in a vendor data center, but challenges may exist if solutions are deployed on customer premises and operated by the customer (i.e., critical infrastructure operator). In the latter case it will be difficult for a vendor to guarantee the hardening of a system, beyond delivering everything in a locked-down state.
Despite diligent use of secure software engineering practices and appropriate hardening, it has to date proved impossible to develop software that is 100% error free, and vulnerabilities are thus discovered in all kinds of software. Thus, it is important that all vendors have a process for vulnerability management that covers discovery, reporting and distribution of patches/updates in a timely manner (See also NIS2 Directive Recital 58). Operators should furthermore be able to monitor the performance of a service provided by a vendor, not only to detect any anomalous behaviour indicating an attack, but also to verify that the security functionality promised by a vendor actually performs as it is supposed to.
Comparing apples and oranges is a difficult exercise, and therefore it would help if vendors would use the same format when describing their offerings. Such a format is provided by the US Vendor Security Alliance in their VSA checklist. This is a benefit to both customers (operators) and vendors; the former can more easily compare offerings, and the latter can use the same format for describing their offering to every customer, not having to re-invent the wheel each time. It could be argued that European Critical Infrastructures should not rely on an American checklist, but this could be an area for further study in EU-CIP and related projects.
Further reading: https://jaatun.no/papers/2023/A_Checklist_for_Supply_Chain_Security.pdf
Martin Gilje Jaatun, SINTEF Digital, Trondheim, Norway, September 2023
