Depending on whether you are a "significant" or "essential" entity, NIS 2 will apply differently.

The principle is known. However, ANSSI provides a new framework in the form of the ReCyF (Cyber France Framework). It outlines the provisions of the directive in 20 objectives.

Pending transposition into French law, the ReCyF is only distributed as a working document—it has not yet been subject to consultation. The agency plans to publish a complementary framework that will include a subset for less mature entities.

A principle of proportionality applies. Significant entities (SE) are thus exempt from 5 objectives, which only apply to essential entities (EE). These generally concern:

Risk governance

Information Security Audit Program

Securing the configuration of IT resources

(In particular, only installing necessary software and reducing risk otherwise)

Dedicated administration networks

Information Security Supervision

(Sizing the IT system in line with the operational capacity of the team responsible for this supervision, continuous improvement approach to this activity, data retention for at least 3 months, etc.)

The other 15 objectives apply to both EE and SE. However, the latter are not expected to implement as many resources to achieve them.

On digital security governance

ANSSI expects SEs to have their executive leader responsible for IT security. But not to appoint at least one person to advise and assist them in exercising this responsibility.

On integrating digital security into HR management

SEs are not expected to include security clauses in employment contracts.

On IT system management

Among the elements expected from SEs is a mapping of IT systems. But not a procedure for the maintenance and operational continuity (MCO/MCS) of hardware and software resources. Nor the planning and installation of security patches on all these resources.

On controlling physical access to premises

ANSSI expects an SE to implement measures to limit unauthorized access to its premises (visitor logs, badges, etc.). But not to ensure their physical protection (video surveillance, security guards, alarms). Nor that physical access rights are granted strictly based on the necessity for carrying out their tasks.

On securing IT system architecture

SEs will physically and/or logically isolate all their IT systems from other IT systems.

However, they are not expected to consider the relevance of defining subsystems. And, consequently, to define at least one "outgoing gateway" (proxy) and one "incoming gateway" (reverse proxy or relay).

Two other "expectations" do not apply to subsystems. On the one hand, ensuring that only the necessary interconnections for the SE's activities or its MCO/MCS are implemented between its IT systems and third-party IT systems (as well as those to which it has chosen not to apply security objectives). On the other hand, defining and documenting these same connections.

On securing remote access to IT systems

ANSSI expects SEs to have encryption and authentication mechanisms in line with its recommendations. But it does not necessarily expect multifactor authentication with at least one knowledge factor. Nor measures to reduce the risk associated with accesses that cannot be covered by MFA for technical or operational reasons. Nor state-of-the-art encryption and authentication for the disks of workstations and mobile devices that allow remote access from locations it does not control.

On protecting IT systems against malicious code

An SE is expected to define the authorized hardware resources to connect to its IT systems. But not to connect only those it—or a service provider—manages and that participate in its activities or its MCO/MCS.

On identity and access management for IT systems

ANSSI expects SEs to have an authentication mechanism involving at least one secret element. It expects risk reduction measures when technical or operational reasons prevent the modification of the secret. But not, within this exception, the implementation of access traceability.

On managing IT system administration

Administration actions are expected to be performed exclusively from administration accounts. And that these accounts are not used for other purposes.

However, ANSSI does not expect SEs to keep an updated list of administration accounts for their IT systems. Nor to verify the consistency of access rights and usage needs when modifying one of these accounts.

Another element not expected from SEs: the designation of a "trust core" bringing together a directory and the hardware and software resources that host it or allow it to be controlled. Nor, consequently:

Performing administration actions on this trust core from accounts dedicated to this task

Filtering external connections to the trust core and its administration resources

The annual review of directory configuration is also not an "expectation" for SEs.

On identifying and responding to security incidents

Like EEs, SEs will implement mechanisms for analyzing and qualifying reported events and identifying incidents. However, they are not expected to:

Have organizational and technical mechanisms to respond to incidents and limit the impact on service delivery

Analyze the causes of each security incident

Retain technical records that could serve as evidence in case of legal proceedings

Protect these records against an incident that would render them unusable

On business continuity and recovery

ANSSI does not expect an SE to define and document, for each of its activities and services, the maximum acceptable interruption duration and the data recovery point. Nor to have a business continuity plan (BCP) and a disaster recovery plan (DRP) coherent with these two indicators.

