Les nouvelles règles de cybersécurité de la SEC responsabilisent davantage les RSSI que les conseils d’administration

Avec l’adoption par la SEC de nouvelles règles sur la gestion des risques de cybersécurité, la stratégie, la gouvernance et la déclaration des incidents par les sociétés cotées, une chose est claire : les définitions doivent être plus précises.

Déclaration des violations de cybersécurité : place à l’interprétation

Si vous n’avez pas lu le dépôt de la SEC du 26 juillet 2023 (ni la dissidence publiée sans tarder par la commissaire Hester M. Peirce), examinons-le rapidement ensemble. Commençons par ceci :

Les nouvelles règles obligent les entités déclarantes à signaler, dans la nouvelle rubrique 1.05 du formulaire 8-K, tout incident de cybersécurité qu’elles jugent important et à décrire les aspects importants de sa nature, de son ampleur et de son calendrier, ainsi que son impact important ou son impact important raisonnablement probable sur l’entité déclarante. En règle générale, la rubrique 1.05 du formulaire 8-K devra être déposée dans les quatre jours ouvrables suivant la décision de l’entité déclarante qu’un incident de cybersécurité est important. La déclaration peut être reportée si le procureur général des États-Unis estime qu’une divulgation immédiate présenterait un risque important pour la sécurité nationale ou la sécurité publique, et en informe la Commission par écrit.

D’accord, c’est simple, mais pas tant que ça. L’interprétation simple est que les sociétés cotées en bourse (toutes sous la supervision de la SEC) doivent déclarer à la SEC, dans les quatre jours, les incidents de cybersécurité ayant un impact important sur les entités déclarantes, au moyen du formulaire 8-K. Voici ce qui est moins simple :

• Qu’est-ce qui est « important » ? Il serait peut-être judicieux que les RSSI alignent la notion d’importance sur les définitions de l’importance utilisées dans le cadre de la loi Sarbanes-Oxley. « Bonjour, CFO, nous allons passer plus de temps ensemble. »

• Qu’entend-on par impact important « raisonnablement probable » ? Vous avez tous reçu des notifications de violation de la part d’entreprises qui vous assurent que vous ne courez aucun risque, que toutes les données sont chiffrées et que les acteurs malveillants ne peuvent pas les déchiffrer. Ces mêmes violations devraient-elles quand même faire l’objet d’un formulaire 8-K ? Et si oui, cela ne risque-t-il pas d’envoyer un message très contradictoire aux utilisateurs et aux investisseurs ?

• Qu’en est-il des violations de données non importantes (par exemple, des données personnelles) qui ne nuisent qu’aux utilisateurs, et non à l’entreprise elle-même ? Si des acteurs malveillants obtiennent votre adresse personnelle, est-ce que la SEC s’en soucie ? Probablement pas (pour l’instant).

• Comment les entreprises sont-elles censées réagir à une vulnérabilité, la résoudre et déposer un formulaire 8-K dans les quatre jours ouvrables ? En tant que RSSI, une règle qu’on m’a rabâchée (et que j’ai depuis rabâchée à d’autres) est que les équipes de sécurité doivent limiter le nombre de personnes au courant d’un incident jusqu’à ce que nous en connaissions l’ampleur et l’impact. C’est pourquoi nous créons des protocoles d’accès comme le TLP (Traffic Light Protocol), qui mettent l’accent sur le principe du « besoin d’en connaître » et sur la consigne « ne pas partager ». L’obligation de rendre publiques les informations sur une violation dans les quatre jours ouvrables me donne à penser que les auteurs considèrent peut-être qu’une « violation » est un phénomène binaire.

• La divulgation de la nature, de l’ampleur et du calendrier d’un incident met-elle les entreprises en danger ? Si vous n’avez découvert qu’une partie d’une violation, votre déclaration révélera-t-elle aux attaquants qu’ils ont eu accès à votre système pendant trois mois avant d’être détectés ? Certains pourraient faire valoir que la publication de ces informations expose votre entreprise à des risques et pourrait même aider les acteurs malveillants à affiner leurs attaques.

