C'est une période difficile pour être un RSSI. La communauté de la sécurité a suivi avec impatience plusieurs histoires concernant Uber au cours des dernières semaines. Du play-by-play de leur récent hack majeur, au verdict de culpabilité de la semaine dernière de l'ancien chef de la sécurité d'Uber, Joe Sullivan, les RSSI sont confrontés à des défis considérables.

Le verdict dans l'affaire Sullivan l'a reconnu coupable d'entrave à une enquête fédérale et de dissimulation d'un crime au gouvernement. Selon le : "Stephanie M. Hinds, l'avocate américaine du district nord de la Californie, a déclaré dans un communiqué : "Nous ne tolérerons pas que des dirigeants d'entreprise soient plus soucieux de protéger leur réputation et celle de leurs employeurs que de protéger les utilisateurs. Lorsqu'une telle conduite viole la loi fédérale, elle sera poursuivie.

Le gouvernement envoie un message aux RSSI aux États-Unis : divulguez et risquez de perdre votre emploi, ou couvrez-vous et allez en prison. S'ils divulguent des informations au gouvernement, ils respectent les règles de conformité, mais leur travail sera en jeu. Une violation, en particulier une violation dans laquelle des informations personnellement identifiables (PII) sont compromises, entraînera un procès et le RSSI sera probablement renvoyé.

Mais la sanction pour non-conformité, incapacité à démontrer une divulgation complète ou toute zone grise au milieu est désormais personnelle (contrairement à d'autres réglementations où la non-conformité entraîne des amendes pour l'entreprise). Couvrir une violation, dans l'affaire Uber, puis cacher davantage les détails du piratage dans le cadre d'une enquête fédérale, peut entraîner une peine de prison.

Cette affaire met également en lumière un nouveau défi pour les RSSI : « Que saviez-vous ? La dissimulation d'informations est une partie importante de cette affaire et du verdict. Cacher des informations en disant "Je ne savais pas" n'est pas une réponse pour un RSSI avec une violation de données - cela reflète au mieux une négligence et au pire un mensonge. Les équipes de sécurité doivent savoir - et très probablement do connaissent leur posture de sécurité, grâce aux nombreux outils de sécurité qu'ils utilisent — et ce qu'ils savent ne peut être dissimulé.

L'affaire Sullivan a une gravité énorme pour l'industrie de la sécurité. Que peut-on attendre des RSSI? Ces attentes sont-elles justes ?

Gérer les attentes des RSSI

Selon le projet de loi, les attentes sont les suivantes. Du Formulaire 8-K (6-K) Divulgation d'incidents matériels de cybersécurité (PDF) — les règles suivantes seront ajoutées :

• Le nouvel article 1.05 du formulaire 8-K obligera les entreprises déclarantes à la SEC à divulguer un incident de cybersécurité important dans les quatre jours ouvrables suivant la détermination qu'un incident important s'est produit.
• L'entreprise doit déterminer l'importance d'un incident de cybersécurité « dès que raisonnablement possible » après la découverte de l'incident.
• La SEC a indiqué l'année dernière dans une mesure d'application de la loi sur la cybersécurité que les entreprises doivent maintenir des contrôles et des procédures de divulgation conçus pour garantir que toutes les informations pertinentes disponibles concernant tout incident de cybersécurité sont analysées pour être divulguées en temps opportun dans les rapports SEC de l'entreprise.
• « Incident de cybersécurité » désigne une occurrence non autorisée sur ou via les systèmes d'information de l'entreprise qui compromet la confidentialité, l'intégrité ou la disponibilité des systèmes d'information d'une entreprise « ou de toute information qui y réside ».

La question est, que doivent faire les RSSI ? Ils déploient déjà plusieurs solutions de sécurité. Sur site, cloud, détection des terminaux, pare-feu, récupération de ransomware, protection de la charge de travail… la liste est longue. Pourtant, les pirates entrent - comme dans le cas d'Uber - souvent simplement en harceler un employé pour qu'il clique sur un lien de phishing. Des millions de dollars pour la prévention des attaques et "l'utilisateur XYZ" met le système hors service.

Façons d'aider les RSSI

J'ai travaillé dans la sécurité pendant la majeure partie de ma carrière, en créant des outils qui empêchent les pirates d'entrer. J'aimerais proposer quelques comment nous pouvons aider les RSSI sortir de la situation compliquée dans laquelle ils se trouvent.

1. Débarrassez-vous des outils qui alertent sur chaque attaque potentielle ou mauvaise configuration. Une génération d'outils de sécurité basés sur des alertes qui contactent les équipes de sécurité pour chaque petite chose a aggravé la situation. Il n'y a aucun moyen pour une équipe de sécurité de suivre les centaines d'alertes, pour la plupart de fausses alertes, que leurs outils de sécurité fournissent. Ils doivent être en mesure de voir une attaque entrante en temps réel, dans le contexte de leurs actifs spécifiques - une attaque qui fournit une séquence d'événements identifiant le risque immédiat pour les actifs les plus précieux de l'entreprise. Nous devons faire mieux pour soutenir les équipes de sécurité avec des outils qui apportent de la valeur, pas seulement des alertes.
2. Réoutiller. Les régulateurs s'attendent à ce que les RSSI soient capables de détecter, d'analyser et de comprendre rapidement l'impact des événements d'attaque réels (par rapport aux erreurs de configuration potentielles). Cela nécessite de rééquiper et de repenser une grande partie de la "pile" des logiciels de sécurité pour s'assurer que nous gardons une longueur d'avance sur les pirates. L'utilisation de techniques obsolètes est un domaine qui entraîne souvent des frictions entre les meilleures pratiques de sécurité et la réalité.
3. Travailler plus étroitement avec le gouvernement sur les règlements importants qui sont proposés pour la législation. Pour empêcher nos RSSI de tomber en territoire criminel, nous avons besoin d'une législation qui protège le public tout en protégeant les RSSI qui se manifestent et signalent des violations de données. Les RSSI qui planifient véritablement chaque scénario d'attaque (et peuvent montrer cette planification) mais se retrouvent déjoués par les pirates ne devraient pas être pénalisés par les entreprises qu'ils servent.
4. Alignez les objectifs de sécurité. De nombreuses organisations vont trop vite pour se concentrer sur la sécurité - et cela les rattrapera. Les équipes de développement s'appuient de plus en plus sur des techniques agiles telles que CI/CD (intégration, livraison et déploiement continus) pour fournir rapidement de nouvelles fonctionnalités innovantes et conserver un avantage concurrentiel. Et la sécurité ne fait pas partie du processus de réflexion quotidien de l'équipe de développement ou de tout employé type, mais elle doit l'être. Les organisations doivent avoir une stratégie de sécurité qui imprègne l'organisation afin que tout le monde - développeurs, marketing, RH, finance, conseil d'administration et tous les autres partagent la responsabilité avec le RSSI et les équipes de sécurité. Tous les employés jouent un rôle dans la sécurisation des actifs de données.