Dans le cas de vulnérabilités très critiques qui ont été exploitées, le RSSI souhaitera que les correctifs soient appliqués immédiatement, et le CIO est probablement aligné sur cette urgence. Mais pour les correctifs de niveau intermédiaire, le DSI peut être sous pression pour reporter ces pannes aux systèmes de production, et il peut faire pression sur le RSSI pour qu’il attende une semaine, voire des mois, avant d’appliquer les correctifs.
La même tension existe pour les programmes qui affectent l’expérience client numérique.. Par exemple, une nouvelle fonctionnalité d’authentification multifacteur nécessite de nouvelles communications avec le client et peut-être une interruption correspondante à court terme du canal, ce qui peut être difficile à accepter pour l’entreprise.
Le DSI et l’équipe d’ingénierie peuvent également travailler avec des unités commerciales pour faciliter les nouvelles fonctions client via une plate-forme API. Du point de vue du RSSI, ces API doivent être correctement gérées, voire testées en termes de pénétration, pour garantir qu’elles ne créent pas un vecteur inattendu de perte de données. Le RSSI voudra mettre en place davantage de contrôles, mais le CIO, tout en étant d’accord en principe, doit également satisfaire les parties prenantes en garantissant la livraison de la fonctionnalité, souvent dans un délai court.
La gestion des incidents est un autre domaine propice aux tensions. Le RSSI a un rôle de leadership à jouer lorsqu’un cyber-incident grave ou une interruption de l’activité survient, et il est souvent le « messager » qui partage les mauvaises nouvelles. Bien entendu, le CIO souhaite être informé immédiatement, mais les détails sont souvent rares et comportent de nombreuses inconnues. Cela peut donner une mauvaise image du RSSI aux yeux du CIO, car il y a souvent plus de questions que de réponses à ce stade précoce.
Un cinquième exemple est DevOps, car de nombreux DSI, dont moi-même, préconisent une livraison continue à grande vitesse. Malheureusement, peu de DSI préconisent que DevSecOps intègre les tests de cybersécurité dans le processus. Cela est peut-être dû au fait que le DSI subit souvent la pression des dirigeants pour qu’il publie de nouvelles versions de logiciels et accepte ainsi le risque qu’une certaine itération soit nécessaire si celle-ci n’est pas parfaite. Pendant ce temps, peu de RSSI sont issus du développement de logiciels, ils ne se sentent donc souvent pas à l’aise de participer et de contester ce processus.
Comment les différents archétypes de DSI et de RSSI sont liés
Les points de friction ci-dessus n’ont rien à voir avec les personnalités du DSI et du RSSI, un problème d’incompatibilité supplémentaire qui peut créer davantage de tensions dans la relation. Le CIO et le RSSI ont probablement accédé à leur poste par des parcours professionnels différents et peuvent avoir une approche différente de leur travail. Certains de ces archétypes résultants fonctionnent naturellement mieux ensemble, tandis que d’autres peuvent entrer en conflit. Mon conseil ici est de réfléchir au fonctionnement de votre homologue, à son style naturel et à la manière dont vous pourriez aborder différemment les points de pression potentiels.. Par exemple, un DSI d’entreprise ou un DSI collaboratif considérera l’engagement des parties prenantes comme la clé du succès. En association avec un RSSI technique ou un RSSI transformationnel, il peut y avoir une certaine incompatibilité d’approche.
mai 22, 2024
Comment réduire les tensions entre le DSI et le RSSI
Dans le cas de vulnérabilités très critiques qui ont été exploitées, le RSSI souhaitera que les correctifs soient appliqués immédiatement, et le CIO est probablement aligné sur cette urgence. Mais pour les correctifs de niveau intermédiaire, le DSI peut être sous pression pour reporter ces pannes aux systèmes de production, et il peut faire pression sur le RSSI pour qu’il attende une semaine, voire des mois, avant d’appliquer les correctifs.
La même tension existe pour les programmes qui affectent l’expérience client numérique.. Par exemple, une nouvelle fonctionnalité d’authentification multifacteur nécessite de nouvelles communications avec le client et peut-être une interruption correspondante à court terme du canal, ce qui peut être difficile à accepter pour l’entreprise.
Le DSI et l’équipe d’ingénierie peuvent également travailler avec des unités commerciales pour faciliter les nouvelles fonctions client via une plate-forme API. Du point de vue du RSSI, ces API doivent être correctement gérées, voire testées en termes de pénétration, pour garantir qu’elles ne créent pas un vecteur inattendu de perte de données. Le RSSI voudra mettre en place davantage de contrôles, mais le CIO, tout en étant d’accord en principe, doit également satisfaire les parties prenantes en garantissant la livraison de la fonctionnalité, souvent dans un délai court.
La gestion des incidents est un autre domaine propice aux tensions. Le RSSI a un rôle de leadership à jouer lorsqu’un cyber-incident grave ou une interruption de l’activité survient, et il est souvent le « messager » qui partage les mauvaises nouvelles. Bien entendu, le CIO souhaite être informé immédiatement, mais les détails sont souvent rares et comportent de nombreuses inconnues. Cela peut donner une mauvaise image du RSSI aux yeux du CIO, car il y a souvent plus de questions que de réponses à ce stade précoce.
Un cinquième exemple est DevOps, car de nombreux DSI, dont moi-même, préconisent une livraison continue à grande vitesse. Malheureusement, peu de DSI préconisent que DevSecOps intègre les tests de cybersécurité dans le processus. Cela est peut-être dû au fait que le DSI subit souvent la pression des dirigeants pour qu’il publie de nouvelles versions de logiciels et accepte ainsi le risque qu’une certaine itération soit nécessaire si celle-ci n’est pas parfaite. Pendant ce temps, peu de RSSI sont issus du développement de logiciels, ils ne se sentent donc souvent pas à l’aise de participer et de contester ce processus.
Comment les différents archétypes de DSI et de RSSI sont liés
Les points de friction ci-dessus n’ont rien à voir avec les personnalités du DSI et du RSSI, un problème d’incompatibilité supplémentaire qui peut créer davantage de tensions dans la relation. Le CIO et le RSSI ont probablement accédé à leur poste par des parcours professionnels différents et peuvent avoir une approche différente de leur travail. Certains de ces archétypes résultants fonctionnent naturellement mieux ensemble, tandis que d’autres peuvent entrer en conflit. Mon conseil ici est de réfléchir au fonctionnement de votre homologue, à son style naturel et à la manière dont vous pourriez aborder différemment les points de pression potentiels.. Par exemple, un DSI d’entreprise ou un DSI collaboratif considérera l’engagement des parties prenantes comme la clé du succès. En association avec un RSSI technique ou un RSSI transformationnel, il peut y avoir une certaine incompatibilité d’approche.
Source link
Partager :
Articles similaires