Il n’y a pas un métier de RSSI, mais des métiers : regard de cinq secteurs économiques

CDN et infrastructure edge : Fastly

Un RSSI est toujours responsable de sa propre organisation. Mais dans une entreprise d’infrastructure, une seule décision d’architecture façonne le risque de tous les clients qui s’appuient sur la plateforme. RSSI adjoint de Fastly, fournisseur mondial de réseau de diffusion de contenu et de services réseau edge, Fernando Medrano porte la responsabilité de la sécurité sur l’ensemble du périmètre.

« L’une des choses qui m’incombent directement, et qui n’incomberaient pas forcément à un RSSI de la distribution ou de la santé, c’est que notre posture de sécurité fait partie du produit que nous vendons, et pas seulement d’une fonction qui le protège », explique Fernando Medrano. « Nous sommes la couche d’infrastructure des sites web et des applications de milliers d’entreprises. Une décision d’architecture de sécurité que je prends – la manière dont nous segmentons les environnements, dont nous gérons les clés, la rapidité avec laquelle nous appliquons les correctifs – ne réduit donc pas seulement notre propre risque. Elle façonne directement le profil de risque de chacun des clients qui s’appuient sur nous. »

La nature de l’activité impose aussi à Fernando Medrano une maîtrise technique suffisante pour tenir tête à ses propres dirigeants de l’ingénierie comme à des clients très techniques. Selon lui, la pression la plus concrète, cette année, est venue de l’IA.

« Toutes les entreprises sont pressées d’adopter l’IA rapidement, mais chez nous, cette pression joue dans les deux sens. Nous devons aider l’ingénierie et l’ensemble de l’entreprise à utiliser l’IA de manière sécurisée, et nous sommes censés l’utiliser nous-mêmes pour faire monter en puissance une équipe sécurité qui ne grandira jamais aussi vite que l’activité », souligne-t-il.

« Dans beaucoup de secteurs, la sécurité peut imposer un contrôle et s’attendre à ce qu’il soit respecté […]. Dans une entreprise pleine d’ingénieurs capables de contourner tout ce qu’ils perçoivent comme un obstacle, cette approche échoue vite. »

L’idée reçue qu’il rencontre le plus souvent, relève Fernando Medrano, est que les entreprises du secteur de l’IT, parce qu’elles regorgent de profils très techniques, auraient forcément réglé la question de la sécurité. « En réalité, l’expertise technique dans un domaine ne se transpose pas à un autre », observe-t-il. « Une entreprise peut avoir des ingénieurs réseau de classe mondiale et présenter malgré tout de vraies lacunes en matière de risque tiers, de gouvernance des données, ou de rapidité avec laquelle une équipe adopte un nouvel outil, sans que la sécurité en soit jamais informée. »

À ses yeux, les cultures d’entreprise rapides et pilotées par l’ingénierie créent leur propre surface de risque. De nombreux profils brillants sont habilités à prendre rapidement des décisions de manière autonome, ce qui est excellent pour l’activité, mais difficile à sécuriser à grande échelle.

Fernando Medrano conseillerait aux RSSI venus d’autres secteurs de désapprendre l’idée que l’autorité de la sécurité découle des politiques et des validations formelles. « Dans beaucoup de secteurs, la sécurité peut imposer un contrôle et s’attendre à ce qu’il soit respecté, du fait des obligations de conformité ou de la hiérarchie », explique-t-il. « Dans une entreprise pleine d’ingénieurs capables de contourner tout ce qu’ils perçoivent comme un obstacle, cette approche échoue vite. »

Ce qui fonctionne dans son secteur, c’est une crédibilité réelle, acquise en comprenant suffisamment bien les systèmes pour livrer la sécurité sous forme d’outils et d’automatisations que les ingénieurs ont vraiment envie d’utiliser. Et non en publiant une politique en espérant qu’elle tienne. « Si votre équipe n’écrit pas de code, ou du moins ne maîtrise pas parfaitement le code qui s’écrit autour d’elle, elle aura du mal à être prise au sérieux ici », prévient Fernando Medrano.

Logiciels de gestion informatique : SolarWinds

SolarWinds conçoit des logiciels de gestion informatique qui aident les organisations à administrer leurs propres réseaux. Comme chez tout éditeur, les décisions et les responsabilités du RSSI, en matière de sécurité, ont des répercussions qui dépassent l’entreprise.