Ce ne sont là que quelques exemples qui me viennent à l’esprit. La commissaire Peirce a exposé ses propres préoccupations, avec beaucoup d’éloquence, et je vous encourage à les lire.

Divulgation des processus de sécurité : coup d’œil sous le capot

La prochaine règle oblige les entreprises à rendre publiques leurs pratiques de sécurité, ainsi que les risques potentiels qu’une violation pourrait entraîner.

Les nouvelles règles ajoutent également la rubrique 106 du règlement S-K, qui obligera les entités déclarantes à décrire leurs processus, le cas échéant, pour évaluer, détecter et gérer les risques importants liés aux menaces de cybersécurité, ainsi que les effets importants, ou raisonnablement susceptibles de l’être, de ces risques et des incidents de cybersécurité antérieurs. La rubrique 106 obligera également les entités déclarantes à décrire le rôle de supervision du conseil d’administration à l’égard des risques liés aux menaces de cybersécurité, ainsi que le rôle et l’expertise de la direction dans l’évaluation et la gestion des risques importants liés à ces menaces. Ces informations devront figurer dans le rapport annuel de l’entité déclarante sur le formulaire 10-K.

Divulgation d’autres préoccupations

Ce nouvel ensemble de règles a été créé dans le but de protéger les investisseurs. « Qu’une entreprise perde une usine dans un incendie ou des millions de fichiers lors d’un incident de cybersécurité, cela peut avoir de l’importance pour les investisseurs », a déclaré Gary Gensler, président de la SEC. Il a ajouté : « À l’heure actuelle, de nombreuses sociétés cotées communiquent des informations sur la cybersécurité aux investisseurs. Toutefois, je pense que les entreprises comme les investisseurs gagneraient à ce que ces informations soient présentées de manière plus cohérente, comparable et utile à la prise de décision. En veillant à ce que les entreprises divulguent les informations importantes en matière de cybersécurité, les règles d’aujourd’hui profiteront aux investisseurs, aux entreprises et aux marchés qui les relient. »

Tout cela est logique dans un monde théorique où toutes les entreprises sont identiques et où chaque incident est maîtrisé en trois jours. Une grande entreprise, même dotée d’une équipe de sécurité complète, serait confrontée à une infrastructure tentaculaire pour laquelle quatre jours ne constituent pas un délai réaliste. À l’inverse, une petite entreprise peut manquer de personnel ou d’expertise pour gérer pleinement un incident aussi rapidement et se voir contrainte de mettre ses activités hors ligne pendant un certain temps. Dans les deux cas, un délai de réponse rigide n’aide pas l’entreprise et, parfois, lui nuit. Si une entreprise souffre, ses investisseurs en souffrent aussi.

Par ailleurs, quelles sont les conséquences d’une déclaration qui dépasse le délai de quatre jours ? Toute entreprise procédera à une analyse coûts-avantages dès la découverte de la violation. Si la déclarer rapidement risque de l’exposer davantage, les CFO travailleront avec les RSSI pour évaluer ce coût potentiel, puis le comparer aux amendes quotidiennes qui s’accumuleront en cas de déclaration tardive. Si une déclaration différée est plus avantageuse financièrement, c’est ce qui se produira. Les entreprises pourraient aussi tout simplement mentir sur la date à laquelle elles ont découvert l’incident. Je ne le recommande pas, mais une rupture de confiance n’entraîne pas nécessairement de sanction durable de la part des marchés (NYSE : EFX > 200 USD).

