Stéphane Czernik (IPSEN) : « L’indépendance du RSSI est un gage de liberté de parole »

Directeur de la sécurité de l’information et RSSI adjoint du laboratoire pharmaceutique français, Stéphane Czernik nous fait part de son expérience et nous livre sa vision de la collaboration idéale entre DSI et RSSI.

>> Cet article est extrait du guide Les défis d’un nouveau monde à télécharger « SI, réseaux et sécurité : les nouveaux challenges de la relation CIO-CISO ». 

Comment s’organise la collaboration entre la DSI et la RSSI dans votre entreprise ?

Stephane Czernik – IPSEN

Stéphane Czernik. La collaboration entre la DSI et la RSSI se passe très bien chez IPSEN. Nous avons tous le même objectif, nous avançons main dans la main. Chez nous, le RSSI est en réalisé un CSO, c’est-à-dire un Chief Security Officer. Il a dans son périmètre la sécurité physique des sites, la sécurité informatique au sens « RSSI » traditionnel et la sécurité informatique pour les sites industriels (périmètre OT / Operational Technology). Il est rattaché au département « risques ».

Si l’on prend les aspects liés à la sécurité physique des sites, les périmètres du RSSI et du DSI n’ont pas vraiment de point commun, si ce n’est lorsque nous devons installer des systèmes informatiques pilotant certains éléments physiques comme des caméras de surveillance.

En revanche, les points communs sont plus nombreux quand il s’agit de la sécurisation des systèmes informatiques traditionnels au sens large et de la sécurisation des sites de fabrication, sans lesquels IPSEN serait dans l’incapacité de produire ses médicaments et donc de remplir sa mission vis-à-vis des patients. Les systèmes informatiques OT doivent en effet être protégés comme il se doit.

Comme vous le soulignez, on assiste aujourd’hui à une convergence de plus en plus forte entre les technologies opérationnelles et informatiques, entre OT et IT, ce qui expose l’OT à de nouvelles menaces. Qui prend en main cet aspect-là ?

S. C. :  Chez IPSEN, c’est la DSI qui prend en charge ces aspects. Nous avons d’ailleurs actuellement un projet de transformation organisationnelle dans le cadre duquel un certain périmètre de l’OT va se retrouver dans le giron du DSI. Une sorte de fusion IT / OT va s’opérer au niveau organisationnel. Le DSI va être, in fine, responsable de la sécurisation de tout ce périmètre OT.

Pour aller plus loin :  Retour sur le workshop « DevSecOps, SI ouverts, réseaux en mutation… Comment la coopération CIO-CISO va-t-elle traverser les challenges des années à venir ? » 

Quels sont les challenges communs entre DSI et RSSI ?

S. C. : Un des principaux challenges communs est tout d’abord la gestion de l’obsolescence. Dans le monde de la pharmacie, les temps de cycle sont assez longs. Un certain nombre de systèmes se retrouvent donc rapidement obsolètes. Pour les maintenir à un bon niveau de sécurité, c’est très compliqué. Nous sommes obligés de passer par des phases très longues de remise à niveau des équipements, des serveurs informatiques et des logiciels pour obtenir les bonnes versions de Windows et les bonnes versions de logiciels qui seraient supportées par les éditeurs et qui seraient patchables, par exemple. Quand ce n’est pas le cas, nous sommes réduits à essayer d’isoler, d’un point de vue réseau, ces équipements pour limiter la surface d’attaque. Un des principaux challenges est donc de sécuriser au maximum le périmètre OT en prenant en compte l’obsolescence des systèmes informatiques.

