0 Fork 0

Files

T

PierreCsn f859ff536c docs: use relative package paths

2026-10-28 16:27:12 +01:00

14 KiB

Raw Blame History

comi-audit-hardeningkitty

Paquet source WAPT d’audit en lecture seule des paramètres de sécurité Windows avec HardeningKitty. Le nom du paquet WAPT reste comi-audit-hardeningkitty (voir WAPT/control) ; comi-audit-secu est le nom du dépôt.

Le paquet lance le mode Invoke-HardeningKitty -Mode Audit, compare le rapport CSV avec la liste de contrôles sélectionnée, conserve des rapports locaux et publie un résumé ainsi que les écarts dans les données d’audit WAPT Enterprise. Il ne lance ni le mode HailMary, ni un mode GPO ou Config, et ne télécharge aucun code sur les postes. Les scripts et listes nécessaires sont préparés et intégrés au paquet signé avant l’installation.

Compatibilité et sélection du benchmark

WAPT/control exige WAPT 2.4 ou ultérieur. Le code Python évite les syntaxes postérieures à Python 3.8; les tests locaux ont été exécutés avec Python 3.9. La compatibilité réelle doit être confirmée avec l’agent et la console WAPT de l’environnement cible.

Avec profile: auto, le runner choisit une liste machine disponible dans la révision HardeningKitty épinglée :

Système	Benchmark sélectionné
Windows 10 20H2/21H1, 21H2 ou 22H2	Microsoft Security Baseline machine correspondante
Windows 11 21H2 à 25H2	Microsoft Security Baseline machine correspondante
Windows Server 2012 R2, 2016 ou 2019	CIS machine, version référencée dans le nom du fichier
Windows Server 2022	Microsoft Security Baseline machine 21H2, contrôleur de domaine ou membre
Windows Server 2025	Microsoft Security Baseline machine 24H2, contrôleur de domaine ou membre

Windows 11 26H2 et toute combinaison OS/build/rôle non reconnue échouent explicitement : aucun benchmark voisin n’est choisi automatiquement. La liste communautaire finding_list_0x6d69636b_machine.csv est disponible avec profile: community. Une liste précise peut être sélectionnée en indiquant son nom de fichier finding_list_*_machine.csv. Les listes *_user.csv sont refusées : un audit lancé par WAPT sous SYSTEM ne représente pas la session interactive d’un utilisateur.

Les fichiers de benchmark sont épinglés avec HardeningKitty au commit acf9ecee3d044a9337df7aad80e730cbd746e8de. tools/vendor_assets.py exige les listes utilisées par le runner. Si une liste manque dans l’archive de cette révision, la préparation échoue au lieu d’annoncer une prise en charge fictive.

Préparer les sources

Cloner le dépôt dans le répertoire de développement WAPT habituel :

cd C:\waptdev
git clone https://git.comitari.fr/paquets-publiques/comi-audit-secu.git
cd .\comi-audit-secu

Dans WAPT Console / VS Code, lancer Update Package. Le point d’entrée unique est update_package.py; il localise le paquet à partir de son propre chemin, quel que soit le répertoire courant. Il récupère l’archive HTTPS du commit fixé, vérifie la structure et prépare vendor/, ses empreintes SHA-256 et package-manifest.json. Il n’incrémente pas la version, ne construit pas le .wapt, ne le signe pas et ne le publie pas.

Pour une préparation hors ligne, fournissez une archive ZIP exacte du commit et son empreinte obtenue par un canal de confiance distinct :

$env:HARDENINGKITTY_ARCHIVE = 'C:\staging\windows_hardening-acf9ece.zip'
$env:HARDENINGKITTY_ARCHIVE_SHA256 = '<SHA256 obtenu indépendamment>'

Puis lancer Update Package. L’empreinte locale calculée à partir du même fichier ne constitue pas une vérification indépendante de son authenticité. Le proxy système configuré pour Python/urllib est utilisé; la validation TLS par défaut n’est pas désactivée. Une erreur réseau ou d’intégrité arrête la préparation et garde le vendor/ précédent.

Le répertoire vendor/ et package-manifest.json sont versionnés avec le paquet. Ainsi, un clone propre contient directement les composants épinglés et peut être construit sans téléchargement préalable. Update Package permet de reproduire leur préparation ou de régénérer les manifestes après une évolution contrôlée de la révision upstream. La règle .gitignore est une règle Git; elle ne sert pas de filtre de contenu WAPT. WAPT applique ses propres exclusions de construction (notamment .git, .gitignore, setup.pyc et __pycache__ dans les versions documentées). Ne configurez pas vendor/ comme exclusion de construction.

