L’édito de Digitemis, par Ludovic de Carcouët (avril 2022)

Cybersécurité : où est notre responsabilité ?

Dès les années 1970, les entreprises ont engagé un vaste mouvement de développement de leurs écosystèmes. Cela s’est traduit par l’externalisation de leurs coûts, l’amélioration de leurs performances et l’internalisation de leurs bénéfices. Les organisations se sont progressivement recentrées sur leurs cœurs de métiers. Aujourd’hui, du fait de l’augmentation exponentielle du nombre de prestataires, de fournisseurs ou de partenaires, ces organisations sont amenées à redéfinir perpétuellement leurs frontières. 

Le paroxysme de ce phénomène a été atteint avec la numérisation de l’économie : multiplication des partages et des accès distants, nombre pléthorique de fournisseurs, apparition de clouds tentaculaires et insondables. Cartographier les actifs et déterminer les responsabilités de chacun sont désormais des tâches particulièrement ardues. Les raisons de cette dilution des responsabilités sont multiples : méconnaissance des risques, complexité des technologies, contrats génériques non pertinents destinés à encadrer des situations singulières, obsolescence des réglementations à contre-courant de l’agilité des entreprises ou encore primauté du business et de la prise de risques. Même les compagnies d’assurances peinent à quantifier le risque cyber et à éclaircir la chaîne de responsabilités. Nous assistons à un jeu de dupes.

Il est primordial de réussir à créer et à pérenniser des écosystèmes de confiance

Dans cette civilisation de l’entreprise sans frontière, les responsabilités se trouvent donc diluées entre les acteurs de l’écosystème. L’application des principes est souvent floue : les métiers, les prestataires, les décideurs connaissent-ils précisément leurs responsabilités ? Les contrats reflètent-ils la réalité des rôles et des responsabilités ? Qui assume la responsabilité : celui qui externalise, celui qui met en œuvre, celui qui exploite, celui qui héberge ou celui qui surveille ? Deux postures sont possibles : assumer ses responsabilités par la maîtrise de toutes les frontières (ligne Maginot) ou bien coopérer avec des tiers de confiance (certifiés, agréés, qualifiés, audités, …).

Cela ne nous dispense pas d’un devoir collectif de vigilance ni d’intégrer le doute – cette vertu cartésienne – au cœur de notre démarche. Il est primordial de réussir à créer et à pérenniser des écosystèmes de confiance car un allié aujourd’hui est susceptible de se muer en vecteur de fragilités demain. Nous devons choisir de manière éclairée nos prestataires, les données à externaliser et les mesures de sécurité nécessaires. Notre vraie responsabilité consiste finalement à orchestrer la partition de chaque acteur de l’écosystème afin d’éviter toute fausse note. Mais pour cela, nous devons accepter de prendre le temps de la réflexion, d’intégrer la cybersécurité dans les décisions et de diffuser les bonnes pratiques à tous les niveaux de l’entreprise. C’est, il me semble, l’attitude à adopter face à des écosystèmes toujours plus à risques, toujours plus étendus, toujours plus complexes. 

Je partage

Derniers articles

Illustration de sécurité WordPress avec logo central et éléments numériques de sécurité

Renforcer la sécurité WordPress, du développement des plugins à la configuration serveur

Il y a peu, dans le cadre de recherches sur des plugins WordPress, notre pentester Vincent Fourcade a découvert une injection de code, côté client, dans un module du célèbre CMS. Celle-ci fut vérifiée et validée par les équipes de WPScan. Aujourd’hui, une CVE lui a été attribuée. L’occasion de revenir aujourd’hui sur la sécurité, au sens large, dans le CMS WordPress, que ce soit au niveau de la couche applicative, de la configuration du serveur ou du bureau. C’est parti !

Lire l'article

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article