On responding to cyber-origin crises

In this area, there are no expectations for SEs regarding:

Criteria for activating and deactivating the crisis management system considering cyber threats

Procedures and mechanisms for crisis management adapted to the cyber threat and based on ANSSI's recommendations

Measures to isolate, protect, and, if necessary, rebuild the affected IT systems

Adapted communication strategy

Emergency communication means

On exercises, tests, and training

ANSSI expects SEs to conduct at least one tabletop exercise—at a frequency deemed appropriate—for individuals who can be mobilized in the cyber crisis management system.

However, it does not expect a training strategy including a list of actors expected to participate in different systems, a list of exercises, objectives and means to evaluate their achievement, risk or attack scenarios to be tested as a priority, and a follow-up committee.

Illustration generated by AI

The post ReCyF, an additional framework for NIS 2 appeared first on Silicon.fr.

Selon que vous serez une entité « importante » ou « essentielle », la NIS 2 s’appliquera différemment.

Le principe est connu. L’ANSSI y apporte cependant une nouvelle grille de lecture, en l’objet du ReCyF (Référentiel Cyber France). Elle y décline les dispositions de la directive en 20 objectifs.

En attendant la transposition dans le droit français, le ReCyF n’est diffusé qu’en tant que document de travail – il n’a d’ailleurs pas encore fait l’objet d’une consultation. L’agence prévoit de publier un référentiel complémentaire qui en reprendra un sous-ensemble pour les entités moins matures.

Un principe de proportionnalité s’applique. Les entités importantes (EI) sont ainsi exemptées de 5 objectifs, qui ne s’appliquent qu’aux entités essentielles (EE). Ils concernent, dans les grandes lignes :

Gouvernance par les risques

Programme d’audit SSI

Sécurisation de la configuration des ressources des SI

(En particulier, n’installer que les logiciels nécessaires et réduire le risque sinon)

Réseaux d’administration dédiés

Supervision de la SSI

(Dimensionnement du SI en adéquation avec la capacité opérationnelle de l’équipe chargée de cette supervision, démarche d’amélioration continue de cette activité, conservation des données au moins 3 mois, etc.)

Les 15 autres objectifs s’appliquent aux EE comme aux EI. Mais on n’attend pas de ces dernières qu’elles mettent en œuvre autant de moyens pour les atteindre.

Sur la gouvernance de la sécurité numérique

L’ANSSI attend des EI que leur dirigeant exécutif soit responsable de la sécurité informatique. Mais pas qu’il désigne au moins une personne pour le conseiller et l’accompagner dans l’exercice de cette responsabilité.

Sur l’intégration de la sécurité numérique dans la gestion des RH

On n’attend pas des EI qu’elles prévoient des clauses de sécurité dans les contrats de travail.

Sur la maîtrise des SI

Au rang des éléments attendus des EI, il y a une cartographie des SI. Mais pas une procédure de MCO/MCS des ressources matérielles et logicielles. Ni la planification et l’installation des correctifs de sécurité sur l’ensemble de ces ressources.

Sur la maîtrise des accès physiques aux locaux

L’ANSSI attend d’une EI qu’elle mette en place des mesures pour limiter l’accès de personnes non autorisées à ses locaux (registre des visiteurs, badges…). Mais pas qu’elle s’assure de leur protection physique (vidéosurveillance, gardiennage, alarme). Ni que les droits d’accès physique soient attribués au regard du besoin strictement nécessaire à l’exécution des missions des personnes.

Sur la sécurisation de l’architecture des SI

Les EI cloisonneront physiquement et/ou logiquement l’ensemble de leurs SI vis-à-vis des autres SI.

On n’attend pas, en revanche, qu’elles mènent des réflexions sur la pertinence de définir des sous-systèmes. Et, par là même, qu’elles en définissent au moins un de type « passerelle sortante » (proxy) et un de type « passerelle entrante » (proxy inversé ou relais).

Deux autres « attendus » ne s’appliquent pas aux sous-systèmes. D’une part, s’assurer que seules les interconnexions nécessaires aux activités de l’EI ou à son MCO/MCS soient mises en œuvre entre ses SI et les SI tiers (ainsi que ceux auxquels elle a choisi de ne pas appliquer les objectifs de sécurité). De l’autre, définir et documenter ces mêmes connexions.

