CICD-SEC-10 : journalisation et visibilité insuffisantes

Dixième et dernière entrée du Top 10 OWASP CI/CD. Libellé officiel : Insufficient Logging and Visibility. Elle ne décrit pas un chemin d’attaque mais ce qui permet aux autres de réussir sans bruit : l’incapacité à détecter une activité hostile à n’importe quelle phase de la chaîne d’attaque, et à identifier après coup les techniques employées.

→ Lire l’explication complète de la marmotte

Le mécanisme : un programme de journalisation qui s’arrête à la porte de l’ingénierie

Le constat du référentiel est d’organisation, pas de technique. Les postes de travail, les serveurs, les équipements réseau et les applications métier importantes sont généralement couverts en profondeur par les programmes de journalisation ; les systèmes et processus des environnements d’ingénierie ne le sont généralement pas, ayant longtemps passé pour de l’outillage interne dont les incidents relevaient de la gêne plutôt que du risque.

Deux distinctions du document font tout le travail.

La première est celle de l’accès humain et de l’accès programmatique. De nombreux vecteurs de cette liste reposant sur le second, un aspect clé consiste à construire une forte visibilité sur les deux. Or les programmes de journalisation sont conçus pour des personnes : connexions, sessions, changements de droits. Un jeton employé par un script ne produit presque rien de comparable, et c’est pourtant par là que passe l’essentiel de l’activité, légitime comme hostile. Prolongement direct de CICD-SEC-2 et de la gouvernance des comptes de service.

La seconde est celle des journaux d’audit et des journaux applicatifs, auxquels le référentiel accorde une importance égale, formule à prendre au sérieux parce que rarement suivie. Les journaux d’audit enregistrent l’accès d’un utilisateur, sa création, la modification d’une permission : ceux-là, on les active, parce qu’ils ressemblent à ceux des autres systèmes. Les journaux applicatifs enregistrent un envoi de code vers un dépôt, l’exécution d’une construction, le téléversement d’un artefact : ceux-là sont les seuls utiles, une attaque de chaîne de livraison étant faite d’actions applicatives parfaitement autorisées.

Cette seconde distinction explique pourquoi les neuf entrées précédentes aboutissent à la même phrase : « le journal montre une construction réussie ». Rien n’y est faux ; il enregistre un autre niveau de réalité que celui de l’attaque. Voir l’éditorial sur le journal que personne ne lit et, pour le cas où l’on découvre le défaut au pire moment, les fuites constatées dans un journal d’accès après coup.

Ce que l’attaquant obtient

Du temps, et l’impunité technique. Le référentiel formule l’enjeu d’une façon qui mérite d’être citée : le temps et les données sont les biens les plus précieux d’une organisation attaquée, et la présence de toutes les sources au même endroit peut faire la différence entre un dénouement maîtrisé et un dénouement dévastateur.

En pratique, trois avantages. Il n’est pas détecté pendant l’opération, ses actions étant autorisées. Il n’est pas reconstitué après coup, faute des journaux qui diraient dans quel ordre les choses se sont produites : la reconstruction de la chronologie d’une attaque. Et il ne laisse pas de techniques identifiables, de sorte qu’on n’en tire pas les indicateurs qui permettraient de détecter la fois suivante.

S’y ajoute un quatrième avantage absent du référentiel et qui découle de CICD-SEC-5 : un pipeline compromis a souvent le droit d’écrire dans ses propres journaux, donc de les noyer. C’est la dégradation des défenses sur une machine de construction, et la raison pour laquelle les journaux doivent quitter le système qui les produit : la journalisation d’audit immuable.

Ce qu’on peut détecter, et par quoi

L’entrée portant sur la capacité de détection elle-même, ce qui se détecte, ce sont les manques.

Les systèmes dont aucun journal n’arrive. Comparer l’inventaire des systèmes de la chaîne à la liste des sources reçues par le collecteur est le contrôle le plus rentable de l’entrée, et il tient dans un tableur ; les absents sont toujours les instances auto-gérées installées par une équipe pour son usage.

Les sources présentes mais incomplètes : un système qui envoie ses journaux d’audit sans les applicatifs donne l’illusion de la couverture, et chercher l’événement « un artefact a été téléversé » suffit à le savoir. Et les accès programmatiques nouveaux, jeton qui apparaît ou application qui se met à écrire : rares et nominatifs, donc supportables en volume, argument décisif face à la fatigue d’alerte.

Les écarts entre deux systèmes sur un même événement. Une construction qui apparaît dans l’outil d’intégration sans demande de fusion correspondante côté code source est l’anomalie que seule la corrélation révèle : la détection la plus utile des dix risques, et elle exige exactement ce que l’entrée demande, les journaux de plusieurs systèmes au même endroit.

Ce que le défenseur fait

Le référentiel propose quatre étapes, et l’ordre compte.