Un autre challenge est lié à toutes les campagnes de phishing dont nous sommes la cible, comme de très nombreuses autres entreprises dans notre secteur d’activité. Notre rôle est donc d’éduquer les utilisateurs au maximum. La technologie en soi, même si on ajoute petit à petit des contrôles, ne suffit pas à parer 100 % des attaques. Le dernier maillon, et parfois le maillon faible, c’est l’humain. C’est l’axe sur lequel nous travaillons beaucoup en commun avec l’informatique, pour organiser des campagnes d’éducation des utilisateurs ainsi que des campagnes de faux phishing pour observer comment les collaborateurs réagissent et renforcer la formation des « serial clickers ». Nous sommes dans ce cadre beaucoup en relation avec les équipes IT. Nous les prévenons en amont des campagnes afin que le support utilisateur ne pense pas que ce sont de vraies attaques et déclenche les procédures prévues en pareil cas. Nous travaillons ensuite avec les équipes informatiques sur les statistiques de ces opérations.

Le pendant de ces attaques de phishing, ce sont les ransomwares, qui sont susceptibles de pénétrer le SI par l’intermédiaire du phishing. Il y a donc un gros travail de sécurisation en cours pour renforcer les Active Directory et la segmentation réseau. Nous travaillons pour cela vraiment de concert avec la DSI. Les roadmaps sécurité sont alignées avec celles de l’IT. On ne pourrait pas travailler autrement.

De qui le RSSI doit-il idéalement dépendre selon vous ?

S. C. : En préambule, je dirais que quand on parle de collaboration, cela dépend essentiellement des personnes et de la culture d’entreprise, pas juste de l’organigramme. Quand il y a une bonne entente entre DSI et RSSI, cela fonctionne très bien. Mais quand, au niveau personnel, cela ne colle pas, c’est là que les difficultés commencent à arriver. Une culture organisationnelle forte peut concilier ces difficultés. Chez Ipsen, la collaboration pluridisciplinaire, l’ouverture et la confiance sont ancrées dans notre raison d’être.

Dans mon parcours professionnel, j’ai pu tester différentes configurations. Quand j’ai commencé, il y a 20 ans, la sécurité était dans le giron de l’informatique, dans une configuration classique. Dans la suite de ma carrière, j’ai travaillé dans le secteur bancaire. Quand je suis arrivé dans une filiale d’une grande banque française, ils avaient, suite à une inspection générale, complètement modifié l’organisation sécurité et avaient temporairement sorti la sécurité de l’informatique pour la rattacher au CEO de la filiale.

L’avantage, c’est que le RSSI avait une énorme visibilité, mais aussi beaucoup de pression. Et comme il était plus libre de remonter les points qui lui paraissaient importants, cela mettait une pression sur la DSI. Parfois, cette pression était mal vécue parce que la roadmap de la DSI ne correspondait pas toujours à ce que le RSSI souhaitait faire. Mais on en revient toujours à la même chose : tout dépend de l’état d’esprit des personnes impliquées. Je ne pense pas qu’il y ait de solution idéale.

Quand le RSSI est indépendant du DSI, n’a-t-il pas plus de liberté, de latitude ?

S. C. : Effectivement, ayant connu plusieurs configurations différentes dans mon parcours professionnel, mon ressenti est que cela peut mieux fonctionner lorsque la RSSI n’est pas dans le giron de l’IT, essentiellement pour des questions de liberté. Je me souviens de certains cas au tout début de ma carrière où, pour des problèmes relativement importants, le DSI, qui chapeautait la sécurité, avait eu un peu trop tendance à enterrer les sujets parce que les coûts de remédiation ne rentraient pas du tout dans ses budgets. Il avait des objectifs business plus importants à ses yeux que de remédier aux points que le RSSI avait soulevés, non pas pour se faire plaisir mais simplement pour permettre à des business de continuer à opérer à moindre risque.

C’est le principal avantage que je vois. L’indépendance du RSSI permet de remonter plus librement vis-à-vis de la DSI des sujets qui doivent être mis sur la table et discutés en toute transparence entre les deux. Mais il est difficile de généraliser. Je pense qu’aujourd’hui, les DSI ont tous intégré qu’ils ont besoin de collaborer avec la sécurité, quel que soit son rattachement.