La règle de cybersécurité proposée par la SEC exercera une pression inutile sur les RSSI

La règle de cybersécurité proposée par la SEC exercera une pression inutile sur les RSSI

La règle de cybersécurité proposée par la SEC exercera une pression inutile sur l'intelligence des données PlatoBlockchain des RSSI. Recherche verticale. Aï.

En mars 2022, la Securities and Exchange Commission (SEC) proposé une règle sur la divulgation, la gouvernance et la gestion des risques en matière de cybersécurité pour les entreprises publiques, connue sous le nom de Règle proposée pour les sociétés publiques (PRPC). Cette règle obligerait les entreprises à signaler les incidents de cybersécurité « importants » dans un délai de quatre jours. Cela exigerait également que les conseils d’administration possèdent une expertise en matière de cybersécurité.

Sans surprise, c'est se heurter à toutes sortes de refus. Dans sa forme actuelle, la règle proposée laisse beaucoup de place à l’interprétation et est peu pratique dans certains domaines.

D’une part, la fenêtre de divulgation étroite exercera une pression énorme sur les responsables de la sécurité de l’information (RSSI) pour qu’ils divulguent les incidents importants avant d’avoir tous les détails. Les incidents peuvent prendre des semaines, voire des mois, pour être compris et entièrement résolus. Il est impossible de connaître l’impact d’une nouvelle vulnérabilité tant que des ressources suffisantes ne sont pas consacrées à la correction. Les RSSI peuvent également devoir divulguer des vulnérabilités qui, avec plus de temps, finissent par être moins problématiques et donc non significatives. Cela pourrait à son tour affecter le prix à court terme d’une entreprise.

Les incidents sont une chose vivante – pas une affaire unique

Les exigences de divulgation de quatre jours peuvent sembler acceptables à première vue. Mais ces mesures ne sont pas réalistes et finiront par empêcher les RSSI d’éteindre les incendies.

J'utiliserai le Règlement général sur la protection des données (RGPD) de l'Union européenne à titre de comparaison. En vertu du règlement, les entreprises doivent signaler les incidents de non-conformité dans les 72 heures. Cependant, dans le cas du RGPD, la nécessité de signaler est bien définie. Même si 72 heures sont souvent trop tôt pour connaître les détails de l'impact global d'un incident, les organisations sauront au moins si des informations personnelles ont été compromises.

Comparez cela avec les exigences de divulgation proposées par le PRPC. Les organisations disposeront de 24 heures supplémentaires, mais — sur la base de ce qui a été annoncé jusqu'à présent — elles doivent se qualifier en interne si la violation est Matériel. En vertu du RGPD, une entreprise peut le faire en fonction de la sensibilité des données, de leur volume et de leur destination. Dans le cadre du PRPC, le « caractère significatif » est défini par la SEC comme tout ce qu'un « actionnaire raisonnable considérerait comme important ». Il peut s'agir de pratiquement tout ce que les actionnaires considèrent comme important pour leur entreprise. C'est plutôt large et pas clairement défini.

Autres définitions faibles

Un autre problème est l'exigence de la proposition de divulguer les circonstances dans lesquelles un incident de sécurité n'était pas important en soi mais l'est devenu « globalement ». Comment cela fonctionne-t-il en pratique ? Une vulnérabilité non corrigée datant d'il y a six mois est-elle désormais susceptible d'être divulguée (étant donné que l'entreprise ne l'a pas corrigée) si elle est utilisée pour étendre la portée d'un incident ultérieur ? Nous confondons déjà menaces, vulnérabilités et impact commercial. Une vulnérabilité qui n’est pas exploitée n’est pas significative car elle n’a pas d’impact métier. Que devrez-vous divulguer lorsque des incidents regroupés doivent être signalés, et la clause de regroupement rend-elle encore plus difficile à discerner ?

Pour compliquer les choses, la règle proposée exigera que les organisations divulguent tout changement de politique résultant d'incidents précédents. Avec quelle rigueur cela sera-t-il mesuré et, honnêtement, pourquoi le faire ? Les politiques sont censées être des déclarations d’intention – elles ne sont pas censées être des guides de configuration médico-légale de bas niveau. La mise à jour d'un document de niveau inférieur (une norme) pour imposer un algorithme de chiffrement spécifique pour les données sensibles est logique, mais il existe peu de documents de niveau supérieur qui seraient mis à jour en raison d'un incident. Des exemples peuvent être l'exigence d'une authentification multifacteur ou la modification de l'accord de niveau de service (SLA) de mise à jour pour les vulnérabilités critiques couvertes.

Enfin, la proposition indique que les rapports sur les résultats trimestriels constitueront le forum de divulgation. Personnellement, les appels aux résultats trimestriels ne semblent pas être le forum idéal pour approfondir les mises à jour des politiques et les incidents de sécurité. Qui donnera les mises à jour ? Le directeur financier ou le PDG, qui fournit généralement des rapports sur les résultats, peut ne pas être suffisamment informé pour fournir ces rapports critiques. Alors, le RSSI se joint-il désormais aux appels ? Et si oui, répondront-ils également aux questions des analystes financiers ? Tout cela semble peu pratique, mais nous devrons attendre et voir.

Questions sur l’expérience au sein d’un conseil d’administration

La première version du PRPC exigeait des divulgations sur la surveillance par le conseil d'administration des politiques de gestion des risques de cybersécurité. Cela comprenait des divulgations sur les membres individuels du conseil d’administration et leur cyberexpertise respective. La SEC affirme avoir délibérément conservé une définition large, compte tenu de l'éventail des compétences et de l'expérience propres à chaque conseil d'administration.

Heureusement, après mûre réflexion, ils ont décidé de supprimer cette exigence. Le PRPC appelle toujours les entreprises à décrire le processus du conseil d'administration pour superviser les risques de cybersécurité et le rôle de la direction dans la gestion de ces risques.

Cela nécessitera quelques ajustements dans la communication et la sensibilisation générale. Récemment, le Dr Keri Pearlson, directrice exécutive de la cybersécurité au MIT Sloan, et Lucia Milică, RSSI chez Stanley Black & Decker, a interrogé 600 membres du conseil d'administration sur les activités liées à la cybersécurité. Ils ont constaté que « moins de la moitié (47 %) des membres siègent à des conseils d’administration qui interagissent régulièrement avec leur RSSI, et près d’un tiers d’entre eux ne voient leur RSSI que lors des présentations du conseil d’administration ». Cela indique clairement un déficit de communication.

La bonne nouvelle est que la plupart des conseils d’administration disposent déjà d’un comité d’audit et des risques, qui peut servir de sous-ensemble du conseil à cette fin. Cela dit, il n'est pas rare que les RSSI et les OSC présentent des questions liées à la cybersécurité que le reste du conseil d'administration ne comprend pas entièrement. Pour combler cet écart, il faut un meilleur alignement entre le conseil d’administration et les responsables de la sécurité.

L'incertitude prévaut

Comme pour toute nouvelle réglementation, le PRPC suscite des questions et des incertitudes. Nous devrons simplement attendre de voir comment tout cela évolue et si les entreprises peuvent répondre aux exigences proposées.

Horodatage:

Plus de Lecture sombre