Cartographier l’environnement. Pas de visibilité sans connaissance intime des systèmes concernés, donc un inventaire de tous ceux en usage, y compris chaque instance des systèmes auto-gérés : la précision désigne l’outil d’intégration installé trois fois par trois équipes. Le périmètre est large : code source, intégration continue, dépôts d’artefacts, gestionnaires de paquets, registres de conteneurs, déploiement continu, orchestration.

Identifier et activer les bonnes sources de journaux, car ce n’est pas l’état par défaut. La visibilité porte sur l’accès humain comme sur l’accès programmatique dans toutes ses formes, avec autant d’insistance sur les journaux d’audit que sur les applicatifs.

Expédier les journaux vers un emplacement centralisé, pour l’agrégation et la corrélation entre systèmes : la théorie de la détection et le SIEM pour le raisonnement, le vrai coût d’un SIEM open source pour la facture, la détection minimale en outils libres pour le chemin court.

Créer des alertes sur les anomalies, dans chaque système pris isolément et sur le processus de livraison du code, qui implique plusieurs systèmes et exige une connaissance plus profonde des processus internes de construction et de déploiement. C’est la demande la plus exigeante du document : il faut que quelqu’un sache à quoi ressemble une livraison normale, ce qui n’est ni une compétence de sécurité ni une compétence de développement, mais le point de rencontre des deux.

Reste la condition de valeur : des journaux exploitables le jour J, donc une chaîne de conservation tenable, et une équipe pour les lire, ce que décrivent le centre d’opérations de sécurité et les premières minutes d’un incident.

Sources

CICD-SEC-10: Insufficient Logging and Visibility, OWASP Top 10 CI/CD Security Risks, 2022 : définition, distinction entre journaux d’audit et applicatifs, quatre étapes. Le document ne cite aucun incident propre à cette entrée : la visibilité est requise pour enquêter sur n’importe lequel des neuf autres.

🐝 Ce qui arrive si on s’en passe

Aucune étape d’une attaque de chaîne de livraison ne laisse de trace distinguable d’une livraison ordinaire, et « quand cet artefact est-il entré » reste sans réponse. Suit le coût réel : l’incident n’est pas bornable, donc pas clos. Faute de journaux applicatifs, on ne sait pas quelles constructions ont tourné avec le code modifié, donc quels artefacts sont suspects, donc quoi reconstruire, et il ne reste que deux mauvaises options, tout reconstruire en arrêtant la production, ou reconstruire ce qu’on soupçonne en laissant le reste. Enfin, comme le cycle complet de réponse à incident suppose un retour d’expérience, celui-ci se tient sans matière : aucune leçon technique ne se tire d’un incident qu’on n’a pas pu reconstituer, ce qui garantit que le suivant se déroulera de même.

🦫 Explication de la marmotte 🍫

Toute organisation un peu sérieuse conserve des traces de ce qui se passe sur ses ordinateurs : qui s’est connecté, quand, depuis où. Elles servent à repérer une anomalie et, après un incident, à reconstituer les faits. Or cet effort s’arrête à la porte des équipes de développement : les machines qui fabriquent et installent les logiciels, et qui détiennent le code comme les mots de passe des serveurs, sont très mal couvertes.

Deux subtilités expliquent pourquoi le peu qui existe ne sert pas à grand-chose. La première est que ces traces sont faites pour des personnes, alors que dans une chaîne de fabrication presque tout est fait par des programmes qui s’identifient avec un jeton, et dont les actions ne laissent rien d’équivalent. La seconde est plus importante : il y a deux sortes de traces, celles des comptes et des droits, et celles du travail, à savoir « du code a été envoyé », « une fabrication a eu lieu », « un paquet a été déposé ». Les premières sont presque toujours activées, parce qu’elles ressemblent à ce qu’on fait ailleurs ; les secondes, seules utiles ici, le sont rarement. Et comme l’attaque consiste à faire faire à la machine ce qu’elle a le droit de faire, c’est uniquement dans ces traces de travail qu’elle apparaît. Le compte rendu dit donc qu’une fabrication a réussi, ce qui est vrai, et ne dit pas qu’elle a fabriqué autre chose que prévu.

Les auteurs demandent quatre choses, dans l’ordre : savoir quelles machines existent, y compris celles qu’une équipe a installées pour son usage ; activer les bonnes traces, inactives par défaut ; les envoyer toutes au même endroit pour pouvoir les rapprocher ; et écrire des alertes, non seulement sur chaque machine mais sur le cheminement complet d’une livraison. Cette dernière est la plus difficile : elle suppose de savoir à quoi ressemble une livraison normale, connaissance qui n’appartient ni tout à fait à la sécurité, ni tout à fait au développement.

Pages voisines

La citent

CICD-SEC-10 : journalisation et visibilité insuffisantes

Elle cite

: les deux pages se citent l’une l’autre.

CICD-SEC-10 : journalisation et visibilité insuffisantes

CICD-SEC-10 : journalisation et visibilité insuffisantes

Le mécanisme : un programme de journalisation qui s’arrête à la porte de l’ingénierie

Ce que l’attaquant obtient

Ce qu’on peut détecter, et par quoi

Ce que le défenseur fait

Sources

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines