Depuis la généralisation de l’informatique en entreprise au cours des cinquante dernières années, les processus métiers se digitalisent de plus en plus pour gagner en efficacité et compétitivité. Cependant, si l’utilisation des ressources informatiques favorise les gains de productivité, elle introduit inévitablement de nouvelles problématiques de cyber sécurité pour les entreprises, que les RSSI doivent affronter.
Exemples :
- Une exposition accrue du système d’information et donc une surface d’attaque plus importante,
- Des applications développées sous pression pour répondre à des besoins métiers sans tenir compte des contraintes réglementaires et de cybersécurité,
- Des ressources IT qui ne sont pas connues des équipes sécurité et qui fonctionnent en dehors de tout contrôle.
Bien que d’origine cyber, le premier constat que l’on peut faire est que ces nouvelles problématiques sont transverses et dépassent les simples aspects techniques pour également toucher les domaines organisationnel, juridique, ou humain.
Les risques cyber sous-jacents ne traduisent cependant aucune fatalité et deviennent maîtrisables sous-réserve d’appliquer – dès la phase projet – une approche méthodique et raisonnée à l’échelle de l’entreprise. C’est le principe même du privacy and security by design. Il est en effet plus simple de revoir une architecture quand elle est encore sous forme de schéma que lorsque les éléments sont physiquement intégrés, connectés, et utilisés.
Ce processus s’appelle l’intégration de la sécurité dans les projets. L’objet de cet article est d’aborder les principales problématiques qu’un RSSI doit avoir à l’esprit dans la mise en œuvre de cette démarche afin de renforcer le processus de gestion des risques SI auxquels est exposée son entreprise. Au regard de nos expériences, ces problématiques peuvent être réparties entre quatre catégories : humaines, organisationnelles, techniques et juridiques.
Problématiques humaines
L’humain est le premier acteur de la sécurité au sein d’une entreprise, il est donc primordial de le sensibiliser à ce sujet, mais également de lui faire comprendre son rôle face aux enjeux de cybersécurité.
La sensibilisation aux risques IT et aux bonnes pratiques de sécurité doit être régulière. Elle doit s’adapter au contexte de l’entreprise et des projets sur lesquels ces personnes sont positionnées : exemple un projet particulièrement critique doit faire l’objet d’une sensibilisation spécifique.
En outre, il est important de responsabiliser les différentes équipes qu’elles soient IT ou métiers. Le RSSI doit s’assurer que chaque personne composant l’équipe projet comprenne son rôle, ses responsabilités et comment son activité impact celle de ses collègues ; et plus globalement l’entreprise d’un point de vue risques IT. Cela se traduit généralement au travers de la mise en place d’une comitologie et d’une gouvernance rigoureuse avec les bonnes parties prenantes et une participation active des équipes du RSSI.
L’avantage d’intégrer des équipes du RSSI au comité projet est double. Comme évoqué ci-dessus elle permettra d’un côté de sensibiliser toutes les parties prenantes aux enjeux cybersécurité dans le cadre de ce projet mais d’un autre côté elle permettra également au RSSI d’avoir une vision fine des risques cyber liés au projet. Cette composante est déterminante pour que le RSSI ait les éléments permettant de prendre les bonnes décisions en terme de gestion de risque cyber dans les projets : est-ce que le risque est acceptable compte tenu des enjeux métiers ? Est-ce qu’il existe une solution interne pour le mitiger ? etc.
Pour appuyer ces décisions, le RSSI a besoin d’indicateurs sur le niveau de sécurité liés au projet. Ces métriques doivent être définies par les équipes cybersécurité et l’équipe projet de façon collégiale pour qu’elles soient à la fois pertinentes et réalistes. En plus d’être utile au projet, ces indicateurs peuvent servir de point de départ pour justifier des financements supplémentaires pour la sécurité.
Les indicateurs types peuvent être divers, par exemple : le nombre d’applications dont le risque dépassent l’appétence de l’entreprise et ont nécessité une acceptation, le nombre de vulnérabilités hautes ou critiques ayant dépassé le délai de remédiation, la couverture des scans de vulnérabilités sur les serveurs ; le pourcentage de personnel ayant été sensibilisé ; etc.
L’objectif principal étant de définir des indicateurs en adéquation avec les besoins de sécurité de l’entreprise et permettant au management d’avoir une vision macro de la maturité en terme de cyber sécurité.
Problématiques organisationnelles
Au-delà de ses collaborateurs, l’intégration de la sécurité dans les projets doit être organisée au niveau de toute l’entreprise : mais comment procéder, et qui doit être impliqué ?
La gestion de son risque et l’intégration de la sécurité dans les projets doivent être formalisées dans des politiques de sécurité. Le RSSI doit donc s’assurer que les différentes parties prenantes participent à sa conception. Cela a deux avantages : obtenir l’appui du management en l’impliquant, mais aussi capter toutes les subtilités des processus métiers. La notion de risque est subjective et doit s’adapter aux appétences de l’entreprise : une entreprise du luxe sera très sensible à son image et sa présence dans les médias, alors qu’une autre dans le domaine médical devra probablement faire face à des risques de conformité et de gestion des données de santé. Formaliser par écrit ce processus permet d’avoir une approche cohérente et pragmatique dans ses projets, et d’obtenir en retour une vue globale des risques auxquels l’entreprise est exposée.
Ce processus doit être diffusé – notamment par le biais de la sensibilisation – afin de s’assurer qu’il soit appliqué sur tous les projets. Trop souvent, des projets sont lancés en marge des équipes sécurité et alimentent le « Shadow IT ». L’enjeu est ici que la sécurité ne soit plus vue comme un frein, mais comme un élément moteur d’un projet.
Problématiques techniques
Les problématiques techniques sont les plus évidentes quand on parle de cyber et s’articulent généralement autour de la question « Comment faire ? ». Cependant, il faut d’abord réfléchir à la pertinence de complexifier le SI avant de s’intéresser à la technique, à notre maîtrise des technologies, et l’intégration avec l’existant et ses mécanismes de sécurité.
En effet, une étape clé dans le déploiement d’une nouvelle composante d’un système d’information est son intégration avec l’existant et ses mécanismes de sécurité. Il est possible que les applications existantes répondent déjà à tout ou partie du besoin, et il est nécessaire d’analyser la pertinence de déployer une nouvelle application plutôt que de faire évoluer l’existant. On rencontre ainsi parfois une multitude d’applications aux rôles très similaires, et qui n’ont parfois été utilisées que de façon très courte, comme lors des campagnes des départements « communication & marketing ». Cette réflexion peut permettre de rationaliser le lancement des projets et apporte un gain de temps et des coûts réduits de déploiement et d’exploitation.
Elle s’applique également aux technologies existantes et déjà maîtrisées en interne : le choix de se tourner vers de nouvelles technologies doit faire l’objet d’une réflexion sur les coûts-bénéfices. Leur manque de maîtrise est également une source de risque, notamment si le peu de connaissance est détenue par un nombre limité de personnes – on parle alors de key person risk.
En parallèle du choix d’architecture et des technologies, il faut s’assurer que le projet s’intègre dans le cadre de sécurité existant comme dit précédemment. Si des développements internes sont nécessaires par exemple, il est important de prévoir des audits de code tant pour en assurer la qualité que la sécurité. En effet, le coût de remédiation d’une vulnérabilité augmente considérablement si elle est découverte une fois le code en production et peut parfois venir remettre en cause les technologies utilisées ou l’architecture déployée. Ces audits de code doivent faire partie d’un processus plus large de sécurisation des systèmes avant leur mise en production qui comprend entre autres les tests de pénétration, de configuration, les procédures de gestions des accès, de fuites de données, etc.
La gestion des accès de l’application est également un élément à arbitrer dès la phase de conception. Si l’entreprise dispose d’un annuaire unique, d’un service de SSO ou de fédération d’identités, elle doit s’assurer de choisir des services compatibles garantissant une gestion sécurisée et centralisée des identités et des accès. Une solution non compatible engendrera non seulement des risques sur l’entreprise, mais induira également des coûts supplémentaires : revue des droits séparée, mots de passe oubliés plus fréquemment, etc.
Problématiques juridiques
Outre les contraintes internes, l’entreprise doit également se conformer à des contraintes externes telles que les réglementations ou les engagements contractuels avec les partenaires. Il est impératif pour le RSSI de s’assurer que ces aspects soient considérés le plus tôt possible – et avant toute contractualisation – notamment en ce qui concerne la localisation des données et la conformité RGPD.
Qu’elle soit gérée par un prestataire ou directement par l’entreprise, le choix de la localisation des données doit être anticipé et arbitré selon le cadre légal des activités traitées. Ainsi, aux Etats-Unis, le PATRIOT Act (2001) ou le CLOUD Act (2018) permettent aux autorités judiciaires et aux agences gouvernementales américaines de demander l’accès aux données hébergées par les sociétés de droit étasunien quelle que soit la localisation physique de ces données, et sans nécessairement en informer leurs propriétaires. Ce type de loi sur les données hébergées n’est pas propre qu’aux États-Unis et existent dans d’autres pays : la loi sur la cybersécurité de 2017 en Chine impose aux entreprises exerçant en Chine d’héberger leurs données sur le territoire chinois. Une vision éclairée sur le cadre juridique peut donc avoir un impact direct sur la mise en place de mesure de sécurité tel que le chiffrement des données applicatives.
Le même type de réflexion doit être appliquée concernant le traitement des données personnelles. Entré en vigueur en 2016, le RGPD vise à responsabiliser les organismes sur les traitements de ce type de données. L’entreprise doit s’assurer d’identifier les données personnelles qui seront utilisées et lister les traitements associés lors du lancement des nouveaux projets.
De façon plus générale, l’entreprise doit s’assurer que ses partenaires aient un niveau de sécurité au moins équivalent à celui de l’entreprise. Il faut donc définir le type de preuves qui peuvent être attendues de leur part : cela peut passer par un questionnaire de sécurité accompagné de documentations internes ou bien par la mise en place d’un plan d’assurance sécurité (PAS) lors de l’appel d’offre. Le PAS permet de décrire et de contractualiser les exigences sécurité entre l’entreprise et le partenaire. En fonction des projets, des certifications spécifiques peuvent également être nécessaires : PCI-DSS dans le cadre d’activité monétique, ou encore HIPAA aux Etats-Unis pour les activités traitant des données de santé.
Conclusion
Nous considérons l’intégration de la sécurité dans les projets comme l’un des enjeux majeurs du RSSI. Les avantages de cette démarche sont multiples. Elle permet de sensibiliser les équipes projets et métiers aux enjeux de la cybersécurité tout en donnant l’opportunité d’intégrer les problématiques de sécurité organisationnelles, techniques et réglementaires en amont des projets (principe du security by design). L’intégration de la sécurité dans les projets permet également de donner une vision pragmatique des risques cyber auxquels l’entreprise est exposée. Ces informations serviront d’entrants au RSSI dans la priorisation du traitement des risques ainsi que dans les tableaux de suivi des risques communiqués à la direction.
