Pour se faire entendre des membres du conseil d’administration, les RSSI doivent non seulement apprendre leur vocabulaire, mais aussi traduire le risque cyber dans le langage des affaires.
S’engager auprès du conseil d’administration ne fera peut-être pas la carrière d’un RSSI, mais c’est une compétence de plus en plus importante, d’autant plus que les membres des instances dirigeantes, inquiets des risques, recherchent des informations stratégiques sur la sécurité. Le défi ne consiste pas seulement à présenter des informations techniques, mais aussi à aligner la cybersécurité sur les priorités et objectifs commerciaux du conseil d’administration.Cependant, les RSSI peuvent avoir du mal à déchiffrer les signaux des conseils d’administration, comprendre ce qu’ils veulent ou ne veulent pas entendre. Mais il existe des moyens de décoder leurs attentes.Trouver un allié au sein du conseil d’administrationTrouver un partisan au sein du conseil peut aider le RSSI à aligner ses rapports sur les exigences de cette instance et à améliorer son engagement auprès de celle-ci. Stephen Bennett, RSSI du groupe Dominos, lance : « trouvez un champion au sein du conseil d’administration qui vous aidera à identifier exactement ce que le conseil veut entendre ». Les RSSI peuvent passer beaucoup de temps à essayer de déterminer ce que souhaite le conseil d’administration et à créer toutes sortes de rapports différents dans l’espoir d’y parvenir. Aller directement à la source évite de gaspiller trop d’énergie dans la recherche de cet alignement.Stephen Bennett s’est associé à un membre de son conseil d’administration. Selon lui, cela l’avait aidé à affiner son approche en matière de rapports à présenter. Il s’est ainsi rendu compte qu’il était nécessaire d’avoir une vision plus stratégique et de haut niveau. Ce dialogue lui a aussi permis d’identifier les informations techniques qui doivent être expliquées aux administrateurs qui n’ont pas de connaissances spécifiques en matière de cybersécurité. « J’ai été surpris de constater que le conseil d’administration ne comprenait pas très bien certains termes que nous utilisons régulièrement, tels que endpoint, pare-feu ou framework NIST », explique-t-il.Il s’est rendu compte qu’il devait combler ce fossé et a ainsi élaboré un glossaire et un livre blanc expliquant les cadres et les normes de conformité applicables à l’organisation. De quoi fournir des informations de base et s’assurer que tout le monde utilise le même langage. « L’idée est que ces deux documents changent rarement parce que les exigences de conformité et les pratiques de gestion des risques sont relativement identiques au fil des évaluations de maturité », précise-t-il.Les bases étant posées, le RSSI a pu utiliser ses rapports réguliers pour faire le point sur la manière dont il atténue les risques pour l’organisation, mettant en évidence la valeur de l’investissement dans la cyber. « J’explique où nous en sommes du point de vue de la maturité cyber, ce que nous avons fait l’année dernière, ce que nous devons faire l’année prochaine et le type de budget dont nous avons besoin », détaille-t-il.Cette expérience l’a aidé à modifier son approche et à passer de rapports qui ressemblent à un registre exhaustif des risques à une évaluation stratégique des risques exprimée dans le langage des affaires. Un changement de ligne hiérarchique – Stephen Bennett dépend aujourd’hui du directeur financier – l’a également aidé à élaborer des rapports orientés business. « Ce n’est que lorsque vous rendez compte à quelqu’un qui n’est pas impliqué dans la technologie que vous appréhendez combien vous parlez en jargon et que vous êtes loin de parler la langue de l’entreprise », reconnaît le RSSI.Décoder ce que le conseil d’administration attend des RSSILes responsables de la cybersécurité doivent avoir des contacts réguliers avec les conseils d’administration afin de se familiariser avec cette instance et de mieux la comprendre. Sans cela, un manque de clarté peut conduire à partager trop de détails techniques ou à ne pas fournir suffisamment de contexte stratégique.Paul Connelly, ancien RSSI devenu conseiller, administrateur indépendant et mentor, estime que de nombreux RSSI se concentrent trop sur les KPI, alors que le conseil d’administration recherche des informations plus stratégiques. Cette instance n’a pas besoin de connaître les résultats de votre test d’hameçonnage, illustre Paul Connelly. Les conseils d’administration se concentrent sur les risques auxquels l’organisation est confrontée, les stratégies pour y faire face, les progrès réalisés, les obstacles et l’allocation des moyens aux sujets qui comptent réellement.« Je conseille aux RSSI d’étudier leur conseil d’administration, de lire leur biographie, de comprendre leurs antécédents et d’appréhender la responsabilité fiduciaire d’un conseil d’administration », ajoute-t-il. L’objectif : décoder la composition du conseil et ses priorités, et mieux canaliser ses métriques en matière d’analyse des risques et des menaces pour l’entreprise.À l’aide de ces informations, les RSSI peuvent élaborer une présentation de leur programme alignée sur l’activité. « C’est un récit de haut niveau – étayé par des mesures – que les conseils d’administration veulent entendre, et non un ensemble de KPI sur les courriels malveillants, les correctifs critiques ou les menaces effrayantes du type Chicken Little », explique Paul Connelly. Cependant, il ne s’agit pas d’une interaction à sens unique, et de nombreux RSSI travaillent avec des conseils d’administration qui n’ont pas les compétences et la compréhension nécessaires pour favoriser des discussions fructueuses sur les cybermenaces. « Très peu de conseils d’administration disposent d’une véritable expertise en matière de technologie ou de cyber », reconnaît l’ancien RSSI.Selon une étude de 2024 du Diligent Institute, seulement 5 % des entreprises comptent des experts en cybersécurité au sein de leur conseil d’administration, ce qui laisse supposer que la majorité de ces instances ont du mal à superviser ce sujet. Bien que la technologie soit une composante clef de l’innovation et de la croissance, et que les risques associés soient parmi les plus importants et les plus complexes auxquels sont confrontées la plupart des entreprises, de nombreux conseils d’administration n’ont pas les compétences nécessaires pour s’attaquer à ce sujet. « Ils approuvent sans discussion ce que leur présente la direction ou posent les cinq questions principales qu’ils ont lues dans un article de McKinsey, mais ne sont pas en mesure d’approfondir les réponses qu’ils obtiennent », dit Paul Connelly.Il suggère aux RSSI d’inclure de brèves vidéos de formation, d’organiser des exercices sur table pour le conseil d’administration ou encore d’inclure des documents de vulgarisation supplémentaires dans les documents remis chaque trimestre au conseil d’administration. « Tout ce qui peut aider à combler le manque d’expertise », selon l’ancien RSSI.Aller au-delà des questions de type oui ou nonIl existe un décalage important entre la vision qu’ont les RSSI des priorités en matière de cybersécurité et celle de leurs conseils d’administration. Et ce, dans un certain nombre de domaines. Selon une étude de l’éditeur Splunk, les RSSI sont plus enclins à penser que la profondeur des connaissances est une compétence importante, alors que les conseils d’administration souhaitent que les RSSI soient plus aptes à communiquer et qu’ils aient un meilleur sens des affaires. En outre, les conseils d’administration sont plus enclins que les RSSI à insister sur les tests de validation des contrôles de cybersécurité existants et à penser que la conformité est un gage de réussite.Ce manque de compréhension de la cybersécurité peut laisser les administrateurs mal équipés pour tirer le meilleur parti de l’expertise de leur RSSI. « Il faut savoir que certains membres du conseil d’administration seront très intéressés par la cybersécurité et d’autres pas du tout. Il faut parfois présenter un rapport à l’ensemble des membres du conseil d’administration, certains voulant une infinité de détails, tandis que d’autres aimeraient simplement savoir si tout va bien ou pas », résume Stephen Bennett, le RSSI de Dominos.Pour aller au-delà des questions de type oui ou non et fournir au conseil d’administration des informations contextuelles et des orientations stratégiques, les RSSI ne doivent pas se contenter de cocher des cases. Stephen Bennett a constaté que le recours à des sources d’information supplémentaires est un moyen efficace d’analyser les risques réels et leurs implications pour l’entreprise. « Je ne me contenterai pas de dire : ‘Voici les risques’. Je leur fournirai un contexte pour les aider à comprendre les choses plus en profondeur », explique le RSSI.Les articles de presse sur les incidents de sécurité peuvent ainsi être reliés aux contrôles de sécurité effectués, à la manière dont le budget est dépensé et à ce que cela signifie pour le niveau de risque de l’organisation et sa capacité de réaction si elle est confrontée au même type de menace. « Au lieu de donner des chiffres, je leur montrerai comment notre investissement a fonctionné. Par exemple, comment nous sommes passés d’un état où il fallait trois jours à cinq membres de l’équipe pour résoudre un incident à une situation où quatre heures suffisent, et avec une visibilité totale », illustre Stephen Bennett.Trouver des occasions de dialoguer avec les membres du conseil d’administration en dehors des réunions officielles est un autre moyen efficace pour les RSSI d’améliorer leur niveau d’échanges avec les membres de cette instance. Qu’il s’agisse de participations à des comités ou de réunions individuelles ad hoc, ces efforts contribuent à développer les relations avec les membres du conseil, souligne le rapport 2025 State of the CISO de l’IANS, institut spécialisé dans la cyber et fournissant conseils et formations.Paul Connelly estime qu’il s’agit d’un autre facteur important pour une relation de travail fructueuse entre le RSSI et son conseil d’administration. Lorsqu’il était RSSI, il était invité à des dîners du conseil d’administration et a ainsi appris à connaître les membres du comité d’audit. « Ce niveau d’accès et de confort a facilité de bonnes discussions au cours desquelles les membres du conseil d’administration n’hésitaient pas à poser des questions », explique-t-il.
Les dépôts de code, issus d’un développement assisté par l’IA, sont 40% plus susceptibles de contenir des clés d’API, des mots de passe ou des jetons. Et il ne s’agit là qu’un des nombreux problèmes auxquels sont confrontés les RSSI avec le code généré par l’IA.
Les assistants de codage à base d’IA font partie des premières réussites de la GenAI en entreprises. De plus en plus adoptés, les copilotes de programmation font des incursions dans les processus de développement, améliorant la productivité des développeurs et aidant à mettre en place rapidement des projets rudimentaires.Mais ils posent également un problème de sécurité, et le volume anticipé de code qu’ils produiront bientôt s’apparente à un cauchemar en devenir pour les responsables de la sécurité, selon les experts. À la discussion habituelle sur les hallucinations inhérentes à la GenAI s’ajoute la probabilité accrue d’exposer des secrets tels que les clés API, mots de passe et jetons dans le code généré par l’IA.Selon une étude récente de GitGuardian, société spécialisée dans la détection automatisée des vulnérabilités dans les codes sources, les référentiels GitHub, issus d’un développement avec un copilote, sont plus susceptibles d’exposer des secrets que les dépôts standard. 6,4% des dépôts échantillonnés contiennent des clés API, des mots de passe ou des jetons risquant d’être volés, contre 4,6% en moyenne.Selon les analystes de GitGuardian, cela se traduit par un taux d’incidents de type fuite de secrets supérieur de 40%. Les mêmes analystes avertissent que l’utilisation d’assistants de codage peut pousser les développeurs à donner la priorité à la productivité plutôt qu’à la qualité et à la sécurité du code, et ajoutent que le code généré par les grands modèles de langage (LLM) peut être intrinsèquement moins sûr que les logiciels écrits de manière conventionnelle.Les failles sous-jacentes au développement avec l’IALes experts en sécurité s’accordent à dire que l’utilisation d’assistants de codage IA aboutit à du code moins sécurisé. David Benas, consultant principal associé chez l’éditeur de solutions de sécurité applicative Black Duck, explique que ces problèmes de sécurité sont une conséquence naturelle de l’entraînement des modèles d’IA sur du code généré par l’homme.« Le plus tôt tout le monde se sentira à l’aise avec le fait de traiter ses LLM générateurs de code comme s’il s’agissait de stagiaires ou d’ingénieurs juniors poussant du code, le mieux ce sera, soupire David Benas. Les modèles sous-jacents aux LLM seront intrinsèquement aussi défectueux que la somme du corpus de code humain, avec une portion supplémentaire de défauts en raison de la tendance de ces outils à halluciner, à raconter des mensonges, à mal comprendre les requêtes, à traiter des requêtes défectueuses, etc. »Si les assistants tels que GitHub Copilot augmentent la vitesse des développeurs, ils introduisent également de nouveaux risques de sécurité, abonde John Smith, directeur de la technologie pour la zone EMEA chez l’éditeur spécialiste de la sécurité applicative Veracode. « Ces outils manquent souvent de conscience contextuelle des pratiques de sécurité et, sans une supervision appropriée, peuvent générer du code non sécurisé et des vulnérabilités persistantes, dit-il. Cela devient un problème systémique lorsque le code généré par les LLM se propage et crée des failles tout au long de la supply chain logicielle. » Selon une récente étude de Veracode, plus de 70 % de la dette critique de sécurité provient désormais de codes tiers.PublicitéDes contrôles de sécurité négligésMark Cherp, chercheur en sécurité au sein du spécialiste de la gestion des identités CyberArk, souligne que les assistants de codage de l’IA n’adhèrent la plupart du temps pas aux bonnes pratiques de gestion des secrets, généralement présentes dans les systèmes traditionnels. « Par exemple, ils peuvent insérer des informations sensibles en texte clair dans le code source ou les fichiers de configuration, explique l’expert. En outre, comme de grandes portions de code sont générées pour des produits en phase de démarrage, les meilleures pratiques telles que l’utilisation de gestionnaires de secrets ou la mise en oeuvre de l’injection de mots de passe et de tokens en temps réel sont souvent négligées. »Et Mark Cherp d’ajouter : « Il y a déjà eu des cas où des clés d’API ou des clés publiques d’entreprises telles qu’Anthropic ou OpenAI ont été laissées par inadvertance dans le code source ou téléchargées dans des projets Open Source, ce qui les rend facilement exploitables. Même dans les projets à code source fermé, si les secrets sont codés en dur ou stockés en texte clair dans des fichiers binaires ou des fichiers JavaScript locaux, le risque reste important, car ces secrets demeurent faciles à extraire. »Établir des pratiques sécurisées pour et avec l’IAChris Wood, spécialiste sécurité applicative de la société de formation en cybersécurité Immersive Labs, qualifie l’avertissement de GitGuardian sur les dangers des assistants de codage à base d’IA de signal d’alarme. « Bien que l’IA présente un potentiel incroyable pour stimuler la productivité, il est crucial de se rappeler que la sécurité qu’offrent ces outils n’est jamais supérieure à celle de leurs données de formation et à la vigilance des développeurs », dit-il.Les RSSI et les responsables de la sécurité doivent commencer par formuler des stratégies globales de gestion des secrets. En outre, les entreprises devraient établir des politiques claires concernant l’utilisation d’assistants d’IA dans la programmation et fournir aux développeurs une formation spécifique sur le développement sécurisé avec l’IA. « Nous devons doter les développeurs des connaissances et des compétences nécessaires pour identifier et prévenir ces types de vulnérabilités, même lorsque l’IA accompagne la création du code, reprend Chris Wood. Cela inclut de solides bases concernant les principes de sécurisation des développements, la compréhension des schémas courants de fuite de secrets, ou encore la connaissance des bonnes pratiques de gestion et de stockage des informations d’identification sensibles. En donnant aux développeurs les connaissances nécessaires et en encourageant un état d’esprit axé sur la sécurité, nous pouvons exploiter les avantages de l’IA tout en atténuant les risques de vulnérabilités accrues [qu’elle introduit], telles que les fuites de secrets. »Contre-mesures proactivesPlus le code issu de LLM sera généralisé, plus les développeurs lui feront confiance, ce qui aggravera encore le problème et créera un cercle vicieux, qu’il faut tenter de briser. « En l’absence de tests de sécurité appropriés, les codes générés par l’IA et non sécurisés deviendront les données d’entraînement des futurs LLM, souligne John Smith de Veracode. Fondamentalement, la façon dont les logiciels sont construits évolue rapidement. »Le développement rapide de l’IA continuera à dépasser les contrôles de sécurité, à moins que les entreprises ne prennent des mesures proactives pour contenir le problème plutôt que de miser sur des correctifs a posteriori. « Les RSSI doivent agir rapidement pour intégrer des garde-fous, en automatisant les contrôles de sécurité et les examens manuels du code directement dans les processus des agents d’IA et des développeurs, conseille John Smith. L’audit des bibliothèques tierces permet de s’assurer que le code généré par l’IA n’introduit pas de vulnérabilités provenant de composants non vérifiés. »L’intégration d’outils automatisés, tels que des scanners dans le pipeline CI/CD, suivie d’une révision humaine obligatoire du code par les développeurs, devrait être systématisée pour examiner les applications développées à l’aide d’assistants à base d’IA. « Tout le code généré par l’IA doit être surveillé et assaini en permanence, et un plan de réponse rapide aux incidents doit être mis en place pour traiter toute vulnérabilité qui serait découverte », tranche Mark Cherp de CyberArk.Une gestion des secrets toujours approximativeLe problème de la gestion des clés d’API, des mots de passe et des jetons n’est pas nouveau dans la sécurité applicative. Mais les récentes innovations dans le développement de code alimenté par l’IA l’aggravent. L’étude State of Secrets Sprawl 2025 de GitGuardian pointe une augmentation de 25 % des fuites de secrets d’une année sur l’autre, avec 23,8 millions de nouveaux identifiants détectés sur des dépôts GitHub publics rien qu’en 2024. Les secrets codés en dur sont partout, mais surtout dans les angles morts de la sécurité comme les plateformes de collaboration (Slack et Jira) et les environnements de conteneurs où les contrôles de sécurité sont généralement plus faibles, selon GitGuardian.Bien que la fonction Push Protection de GitHub aide les développeurs à détecter les schémas de divulgation connus, les secrets génériques – comme les mots de passe codés en dur, les identifiants de base de données et les jetons d’authentification personnalisés – représentent désormais plus de la moitié de toutes les fuites détectées. En effet, contrairement aux clés d’API ou aux jetons OAuth qui suivent des schémas reconnaissables, ces informations d’identification ne correspondent à aucun modèle standardisé, ce qui les rend presque impossibles à détecter avec les outils conventionnels, prévient GitGuardian.GitGuardian met ainsi en avant la fuite de données du département du Trésor américain en 2024. Eric Fourrier, PDG de GitGuardian, y voit un avertissement : « une simple fuite de clé API de BeyondTrust a permis à des attaquants d’infiltrer les systèmes gouvernementaux. Il ne s’agissait pas d’une attaque sophistiquée, mais d’un simple cas d’identification exposée qui a permis de contourner des millions d’investissements en matière de sécurité. »Les mesures correctives tardent à venirL’étude montre également que 70 % des secrets divulgués restent actifs même deux ans après leur première exposition. Selon les experts en sécurité, les retards sont dus à la complexité des mesures correctives. « Les fuites de clés d’API, de mots de passe et de jetons sont souvent négligées parce que leur détection ne constitue qu’une partie de la solution ; une remédiation efficace est complexe et souvent différée », indique Mayur Upadhyaya, PDG du fournisseur d’outils de cybersécurité APIContext. « La dépendance à l’égard des clés statiques, souvent intégrées dans le code pour des raisons de commodité, continue d’être un point faible majeur ».Et Mayur Upadhyaya d’ajouter : « Les meilleures pratiques telles que la rotation des clés, la mise en oeuvre de jetons à courte durée de vie et l’application de la règle du moindre privilège sont bien comprises mais difficiles à maintenir à l’échelle d’une organisation ». Selon lui, les entreprises devraient chercher à mettre en place des garde-fous plus solides, comme des outils d’analyse automatisés, une surveillance proactive du code et un meilleur accompagnement des développeurs.
En milieu de semaine, Zoom a vécu une panne de quelques heures rendant indisponibles ses services de visioconférence. Dans son enquête post-incident, l’éditeur a constaté une série d’erreurs de communication entre plusieurs prestataires techniques.
Mercredi 16 avril, de nombreux utilisateurs de Zoom ont signalé des problèmes de connexion, entraînant une vague de plaintes et de rapports de pannes. Ces perturbations ont duré environ deux heures. Cependant, contrairement à ce que l’on pouvait craindre, l’indisponibilité n’était ni liée à une attaque ni à une défaillance interne du réseau. La cause de l’interruption a été attribuée à son domaine principal, zoom.us, qui a été temporairement désactivé à la suite d’une série d’erreurs de communication entre différents prestataires techniques.
Une erreur administrative
Selon la plateforme, la panne provient d’une « erreur de communication » entre Markmonitor, service de protection des marques et GoDaddy, son gestionnaire de domaine. D’après le communiqué de la plateforme, cette défaillance de coordination a conduit ce dernier à désactiver par erreur le domaine zoom.us, rendant le service inopérant pour une grande partie des utilisateurs. Cependant, la version de GoDaddy diffère. Interrogée par Computerworld, Kristy Nicholas, porte-parole du registrar, précise que le problème se situe entre Markmonitor et Zoom. Le gestionnaire aurait alors contacté un représentant de Markmonitor pour l’en informer. Bien que ce dernier ait accusé réception, il n’aurait pas transmis l’information à Zoom. Faute de retour et d’action dans les jours suivants, GoDaddy a appliqué son protocole standard en plaçant un blocage sur le serveur concerné. Ce genre de problème de communication n’est “pas rare” avec de nombreux clients, a-t-il ajouté.
Une fois le problème identifié, les trois parties, ont travaillé ensemble pour lever le blocage et réactiver le domaine zoom.us. Toutefois, le rétablissement total du service n’a pas été instantané : les enregistrements DNS, stockés à divers niveaux sur l’Internet mondial, ont nécessité quelques minutes supplémentaires pour se propager complètement.
Un système obsolète
Pour Johannes Ullrich, doyen de la recherche au SANS Institute, cet incident met en évidence les failles d’un système devenu obsolète : « Le système whois, censé fournir des contacts techniques fiables et à jour, n’a jamais vraiment fonctionné correctement. Aujourd’hui, la plupart des domaines utilisent des services de confidentialité qui masquent ces informations, rendant la communication entre acteurs plus difficile. »
De son côté, Markmonitor, filiale de Newfold Digital, a confirmé avoir inclus Zoom dans les échanges avec GoDaddy, tout en reconnaissant que la coordination entre les différents intervenants aurait pu être améliorée. Dans cette optique, le gestionnaire de domaine envisage déjà des ajustements pour éviter de futures erreurs. « À l’avenir, si nous ne pouvons pas confirmer qu’un message a bien été transmis au client, nous le contacterons directement avant de prendre toute mesure sur le domaine », assure Kristy Nicholas.
Face à l’émoi provoqué par l’arrêt du financement du programme CVE de MITRE, l’administration américaine a finalement prorogé son aide de 11 mois. L’affaire a cependant soulevé des inquiétudes sur la pérennité budgétaire du projet et a enclenché plusieurs initiatives alternatives y compris en Europe.
Le signal d’alarme lancé par l’association MITRE n’est pas resté sans réponse. Menacée de disparition en raison des coupes budgétaires envisagées par l’administration Trump, la base de données CVE (Common Vulnerabilities and Exposures), en service depuis 25 ans, a finalement été préservée in extremis. Le département américain à la sécurité intérieur (DHS) principal bailleur de fonds décidé au dernier moment de maintenir son financement, comme l’a confirmé un porte-parole de l’agence américaine de cybersécurité CISA auprès de Bleeping Computer. Si cette décision apporte un soulagement temporaire à la communauté cybersécurité, elle laisse subsister de fortes incertitudes quant à au soutien financier à long terme.
Bruce Schneier, expert reconnu en cybersécurité et membre du conseil d’administration de l’Electronic Frontier Foundation, s’est dit préoccupé par le caractère improvisé de cette décision. Selon lui, elle reflète une tendance inquiétante à réduire arbitrairement les budgets sans évaluer l’importance critique de certains programmes, comme celui de la base CVE. “Quelqu’un a fini par réaliser son importance et a rétabli temporairement le financement. Mais rien ne garantit sa pérennité”, a-t-il déclaré. Bruce Schneier a également rappelé le rôle central du programme CVE dans la cybersécurité mondiale soulignant qu’une base de données centralisée reste essentielle pour identifier, classer et gérer les failles de manière efficace. Il appelle à préparer dès aujourd’hui une solution durable, au cas où les États-Unis décideraient de se retirer définitivement du projet.
La CVE Foundation voit le jour et l’Enisa se mobilise
Face à ces incertitudes, plusieurs initiatives ont été mises en place. Ainsi le conseil d’administration du programme CVE a annoncé la création de la CVE Foundation. Elle se concentrera uniquement sur la poursuite de la mission d’identification des vulnérabilités de haute qualité et de maintien de l’intégrité et de la disponibilité des données CVE pour les défenseurs du monde entier, ont déclaré les organisateurs. Dans un courrier, Johannes Ullrich, chercheur au SANS Institute, évoquait la tenue de discussions « sur la possibilité de créer une nouvelle entité pour diversifier les sources de financement, notamment la participation d’acteurs internationaux ».
L’affaire a également eu pour effet de réveiller l’Union européenne sur ce sujet à travers l’Enisa, l’organisme en charge des questions de cybersécurité. Depuis juin 2024, ce dernier a la charge d’une base de donnée nommée European Union Vulnerability Database (EUVD) dans le cadre de la directive NIS 2. Ce projet est co-financé par l’Union européenne et le CERT Luxembourgeois. La base est pour l’instant en version beta.
La base EUVD de l’Enisa fait ses premiers pas. (Crédit Photo : Enisa)
L’appel à un financement stable et durable
Roger Grimes, expert en défense de la cybersécurité chez KnowBe4, a critiqué dans un courrier à nos confrères de CSO la situation actuelle où les responsables de MITRE se voient dans l’obligation de solliciter des financements privés. “Ce n’est pas un programme où les responsables devraient mendier pour obtenir des fonds. Il devrait être pleinement financé, correctement doté en ressources et capable de réaliser son travail de manière optimale,” a-t-il déclaré. Il a exprimé l’espoir que la prolongation du financement n’était pas qu’une mesure temporaire, mais qu’elle permettrait d’améliorer le programme pour qu’il devienne un service véritablement à la hauteur de sa mission.
Le fournisseur de Sase a ajouté à son courtier en sécurité d’accès au cloud (Cloud Access Security Broker ou CASB) des contrôles de sécurité pour suivre l’usage de la GenAI.
Selon Cato Networks, les capacités d’IA générative de son Cloud Access Security Broker (CASB) récemment dévoilées permettront aux services IT des entreprises de détecter, d’analyser et d’obtenir des informations sur l’utilisation des applications GenAI. Le CASB du fournisseur de services d’accès sécurisés (Sase), qui fonctionne en natif au sein de la plateforme Cato Sase Cloud Platform, peut suivre les applications auxquelles accèdent les employés, savoir d’où ils se connectent et, dans certains cas, ce qu’ils font lorsqu’ils utilisent ces applications. L’équipementier a ajouté au CASB un tableau de bord pour l’IA fantôme ainsi qu’un moteur de politique qui, selon le fournisseur, aidera les équipes IT à avoir une visibilité sur les activités des utilisateurs finaux avec les applications GenAI et à appliquer les règles liées à l’utilisation de l’IA générative. « Cato Networks nous permet d’adopter la GenAI avec confiance sans craindre d’exposer des données sensibles ou la propriété intellectuelle », a déclaré Shayne Green, responsable des opérations de sécurité chez CloudFactory, dans un communiqué. « Grâce aux nouveaux contrôles de sécurité GenAI du CASB de Cato, nous pouvons adopter ces outils en contrôlant les risques. »
Les courtiers en sécurité d’accès au cloud (CASB) s’interposent entre l’utilisateur final et le service cloud pour appliquer les politiques de sécurité, protéger les données et garantir la conformité. Ils fournissent aux équipes réseau et de sécurité des entreprises des informations sur la manière dont les utilisateurs finaux accèdent et utilisent les ressources cloud comme les données, les applications et les services. Ils fournissent une visibilité sur l’utilisation du cloud, contrôlent l’accès aux applications cloud et offrent une protection contre les menaces auxquelles sont exposés les environnements d’entreprise et ils sont souvent intégrés aux plateformes Sase. Alors que la GenAI est devenue populaire auprès de nombreux utilisateurs finaux, les équipes IT des entreprises doivent être en mesure de surveiller son utilisation et de s’assurer que l’activité ne constitue pas une menace pour l’environnement. Selon Cato Networks, l’adoption de l’IA générative a généré un problème d’« IA fantôme ». Semblable à l’informatique fantôme, l’IA fantôme désigne l’utilisation d’outils d’IA par des utilisateurs finaux à l’insu ou sans l’autorisation des équipes IT ou de sécurité de l’entreprise. Gartner prévoit que d’ici à 2027, plus de 40 % des violations de données liées à l’IA résulteront de « l’utilisation inappropriée de la GenAI. »
90 points de présence (PoP) connectés dans le monde
Grâce aux contrôles de sécurité supplémentaires sur la GenAI, Cato CASB permet aux équipes IT et de sécurité des entreprises de :
– Découvrir les poches d’IA fantôme en détectant et en distinguant les utilisations autorisées de celles qui ne le sont pas, en identifiant toutes les applications de genAI et en les classant. (Cato suit plus de 950 applications de GenAI).
– Contrôler l’accès aux applications de genAI en définissant les actions autorisées avec les applications de GenAI et en appliquant ces politiques d’accès à un niveau granulaire.
– Protéger les données sensibles en limitant ou en empêchant le téléchargement de données sensibles dans les grands modèles de langage (LLM).
– Maintenir la gouvernance et la conformité en surveillant les activités des utilisateurs finaux avec la GenAI et en s’alignant sur les politiques de l’entreprise et les normes réglementaires.
« Les entreprises ont besoin de moyens intelligents pour gouverner la GenAI », a affirmé Ofir Agasi, vice-président de la gestion des produits chez Cato Networks, dans un communiqué. « Avec ces améliorations de Cato CASB, nous exploitons l’IA au sein de la plateforme cloud Cato SaseE pour découvrir, classer et sécuriser la façon dont les applications de GenAI sont utilisées dans l’entreprise. Nous donnons aux équipes IT et de sécurité les outils pour gérer les risques et rendre possible l’innovation responsable. »
Cato Sase Cloud Platform fonctionne sur une dorsale mondiale privée de plus de 90 points de présence (PoP) connectés via de multiples fournisseurs de réseaux offrant des garanties SLA. Le logiciel des PoP surveille en permanence la latence, la perte de paquets et la gigue des fournisseurs afin de déterminer en temps réel le meilleur itinéraire pour chaque paquet. Le fournisseur applique l’optimisation et l’accélération à tout le trafic passant par le backbone pour améliorer la performance des applications et l’expérience de l’utilisateur. Pour s’assurer que tous les sites en bénéficient, la firme optimise le trafic à partir de tous les bords et vers toutes les destinations, sur site et dans le cloud. Les contrôles de sécurité de la GenAI pour Cato CASB sont désormais disponibles pour les clients du monde entier.
En s’appuyant sur un dernier chargeur de malwares pour installer discrètement et déployer ses charges malveillantes, APT29, affilié au renseignement russe, a mené une campagne de phishing ciblée contre des ambassades européennes.
APT29, n’est pas étranger aux opérations de cyberespionnage numérique. Ce groupe, tristement célèbre pour son implication dans l’attaque SolarWinds en 2020, continue de perfectionner ses méthodes tout en conservant une signature identifiable. Dans cette campagne, les pirates russes ont envoyé des emails déguisés en messages officiels d’un ministère des Affaires étrangères européen, invitant leurs cibles à une dégustation de vin. Selon les chercheurs de Check Point, cette invitation était en réalité un leurre destiné à diffuser un cheval de Troie nommé Grapeloader.
Infiltration via DLL
Le chargeur de logiciels malveillants Grapeloader, utilisé dans cette campagne, est un outil de première étape qui facilite l’infiltration du système. Ce programme malveillant s’appuie sur une vulnérabilité de chargement latéral de DLL pour injecter du code malveillant dans un exécutable légitime. Lorsqu’une victime clique sur l’invitation et télécharge l’archive wine.zip, elle obtient trois fichiers : wine.exe, un exécutable PowerPoint vulnérable au chargement latéral de DLL, ainsi que deux fichiers DLL modifiés, AppvIsvSubsystems64.dll et ppcore.dll. Le premier fichier DLL, initialement légitime et destiné à être exécuté par PowerPoint, a été altéré pour inclure du code malveillant. La seconde DLL, ppcore.dll, est directement liée à l’installation du Grapeloader, qui est chargé en mémoire par l’exécutable PowerPoint wine.exe.
Lors de son exécution, ce chargeur malveillant s’installe sur l’ordinateur de la victime, s’assure de sa persistance après chaque redémarrage et commence à collecter des informations telles que le nom d’utilisateur, les processus actifs et d’autres données systèmes. Ces informations sont ensuite envoyées à un serveur de commande et de contrôle (C2) via HTTPS, permettant à APT29 d’envoyer des instructions supplémentaires au malware, y compris du code malveillant injecté directement en mémoire.
Une variante de Wineloader
Bien que le Grapeloader soit au cœur de cette campagne, les chercheurs de Check Point ont également observé la présence d’une variante de Wineloader, un ancien outil utilisé par le groupe de cyberespionnage russe dans des attaques précédentes. Cette version, repérée sur VirusTotal, se présente sous la forme d’un fichier DLL appelé vmtools.dll, probablement chargé par un exécutable légitime lié à VMWare Tools. Le chargement latéral de DLL est une méthode efficace qui permet aux cybercriminels de contourner les systèmes de détection en exploitant des logiciels réputés sûrs pour exécuter leur code malveillant en mémoire.
Cette variante de WINELOADER rappelle une attaque similaire survenue en mars 2024, où « APT29 a également lancé la campagne avec un e-mail de phishing déguisé en invitation à un événement de dégustation de vin, cette fois-là usurpant l’identité d’un ambassadeur indien », ont déclaré les chercheurs.
APT29 déploie uneversion de WINELOADER via la DLL vmtools.dll pour contourner les détections. (Crédit photo: Check Point Research)
Des chercheurs ont découvert une technique où des attaquants peuvent utiliser et distribuer des paquets recommandés mais surtout inventés par des modèles IA.
La sécurité des modèles d’IA est devenue un sujet important. Plusieurs techniques existent pour faire plier les garde-fous et corrompre les résultats : empoisonnement de données, usage de langage méconnu, …. Une équipe de l’université du Texas à San Antonio, de Virginia Tech et de l’université d’Oklahoma vient d’en trouver une autre qui s’appuie sur la capacité des LLM à halluciner du code. Nommée slopsquatting, elle constitue une menace pour le cycle de…
Il vous reste 90% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Une gestion efficace des risques est une priorité absolue pour tout DSI. Le respect de quelques règles fondamentales permet de s’assurer que la stratégie IT s’aligne bien sur la tolérance aux risques de l’organisation.
Le risque est partout et protéiforme. Regardez autour de vous et vous verrez des obstacles technologiques, économiques et concurrentiels que les DSI doivent non seulement gérer, mais aussi dépasser. Selon une enquête mondiale de PwC, 75 % des responsables des risques affirment que les pressions financières limitent leur capacité à investir dans les technologies de pointe nécessaires à l’évaluation et au contrôle des risques. Pourtant, ne pas s’attaquer à ce sujet clef avec un programme efficace revient à courir à la catastrophe. Votre organisation fait-elle tout ce qui est en son pouvoir pour se protéger des menaces internes et externes ? Les sept règles de base suivantes peuvent vous aider à vous assurer d’être sur la bonne voie.Règle n° 1. Définissez le niveau de risque acceptableUne fois que le DSI a compris la propension au risque de son organisation, tout le reste – stratégie, innovation, sélection des technologies – peut s’aligner sans problème, explique Paola Saibene, consultante principale au sein de la société de conseil aux entreprises Resultant. Mais établir cette appétence au risque, c’est-à-dire le niveau de risque acceptable dans une situation spécifique, est un défi, car de nombreuses organisations comprennent intuitivement le sujet, sans le définir explicitement ou sans communiquer sur le sujet de manière structurée, note Paola Saibene.« En fait, les DSI confondent souvent la gestion des risques avec la conformité ou la cybersécurité, alors que le risque est une notion beaucoup plus large », dit-elle, conseillant aux responsables informatiques de désigner un responsable des risques au niveau de l’entreprise. Ce dernier peut alors devenir le meilleur allié du DSI, en l’aidant à naviguer dans les risques, à accélérer les initiatives stratégiques et à fournir des conseils sur les domaines où la prudence est nécessaire par rapport à ceux où la rapidité doit primer.La gestion des risques est l’un des aspects les plus mal compris et pourtant les plus précieux en matière de leadership, selon Paola Saibene. Lorsque les DSI adoptent des cadres formels de gestion des risques, ils peuvent identifier de manière proactive les risques liés aux technologies de l’information, proposer des stratégies d’atténuation et collaborer efficacement avec les responsables des risques. « Cela permet non seulement de renforcer l’adhésion de la direction, mais aussi d’accélérer les progrès », explique-t-elle.Règle 2. Inventoriez les applicationsLa plus importante règle de gestion des risques pour tout DSI consiste à maintenir un inventaire complet et constamment mis à jour de l’ensemble du portefeuille d’applications de l’organisation, afin d’identifier et d’atténuer de manière proactive les risques de sécurité avant qu’ils ne se matérialisent, conseille Howard Grimes, PDG du Cybersecurity Manufacturing Innovation Institute, un réseau d’instituts de recherche américains qui se concentrent sur le développement de technologies de fabrication par le biais de partenariats public-privé.PublicitéCela peut sembler simple, mais de nombreux DSI ne respectent pas cette discipline fondamentale, selon Howard Grimes. « Les risques apparaissent souvent lorsqu’une organisation néglige une gestion rigoureuse de son portefeuille d’applications, en particulier avec l’adoption rapide de nouveaux outils pilotés par l’IA qui, s’ils ne sont pas contrôlés, peuvent exposer par inadvertance la propriété intellectuelle de l’entreprise. »En l’absence d’un examen et d’une rationalisation structurés des applications, les organisations deviennent vulnérables aux inefficacités opérationnelles, aux manquements à la conformité et à l’augmentation exponentielle des risques cyber, prévient le dirigeant de l’institut. « Les DSI devraient adopter une approche proactive et préventive – gérer les applications d’entreprise de manière holistique pour prévenir les failles de sécurité avant qu’elles n’apparaissent », dit-il.Actuellement, une préoccupation majeure provient de l’adoption rapide d’outils alimentés par l’IA qui, tout en favorisant l’efficacité, présentent également des risques pour la propriété intellectuelle de l’entreprise, selon Howard Grimes. « Les organisations doivent déployer des mécanismes pour protéger leur propriété intellectuelle et empêcher les données sensibles d’être introduites dans les moteurs d’IA publics, dit-il. Dans de nombreux cas, les entreprises devraient opter pour des modèles d’IA fermés et propriétaires qui ne sont pas connectés à Internet, garantissant ainsi que les données critiques restent sécurisées au sein de l’entreprise. »Et d’ajouter : « les DSI doivent rationaliser chaque application, ressource et actif au sein de leur entreprise, en s’assurant que les outils redondants ou inutiles sont éliminés, que les failles de sécurité sont traitées de manière proactive et que les employés n’introduisent pas d’applications non autorisées dans l’écosystème. » L’extension de l’utilisation d’une application au-delà de son objectif initial doit également être évaluée avec soin, conseille-t-il, car elle peut entraîner de nouveaux risques de sécurité, qui ont échappé à l’analyse initiale. « En outre, sans une rationalisation fréquente et proactive du portefeuille, le ‘monstre applicatif’ peut conduire à des inefficacités, à un risque cybern accru et à des charges inutiles pour les équipes de support informatique », ajoute-t-il.Règle n° 3. Soyez proactifChaque DSI doit adopter une approche proactive de la cybersécurité, recommande Jonathan Selby, responsable de la pratique technologique au sein de la société de conseil en gestion des risques Founder Shield. Il suggère de créer une culture de la sécurité par la formation des employés, la mise à jour des systèmes et la mise en oeuvre de mesures de sécurité complètes, y compris un plan de réponse à incident.Selon lui, la cybersécurité est désormais une guerre qui se mène sur plusieurs fronts. « Nous n’avons plus le luxe d’anticiper les attaques qui nous atteignent de plein fouet », dit-il. Les dirigeants doivent reconnaître l’interdépendance entre les différents volets d’un plan de gestion des risques. « Ce n’est pas seulement la politique cyber qui fait le gros du travail, ni même une formation poussée des employés qui constituent votre armure, c’est un tout. » La première façon de minimiser les risques est de commencer par le haut, conseille Jonathan Selby.Règle 4. Formalisez la gestion des risques à l’échelle de l’entrepriseLes DSI et leurs services gèrent déjà les risques au quotidien, alors pourquoi ne pas formaliser ce processus et l’intégrer au reste de l’entreprise, souligne Will Klotz, consultant en sécurité chez GuidePoint Security, une société de services spécialisée sur ces sujets. « Il est préférable d’intégrer délibérément le management des risques dans la gestion, les décisions et les opérations quotidiennes », suggère-t-il.En exprimant les risques en termes compréhensibles par l’ensemble de l’entreprise, vous pouvez assurer une priorisation correcte des projets et des discussions plus significatives avec les parties prenantes moins techniques, tout en renforçant la confiance dans l’ensemble de l’organisation, explique Will Klotz.Règle n° 5. Restez réalisteDe nombreuses organisations ont des stratégies de management des risques irréalistes qui ne tiennent pas compte des risques réels ou de la façon ils se matérialisent, explique Brian Soby, directeur technique et cofondateur du fournisseur de services de sécurité SaaS AppOmni. Celui-ci recommande de tester le programme actuel de gestion des risques de l’entreprise par rapport à des incidents réels. « Tous les mois, voire toutes les semaines, nous entendons parler de brèches de sécurité dans la presse, observe-t-il. Pour chacun de ces incidents, prenez les circonstances de la violation ou de l’attaque et appliquez-les à votre entreprise, conseille Brian Soby. « Et demandez-vous si votre entreprise aurait fait les gros titres », dit-il.Le CTO estime qu’il existe un décalage flagrant entre les types de menaces et de risques que les entreprises pensent devoir atténuer et les risques auxquels elles sont réellement confrontées. « Les entreprises doivent évaluer leurs programmes de gestion des risques par rapport à la réalité, et le moyen le plus simple d’y parvenir est de comparer ce programme à des incidents réels pour évaluer quel aurait été le résultat », souligne Brian Soby. Et de conseiller un examen des approches adoptées par d’autres entreprises pour atténuer les risques en recourant à des formations et à des contrôles techniques.Règle 6. Recherchez la résilienceSelon Greg Sullivan, associé fondateur de CIOSO Global, société spécialisée dans la cybersécurité et la gestion des risques, et ancien DSI de Carnival Corp, l’entreprise doit se concentrer sur la résilience et la mise en place de systèmes capables de se remettre rapidement d’une perturbation. « Les systèmes résilients s’attaquent simultanément à de multiples vecteurs de menace tout en s’alignant sur les priorités de l’entreprise, résume-t-il. Cette approche crée également un cadre formel avec des mesures de RTO (objectif de temps de récupération) et de RPO (objectif de point de récupération). »Selon Greg Sullivan, les DSI commettent souvent l’erreur de surinvestir dans des mesures défensives et préventives tout en négligeant la résilience et les capacités de récupération. « Cela crée un déséquilibre et un faux sentiment de sécurité, prévient-il. Il est primordial que toutes les parties prenantes participent aux efforts de récupération et suivent des procédures de reprise bien rodées et bien communiquées. »Chaque entreprise a besoin d’un plan actualisé de reprise après sinistre et de continuité des activités, selon lui. « Ces plans permettent de renforcer la résilience tout en se concentrant sur la restauration des systèmes et sur une stratégie opérationnelle visant à maintenir les fonctions critiques de l’entreprise, explique Greg Sullivan. Plus important encore, ce plan doit être testé et mis à jour régulièrement. »Règle n° 7. Alignez risques IT et objectifs de l’entrepriseL’informatique n’existe jamais de manière isolée – elle doit soutenir directement les objectifs de l’entreprise tout en la protégeant contre les menaces technologiques pertinentes, souligne John Bruce, RSSI de la société de cybersécurité Quorum Cyber. Un alignement solide entre l’IT et les métiers garantit que les investissements informatiques apporteront une valeur ajoutée à l’entreprise plutôt que de simples capacités techniques. « Lorsque les objectifs informatiques et métiers sont synchronisés, les organisations prennent des décisions plus judicieuses en matière de risques, allouent les ressources de manière plus efficace et obtiennent l’adhésion de la direction », explique John Bruce.Le RSSI recommande d’établir une structure formelle de gouvernance des risques, sous le parrainage de la direction. « En développant des registres de risques qui relient les risques technologiques aux impacts métiers, et en utilisant des KPI axés sur l’activité que les dirigeants peuvent comprendre, le DSI peut mettre en place un comité cross-fonctionnel des risques avec les différentes parties prenantes de l’organisation afin de mener des analyses régulières », explique John Bruce.
Le référentiel des vulnérabilités en cybersécurité prend fin aujourd’hui après le non-renouvellement du contrat de financement par le département américain de la sécurité intérieure. Cet arrêt plonge le suivi des failles dans l’incertitude.
Mauvaise nouvelle pour le monde de la cybersécurité avec l’annonce de l’arrêt du programme CVE (common vulnerabilities and exposures) de MITRE qui existe depuis 25 ans. La raison ? Le DHS (department of homeland security) n’a pas reconduit le contrat de financement du programme mené par l’association américaine à but non lucratif. Yosry Barsoum, vice-président et directeur du Center for Securing the Homeland de MITRE, a écrit dans un courrier adressé au conseil d’administration de CVE : « le mercredi 16…
Il vous reste 94% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?
Les membres du CA/Browser Forum ont voté en faveur d’une réduction de la durée de vie des certificats pour les sites web. Elle passerait ainsi d’un an à 47 jours d’ici 2029. L’association justifie cette décision par le renforcement de la sécurité.
Un simple vote, mais avec des grandes conséquences. En effet, le Certification Authority Browser Forum (CA/Browser) regroupant les émetteurs de certificats et les éditeurs d’applications ont voté en fin de semaine dernière la baisse radicale de la durée de vie des certificats vérifiant la propriété des sites. Les modifications approuvées à une écrasante majorité seront introduites progressivement jusqu’en mars 2029, date à laquelle les certificats ne dureront plus que 47 jours.
Les…
Il vous reste 93% de l’article à lireVous devez posséder un compte pour poursuivre la lecture
Vous avez déjà un compte?