Contrôler, construire, signer et publier

Avant toute construction, exécuter le contrôle bloquant des sources :

waptpython tools\package_verify.py --source .

Il refuse les assets absents, une révision upstream différente, un manifeste invalide ou des fichiers PowerShell/listes dont les hashes ne correspondent pas. Le contrôle lit réellement les fichiers sous vendor/. Après toute modification voulue de setup.py, runner.ps1, audit_config.json, WAPT/control ou du contenu vendor, relancer Update Package pour actualiser les manifestes, puis ce précontrôle.

Ensuite, dans WAPT Console, utiliser Build pour construire et signer le paquet selon le certificat et le workflow standards de l’organisation. Ne pas utiliser Build and upload avant la vérification du fichier construit. Inspecter le .wapt réellement généré :

waptpython tools\package_verify.py --wapt .\comi-audit-hardeningkitty_0.9.8-0_all.wapt

Cette vérification ouvre l’archive ZIP .wapt et contrôle les scripts, vendor/HardeningKitty.psm1, vendor/HardeningKitty.psd1, le manifeste vendor, les listes CSV et toutes les empreintes référencées. Si elle réussit, publier ensuite depuis WAPT Console selon le workflow habituel. La réussite d’Update Package ou du précontrôle ne signifie jamais que la construction, la signature ou la publication ont réussi. La vérification locale contrôle les hashes de contenu; elle ne remplace pas la validation cryptographique de la signature WAPT, qui reste au workflow Console/agent.

Le builder WAPT documenté peut également être lancé par CLI avec wapt-get build-package ., puis le .wapt doit passer le même contrôle d’archive. Éviter build-upload avant ce contrôle post-build.

Installation et audit poste

L’installation ne contacte ni GitHub, ni la PowerShell Gallery. Elle vérifie le manifeste de paquet et chaque fichier vendor avant la copie, copie vers un répertoire temporaire, vérifie à nouveau les hashes, applique une ACL limitée à SYSTEM et Administrateurs locaux, puis remplace atomiquement l’installation précédente avec restauration en cas d’échec. Les rapports sont conservés lors d’une mise à jour.

Emplacements par défaut :

C:\ProgramData\Comitari\Audit-HardeningKitty\
C:\ProgramData\Comitari\Audit-HardeningKitty-Reports\

audit() choisit Windows PowerShell 5.1 64 bits, vérifie la bitness du processus, lance le runner avec timeout (timeout_seconds, défaut 900 s) et refuse un rapport absent, vide, incomplet, mal formé ou corrompu. Un contrôle manquant/ignoré/non évaluable est distinct d’un contrôle conforme. Les exclusions conditionnelles ne sont acceptées que si elles sont explicitement documentées dans intentional_exclusions, par nom exact de benchmark et ID, avec une raison non vide. Elles sont comptées comme exclues et jamais comme conformes. Les résultats Not Applicable explicites sont également séparés du dénominateur de conformité.

Le rapport attendu est le CSV HardeningKitty à colonnes ID,Category,Name,Severity,Result,Recommended,TestResult,SeverityFinding. Une ligne n’est conforme que si Severity=Passed et TestResult=Passed; un écart Low/Medium/High exige TestResult=Failed et une sévérité concordante. Les autres combinaisons sont inconnues et produisent ERROR. Le parseur accepte les rapports UTF-8/BOM, UTF-16 et l’encodage local Windows strictement, car Windows PowerShell 5.1 n’a pas un encodage par défaut uniforme pour les fichiers CSV. La couverture est jointe par ID, pas par les noms/catégories qui peuvent être localisés; les IDs doivent être uniques dans le benchmark et le rapport.

La classification est :

Résultat	Statut WAPT par défaut
Tous les contrôles applicables conformes	`OK`
Écart Medium ou Low	`WARNING`
Écart High	`ERROR`
Erreur technique, timeout, résultat manquant/ignoré/inconnu ou aucune population évaluable	`ERROR`

error_on_high et warn_on_low configurent les seuils métier. Désactiver l’alerte High ou Low ne transforme jamais une collecte incomplète en résultat conforme. Le statut retourné par audit() est le résultat courant; une erreur de publication WAPT provoque elle-même un ERROR.

Données et Reporting WAPT

Le paquet utilise les API d’audit documentées pour WAPT 2.4+ : WAPT.write_audit_data_if_changed(section, key, value, ..., max_count=5, keep_days=120) pour les mesures stables, et WAPT.write_audit_data() pour l’observation horodatée last_run_utc. Une erreur d’écriture ne reste pas silencieusement cachée : l’audit retourne ERROR et tente de publier ce statut.

