Face à la démultiplication des outils de sécurité, la notion de consolidation n’évoque plus uniquement une concentration organique des acteurs du marché. C’est également une approche technologique destinée à éviter une porosité du système d’information causée, notamment, par une architecture cyber criblée de “rustines” génératrices de brèches et d’angles morts.
Les RSSI sont 77 % à considérer, aujourd’hui, comme critique la réduction du nombre de solutions et de services de sécurité. Ce chiffre, remonté par une étude menée par Palo Alto Networks, s’explique par une véritable explosion du nombre d’applications dans les services informatiques des entreprises, due notamment à l’augmentation de la surface d’attaque. En cause, l’évolution technologique, le passage au “move to Cloud”, une propension forte à l’adoption du multi Cloud et une industrie qui cumule à la fois de plus en plus d’objets connectés et fait converger son informatique bureautique (IT) avec son informatique opérationnelle (OT). Pour les cybercriminels, le terrain de jeu s’est démultiplié avec un niveau d’exposition jusqu’alors inégalé et l’apparition de nouveaux scénarios d’attaques. “C’est un processus qui évolue depuis que le monde de l’IP a été introduit dans les entreprises avec des modems, donc depuis une bonne vingtaine d’années, précise Raphaël Marichez, Chief Security Officer Régional (France et Europe du Sud), chez Palo Alto Networks. C’est très progressif, mais surtout, ça continue !” Pour lui, nous ne sommes pas face à un pic mais sur une tendance de fond qui devrait obliger les RSSI à prendre du recul sur ce phénomène et à ne pas foncer tête baissée.
Gérer les espaces entre les “rustines”
Trop souvent encore, la décision d’acquérir un produit cyber découle de la découverte d’une brèche, même ponctuelle. “Dans le cas d’un move to Cloud, par exemple, si le responsable sécurité souhaite protéger l’accès aux ressources applicatives, le réflexe est de mettre un reverse proxy. L’évolution incrémentale de l’architecture cyber dans les entreprises où les administrations publiques se fait par à-coups.”, illustre Raphaël Marichez. Il ne s’agit pas ici, bien entendu, de remettre en question le dynamisme d’un marché qui fait de son mieux pour être inventif, mais de s’interroger sur les espaces présents entre lesdites rustines. “Dans mon premier métier, c’est en tout cas ce que je recherchais en tant que consultant en test d’intrusion : des interstices entre les solutions de sécurité, les durcissements des politiques, les mots de passe robustes, les pare-feu, etc. en gros tout ce qui m’empêche d’accéder au contrôleur de domaine. Il suffit d’une brèche pour l’exploiter”, raconte Raphaël Marichez.
Anticiper les éventuels dysfonctionnements
Le deuxième corollaire négatif est qu’une fois empilées les unes sur les autres, les rustines fonctionnent généralement moins bien. Certaines entreprises ont trois, voire quatre agents logiciel de sécurité installés sur les postes de travail des collaborateurs. Même si chacun d’entre eux a une spécificité, les chevauchements sont nombreux et ont des conséquences économiques, opérationnelles et organisationnelles. Les entreprises paient en effet plusieurs fois pour un même service, parfois même sans le savoir. Elles se retrouvent confrontées à un risque opérationnel avec une surconsommation de CPU et de mémoire ainsi que des postes de travail moins opérationnels.
Au-delà de l’interopérabilité, faire coopérer les applications
Les équipes IT se retrouvent à gérer un effet de bord qui aurait pu être évité. Comment ? “En prenant du recul, explique Raphaël Marichez. Cette tendance à empiler des briques fonctionnelles est durable. Il faut donc réfléchir à la façon de les agencer, non seulement pour garantir qu’il n’y ait pas d’interstices mais aussi pour voir comment elles peuvent coopérer.” Mais coopérer ne signifie pas se contenter de mettre en place des APIs, explique l’ingénieur. “Ça c’est de l’interopérabilité. Le réseau va apporter de la valeur lorsque les différents membres du réseau, en se rencontrant, vont créer plus de valeur avec des sémantiques de données qui ont été pensées dans une finalité unique et cohérente afin de réduire les risques. N’oublions pas que l’objectif est de réduire les risques et d’avoir le moins d’alarmes possibles à traiter !” Reste qu’il faut, au préalable, définir dans la phase du design des produits, la façon dont les données sont normalisées et structurées. Pour faire coopérer deux produits indépendants, il faut normaliser les échanges de données en prenant le plus petit dénominateur commun. L’information transmise risque d’être partielle et donc incomplète. Un analyste SOC qui récupère une alarme peut ne pas savoir, par exemple, à qui appartient l’agent qui l’a générée et va devoir changer de console pour le savoir. Une perte de temps et, surtout, d’efficacité.
