Dans l’océan de solutions existantes pour piloter l’activité GRC de cybersécurité, les mêmes questions semblent se poser régulièrement : Quels sont les apports de cet outil ? Comment bien choisir la solution adaptée à mon besoin ? Pourquoi les solutions semblent-elles si différentes en termes de fonctionnalité et surtout en termes de prix ?
Nous vous proposons ainsi dans cette article notre retour d’expérience sur les apports de ces solutions de GRC et sur la méthodologie que nous employons auprès de nos clients pour les aider à s’outiller.
S’outiller en GRC : Indispensable ?
Pour une société relativement mature en cybersécurité, une action dite « élémentaire » (par exemple la mise en place d’un SOC) va impliquer la mise à jour de nombreux éléments liés à la GRC (niveaux de risques et du plan de traitement associé ; conformité par rapport à des frameworks internes et externes ; roadmap Cybersécurité ; indicateurs à présenter à la direction etc.). Il faudra donc penser, suite à la mise en place de cette action, à faire des mises à jour sur de nombreux documents/outils pour s’assurer de la cohérence globale du pilotage de la cybersécurité de l’entreprise.
La majorité des outils de GRC du marché proposent de simplifier cet exercice en centralisant l’information et en automatisant la mise à jour de celle-ci. Ce sont donc majoritairement des outils de pilotage, qui aident à la définition de la stratégie globale de cybersécurité, et non des outils qui aident « directement » à la sécurisation du SI.
Nous observons aujourd’hui que la mise en place d’un outil GRC semble particulièrement approprié pour les structures qui :
- Ont des enjeux de certification
- Ont une organisation de la cybersécurité avec un fort niveau de délégation
- Ont une organisation multi filiale de la cybersécurité
- Sont soumises à de nombreuses normes et réglementations
Un marché très mature et varié, dans lequel il peut sembler complexe de s’y retrouver
Un tour d’horizon du marché des solutions GRC permet de se mettre en évidence que certaines solutions du marché peuvent être très polyvalentes (capacité à adresser la majorité des sujets de GRC via un ou plusieurs modules dédiés) tandis que d’autres apparaissent dédiées à un usage spécifique (en particulier la gestion du risque ou la gestion de la conformité). La réponse aux besoins de reporting, bien que toujours adressée, reste quant à elle très hétérogène.
Il n’existe par ailleurs pas de définition formelle d’un outil GRC, cette appellation étant finalement utilisé de manière variable selon les éditeurs, tant qu’elle adresse au moins un de ces sujets. Par conséquent, il n’existe pas de magic quadrant du gartner dédié, contrairement à d’autres outils de cybersécurité (comme un EDR ou un SIEM par exemple).
Ainsi, pour s’outiller en GRC, il ne suffit pas de dire « je prends le meilleur outil du marché » Cadrer son besoin en amont devient indispensable, et c’est cette approche que nous mettons en place auprès de nos clients avant toute proposition d’un outil GRC.
Cadrer son besoin pour s’y retrouver dans les solutions du marché
Cadrer son besoin implique non seulement d’identifier ces besoins actuels en termes de GRC, mais aussi les besoins à venir, afin d’identifier un outil qui puisse évoluer avec son entreprise.
Pour les entreprises multi filiale, viennent s’ajouter à ce cadrage l’identification des besoins de leurs filiales, mais aussi de l’approche à adopter sur le déploiement : imposer l’utilisation de l’outil ou le rendre disponible aux filiales et leur laisser le choix de l’adoption. Cette seconde approche semble par ailleurs la plus appropriée pour les clients que nous avons pu accompagner sur le sujet.
Le cadrage du besoin doit aussi permettre d’identifier les critères qui font que l’outil GRC répondra à vos besoins (niveau de flexibilité et de customisation attendu ; facilité de prise en main et d’automatisation ; niveau de support attendu ; etc). Si cette étude est facilement réalisable en interne pour une petite structure, elle nécessite souvent pour des structures plus grande la mise en place d’ateliers dédiés avec les filiales pour identifier leurs attentes dans ce cadre.
Dans ce cadre, nous avons d’ailleurs pu constater que :
- La réponse au besoin des filiales ne doit pas se faire au détriment de la réponse au besoin de la « société mère ».
- Les filiales ayant souvent des niveaux de maturité très différents, il sera complexe d’avoir des outils qui satisferont l’ensemble des filiales.
- Les filiales peu matures sont souvent les meilleurs acteurs pour promouvoir l’utilisation d’un outil.
Une fois les besoins cadrés, une première étude du marché s’avère indispensable pour identifier les solutions qui semblent les plus adaptés à vos besoins.
Ces éléments identifiés dans le cadrage seront à mettre en comparaison du budget que vous souhaitez allouer à votre solution.
Dans le cadre d’une intégration de la solution au sein de plusieurs filiales, nous vous préconisons d’identifier en amont un potentiel taux d’adoption de l’outil afin de prévoir un budget adapté et évolutif.
Tour d’horizon des coûts et des inducteurs de coût
Une première demande d’information auprès des différents acteurs du marché mets rapidement en avant le fait que certains acteurs se trouvent très réticent à donner des informations sur leur solution, en particulier sur leur prix. Voici donc quelques éléments sur les solutions du marché que nous avons pu avoir identifiés lorsque que nous avons accompagnés nos clients.
Les coûts de licences annuelles des outils que nous avons analysés sont très variables, allant de moins de 10k€ pour des solutions très spécialisées, à plus de 500k€ pour des solutions avec des fortes capacités d’automatisation. Les solutions dédiées à la gestion des risques peuvent s’avérer souvent moins couteuse que leurs homologues axées sur la gestion de la conformité. Les variations de prix sont principalement influencées par les inducteurs de cout suivant :
- Le nombre de fonctionnalité/module utilisés dans l’outil
- Le chiffre d’affaires de la société.
- Le nombre de sous-tenants/workspace
- Le nombre de Framework de conformité/d’analyse de risques disponibles
- Le nombre d’utilisateurs et/ou administrateurs
- Le nombre d’assets présents dans l’outil
- Le nombre d’employés/utilisateurs IT de l’entreprise
- Le nombre de connecteurs nécessaire.
A noter que les éditeurs que nous avons analysés n’utilisent pas l’ensemble des inducteurs de cout présentés ici, mais seulement une partie de ces dernières. Il n’y a pas, à notre connaissance, d’inducteur de cout commun à tous les éditeurs.
Comme pour les licences, le coût de BUILD reste très variable selon les éditeurs. Certains éditeurs incluent toute la phase d’intégration dans la licence, sans surcout associé. La majorité des éditeurs ont des partenariats avec des sociétés externe pour intégrer la solution, ce qui peut entrainer des couts de BUILD assez conséquent. Nous vous préconisons fortement de challenger les éditeurs sur le contenu de la phase de BUILD (et donc sur son coût) car il arrive que les stratégies de BUILD proposées soient standardisées et non adaptées à votre entreprise et ses besoins immédiats.
Et après ?
La première phase d’analyse du marché se conclut souvent par la mise en place d’un appel d’offre, indispensable aujourd’hui pour la plupart des solutions de GRC afin de cadrer le cout de celle-ci. A noter cependant qu’il existe certains acteurs où le passage par un appel d’offre n’est pas indispensable, les prix étant fixés en amont.
Nous accompagnons aujourd’hui de nombreux client sur ces appels d’offre. Nous pouvons donc peut vous accompagner sur cette étape, ainsi que sur l’identification de votre besoin en GRC selon la méthode décrite dans cet article, alors n’hésitez pas à nous solliciter pour que nous échangions sur la meilleure manière de répondre à vos besoins d’outillage.
Prendre un rendez-vous
