Comme moi vous l’avez surement déjà remarqué, les audits de conformité IT ne demandent plus seulement de montrer une politique de sécurité, ils demandent également de prouver qu’elle s’applique sur les serveurs, les postes et les environnements hybrides. Dans cet écart entre règle écrite et configuration réelle, l’automatisation, gros enjeu des systèmes d’information, a sa (grande) part d’importance.
L’audit face au réel
Un audit de sécurité commence très rarement par une grosse surprise, la plupart des organisations disposant déjà de politiques, de procédures et parfois même d’un SMSI (système de management de la sécurité de l’information) très structuré.
Généralement, la difficulté apparaît plutôt au moment où l’auditeur demande à voir l’état réel du terrain…
Et c’est là que la conformité IT se durcit. En effet, les référentiels ne s’intéressent plus seulement à l’existence d’un cadre, mais à sa mise en œuvre, à son suivi et à sa capacité à progresser.
ISO/IEC 27001:2022 définit ainsi les exigences permettant d’établir, mettre en œuvre, maintenir et améliorer en continu un SMSI. La logique est finalement celle d’un dispositif « vivant ».
Pour nous DSI ou RSSI, le centre de gravité est déplacé en quelque sorte. La conformité devient une capacité permanente à démontrer que le SI reste aligné avec les règles annoncées.
L’écart des configurations
Les problèmes tiennent souvent dans un décalage banal, presque invisible, qui ne relève pas forcément d’un manque de rigueur. Ils sont le produit normal de ce fameux SI vivant. À chaque opération, une configuration peut dériver, et à chaque dérive, la conformité s’éloigne de ce qui avait été décidé initialement…
C’est ici que l’automatisation des infrastructures IT apporte énormément, en permettant de passer d’un contrôle périodique à une vérification régulière de l’état attendu, avec des règles qui deviennent des états de configuration que l’on peut appliquer, contrôler et corriger.
Une bascule qui est d’ailleurs particulièrement utile dans les environnements distribués. Une organisation peut difficilement vérifier manuellement, avec la même précision, des centaines de postes, de serveurs Linux et Windows, de machines virtuelles ou de ressources cloud. Ici l’automatisation rend l’expertise moins dépendante de la mémoire, de la disponibilité et de la répétition humaine.
La fin du grand ménage
Beaucoup d’entre vous connaissent certainement ce moment inconfortable où l’audit approchant, les contrôles internes s’accélèrent, les fichiers de preuves se remplissent dans l’urgence, les configurations sont vérifiées à la main et les non-conformités évidentes sont corrigées avant le passage de l’auditeur.
Certes, ce « grand ménage », à la manière d’un restaurateur pris de panique avant l’arrivée des équipes de Philippe Etchebest, peut permettre de limiter les dégâts…
… mais il ne prouve pas que la sécurité fonctionne dans la durée.
Alors que c’est justement le but recherché.
L’automatisation de la sécurité répond précisément à cette faiblesse. Une plateforme spécialisée peut vérifier régulièrement :
- les paramètres de sécurité,
- l’état des mises à jour,
- les règles de durcissement,
- les écarts de configuration,
- la conformité aux politiques internes, etc.
On « non-événementialise » le contrôle finalement.
Rudder se positionne sur ce terrain, avec une plateforme d’automatisation des infrastructures IT conçue pour piloter configurations, patchs et conformité sur des environnements Linux et Windows, cloud ou on premise. L’éditeur met en avant une approche de visibilité et de contrôle en temps réel, ainsi qu’une capacité à appliquer et auditer des politiques internes ou des référentiels comme CIS, NIST ou ISO 27001.
Cette logique change la préparation d’un audit, en permettant aux équipes de s’appuyer sur des contrôles déjà exécutés, des écarts déjà identifiés et des remédiations tracées. Ainsi, l’audit devient moins une course à la preuve qu’un exercice de vérification.
Des preuves qui tiennent
Selon moi, la conformité se joue de plus en plus dans la qualité des preuves. J’ai rarement vu un auditeur se contenter d’une déclaration ou d’une capture ponctuelle (« tout va bien », source : « t’inquiètes »). Il va généralement préférer demander un historique, une trace horodatée ou une preuve d’application d’un correctif, un journal permettant de comprendre qui a fait quoi et quand.
D’ailleurs, l’ANSSI place cette culture de la preuve au cœur de plusieurs règles de sécurité applicables aux systèmes d’information d’importance vitale. Elle mentionne notamment l’homologation incluant un audit réalisé selon ses critères, le maintien en conditions de sécurité, avec suivi des correctifs et gestion des mises à jour, ainsi que la journalisation, destinée à détecter les incidents, réaliser des investigations a posteriori et rechercher des compromissions.
Ces exigences concernent des périmètres spécifiques, mais leur logique irrigue largement les bonnes pratiques de sécurité. Une preuve n’a de valeur que si elle est fiable, compréhensible et exploitable. Aussi, un rapport généré automatiquement, fondé sur l’état réel des machines et enrichi par l’historique des corrections, pèse davantage qu’un tableur mis à jour à l’arrache
Dans cette perspective, l’automatisation aide aussi les équipes sécurité à dialoguer avec les autres parties prenantes. Les comités de sécurité, les auditeurs, les responsables conformité ou les directions métiers ont très rarement besoin du détail technique complet. En revanche, ils veulent des indicateurs lisibles :
- taux de conformité,
- nombre d’écarts critiques,
- délais de correction,
- actifs non couverts,
- systèmes en retard de patch,
- exceptions justifiées, etc.
Corriger pour se protéger
Entendons-nous bien, passer un audit n’est jamais une fin en soi. Vous pouvez parfaitement obtenir une conformité satisfaisante à un instant donné tout en restant exposé si les corrections tardent, si les écarts reviennent ou si les vulnérabilités restent ouvertes.
L’intérêt profond de l’automatisation réside donc dans la remédiation.
Sur ce point, le patch management illustre bien le changement d’échelle, avec pour objectif de réduire la zone grise entre la détection d’un défaut et sa correction effective.
La même logique vaut pour les règles de durcissement. Lorsqu’une configuration dévie, l’enjeu n’est pas seulement de la signaler, il faut savoir si elle expose un actif critique, si elle contrevient à une politique interne, si elle bloque une exigence d’audit, puis décider s’il faut corriger automatiquement, ouvrir une demande de changement ou documenter une exception.
C’est dans ce subtil dosage que l’automatisation prend toute sa valeur :
- Trop rigide, elle peut casser un service.
- Trop prudente, elle laisse les écarts s’accumuler.
- Bien gouvernée, elle accélère la remise en conformité sans enlever aux équipes leur capacité d’arbitrage.
Une conformité opérée
Alors oui, les règles écrites restent indispensables, mais elles ne suffisent plus du tout à rassurer un auditeur, un client, une direction générale ou un assureur cyber.
Ce qui compte désormais, c’est la capacité à démontrer que les règles sont appliquées, surveillées, corrigées et améliorées.
Et grâce à l’automatisation, vous pouvez relier la politique à la configuration, le contrôle à la preuve et l’écart à la remédiation, et ainsi passer à une conformité opérée, fondée sur ce qu’elle peut constater et documenter.
Bien sûr, loin de moi l’idée que cette évolution rendrait les audits plus faciles. Mais elle a le mérite de les rendre moins artificiels.