Sur la sécurisation des accès distants aux SI

L’ANSSI attend des EI des mécanismes de chiffrement et d’authentification conformes à ses recommandations. Mais elle n’attend pas nécessairement de multifacteur avec au moins un facteur de connaissance. Elle n’attend pas non plus des mesures de réduction du risque associé aux accès qui ne peuvent être couverts par du MFA pour raisons techniques ou opérationnelles. Ni un chiffrement et une authentification à l’état de l’art pour les disques des postes de travail et des équipements mobiles qui permettent les accès à distance depuis des lieux qu’elle ne maîtrise pas.

Sur la protection des SI contre les codes malveillants

On attend d’une EI qu’elle définisse les ressources matérielles autorisées à se connecter à ses SI. Mais pas qu’y connectent uniquement celles dont elle – ou un prestataire – assure la gestion et qui particpent à ses activités ou à son MCO/MCS.

Sur la gestion des identités et des accès aux SI

L’ANSSI escompte, de la part des EI, un mécanisme d’authentification impliquant au moins un élément secret. Elle attend des mesures de réduction du risque lorsque des raisons techniques ou opérationnelles empêchent la modification du secret. Mais pas, dans le cadre de cette exception, la mise en œuvre d’une traçabilité des accès.

Sur la maîtrise de l’administration des SI

Il est attendu que les actions d’administration soient effectuées exclusivement à partir de comptes d’administration. Et que ces derniers ne soient pas utilisés à d’autres fins.

L’ANSSI n’attend cependant pas que les EI tiennent à jour la liste des comptes d’administration de leurs SI. Ni que lors de la modification d’un de ces comptes, elles vérifient la cohérence des droits d’accès et des besoins d’utilisation.

Autre élément non attendu des EI : la désignation d’un « cœur de confiance » réunissant un annuaire et les ressources matérielles et logicielles qui l’hébergent ou permettent d’en prendre le contrôle. Ni, par voie de conséquence :

Réalisation des actions d’administration sur ce cœur de confiance depuis des comptes d’administration dédiés à cette tâche

Filtrage des connexions externes au cœur de confiance et à ses ressources d’administration

La revue annuelle de la configuration des annuaires n’est pas non plus un « attendu » pour les EI.

Sur l’identification et la réaction aux incidents de sécurité

Comme les EE, les EI mettront en œuvre des mécanismes d’analyse et de qualification des événements remontés et d’identification des incidents. On n’attend par contre pas d’elles :

Des mécanismes organisationnels et techniques pour réagir en cas d’incident et limiter les conséquences sur la fourniture de services

Une analyse des causes de chaque incident de sécurité

La conservation des relevés techniques pouvant servir d’éléments de preuve en cas de judiciarisation

La protection de ces relevés contre un incident qui les rendrait inexploitables

Sur la continuité et la reprise d’activité

L’ANSSI n’attend pas d’une EI qu’elle définisse et documente, pour chacun de ses activités et services, la durée maximale d’interruption admissible et le point de rétablissement des données. Ni qu’elle ait un PCA et un PRA cohérents vis-à-vis de ces deux indicateurs.

Sur la réaction aux crises d’origine cyber

En la matière, pas d’attentes envers les EI concernant :

Critères permettant d’activer et de désactiver le dispositif de gestion de crise prenant en compte les menaces cyber

Procédures et mécanismes de gestion de crise adaptés à la menace cyber et s’appuyant sur les recommandations de l’ANSSI

Mesures pour isoler, protéger et, le cas échéant, reconstruire les SI concernés

Stratégie de com adaptée

Moyens de communication de secours

Sur les exercices, tests et entraînements

L’ANSSI attend, chez les EI, au moins un exercice sur table – à la fréquence jugée adéquate – pour les personnes mobilisables dans le dispositif de gestion des crises cyber.

Elle n’attend pas, en revanche, de stratégie d’entraînement comportant une liste des acteurs amenés à participer aux différents dispositifs, une liste d’exercices, des objectifs et des moyens d’évaluer leur atteinte, des scénarios de risque ou d’attaques à tester en priorité et une comitologie de suivi.

Illustration générée par IA

The post ReCyF, une grille de lecture supplémentaire pour la NIS 2 appeared first on Silicon.fr.