Secu
CISO et CTO : un dialogue tout en technicité sur la sécurité
Par CESIN, publié le 24 juin 2018
S’il y a bien un « couple professionnel » qui doit absolument s’entendre et coopérer étroitement, c’est bien le Chief Information Security Officer (CISO), qui communique la politique et les standards de sécurité, et l’équipe de la direction technique sous la responsabilité du CTO (Chief Technical Officer), qui est en charge de les mettre en œuvre.
Cette entente s’appuie sur une même compréhension des risques de l’entreprise ; ceux liés à l’exposition de l’infrastructure et de ses vulnérabilités techniques et fonctionnelles, à la concurrence commerciale, financière ou encore étatique. Les ennemis vont utiliser des cyber-armes pour passer les couches de protection mises en place par l’équipe du CTO. Les autres risques sont ceux à l’origine des utilisateurs eux-mêmes, qui sont réduits par une sensibilisation à la protection de l’information sous l’égide du CISO.
L’infrastructure en trait d’union
Un des cauchemars du CTO et de son équipe est bien la gestion des vulnérabilités de l’infrastructure liées d’une part, à l’application des patchs qui peuvent (c’est de plus en plus rare !) impacter la continuité de service qui est des principaux indices de qualité du service fourni par le CTO et d’autre part, à toutes les évolutions, souvent faites sous la pression des utilisateurs ou des fournisseurs de services, ne respectant pas totalement la Politique Sécurité définie par le CISO. Il est donc impératif pour le CTO et son équipe de maîtriser parfaitement l’infrastructure en maintenant à jour un plan du réseau, une carte des flux entre systèmes et la compréhension de la criticité des données échangées. Si les deux premiers points sont effectivement de sa responsabilité, il est évident que la dimension sensibilité des informations doit lui être présentée par le CISO, soit dans le cadre d’un Business Impact Analysis[1] pour un plan de recouvrement des systèmes et services informatiques, soit dans le cadre de l’application de réglementations comme celle imposées aux OIV ou dans le cadre du RGPD.
Il est évident qu’une infrastructure à jour des patchs de sécurité et autres offrira moins de prises aux attaquants potentiels ainsi qu’aux erreurs maladroites des utilisateurs. Les contrôles du maintien en condition opérationnelle que le CTO doit mettre en place au sein de son équipe va permettre d’indiquer de manière régulière dans un rapport mensuel l’état « sanitaire » des applications et des services. Le CTO sera alors en mesure de communiquer clairement au CIO sur l’état de l’infrastructure et de lui présenter les plans d’actions en cours pour maintenir cette qualité de service.
Un plan de bataille commun
Dans le contexte actuel, où une partie de plus en plus importante des systèmes d’information est externalisée, cet exercice est complexe et nécessite d’avoir anticipé ce besoin de reporting des contrôles de sécurité dans les contrats avec les fournisseurs.
Les actions pour limiter les vulnérabilités de l’infrastructure sont les suivantes :
1. Mettre en place des procédures pour protéger les clefs[2] de l’entreprise,
2. Effectuer une revue des droits d’accès régulièrement et les ajuster en cas d’incohérence (entre autres entre les listes des RH et les listes d’accès extraites directement des SI),
3. Mettre en place d’une authentification à double facteurs pour tous les accès aux comptes à privilèges (en particulier ceux qui ouvrent le droit aux « clefs » de l’entreprise),
4. Intégrer les logs des solutions de sécurité en place : (FW, anti-spam, anti-virus, sonde de détection d’intrusion, filtrage des accès Internet, sandboxing de la messagerie, …) à un outil ou un service de supervision (SOC)
5. Produire le rapport d’exception de l’application des patchs sur l’infrastructure.
L’application des patchs de sécurité sur l’infrastructure de l’entreprise est sans doute l’un des points les plus critiques pour le CTO actuellement. Pour cela, le CISO devra définir la stratégie d’application de ces patchs de sécurité en définissant un standard de sécurité[3] listant les OS et middleware existants et les classant en trois catégories :
1. Ceux pour lesquels il faut les appliquer immédiatement, dès la publication de l’éditeur[4],
2. Ceux pour lesquels il est nécessaire d’appliquer les Patchs dans un environnement de test avant mise en Production,
3. Ceux pour lesquels il faut mettre en place un projet d’upgrade de la solution existante[5].
Sur la base de ce standard de sécurité et du rapport d’analyse des vulnérabilités[6], le rapport d’exception de l’application des patchs émis par le CTO et son équipe sera alors simple à comprendre pour le CIO ainsi que le CISO.
L’évolution des besoins fonctionnels semble diminuer l’importance du rôle du CTO au profit de prestations externalisées, non seulement par les services de Cloud officiels mais aussi par le recours plus ou moins massif au Shadow IT où le CTO n’a plus la maîtrise. Il faut au contraire rappeler l’importance de cette fonction dans le contexte ou de nouvelles technologies vont bouleverser l’usage de l’information. En s’appuyant sur le CISO, le CTO doit appliquer la Politique Sécurité (notamment pour l’application des patchs), garder la maîtrise de l’infrastructure et être en mesure de garantir un état sain et sécurisé des applications et services informatiques quelles que soit les évolutions.
En résumé, il est impératif qu’il y ait une excellente coordination entre le CISO et le CTO pour protéger efficacement l’entreprise ; dans le cas contraire, le niveau de protection de l’entreprise pourra en pâtir.
Tribune de Michel Juvin, membre du CESIN
[1]Matrice des applications et services informatiques indiquant leur criticité pour l’entreprise
[2]Il faut comprendre pas « clefs » de l’entreprise, tous les droits d’accès aux systèmes d’information et services ainsi que les accès aux comptes administrateurs du réseau, de l’Active Directory et des serveurs essentiels de l’infrastructure (messagerie, base de données clients et employés, …)
[3]Issu de la politique de sécurité
[4]Dans cette catégorie on trouvera tous les OS Microsoft, Adobe ou encore les OS des équipements actifs du réseau
[5]C’est le cas pour les upgrades de solutions de gestion de base de données ou d’ERP
[6][6]De nombreuses solutions d’analyse de vulnérabilité existent sur le marché apportant beaucoup (parfois trop) d’information nécessitant de redéfinir un rapport simplifié et plus adapté