Supply Chain and NIS2

Indice

The supply chain is increasingly becoming a key focus for businesses, and it could hardly be otherwise: without proper supplier management, a company could indeed find itself indirectly affected by a cyber incident. This issue has already been addressed in several articles on this portal, including in relation to the Jaguar-Land Rover case and in a more general article.

Supply chain and contracts

NIS2 is accompanied by security measures, including the ACN’s ‘basic security measures’, many of which relate to the supply chain; the first measure to be examined is rule GV.SC-05.

GV.SC-05The requirements for addressing cybersecurity risks in the supply chain are established, prioritised and incorporated into contracts and other types of agreements with suppliers and other relevant third parties.Unless there are justified and documented regulatory or technical reasons, the security requirements set out in measure GV.SC-01, point 1(b) shall be included in requests for proposals, calls for tenders, contracts, agreements and memoranda of understanding relating to supplies that may have an impact on the security of information and network systems.

This measure requires NIS entities to include appropriate security requirements in tenders, calls for tenders, contracts and agreements. This security clause, which is also present in ISO 27001, albeit in less detail, is implemented through the inclusion of service level agreements (SLAs), incident response procedures and communication protocols. This security measure is particularly important and is often the most overlooked precisely because organisations do not contractually define the correct procedures for incident management and communication. Furthermore, service levels are often absent or poorly defined within agreements between the parties. It is an obligation, not an option, and they must be established but also prioritised (which implies a properly formulated risk analysis).

Supplier directory

Another aspect that is often overlooked is the supplier register, which does not ‘simply’ mean having a list of contracts containing contact details, but also understanding the security implications of each supply arrangement. Security measure GV.SC-04 is a prime example of this.

GV.SC-04Suppliers are identified and prioritised according to their criticality.An up-to-date inventory is maintained of suppliers whose supplies may have an impact on the security of information and network systems, which includes at least:

a) the contact details of the supply contact person;

b) the type of supply.”

It is certainly clear that the measure also requires the inclusion of general information (contact details, type of service), but it is in the initial description that the most important aspects emerge, specifically where it states “with potential impacts on the security of information and network systems”, which implies that appropriate analyses have been carried out with the involvement of the cybersecurity organisation. This is required, among other things, by measure GV.SC-01.

GV.SC-01The organisation’s stakeholders have established and accepted a programme, strategy, objectives, policies and processes for managing cybersecurity risks in the supply chain.With regard to the award of supply contracts that may have an impact on the security of information and network systems , including through the use of the central purchasing bodies referred to in Annex I.1, Article 1(1)(i) of the Legislative Decree of 31 March 2023, No. 36, the following are required:

a) the involvement of the cybersecurity organisation referred to in measure GV.RR-02 in the definition and execution of procurement processes from the supply identification and design phase onwards;

b) in accordance with the results of the risk assessment associated with the supply referred to in measure GV.SC-07, the definition of security requirements for the supply consistent with the security measures applied by the NIS entity to information and network systems.

In point (b), where it states that“the definition of security requirements for the supply must be consistent with the security measures applied by the NIS entity to information and network systems”, it is important to note that this refers to a previous risk assessment. A final point should be made regarding the concept of inventory, bearing in mind security measure ID.AM-04.

ID.AM-04Inventories of the services provided by suppliers are maintained .An up-to-date inventory is maintained of the IT services provided by suppliers, including cloud services.

As can be seen, the legislation requires NIS2 entities to maintain an inventory that includes cloud services provided by third-party suppliers, which means that this inventory must be accompanied by specific attributes. Some of the most common attributes might include:

Basic information about the service

  • Service Name: the brand nameof the cloud service (e.g. AWS, Microsoft 365, Salesforce).
  • Supplier: the supplier’s company name and contact details for support or the Account Manager.
  • Service model: standard cloud classification: IaaS, PaaS or SaaS. This information is essential for understanding who manages what (shared responsibility model).
  • Internal manager: the department or individual within the organisation that uses and is responsible for the service budget.
  • Service administrator: someone who has administrative privileges on the platform.

Security and data protection

  • Classification of processed data: what types of data pass through or are stored in the cloud? (e.g. public, internal, confidential, personal data, etc.)
  • Geographical location of data: Where are the servers physically located? (e.g. EU, US, Global). This is a critical factor for GDPR and NIS2 compliance, particularly in cases involving data transfers outside the EU.
  • Supplier certifications: what guarantees does the vendor offer? (e.g. ISO 27001, ISO 27017:2018 for the cloud, SOC 2 Type II, CSA STAR certification).
  • Service criticality level (TIER): the impact the service has on the business in the event of downtime (e.g. critical, high, medium, low).

