Skip to content

Complying with the NIS2 directive

Access security contributes directly to NIS2 compliance

GDPR, CSA, CRA, NIS (NIS 2), DORA, LPM, SOX, PCI-DSS, SOC2, HIPAA, TISAX, IEC42663, NIST800-53, ISO27001/27002, ANSSI PA022/PAMS, … Whether legal, industry-specific or cybersecurity-related, regulatory obligations are multiplying, and increasing the pressure on a growing number of companies and organizations. This is obviously the case with the NIS 2 directive, whose national transposition is expected to come into force in October 2024, to become applicable in the months and years to come. In this article, we unfold the NIS2 directive, and illustrate how the cyberelements offer contributes to achieving the objectives set by this directive.

What’s new compared to “NIS 1”?

The NIS 2 directive consists of a 150-paragraph preamble on the state of cybersecurity in Europe, and around 50 articles describing the overall cybersecurity governance and organization in Europe.

Above all, it’s about creating an ecosystem of cooperating organizations for European cyber resilience. The attached figure summarizes this ecosystem, with European actors on the left (starting with the European Commission, where “everything starts”), national actors in the center (with cybersecurity national agencies and networks of cybersecurity actors), and finally the companies and organizations concerned on the right (henceforth referred to as “essential entities” and “important entities”). The figure shows, in simplified form, the types of interactions between these organizations, and numbers refer to the NIS 2 articles that establish the roles and interactions between these organizations.

NIS Compliance
Figure 1: A European ecosystem for cyber resilience

Other innovative aspects of the directive, and the focus of most communications on the subject, are:

  • The number of organizations now concerned and subject to the directive’s obligations (in terms of industries and sizes, whether in HR or financial terms): from 15,000 operators to over 100,000 at European level; from a few hundred to thousands at national level;
  • The personal liability of the managers of these organizations, and the potential penalties for “non-compliance” (in % of revenues);
  • Security incident notification obligations (reduced to 24 hours) and disclosure of known vulnerabilities;
  • The role of national agencies (such as ANSSI in France) is evolving, on the one hand in relation to the role of the European agency (ENISA), and on the other in relation to the national role (given the number of organizations involved, the ANSSI will need partners to accomplish its missions).

The key article: Article 21

In NIS 2 Directive, the article that defines the most operational obligations for the entities concerned is Article 21. It sets out the measures that these entities must implement to meet the requirements of NIS 2: these measures are then broken down into objectives, along four main lines:

  • Governance: everything starts with a cyber risk analysis; staff awareness and training in cybersecurity, and the application of good cyber hygiene practices, constitute “a basic foundation”; supply chain security, and in particular the requirements placed on suppliers and service providers and the monitoring of the latter; particularly in the digital sector, where the disclosure of known vulnerabilities is essential; and finally, measuring the effectiveness of the measures taken.
  • Defense: all measures relating to the handling of security incidents.
  • Resilience: all measures related to business continuity, including backup management and disaster recovery, as well as crisis management.
  • Protection: all aspects of cryptography and encryption (guaranteeing data confidentiality and integrity); access control and asset management policies; and the use of multi-factor authentication and/or continuous authentication. We’ll come back to this last measure, which has a “zero trust” flavor.

The transposition of the NIS 2 directive into national law should focus on translating these measures into objectives and rules to be met. Will there be many new rules or objectives compared to “NIS 1”? A lot has been done since “NIS 1”, and standards such as ISO 27001 or guides published by the respective national agencies (such as ANSSI PA022 or PAMS guides in France) have already provided many recommendations for translating these measures into operational requirements to be met. The attached figure illustrates the correspondence between the themes addressed by the various directives and standards for France: NIS2, LPM, ISO 27001, ANSSI PA022 and PAMS. There is a similarity and consistency in the themes addressed: any organization that is ISO 27001 certified, or that implements the national cybersecurity recommendations in their various guides, is already very well prepared for compliance with the NIS 2 directive.

Figure 2: Correspondence between the various directives and standards

Protection through identity and access management

Identity and access management is essential to the protection of “Regulated Information Systems” (RIS) (the “enterprise” or production information systems of essential or important entities). This is a central area of the “protection” axis of the NIS2 directive objectives. It can be broken down into 3 main themes:

  1. A theme on RIS architecture,
  2. A purely “IAM” (Identity and Access Management) theme, focusing on the identification, authentication and access rights of RIS users,
  3. A RIS administration theme, focusing on Privileged Access Management (PAM).

An architecture which protects

A key word emerges as an architectural principle: partitioning. The entity must partition the RIS from other information systems, either physically or logically, and similarly for each RIS subsystem. The entity must also implement “inbound gateways” and “outbound gateways” to interconnect the RIS with other IT Systems. Securing remote access is also a concern, with the implementation of encryption mechanisms (everything outside the RIS must be encrypted) and reinforced authentication mechanisms (known as “multi-factor”). The RIS must be protected against the intrusion of malicious code, with particular attention paid to all devices (hardware & software) interconnecting with the RIS. The RIS must contain only resources essential to its activity and accept only connections essential to its activity.

IAM: the cornerstone of protection