Enfin, il s’agit d’une décision de la SEC. Elle ne concerne que les sociétés cotées en bourse. Qu’en est-il des grandes entreprises privées qui détiennent de nombreuses données hautement sensibles ? X (anciennement Twitter) détient beaucoup d’informations privées, mais échappe à la SEC tant qu’elle reste une entreprise privée. Et les start-up qui, souvent, « avancent vite et cassent des choses » pour être les premières sur le marché ? Et les organismes publics qui m’écoutent peut-être par l’intermédiaire de mon ordinateur, parce qu’il m’arrive de parler tout haut en tapant ?

Dans l’ensemble, cette première étape part d’une bonne intention, mais elle s’égare parfois et reste insuffisante sur d’autres points. Heureusement, en tant que RSSI d’une entreprise privée, je ne suis pas concerné pour l’instant.

Le message implicite : concevoir et développer de manière sécurisée dès le départ

D’accord, j’ai beaucoup critiqué, mais je suis RSSI : mon travail consiste à repérer les failles potentielles. Dans l’ensemble, je suis favorable à la transparence. Je pense que les sociétés cotées doivent faire preuve de transparence. Après tout, toutes les entreprises et tous les gouvernements devraient l’être, mais les gens ne savent pas très bien mesurer ou définir ce qu’est une violation.

Si nous lisons le texte à la lettre, nous pouvons en repérer les problèmes. Mais si nous lisons entre les lignes, le véritable message de la SEC (qu’elle en ait conscience ou non), c’est que les entreprises doivent toujours placer la sécurité au premier plan de toute technologie. Hourra ! Si vos données « importantes » ne peuvent pas faire l’objet d’une violation, le délai de déclaration pourrait être d’une heure sans que cela ait le moindre impact sur vous.

Cela dit, je comprends qu’il est impossible d’être totalement à l’abri. Peu importe à quel point un château est fortifié, il suffit à un attaquant de trouver un point faible dans le mur (ou de construire un trébuchet ridiculement gigantesque). Puisque nous ne pouvons pas créer un écosystème technologique parfaitement sécurisé, voici quelques mesures que nous devrions tous prendre, quelle que soit la réglementation de la SEC :

1. Connaissez vos actifs : la découverte des actifs est un fondement essentiel de la sécurité de vos systèmes. Si vous ne savez pas tout ce qui fonctionne dans votre environnement ni par quels points ces éléments sont accessibles, quelqu’un pourrait s’y introduire sans être détecté.

2. Continuez à intégrer la sécurité dès le début : oui, je sais, on n’arrête pas de le répéter, mais c’est important. Les systèmes doivent être conçus en tenant compte de la sécurité dès le départ. Ajouter la sécurité après coup est une mauvaise solution, et elle coûte nettement plus cher.

3. Faites de la réponse aux incidents et de la communication des automatismes : préparez un plan de communication et entraînez-vous à le mettre en œuvre en cas de violation. Les équipes de relations publiques et de réponse aux incidents, le RSSI et les juristes doivent élaborer une procédure éprouvée, avec des variantes adaptées aux différents types de violation. Même si votre entreprise est privée, vous devez avoir un tel plan. Ce n’est qu’une question de temps avant que ce type d’obligation s’applique à l’échelle fédérale. Mieux vaut prévenir que guérir.

4. Utilisez des outils précis pour corriger rapidement les problèmes : les équipes de sécurité manquent généralement de personnel et sont débordées. Donnez-leur les outils dont elles ont besoin pour réussir rapidement. Sans vouloir trop vanter Snyk, lorsque Log4Shell a fait son apparition fin 2021, 98 % de nos clients ont pu corriger les vulnérabilités concernées dans les 48 premières heures. Ils auraient ainsi eu 48 heures de plus pour déposer leur formulaire 8-K.

5. Enfin, collaborez avec vos collègues de l’ingénierie : dans le domaine de la sécurité, nous comptons sur beaucoup d’autres personnes pour nous aider à sécuriser nos systèmes. Utilisez des technologies faciles à comprendre et accessibles aux autres spécialistes de la tech. Le bon milkshake les fera accourir (pour moi, c’est menthe et pépites de chocolat, merci).