Dans la section HardeningKitty, les clés publiées comprennent :

status, benchmark, os_caption, os_build, display_version, source, upstream_commit, last_run_utc, last_error ;
expected, executed, passed, high, medium, low, ignored, not_applicable, excluded, unknown, skipped, total et compliant_percent ;
findings_00 à findings_15, des fragments JSON stables avec ID, catégorie, nom, sévérité du contrôle et résultat. Les valeurs actuelles/recommandées ne sont pas dupliquées dans ces fragments lorsque publish_current_values est faux.

Les valeurs actuelles et recommandations issues du poste ne sont pas envoyées par défaut (publish_current_values: false). Les écarts détaillés restent dans le CSV local, protégé par ACL; les journaux locaux peuvent inclure les erreurs techniques. Huit exécutions locales sont conservées par défaut. WAPT limite les mesures stables à cinq changements pendant 120 jours, les fragments à trois changements pendant 120 jours, et les horodatages à cinq observations pendant 120 jours. Ces valeurs suivent les paramètres documentés des API d’audit WAPT.

La suite mesure aussi la taille série des écarts sur des CSV synthétiques. Pour 10/100/500 lignes d’écart, le CSV brut local faisait 3 562/35 062/175 462 octets; les fragments JSON WAPT par défaut faisaient 1 125/11 106/55 906 octets. Le mode qui ajoute les valeurs et recommandations synthétiques faisait 4 305/42 906/214 906 octets. Ce sont des tailles de sérialisation, sans surcoût PostgreSQL/WAPT, et non une mesure sur un parc réel. Les métriques de résumé et les détails restent séparés; les valeurs de contrôle ne sont pas copiées dans Reporting par défaut.

Configuration

Dans audit_config.json :

source: GPO ou Intune (source de comparaison HardeningKitty, pas un changement de stratégie) ;
profile: auto, community ou nom exact d’une liste machine embarquée ;
timeout_seconds: délai d’exécution entre 30 et 7200 secondes ;
error_on_high, warn_on_low: seuils de statut ;
publish_to_wapt: publication structurée dans les données d’audit ;
publish_current_values: autorise explicitement la transmission des valeurs observées et recommandées ; désactivé par défaut ;
intentional_exclusions: dictionnaire benchmark → ID → raison pour les contrôles omis par une condition explicitement revue ; vide par défaut ;
retain_audit_runs, max_findings_in_log: rétention locale et volume de sortie console.

Les exclusions doivent être fondées sur une revue du benchmark et ne doivent pas être ajoutées uniquement pour faire passer un audit. L’ID exclu reste visible et comptabilisé dans excluded.

Désinstallation et limites

uninstall() supprime uniquement les fichiers répertoriés dans le manifeste du paquet et conserve les éventuels fichiers étrangers présents dans le répertoire d’installation. Les rapports locaux ne sont pas supprimés. Pour effacer ces rapports, appliquer séparément la politique de conservation de l’organisation.

HardeningKitty peut ne pas évaluer certains contrôles faute d’outil, droits ou prérequis; ces résultats ne sont jamais assimilés à des succès. Les vérifications utilisant des libellés localisés peuvent varier selon la langue Windows. Les résultats sur Windows français, les différents rôles serveur, les GPO/Intune réels et les performances parc doivent être validés sur des machines de test représentatives. Une conformité au benchmark n’est pas une preuve d’absence de vulnérabilité; un écart n’est pas une recommandation automatique de remédiation.

Cette version n’a pas été validée par un audit PowerShell réel sur Windows ni par une installation signée avec un agent WAPT 2.6. Les tests du dépôt sont synthétiques et ne modifient pas la configuration Windows.

Tests synthétiques

Depuis la racine du dépôt, avec le waptpython de l’environnement WAPT :

waptpython tests\test_package.py -v
waptpython -m py_compile setup.py update_package.py tools\vendor_assets.py tools\package_verify.py
waptpython tools\package_verify.py --source .

Les tests utilisent des listes, rapports et archives synthétiques. Ils couvrent la préparation offline, hashes, intégrité et répétition, parseur CSV, contrôles manquants/doublons/ignorés, confidentialité, statut et API WAPT simulés, installation/désinstallation, et inspection d’un .wapt synthétique. Ils ne remplacent pas une validation sur poste Windows.

14 KiB Raw Blame History Unescape Escape