The entity must know and map all the identities and applications using the RIS and ensure that each one accesses it using individual accounts. Unused accounts must be disabled, and the associated authentication secrets rendered inoperative. For authentication to RIS resources, multi-factor mechanisms are preferred (factor management policy), and particular care must be taken with authentication secrets (authentication secret management policy, such as their robustness, complexity and frequent modification). Any attempt to access a RIS resource must be traced. The entity assigns access rights only to users (people or applications) who need them, only to the resources they need, and only for the period of use required. These are the basic Zero Trust principles: access to resources must be granted on a need-to-know basis, with least privilege necessary to perform the task, for the duration of the task, leaving no standing rights after the task has been completed. It is also recommended to carry out regular campaigns to review access rights to RIS resources.

PAM: protection that can’t be ignored

We could say that the architectural principle of partitioning also applies to RIS administration. The Administration Information System (AIS) of a RIS must be in some way separated from the RIS: all resources used for RIS administration (workstations, networks, servers, infrastructures, etc.) must be exclusively dedicated to RIS administration, and may not be used for any other purpose. Administration accounts must therefore be separated from end user accounts, and the authentication secrets of administrators must be different from those of “business” users, when the same person is involved (different roles). It is forbidden to grant administration rights to a “business” user, or for an administrator to perform administration actions from his/her “business” user workstation. The same basic zero-trust principles apply to AIS. As far as possible, network connections to resources should be separated between the connection used for resource administration and those used for “business” use. When, for administrative purposes (such as updating a resource’s software), files or data need to be transferred to the RIS, an “exchange zone” architecture should be implemented, so that the exchange zone accessible from the RIS is not accessible from another exchange zone, and data transfer between exchange zones takes place via secure data transfer “diodes”.

AIS and RIS
Figure 3: AIS and RIS

cyberelements’s contribution to achieving NIS2 objectives

Compliance with the NIS2 directive is obviously not just a question of technological solutions. It is above all a question of governance, management, organization, processes, practices, etc. But when we consider the objectives of the “Protection” axis, we can see that technologies for securing access to the RIS can make a direct contribution, whether in terms of

  • Identity Governance and Administration (IGA),
  • User authentication (AM, Access Management; UA, User Authentication; SSO, Single Sign On; MFA, Multi-Factor Authentication),
  • Secure remote access (VPN, Virtual Private Network; ZTNA, Zero Trust Network Access) or
  • Privileged Access Management (PAM).

All these technologies contribute directly to meeting these requirements. Let’s take a look at each of the areas under the “Protection” heading, and illustrate how certain product capabilities or functionalities contribute to the effort to comply with the NIS2 directive:

Architecture

  • Double-barrier architecture with end-to-end encrypted tunnels;
  • Organizational (multi-tenant) and network (gateways with outgoing flows without opening network ports) partitioning;
  • Clientless provider access on the workstation with protocol break;
  • Protection against attacks thanks to volatile and random ports, url rewriting and display isolation;
  • Integration with security information and event management (SIEM) tools.

IAM

  • Enforcement of a zero-trust access policy;
  • Automatic provisioning and de-provisioning of accounts and rights based on centralized entitlement rules;
  • Authentication secret vault, resource-oriented and user-oriented, and enforcement of password and password rotations policies;
  • Management of rights reviews (certification campaigns) and assurance of the “segregation of duty” (SoD);
  • Access request workflows, with traceability of requests (“just-in-time” access);
  • Reinforced primary authentication (multi-factor) and transparent secondary authentication, non-disclosure of passwords/authentication secrets;
  • Analysis of the context and behavior of the user and his/her device.

PAM

  • Single, dedicated bastion for access from the corporate network by internal administrators and from the Internet by service providers;
  • AIS-RIS connection via encrypted tunnels and zero-trust conditional access;
  • Detailed traceability in audit logs and recording of all actions and access sessions to critical resources;
  • Where applicable, compliance with AD tiering and secure access to the Privileged Access Workstation (PAW) without incoming protocols;
  • Protection and non-disclosure of authentication secrets (passwords, keys, certificates), including those used by applications, scripts and other non-human identities in DevOps and CI/CD chains.

The best way to prepare for NIS2 is to initiate or continue efforts with a 360° corporate cybersecurity program. We now know that organizational and technological aspects are intertwined and need to be managed together. Each of the measures to be implemented relies on a technological foundation to achieve the desired cybersecurity objectives, whether in terms of risk analysis, security posture evaluation (including attack surface analysis), staff awareness and training, security incident management, etc. With regards to the area of “Protection”, more specifically addressed in this article, particular attention will be paid to the following aspects:

  • The adoption of a zero-trust approach, both functionally and architecturally. Traditional approaches that consider the enterprise network as the security perimeter, with relatively static access policies, are not adapted to a world where “the Internet becomes the enterprise network” (hybrid work environment, third-party remote access, cloud services (xaaS), including “networks as cloud services” (SD-WAN), …).
  • In this post-perimetric world, the new security perimeter is dynamic, defined by the access rule that takes into account the user’s context and the tasks he must perform on the resource at a given time. This means overloading entitlement rules with access conditions, implementing a zero-trust access policy AND deploying a zero-trust access infrastructure.
  • Protection against the intrusion of malicious code is not just a matter of monitoring and detection: it’s also a matter of prevention and blocking, and this requires capabilities of the access infrastructure, and in the entire end-to-end access chain, from the user’s terminal to the resource to which he/she is connecting. If malicious code has no way of getting through, there’s no need to detect it.
  • Special protection for privileged accounts. These are the accounts which, if usurped, will give cyber-actors the greatest opportunities. These accounts need to be strictly managed (limited, i.e. provisioned and de-provisioned, orphaned accounts avoided, duration of secrets linked to these accounts reduced, etc.).