Business continuity and SLAs

  • SLA (Service Level Agreement): The service levels specified in the contract and the minimum availability guaranteed by the supplier (e.g. 99.9%).
  • RTO (Recovery Time Objective) and RPO (Recovery Point Objective): the maximum acceptable recovery times and the maximum tolerable data loss for that specific service.
  • Backup/exit strategy: assess whether data is also backed up outside the cloud and whether there is a plan in place to migrate the data elsewhere in the event of the vendor’s failure. This is crucial and often indicates an intention on the part of the provider to lock customers in.

Integration and how to access the service

  • Authentication method: how do users access the service? (e.g. integration with corporate Single Sign-On (SSO), mandatory MFA, local credentials). It is worth noting that Article 24(2)(L) requires the use of “multi-factor authentication solutions or continuous authentication”. This is a legal obligation! It is not an optional choice.
  • Interconnections (API/Network): it must be specified whether the service is connected to the corporate network via VPN/Direct Connect, whether it is freely accessible from the internet, or whether it communicates with other internal systems. This must then be reflected in the data traffic security measures.

Risk assessment

With regard to risk assessment, reference should also be made to ISO 27005. It is important to bear in mind the provisions of GV.SC-07. The standard specifies the elements to be assessed as part of the risk analysis.

GV.SC-07The risks posed by a supplier, its products and services, and other third parties are identified, recorded, prioritised, assessed, managed and monitored throughout the course of the relationship.As part of the risk assessment referred to in measure ID.RA-05, the risk associated with supplies is assessed and documented. To this end, the following are assessed as a minimum:

  • the level of the supplier’s access to the NIS entity’s information and network systems;
  • the supplier’s access to intellectual property and data, including on the basis of their criticality;
  • the impact of a serious disruption to the supply;
  • the time and costs of restoration in the event of service unavailability;
  • the supplier’s roles and responsibilities in the governance of information and network systems.

It is worth noting that factors such as the“level of access granted to the supplier to the NIS entity’s information and network systems”have always been taken into account by the regulatory framework. Consider Provision 426 of 2023 of the GPDP, which states that“the lack of segmentation between critical services, applications and workstations [led] to the spread of a single breach across the entire infrastructure”. The rule requires the design of security measures appropriate to the task performed by the supplier.

Levels of implementation

When the ACN outlined the five levels of implementation, it succeeded in capturing the reality of a great many medium-sized and large organisations. In particular, ‘Level 1’ is the one we encounter most frequently.

LevelDescription
1 InitialThe implementation of controls relies on processes, procedures and technical solutions that yield unpredictable, undocumented and disorganised results, and are often carried out on an ad hoc basis. The success of the management process depends on the individual skills of staff rather than on the proven use of well-defined processes.
2 RepeatableThe implementation of the control relies on well-defined and documented processes, procedures and technical solutions within each of the organisation’s functions involved, or within a subset thereof; however, this is not consistent across the organisation as a whole (each function manages its own processes, procedures and technical solutions independently).
3 DefinedThe implementation of controls relies on processes, procedures and technical solutions that are clearly defined, documented and standardised in accordance with company policy. The various departments may tailor their own processes, building on those standardised in accordance with company policy.
4 ManagedIn addition to incorporating the aspects of the “Defined” maturity level, quantitative targets are set for the performance of the processes, procedures and technical solutions underpinning the implementation of the control. The effectiveness of these processes, procedures and technical solutions is monitored and measured quantitatively.
5 OptimisedIn addition to incorporating the aspects of the ‘Managed’ maturity level, the processes, procedures and technical solutions underpinning the implementation of the control are subject to continuous improvement in response to changes within the organisation and in light of past experience.

In fact, in the vast majority of organisations, security procedures are implemented without being properly formalised and without being adequately documented in a single document designed to systematise them. The backup and restore procedure itself is often carried out without any real formalisation to define how the procedure should be carried out and how the results should be verified.

Conclusions

The conclusion of this article consists of a number of substantive considerations.

The first is the need to carry out a risk assessment that also takes outsourced services (e.g. cloud services) into account. Many organisations have a dismissive attitude, to say the least, towards risk analysis: they do not invest a single euro in creating documents and plans, only to shed bitter tears when they find themselves dealing with notifications and incidents. This lack of awareness points to the absence of a culture without which regulations lose their effect.

The second point to note is that this risk assessment is not optional for NIS2 entities, but constitutes a specific obligation from which there is no exemption. Often, even when the document is present, it is incomplete or poorly drafted because it does not follow a tailored approach but addresses the organisation’s issues in a generic and ‘vague’ manner.

The third point is that the measures designed and implemented must be clearly reflected in the supply contract, in the form of appropriate service levels and procedures for incident management and reporting. For this reason, it is always advisable to undertake a review and adaptation of the contract from a technical and organisational perspective in order to achieve regulatory compliance. Here too, contracts are often found to lack management and communication procedures, as well as technical measures designed to protect the organisation (and the supplier). All of this constitutes a breach of current legislation.