fournisseur.
Contrôle du prestataire : comme, par nature, toutes les données d’une application
cloud sont hébergées et gérées chez le prestataire, il est capital que le client contrôle le
sérieux de son fournisseur en matière de sécurité. La solution la plus simple consiste à
auditer le fournisseur en visitant ses locaux (notamment ses salles machines) et en
prenant connaissance de ses pratiques en matière de sécurité. Cependant, lassés de se
faire auditer constamment par leurs clients, les fournisseurs recourent de plus en plus
fréquemment à des certifications pour prouver leur sérieux. C’est notamment le cas
des certifications comme l’ISAE 3402 ou l’ISO 27001. En se faisant certifier, ils
espèrent échapper aux audits ou, tout du moins, les alléger considérablement. Donc, si
le fournisseur est certifié, il est possible de lui demander les rapports d’audits ainsi
que les certificats dont il se prévaut.
Difficultés
Les exemples présentés jusqu’ici sous-entendent que le RSSI a un certain pouvoir, plus
ou moins important, vis-à-vis du tiers. La réalité est parfois très décevante. Certains
fournisseurs sont tellement puissants qu’ils sont en mesure de refuser en bloc toutes les
demandes du RSSI, aussi client soit-il. C’est le cas des gros prestataires de solutions
CRM ou de paie ainsi que de certains éditeurs de bases de données.
D’autres situations peuvent rendre difficile la mise en place de mesures de sécurité chez
les tiers. C’est le cas des prestataires intervenant dans la société, mais n’ayant aucune
relation contractuelle avec celle-ci. Cela arrive dans le cas de sociétés appartenant à un
groupe. Le groupe passe un contrat global avec un prestataire, qui intervient ensuite dans
chaque filiale, sans aucune relation contractuelle directe avec ces dernières. Le RSSI de
l’entité n’a que peu de pouvoir sur le prestataire.
Une autre situation très inconfortable est celle des sous-traitances imbriquées. On trouve
régulièrement ce cas dans les groupes. La société passe un contrat de service avec un
GIE, qui sous-traite ce service à un autre GIE, qui lui-même sous-traite auprès d’un
spécialiste. Il faut donc descendre de trois niveaux pour atteindre le sous-traitant qui
opère réellement le service. Dans ces conditions, il est très difficile pour le RSSI
d’imposer des mesures de sécurité à son sous-traitant.
Aspects opérationnels de la gestion des tiers sensibles
Maintenant que nous avons détaillé les points d’attention concernant les tiers sensibles, il
nous est possible de préciser les aspects opérationnels de leur gestion.
Remarque
Une procédure de gestion des tiers sensibles pour le SI est fournie à titre d’exemple en annexe de cet
ouvrage.
Inventaire des tiers sensibles
Nous avons commencé ce chapitre en définissant ce qu’on entend par tiers sensible pour
Contrôle du prestataire : comme, par nature, toutes les données d’une application
cloud sont hébergées et gérées chez le prestataire, il est capital que le client contrôle le
sérieux de son fournisseur en matière de sécurité. La solution la plus simple consiste à
auditer le fournisseur en visitant ses locaux (notamment ses salles machines) et en
prenant connaissance de ses pratiques en matière de sécurité. Cependant, lassés de se
faire auditer constamment par leurs clients, les fournisseurs recourent de plus en plus
fréquemment à des certifications pour prouver leur sérieux. C’est notamment le cas
des certifications comme l’ISAE 3402 ou l’ISO 27001. En se faisant certifier, ils
espèrent échapper aux audits ou, tout du moins, les alléger considérablement. Donc, si
le fournisseur est certifié, il est possible de lui demander les rapports d’audits ainsi
que les certificats dont il se prévaut.
Difficultés
Les exemples présentés jusqu’ici sous-entendent que le RSSI a un certain pouvoir, plus
ou moins important, vis-à-vis du tiers. La réalité est parfois très décevante. Certains
fournisseurs sont tellement puissants qu’ils sont en mesure de refuser en bloc toutes les
demandes du RSSI, aussi client soit-il. C’est le cas des gros prestataires de solutions
CRM ou de paie ainsi que de certains éditeurs de bases de données.
D’autres situations peuvent rendre difficile la mise en place de mesures de sécurité chez
les tiers. C’est le cas des prestataires intervenant dans la société, mais n’ayant aucune
relation contractuelle avec celle-ci. Cela arrive dans le cas de sociétés appartenant à un
groupe. Le groupe passe un contrat global avec un prestataire, qui intervient ensuite dans
chaque filiale, sans aucune relation contractuelle directe avec ces dernières. Le RSSI de
l’entité n’a que peu de pouvoir sur le prestataire.
Une autre situation très inconfortable est celle des sous-traitances imbriquées. On trouve
régulièrement ce cas dans les groupes. La société passe un contrat de service avec un
GIE, qui sous-traite ce service à un autre GIE, qui lui-même sous-traite auprès d’un
spécialiste. Il faut donc descendre de trois niveaux pour atteindre le sous-traitant qui
opère réellement le service. Dans ces conditions, il est très difficile pour le RSSI
d’imposer des mesures de sécurité à son sous-traitant.
Aspects opérationnels de la gestion des tiers sensibles
Maintenant que nous avons détaillé les points d’attention concernant les tiers sensibles, il
nous est possible de préciser les aspects opérationnels de leur gestion.
Remarque
Une procédure de gestion des tiers sensibles pour le SI est fournie à titre d’exemple en annexe de cet
ouvrage.
Inventaire des tiers sensibles
Nous avons commencé ce chapitre en définissant ce qu’on entend par tiers sensible pour