« Une décision de configuration que je prends sur notre environnement de build, ou un arbitrage sur la manière et le moment de divulguer une vulnérabilité ne concerne pas seulement l’entreprise. Elle se répercute sur toutes les organisations qui utilisent notre produit », explique Justin Henkel, RSSI de SolarWinds.

« Pour un éditeur, si quelque chose tourne mal dans votre environnement de build ou dans votre produit, cela devient aussi le problème de vos clients, et c’est vous qui vous retrouvez sur la sellette pour vous expliquer. »

L’éditeur compte de nombreux produits à son catalogue, dont des technologies anciennes qui ne s’inscrivent plus dans ses processus de sécurité actuels. « Si nous ne consacrons pas activement des ressources à un produit et ne le testons pas selon les mêmes exigences que notre démarche actuelle de sécurité, dès la conception (secure by design), nous devons nous demander s’il faut continuer à le prendre en charge. Un produit qui n’est plus maintenu, mais reste installé chez un client représente un risque pour lui comme pour nous », souligne-t-il.

En dehors du secteur, on imagine souvent que le travail d’un RSSI d’éditeur est essentiellement réactif. « C’est tout le contraire : mon travail est très majoritairement proactif », affirme Justin Henkel. « Je siège aux côtés des équipes d’ingénierie et produits dès le premier jour du processus de développement. »

Le plus grand changement d’état d’esprit, ajoute-t-il, consiste à abandonner l’idée que la sécurité joue un rôle de gardien qui examine les produits une fois construits. Ceux qui viennent d’autres secteurs doivent aussi réapprendre l’ampleur des conséquences.

« Dans beaucoup de secteurs, si vous êtes victime d’une intrusion, c’est votre problème », explique Justin Henkel. « Pour un éditeur, si quelque chose tourne mal dans votre environnement de build ou dans votre produit, cela devient aussi le problème de vos clients, et c’est vous qui vous retrouvez sur la sellette pour vous expliquer. »

Plateforme de données en temps réel : Hydrolix

Hydrolix développe une plateforme de données en temps réel utilisée pour l’analytique. Son RSSI, Joshua Scott, est confronté à des problèmes d’une autre nature. La plupart des RSSI limitent l’accès aux données clients en production, par souci de confidentialité. Pas chez Hydrolix.

« Mon travail ne se limite pas à décider d’autoriser ou non un accès. Je dois déterminer qui a consulté les données, qui en a fait quoi, si c’était réellement autorisé, quelles sont les modalités de l’accord […].  »

« Ce n’est pas une règle que nous pouvons appliquer chez Hydrolix : nous sommes une plateforme de données à l’échelle du pétaoctet, et certains salariés ont besoin d’accéder directement à notre plateforme », explique Joshua Scott. « Mon travail ne se limite pas à décider d’autoriser ou non un accès. Je dois déterminer qui a consulté les données, qui en a fait quoi, si c’était réellement autorisé, quelles sont les modalités de l’accord et si nous avons bien le bon accord en place. »

Lorsqu’une équipe d’ingénierie a besoin de vraies données clients pour développer quelque chose, son rôle est de trouver un moyen de dire « oui » plutôt que de bloquer purement et simplement la demande, explique Joshua Scott, car un « non » systématique n’est pas tenable lorsqu’un impact réel pour les clients est en jeu.

Dans une grande entreprise, les fonctions rattachées au RSSI, comme l’informatique, la conformité ou le risque fournisseurs, relèvent généralement d’équipes distinctes. Dans une start-up, précise Joshua Scott, le rôle du RSSI ne se découpe pas ainsi. Il prend lui-même en charge l’informatique, l’architecture, la sécurité logicielle, la conformité, la protection des données personnelles, le risque fournisseurs et une partie des questions juridiques.

Selon lui, quiconque prendrait le poste de RSSI dans une entreprise comme Hydrolix devrait désapprendre l’idée qu’il suffit d’interdire l’accès aux données de production. « Nous devons remplacer cette interdiction par un modèle d’autorisation, car si nous commençons à imposer des restrictions, les équipes nous contournent et nous finissons avec moins de visibilité qu’au départ. »

Services juridiques : Lexitas

Lexitas fournit des technologies aux prestataires de services juridiques et aux cabinets d’avocats. Joe Giannetti y occupe actuellement à la fois les fonctions de DSI et de RSSI.

« Je dois faire vivre un programme de sécurité capable d’absorber l’environnement d’une nouvelle entreprise, [...] sans jamais créer, pendant la transition, un moment où des données confidentielles seraient exposées. »

