Introduction
Unanimement reconnu au sein de la communauté cyber, le CIS[1] publie entre autres des référentiels de sécurisation, appelés « benchmark »[2], décrivant chacun un ensemble d’exigences de sécurisation par contexte technologique (ex : Windows 11, Apache Tomcat, F5, Ubuntu Linux, etc.).
Un audit de conformité CIS consiste donc à évaluer si la configuration sécurité du périmètre audité correspond, ou non, aux exigences de sécurité décrites par le CIS dans ses référentiels.
Préambule : prise de recul sur la conformité et le référentiel
Tout d’abord, il convient de garder en tête qu’une configuration de sécurité est généralement liée au contexte technique, applicatif, voire même règlementaire, de l’écosystème qui l’entoure.
Par exemple, si aujourd’hui, la plupart des référentiels de sécurisation (dont le CIS) recommandent de désactiver la version 1 du protocole SMB, réputée vulnérable, il peut y avoir des applications héritées qui imposent une version obsolète de Windows pour fonctionner, et que ce protocole soit laissé actif. Cela suppose alors des mesures de sécurisation permettant de réduire les risques inhérents à l’exploitation réussie des vulnérabilités de cette version de SMB. Par conséquent, une « non-conformité CIS » pour SMB version 1, pourrait être explicable, et même associée à un risque considéré maîtrisé ; et au final, cette non-conformité ne devrait plus être considérée comme problématique.
Ensuite, il semble important de tenir compte du fait que le niveau 2 des exigences CIS est documenté comme étant adapté à des environnements sous forte contrainte de sécurisation, et qui sa mise en œuvre a des impacts clairs sur les usages courants (type bureautique). Voici une citation du référentiel CIS « Microsoft Windows 11 Enterprise », à ce sujet :
La recommandation est donc de se focaliser en premier lieu sur le niveau 1 des « benchmarks » du CIS. Ensuite, si ce dernier est quasiment entièrement respecté, alors une conformité au niveau 2 peut être envisagée.
Exploitation du référentiel CIS : incomplétude
Ensuite, comme tout référentiel, un « benchmark » du CIS peut être perfectible. C’est notamment le cas pour celui « Microsoft Intune for Microsoft Windows »[3], v3.0.1 en date de rédaction de cet article, et nous allons en donner quelques exemples concrets.
Cependant, au-delà du fait qu’un référentiel soit complet en lui-même ou non, il demeure une problématique liée au passage de l’exigence exprimée en langue de Shakespeare, vers un réglage technique concret, qui soit auditable (de préférence par un outillage adapté). Et c’est peut-être là que se cache la plus grande problématique, comme nous allons en parler plus loin.
Outillage : le 100% n’existe pas
Qu’il soit communautaire ou propriétaire, le 100% n’existe pas en ce qui concerne l’outillage technique. C’est donc une difficulté supplémentaire à prendre en compte, qui peut très concrètement soit donner des résultats de conformité erronés, soit ne pas donner de résultat du tout (et donc, des éléments techniques à aller chercher à la main par l’auditeur…!).
En outre, comme les référentiels tels que les « benchmarks » sont mis à jour régulièrement. Cela suppose donc que les outils qui implémentent les exigences décrites dans ces référentiels, aussi. Or, il n’est pas toujours simple de s’assurer que l’outillage utilisé pour réaliser un audit de conformité implémente bien la dernière version de chacune des plus de 360 exigences de sécurité (si l’on prend l’exemple du référentiel CIS « Microsoft Windows 11 Enterprise »[4]).
A ce sujet, le monde du logiciel communautaire apporte aussi ses propres problématiques. D’aucuns se souviendront de questions posées sur des forums de sites de logiciels libres, et qui ont attendu des jours voire semaines, avant d’avoir une réponse (et une solution ?) ; d’ailleurs cela se transpose assez bien de nos jours sur des dépôts GitHub de solutions communautaires.
Lien entre insuffisance de documentation éditeur, et trous dans la raquette du référentiel de sécurisation
Pour le cas de Microsoft Intune, l’éditeur Microsoft évoque sur son site que les exigences CIS sont implémentées dans ses consoles. Cependant, en lisant bien[5], il est possible de tomber sur la mention suivante :
Cela signifie que Microsoft considère que le « benchmark » CIS de sécurisation ne prend en compte que des configurations « en mode GPO », et donc pas celles avec Intune !
Par ailleurs, au-delà du discours éditeur Microsoft, cette situation se confirme dans le référentiel du CIS « Microsoft Intune for Microsoft Windows »[6].
En effet, pour certaines exigences dudit référentiel, le paramétrage technique Intune CSP à aller concrètement vérifier sur un poste Windows 11 audité, est pleinement expliqué. Exemple :
Cependant, pour d’autres, ce n’est pas le cas du tout, et l’on peut typiquement retomber sur un paramétrage « à la GPO » :
Cela voudrait donc dire, que selon les cas, l’audit de conformité CIS d’un Windows 11 géré par Intune est censé s’appuyer sur des paramétrages GPO à vérifier, alors que pour d’autres exigences du même référentiel, ce serait des clefs de registre spécifiques à Intune CSP[7] ?
Une telle méthodologie peut sembler incohérente, et pourtant… Telle est la réalité de notre RETEX sur le sujet.
Pire, certaines exigences du CIS ne sont purement et simplement pas présentes dans le référentiel CIS pour Windows 11 géré par Intune (« Microsoft Intune for Microsoft Windows »), alors qu’elles le sont dans le référentiel CIS pour Windows 11 Enterprise (« Microsoft Windows 11 Enterprise »)…
Exemple : pour l’exigence « (L1) Ensure ‘Select when Preview Builds and Feature Updates are received’ is set to ‘Enabled: 180 or more days’», dans le référentiel CIS « Microsoft Intune for Microsoft Windows », on peut lire :
Conclusion : avis de l’équipe d’audit Metsys concernant un audit de « conformité CIS » sur du Windows 11 géré par Intune
Bien qu’un auditeur technique soit censé être dans une démarche très rigoureuse, il apparaît qu’il faille faire preuve ici d’une certaine forme de souplesse intellectuelle afin de mener à bien de tels audits de conformité CIS.
En effet :
- certaines exigences de sécurité listées par le CIS ne sont pas documentées suffisamment dans le référentiel « Microsoft Intune for Microsoft Windows » pour être auditables (ie. le point de contrôle technique n’est pas documenté) ;
- une solution pourrait être alors d’aller chercher les informations manquantes dans le référentiel pour Windows 11 : « Microsoft Windows 11 Enterprise » ;
- mais cela peut susciter des objections pour quiconque ayant une démarche d’audit très rigoriste ;
- certaines exigences de sécurisation listées par le CIS, bien que documentées sous l’angle de la configuration Intune CSP, sont en fait trop peu décrites pour être auditables ;
- la solution est donc vraisemblablement de monter une maquette de reproduction du l’environnement audité, et pour chaque élément de configuration Intune CSP, identifier la ou les clefs de registre qui sont concrètement modifiées quand le réglage est appliqué, afin de pouvoir confirmer que c’est le cas, ou non, sur le poste audité ;
- là, encore, le fait que l’auditeur définisse lui-même le point de contrôle technique à auditer pour évaluer la conformité, peut susciter des objections en termes de rigueur de méthodologie d’audit.
Il apparaît donc nécessaire de définir très précisément le cadre technique de l’audit de conformité CIS, et de prendre en compte les limites du référentiel CIS lui-même afin d’acter de la façon de prendre en compte ces limitations, dans une méthodologie d’audit acceptée par l’entité bénéficiaire.
Les équipes de Metsys sont à votre disposition si vous souhaitez poursuivre plus loin la réflexion, et auditer votre environnement (y compris réaliser des tests d’intrusion).
[1] Cf. https://www.cisecurity.org/
[2] Cf. https://www.cisecurity.org/cis-benchmarks
[3] Cf. https://www.cisecurity.org/benchmark/intune
[4] Cf. https://www.cisecurity.org/benchmark/microsoft_windows_desktop
[5] Cf. https://learn.microsoft.com/en-us/defender-vulnerability-management/tvm-security-baselines
[6] Cf. https://www.cisecurity.org/benchmark/intune
[7] Cf. https://learn.microsoft.com/fr-fr/windows/client-management/mdm/policy-configuration-service-provider