Chez Lexitas, la croissance passe essentiellement par l’acquisition d’autres sociétés. « Je dois faire vivre un programme de sécurité capable d’absorber l’environnement d’une nouvelle entreprise, avec son histoire et ses lacunes, sans jamais créer, pendant la transition, un moment où des données confidentielles seraient exposées », explique Joe Giannetti.

Il cite l’évaluation des risques liés aux fournisseurs d’IA comme un défi particulier, qui pèse plus lourd chez Lexitas que dans un achat de logiciel classique. Avant qu’un outil d’IA ne touche au moindre travail lié à un client, son équipe exige du fournisseur une réponse claire sur la conservation des données et l’entraînement des modèles.

Hors du secteur juridique, on suppose parfois que celui-ci est peu technologique et fonctionne encore beaucoup sur papier, et que les enjeux de sécurité y sont donc moindres que dans une banque ou un hôpital. « Nous traitons certaines des mêmes catégories de données sensibles : données financières, informations de santé, données à caractère personnel », rappelle Joe Giannetti.

Selon lui, les RSSI qui arrivent dans le secteur juridique doivent renoncer à l’idée que leur seule obligation concerne le client signataire du contrat. En réalité, une grande partie de ce qui transite par les systèmes du cabinet appartient à des plaignants, des témoins ou des parties adverses qui n’ont jamais rien signé directement avec lui. « Vous leur devez la même diligence qu’à un client direct, même s’ils ne connaîtront jamais votre nom », insiste Joe Giannetti.

Enseignement supérieur : DeVry University

Sensibiliser les utilisateurs fait partie du rôle de tout RSSI. Pour Fred Kwong, vice-président et RSSI de DeVry University, c’est même l’une des raisons essentielles pour lesquelles il a accepté le poste.

Le RSSI de DeVry contribue, avec le doyen, à façonner le programme d’enseignement en cybersécurité de l’université. « Je m’assure que les étudiants apprennent ce qu’ils devront savoir en entreprise à l’avenir – les dernières tendances, les dernières technologies – et que le programme ne se limite pas à des technologies open source, mais intègre aussi des outils que les entreprises utilisent réellement », explique Fred Kwong.

« L’une des particularités de l’enseignement, c’est que vos clients peuvent aussi devenir vos attaquants », observe-t-il. « Dans le monde éducatif, comme nous avons affaire à des étudiants, ce n’est généralement pas malveillant : il s’agit plutôt d’explorer, juste pour voir jusqu’où ils peuvent aller. »

Cette frontière floue se traduit dans le volume d’alertes que gère le centre opérationnel de sécurité de DeVry. Selon Fred Kwong, son équipe trie bien plus d’activité qu’un SOC d’entreprise classique, car les étudiants qui se connectent depuis des machines personnelles et des lieux inhabituels ne correspondent pas aux schémas normaux. Chaque compte signalé est pourtant examiné avec autant de soin que s’il s’agissait du compte compromis d’un salarié.

« Le rôle évolue et se transforme en permanence, en particulier dans l’enseignement. »

« Nous avons des étudiants qui passent par des VPN et semblent se connecter à nos réseaux depuis l’Afrique, la France ou d’autres pays », explique Fred Kwong. « Ce sont autant de cas que nous devons distinguer, car ils sortent des schémas habituels. »

Les RSSI doivent comprendre que l’enseignement supérieur est en grande partie décentralisé, souligne Fred Kwong. Une université fonctionne comme une grande entreprise composée de divisions distinctes, et les écoles qui la composent gèrent souvent leurs propres opérations informatiques et de sécurité, chacune avec ses propres difficultés. Il pointe aussi le financement de la recherche comme une lacune persistante. « Les enseignants-chercheurs et les autres bénéficiaires de subventions de recherche investissent souvent cet argent dans des technologies, sans forcément penser à investir dans la sécurité pour protéger ces technologies ou les données qu’ils produisent. »

« Le rôle évolue et se transforme en permanence, en particulier dans l’enseignement », conclut Fred Kwong. « Nous devons presque suivre la technologie de plus près que dans d’autres domaines : non seulement nous l’adoptons en interne pour améliorer nos services, mais nous l’enseignons aussi. Faire les deux de manière responsable est essentiel. »

Sean Michael Kerner est consultant informatique, passionné de technologie et bricoleur dans l’âme. Il a tiré des câbles Token Ring, configuré NetWare et il lui arrive de compiler son propre noyau Linux. Il conseille des acteurs de l’industrie et des médias sur les questions technologiques.

Ce conseil est initialement paru en anglais sur Techtarget.com, une publication sœur du MagIT.