Présentation des principes de sécurité dans WAPT¶

Date	avr. 24, 2024
Rédigé par	Hubert TOUVET, Vincent Cardon
S’applique à WAPT	>= 2.3.0.13180
Version du Document	2.3.0.0-0
Hash Git	7e46aa8617c72228976f383be2e9d2f70c3cc7bd

Sont documentés ici différents principes avancés de sécurité incorporés dans WAPT.

La lecture de cette documentation n’est pas indispensable pour utiliser WAPT ; elle est cependant recommandée pour vous permettre de mieux comprendre certains choix architecturaux.

Préambule et définitions¶

Attention

Le service WAPT fonctionne en compte système privilégié.

Environnement technique pour le fonctionnement du produit¶

Champ d’application de la Cible d’Évaluation¶

L’évaluation porte sur :

un Serveur WAPT et son dépôt (waptserver et waptrepo) ;
un Agent WAPT, avec waptexit activé (wapttray désactivé) ;
La console de management (waptconsole) ;
Les communications réseaux entre ces différentes composantes.
la gestion sécurisée des paquets WAPT :
- le déploiement sécurisé d’un ou plusieurs paquets WAPT ;
- le déploiement sécurisé d’une mise à jour du paquet WAPT ;
- la désinstallation d’un paquet WAPT.

La gestion sécurisée est basée sur l’utilisation de certificats différenciés entre le gestionnaire de déploiement (certificat X509 standard) et le concepteur de paquets WAPT (certificat X509 avec attribut Code-Signing).

Les opérations qui font partie du périmètre externe de la TOE, et qui ne font donc pas partie du champ d’application de l’évaluation, sont les suivantes :

Écrire le script WAPT en Python, et fournir tous les autres fichiers nécessaires à la création du paquet WAPT.
Il gère les clés privées pour la signature des paquets, ainsi que la gestion et la révocation des certificats SSL.

Plate-forme d’évaluation¶

L’évaluation portera sur les points suivants :

Serveur WAPT (waptserver et waptrepo) installé sur Rocky Linux 9 (clone de RedHat 9) avec SELinux et firewalld activés.
Un Agent WAPT installé sur Windows 10.
La console de gestion (WAPT Console) installée sur Windows 10.

La console est connectée au Serveur WAPT via un réseau local. Ce poste de travail hébergeant la console peut également avoir accès à un réseau non contrôlé, par lequel il obtient des paquets (logiciels ou mises à jour de logiciels) que l’administrateur d’entreprise souhaite ensuite intégrer dans son référentiel WAPT privé.

Les postes de travail et la console d’administration de la plate-forme d’évaluation sont liés à un domaine d’authentification Active Directory.

Le fonctionnement de WAPT sur les plateformes client Linux et macOS (agent, console d’administration) ne sera pas évalué.

Le certificat HTTPS pour le serveur Nginx utilisé dans l’évaluation est un certificat auto-signé généré lors de l’installation de WAPT. Il est déployé en même temps que les agents et est rattaché au certificat du Serveur WAPT.

Liste des composants tiers intégrés dans WAPT (COTS)¶

Composants tiers intégrés au Serveur WAPT waptserver¶
Composant	Version	a été mis à jour par rapport à la dernière version	Maintenu	Source
Nginx	1.20.1	Oui (distribution)	Oui (distribution)	Distribution RHEL9.1
nginx-mod-http-auth-spnego	1.20.1	Oui (en amont)	Oui (en amont)	compilé à partir de nginx et de Nginx SPNego sources (hash git bd4e8c3)
PosgreSQL	13.7	Oui (distribution)	Oui (distribution)	Distribution RHEL9.1
python 3.8	3.8.18	Oui (branche amont 3.8)	Oui (branche amont 3.8)	compilé à partir des sources Python 3.8
kerberos MIT	1.19.1	Oui (distribution)	Oui (distribution)	Distribution RHEL9.1
OpenSSL pour les modules compilés en python et Freepascal	3.1.3	Oui (en amont)	Oui (en amont)	Compilé à partir des ` sources OpenSSL`_
Modules Python	voir ci-dessous pour la liste			installé par la commande pip

Composants tiers intégrés dans l’Agent WAPT waptservice¶
Composant	Version	a été mis à jour par rapport à la dernière version	Maintenu	Source
python 3.8	3.8.18	Oui (branche amont 3.8)	Oui (branche amont 3.8)	compilé à partir des sources Python 3.8
OpenSSL pour les modules compilés en python et Freepascal	3.1.3	Oui (en amont)	Oui (en amont)	Compilé à partir des ` sources OpenSSL`_
Modules Python	voir ci-dessous pour la liste			installé par la commande pip

Composants tiers intégrés dans les binaires spécifiques à WAPT : waptconsole, wapt-get, waptexit, wapttray, waptdeploy, waptlicences¶
Composant	Version	a été mis à jour par rapport à la dernière version	Maintenu	Source
lazarus 2.3	2.3 fixe tag_2_3	Oui (en amont)	Oui (en amont)	Sources Lazarus
freepascal 3.2.3	3.2.3 fixe tag_3_2	Oui (en amont)	Oui (en amont)	Sources FPC
mormot2	2.1 Git Sha1 c3a060ea35e380a7e5f26ec6e23c5005a5d79f36	Oui (en amont)	Oui (en amont)	Sources mORMot

Modules agent et serveur Python¶

Les modules Python sont importés sous forme de source depuis Pypi.org et compilés sous forme de roue et stockés dans un dépôt pip interne. La ferme de construction de WAPT ne fournit pas de connexion directe à l’Internet pour l’installation des modules Python.

La colonne « Plate-forme Cible » indique les paquets de roues qui ne sont installés que sur certaines architectures cibles.

Modules Python communs aux Agents et au Serveur WAPT¶
Modules Python communs aux Agents et au Serveur	Version	Plate-forme cible
arpy	2.2.0
babel	2.9.1
beautifulsoup4	4.11.2
certifié	2023.7.22
cffi	1.15.1
chardet	4.0.0
cliquer	8.1.3
configparser	5.0.2
cryptographie	41.0.4
décorateur	5.1.1
distribution	1.5.0
dnspython	1.16.0	sys_platform == “linux” or sys_platform == “darwin”
flacon	2.3.2
futur	0.18.3
gssapi	1.8.2	sys_platform == “linux” or sys_platform == “darwin”
idna	2.10
iniparse	0.5
ipaddress	1.0.23
itsdangerous	2.1.2
jinja2	3.1.2
kerberos	1.3.1	sys_platform == “linux” or sys_platform == “darwin”
krb5	0.4.1	sys_platform == « linux » or sys_platform == “darwin”
ldap3	2.9
markupsafe	2.1.3
netifaces	0.11.0
packaging	20.9	sys_platform == “darwin”
psutil	5.8.0
pyad	0.6.0	sys_platform == “win32”
pyasn1	0.4.8
pycparser	2.21
py-cpuinfo	8.0.0	sys_platform == “linux” or sys_platform == “darwin”
pyedid	1.0.2
pykerberos	1.2.4	sys_platform == “linux” or sys_platform == “darwin”
pyobjc	8.5	sys_platform == “darwin”
pyobjc-core	8.5	sys_platform == “darwin”
pyobjc-framework-cocoa	8.5	sys_platform == “darwin”
pyobjc-framework-quartz	8.5	sys_platform == “darwin”
pyopenssl	23.2.0
pyparsing	2.4.7	sys_platform == “linux” or sys_platform == “darwin”
pyspnego	0.7.0
python-engineio	4.7.1
python-pam	1.8.4	sys_platform == “linux” or sys_platform == “darwin”
python-socketio	4.6.1
pytz	2021.1
pywin32	301	sys_platform == “win32”
requêtes	2.31.0
requêtes-kerberos	0.14.0
rpmfile	1.0.8
setproctitle	1.2.2
six	1.16.0
smmap	4.0.0
dactylographie	3.7.4.3
ujson	5.5.0
temps de fonctionnement	3.0.1
urllib3	2.0.4
serveuse	2.1.2
wakeonlan	2.0.1
websocket-client	1.1.0
werkzeug	2.3.6
winkerberos	0.8.0	sys_platform == “win32”
winshell	0.6	sys_platform == “win32”
winsys	0.5.2	sys_platform == “win32”
wmi	1.5.1	sys_platform == “win32”

Modules Python spécifiques au Serveur WAPT¶
Modules Python spécifiques au Serveur	Version
dnspython	1.16.0
eventlet	0.31.0
flacon-Babel	2.3.0.0-0
flask-Login	0.5.0
flask-SocketIO	4.3.2
greenlet	1.1.0
huey	2.4.3
monotone	1.6
passlib	1.7.4
peewee	3.14.4
fichier de données	2022.5.30
psycopg2	2.9.1
psycopg2-binary	2.9.1
psycogreen	1.0.2

Patchs spécifiques¶

Modules Python spécifiques au Serveur WAPT¶
Module Python	Version
description	iniparse
0.5	Le mot-clé REM (remarque) doit être suivi d’un espace pour être une remarque.
certifié	2023.7.22
Importation de certificats racine à partir de magasins système pour Windows et macOS	cryptographie
41.0.4	Désactiver le chargement des anciens algorithmes.

Vulnérabilités identifiées¶

La dernière version du module python « kerberos » est affectée par la vulnérabilité CVE-2015-3206.

La fonction checkPassword de python-kerberos n’authentifie pas le KDC avec lequel elle tente de communiquer, ce qui permet à des attaquants distants de provoquer un déni de service (mauvaise réponse) ou d’avoir d’autres impacts non spécifiés en effectuant une attaque de type « man-in-the-middle.

Cette fonction n’est pas utilisée dans le produit WAPT.

Actifs sensibles à protéger¶

Préambule et définitions¶

Veuillez noter : Le service WAPT fonctionne comme un compte système privilégié.

Périmètre à sécuriser¶

B1 Paquets WAPT¶

Les paquets WAPT à déployer sont l’un des principaux actifs sensibles à protéger. Ils doivent être protégés en termes de disponibilité sur le référentiel et d’intégrité pendant le déploiement.

Les besoins de sécurité : intégrité, authenticité, disponibilité

B2 Actions déclenchées sur le poste client à partir de la console¶

Les actions sont envoyées aux agents depuis la console (via une charge utile json signée). Ces actions peuvent être la mise à jour du poste de travail, le déploiement/désinstallation d’un paquetage particulier, le redémarrage des machines…. Ces actions sont des actifs sensibles qui doivent être protégés en termes d’intégrité et d’authenticité.

Nécessité de sécurité : intégrité, authenticité

B3. Matériel cryptographique¶

Le matériel cryptographique est un bien sensible qui doit être protégé. Il sert de données d’authentification et est utilisé pour le cryptage.

Exigences de sécurité : intégrité, confidentialité, disponibilité

Il existe plusieurs dispositifs cryptographiques dans un déploiement WAPT :

certificat de serveur pour la communication https.
la clé privée du serveur pour les communications https.
Certificat de l’agent WAPT : certificat signé par le Serveur WAPT après CSR par le poste de travail authentifié.
la clé privée du poste de travail correspondant au certificat de l’Agent WAPT.
le certificat de signature de code de l’administrateur WAPT.
la clé privée de l’administrateur WAPT, correspondant au certificat de signature de code de l’administrateur WAPT.
le certificat standard sans signature de code de l’administrateur WAPT.
la clé privée de l’administrateur WAPT correspondant au certificat sans signature de code de l’administrateur WAPT.
Mot de passe de l’administrateur WAPT pour se connecter au Serveur WAPT.
le jeton kerberos de l’administrateur WAPT (ticket de service pour le Serveur WAPT).

B4. Communications¶

Les communications entre le serveur central et les agents ainsi que les communications entre la console et le serveur sont un bien sensible et doivent être protégées.

Les besoins de sécurité : intégrité, confidentialité, authenticité.

B5. Données d’inventaire¶

Les informations sur l’état de déploiement des paquets, ainsi que configuration matérielle et logicielle des postes clients sont un bien sensible et doivent être protégées.

Les besoins en matière de sécurité : intégrité, confidentialité.

B6. Les journaux¶

Les journaux générés par WAPT sur le serveur central et les agents sont un bien sensible et doivent être protégés.

Les besoins en matière de sécurité : intégrité, disponibilité, confidentialité.

B7. Valeurs de configuration¶

Les valeurs de configuration du Serveur (clés du serveur https, configuration accès à la base de données, configuration de l’authentification au serveur) sont un bien sensible et doivent être protégés.

Les besoins de sécurité : intégrité, confidentialité, disponibilité.

B8. Exécutables WAPT installés¶

Les exécutables WAPT installés sur les postes clients gérés (contenu du répertoire wapt, y compris les binaires, les dll, les fichiers de configuration et la base de données) constituent un bien sensible et doivent être protégés.

Nécessité de sécurité : intégrité.

B9. Système d’accueil¶

Les systèmes hôtes, qui comprennent ici le serveur hébergeant le Serveur WAPT ,les postes d’administration hébergeant la console d’administration et les postes utilisateurs équipés de l’Agent WAPT, sont un bien sensible et doivent être protégés.

Exigences de sécurité : intégrité, confidentialité, disponibilité.

Mesures environnementales¶

Un opérateur WAPT devra choisir et suivre une méthodologie adaptée :

Assurer un téléchargement sûr de tous les autres fichiers servant à constituer un paquet WAPT.
Rédiger le script python setup.py d’installation d’un paquet WAPT de telle manière à éviter toute faille de sécurité ou de confidentialité exploitable.
Gérer de manière sûre les clés privées de signature des paquets.
Gérer de manière sûre les Autorités de certification et de révocation des certificats SSL et HTTPS.

Description des utilisateurs typiques de WAPT¶

Les rôles suivants doivent être compris pour évaluer les principes de sécurité présents dans WAPT :

Utilisateur final¶

Un utilisateur est une personne équipée d’une machine sur laquelle tourne l’Agent WAPT. Il peut mettre à jour sa machine selon les paramètres définis par le gestionnaire de déploiement.

Administrateur professionnel : gestionnaire de déploiement¶

Un gestionnaire de déploiement est une personne qui peut signer des paquets ne contenant PAS de code python (généralement des paquets de groupe, d’unité et d’hôte) et les télécharger vers le référentiel principal. Il définit les profils de déploiement (un ensemble de paquets WAPT assignés aux postes de travail). Il est identifié par l’absence de l’attribut Code-Signing dans son certificat.

Administrateur professionnel : développeur de paquets¶

Un développeur de paquets est une personne qui peut signer des paquets, qu’ils contiennent ou non du code python, et les télécharger dans le dépôt principal. Le développeur de paquets est identifié par l’attribut Code-Signing de son certificat.

Administrateur de l’emploi : SuperAdmin¶

Le SuperAdmin est un individu avec tous les droits dans WAPT (Enterprise and Discovery).

Administrateur du système : Administrateur local¶

Un administrateur local est un utilisateur disposant de droits d’administration locaux sur les postes de travail équipés de WAPT. Il est utilisé pour le déploiement initial de l’Agent WAPT, si nécessaire.

Description des hypothèses sur l’environnement d’exploitation de WAPT¶

Les hypothèses suivantes sur l’environnement d’exploitation de WAPT doivent être considérées :

H1. Les administrateurs d’entreprise de WAPT sont formés¶

Les administrateurs d’entreprise sont fiables et formés à l’utilisation de WAPT. Ils doivent notamment veiller à ce que leurs identifiants et leurs clés de sécurité restent secrets et protégés.

H2. Les systèmes sous-jacents à WAPT sont sains¶

Les systèmes d’exploitation sur lesquels les Agents WAPT s’exécutent mettent en œuvre des mécanismes de protection adéquats (confinement, contrôle d’accès, etc.) paramétrés et configurés selon les bonnes pratiques.

Les systèmes d’exploitation sont à jour des correctifs en vigueur au moment de l’installation et sont sains et exempts de virus, de chevaux de Troie, etc.

H3. Les binaires nécessaires à l’exécution de WAPT sont intacts¶

Toutes les bibliothèques et tous les outils nécessaires à l’installation de WAPT sont considérés comme sûrs.

H4. Les paquets WAPT sont construits de manière sûre¶

Il incombe à l’administrateur de s’assurer que les fichiers destinés à être inclus dans les paquets WAPT proviennent de sources sûres et sont exempts de virus, de chevaux de Troie, etc.

Les Administrateurs sont également responsables d’écrire et d’incorporer des scripts setup.py sûrs dans les paquets WAPT.

H5. Les utilisateurs du client ne sont pas des administrateurs locaux¶

Un utilisateur n’a pas de droits d’administration sur son poste de travail. Dans le cas contraire, l’utilisateur est considéré comme un administrateur local.

En particulier, l’utilisateur n’a pas d’accès en écriture au répertoire d’installation du client WAPT.

H6. Les administrateurs locaux des postes de travail clients sont formés¶

L’administrateur local d’un poste client doit être formé au fonctionnement de WAPT ou ne doit pas modifier les fichiers d’installation dans le dossier d’installation de WAPT.

H7. Le Serveur WAPT est réservé à un usage spécifique.¶

Le Serveur sur lequel WAPT est installé est dédié exclusivement à WAPT.

H8. Les mots de passe sont conformes aux critères minimaux de sécurité¶

Les mots de passe utilisés par les administrateurs sont censés respecter les critères minimaux de sécurité de l’ANSSI.

H9. L’environnement Windows est configuré selon les meilleures pratiques¶

L’environnement sous-jacent est configuré selon les bonnes pratiques décrites dans le guide de durcissement des postes de travail de l’ANSSI.

Description de la menace¶

Les agents menaçants à prendre en compte pour l’évaluation de la sécurité sont les suivants :

Entités non autorisées : un attaquant humain ou une entité qui interagit avec le WAPT mais n’y a pas d’accès légitime.
Utilisateur final malveillant : un utilisateur final ayant accès à un poste de travail sur lequel l’Agent WAPT est installé et cherchant à élever ses privilèges sur le poste de travail.

Les Administrateurs d’entreprise et les Administrateurs locaux ne sont pas considérés comme des attaquants.

Les menaces qui portent sur les biens sensibles WAPT définis ci-dessus sont les suivantes :

M01. Installation d’un paquet corrompu¶

Cette menace correspond à un attaquant qui parvient à utiliser un composant de l’Agent WAPT pour déployer un paquet corrompu, en contournant la sécurité normalement assurée par la signature du paquet.

M02. Modification des valeurs de configuration¶

Cette menace correspond à un attaquant qui parvient à modifier ou à supprimer les paramètres d’un élément WAPT défini par un administrateur WAPT légitime.

M03. Accès illégitime¶

Cette menace correspond à un attaquant qui réussirait à récupérer les données d’authentification d’un administrateur, à contourner le mécanisme d’authentification afin d’accéder à un bien sensible stocké sur le serveur ou de le modifier. Elle correspond également à un attaquant qui pourrait se faire passer pour un Agent WAPT.

M04. Écoute réseau¶

Cette menace correspond à un attaquant qui parviendrait à intercepter et prendre connaissance des communications réseaux entre les agents et le serveur hébergeant WAPT.

M05. Modification du trafic réseau (type Man In the Middle)¶

Cette menace correspond à un attaquant qui parviendrait à modifier les communications réseaux entre les agents et le serveur hébergeant WAPT ou les communications réseau entre la console et le Serveur WAPT.

M06. Altération des grumes¶

Cette menace correspond à un attaquant qui réussirait à corrompre les journaux renvoyés par les agents et stockés dans la base de données.

M07. Récupération du matériel cryptographique¶

Cette menace correspond à un attaquant qui réussit à récupérer des clés cryptographiques ou à en prendre connaissance.

M08. Modification du matériel cryptographique¶

Cette menace correspond à la corruption illégitime des clés cryptographiques par un attaquant.

M09. Déni de service¶

Cette menace correspond à un attaquant qui affecte la disponibilité des actifs sensibles.

M10. Modification ou envoi d’une action non désirée sur le poste de travail¶

Cette menace correspond à un attaquant qui parvient à générer ou modifier le flux json contenant des actions et à les exécuter sur le poste de travail.

M11. Élévation des privilèges du poste de travail¶

Cette menace correspond à un attaquant qui parvient à élever ses privilèges sur le poste de travail en utilisant l’environnement WAPT.

Fonctions mises en œuvre par le produit¶

Fonctions de sécurité (FS)¶

FS1. Communications sécurisées¶

Communications initiées par les agents¶

L’agent télécharge ses paquets à partir d’un serveur https, qui vérifie que le certificat du référentiel provient d’une autorité présente dans son répertoire <wapt>/ssl/server. Le serveur https vérifie que le certificat du client provient d’une autorité présente dans le magasin de confiance du client du référentiel.

Les requêtes de l’agent vers le serveur utilisent le protocole https. L’agent vérifie que le certificat du serveur provient d’une autorité présente dans son répertoire <wapt>/ssl/server.

L’agent établit un tunnel websocket avec le serveur pour recevoir les actions de la console. La connexion websocket est encapsulée dans un tunnel TLS. L’agent vérifie que le certificat du serveur provient d’une autorité présente dans son répertoire <wapt>/ssl/server.

Communications initiées par la Console¶

La console télécharge des paquets à partir de dépôts, en vérifiant que le certificat provient d’une autorité présente dans son %localappdata%/waptconsole/ssl/server répertoire. Les serveurs https des dépôts sont configurés pour n’accepter que les certificats clients provenant d’autorités de confiance.

Les requêtes de la console au Serveur WAPT utilisent le protocole https. La console vérifie que le certificat du serveur provient d’une autorité présente dans son répertoire <wapt>/ssl/server. Le Serveur WAPT est configuré pour n’accepter que les certificats clients provenant d’autorités de confiance.

Connexion websocket de l’Agent¶

Les agents demandent au serveur un jeton d’authentification signé avec leur clé privée. Ce jeton est vérifié par le Serveur WAPT au cours de la connexion websocket.
L’accès au Serveur WAPT pour obtenir le jeton et établir la connexion websocket est protégé par l’authentification du certificat du client.

Connexion de l’Agent pour un retour d’information sur l’inventaire¶

Les Agents signent leurs données d’inventaire avec leur clé privée, et le serveur vérifie la clé et la signature à l’aide du certificat public stocké dans sa base de données lors de l’enregistrement initial de l’agent.
L’accès au Serveur WAPT est protégé par l’authentification du certificat du client.

Connexion des Agents pour le téléchargement des paquets¶

L’accès au(x) dépôt(s) de paquets WAPT est protégé par l’authentification du certificat du client.

Authentification du Serveur par les Agents¶

Lorsque l’agent se connecte au serveur via des requêtes HTTPS, il vérifie que le certificat du serveur est valide et qu’il provient d’une autorité de certification de confiance. Lors de l’installation de l’agent, vous choisissez d’utiliser :

Le magasin de certificats du système.
Ou un magasin spécifique à WAPT stocké dans le dossier <wapt>sslserver (épinglage de certificat). Pour les besoins de l’évaluation, c’est cette deuxième option qui a été retenue.

Authentification du (des) dépôt(s) par les Agents¶

Lorsque l’agent se connecte à un référentiel via des requêtes HTTPS, il vérifie que le certificat du référentiel est valide et qu’il provient d’une autorité de certification de confiance. Lors de l’installation de l’agent, vous choisissez d’utiliser :

Le magasin de certificats du système.
Ou un magasin spécifique à WAPT stocké dans le dossier <wapt>sslserver (épinglage de certificat). Pour les besoins de l’évaluation, c’est cette deuxième option qui a été retenue.

FS2. Identification, authentification et contrôle d’accès¶

Enregistrement initial de l’Agent WAPT¶

Pour exister dans la base de données et ainsi apparaître dans la Console WAPT, une machine doit s’enregistrer auprès du Serveur WAPT avec une commande register.

La commande register peut être exécutée automatiquement lors de l’installation ou de la mise à jour de l’Agent WAPT si la machine est correctement enregistrée avec un compte machine Kerberos dans le domaine Active Directory de l’Organisation.

Si la machine ne présente pas au Serveur WAPT un ticket kerberos valide, l’action register échoue avant de demander l’accès à la base de données.

Lors de l’enregistrement, le poste client génère une paire de clés RSA dans le répertoire privé local et envoie au serveur une demande de signature de certificat avec le ticket kerberos.

Si le ticket Kerberos est valide, le Serveur WAPT enregistre le client dans sa base de données, signe le CSR, stocke le certificat dans sa base de données et le renvoie au client.

Si un appareil est déjà enregistré, il peut se ré-enregistrer sans ticket kerberos en utilisant le certificat signé de son serveur actuel.

Si l’authentification kerberos échoue ou n’est pas disponible, le serveur envoie un statut non autorisé, et le client peut demander à l’administrateur local d’entrer les informations d’identification d’un compte du Serveur WAPT ayant le privilège admin ou le privilège register_host.

Note : La méthode Kerberos suppose que le serveur Active Directory répond au moment de l’enregistrement.

Actions locales sur les agents¶

L’utilisateur du poste de travail peut interagir avec l’Agent WAPT par le biais d’actions HTTP locales. L’utilisateur est identifié par son nom d’utilisateur, qui détermine les propriétés de sa session locale.

Les actions de l’utilisateur (installations, désinstallations, mises à jour de paquets) sont authentifiées par le service local à l’aide d’un jeton déposé dans le répertoire personnel associé à la session de l’utilisateur.

L’accès aux actions est conditionné par l’appartenance du compte de l’utilisateur aux groupes de sécurité du système local (voir les règles de libre-service définies par un paquet de libre-service).

Authentification de l’administrateur d’entreprise sur la Console WAPT¶

La connexion HTTPS entre la console de gestion et le serveur est d’abord authentifiée par le certificat client du Business Administrator.

La demande de connexion initiale est authentifiée par le ticket de session kerberos de l’administrateur d’entreprise. Il est utilisé pour récupérer un jeton de session qui authentifiera les demandes suivantes.

Les ACL de WAPT associées au compte de l’administrateur d’entreprise déterminent les fonctions accessibles du serveur. Elles sont destinées à faciliter l’organisation et ne sont pas considérées comme une fonction de sécurité.

FS3. Protection des données¶

Accès au répertoire d’installation de l’Agent WAPT¶

Le répertoire d’installation <wapt> (C:NProgram Files (x86)Nwapt par défaut) est lisible et modifiable :

Administrateurs locaux grâce à un accès local au répertoire d’installation de l’Agent WAPT.
Aux Administrateurs à travers le mécanisme de déploiement des mises à jour de l’Agent WAPT.

Les utilisateurs n’ont pas d’accès en écriture au répertoire d’installation de l’Agent WAPT.

Les restrictions d’accès au dossier <wapt> sont basées sur le mécanisme ACL standard du système d’exploitation et sont appliquées lors de l’installation de l’Agent WAPT.

Accès au répertoire de stockage privé <wapt>/private storage directory¶

Le répertoire <wapt>/private (C:NProgram Files (x86)Nwapt/private par défaut) contient :

La paire clé privée/certificat identifiant l’agent auprès du serveur.
Données persistantes du paquet dans le sous-répertoire <wapt>/private/persistent.

Aucun droit d’accès au répertoire n’est accordé à un utilisateur. Seuls l’Agent WAPT et les administrateurs locaux ont un accès en lecture et en écriture à ce répertoire.

Les restrictions d’accès au dossier <wapt> sont basées sur le mécanisme ACL standard du système d’exploitation et sont appliquées lors de l’installation de l’Agent WAPT.

Accès à la paire clé privée/certificat de l’administrateur métier¶

La clé privée doit être stockée par l’administrateur d’entreprise dans un dossier qu’il est le seul à pouvoir consulter et qu’il considère comme sûr. Lorsque les clés sont générées par la console, il est suggéré qu’elles soient stockées dans le répertoire personnel de l’administrateur d’entreprise dans un dossier <wapt>/privé.

La clé est cryptée par une clé dérivée d’un mot de passe fort fourni par l’Administrateur d’Entreprise.

FS4. Fonctions cryptographiques : Authenticité et intégrité¶

Signature des attributs du fichier de contrôle¶

Les métadonnées (attributs) d’un paquet sont définies dans un fichier texte appelé control.

Une somme de contrôle de tous les attributs du fichier control est générée, puis signée par la clé privée du développeur du paquet. La signature est ajoutée au fichier control.

Lors de la mise à jour des paquets disponibles, l’agent est ainsi en mesure de vérifier que le certificat du développeur du paquet provient d’une autorité présente dans son répertoire local <wapt>/ssl.

La clé publique est utilisée pour vérifier la signature des attributs du paquet et l’authentifier.

La signature de la somme de contrôle vérifie l’intégrité du fichier control.

Signature des paquets WAPT¶

Les paquets sont des archives ZIP. Lorsque le paquet est signé, un fichier manifest est généré, contenant la liste des fichiers de l’archive, ainsi que la somme de contrôle de chaque fichier.

La somme de contrôle de ce fichier manifest est signée par la clé privée du développeur du paquet.

L’agent est ainsi en mesure de vérifier que le certificat du Développeur de Paquets provient d’une autorité présente dans son répertoire local <wapt>/ssl.

La clé publique est utilisée pour vérifier la signature du fichier manifest et authentifier le paquet. La liste des fichiers du manifeste et les sommes de contrôle sont utilisées pour vérifier l’intégrité des fichiers composant le paquet WAPT.

Signature des actions envoyées aux Agents WAPT¶

Une action est définie par un ensemble de propriétés encodées en JSON par la Console WAPT.

Une somme de contrôle des données JSON est générée, puis signée par la clé privée de l’administrateur. La signature est ajoutée aux données JSON.

Lors de la réception de l’action, l’agent est ainsi en mesure de vérifier que le certificat qui a signé l’action provient d’une autorité présente dans son répertoire local <wapt>/ssl.

La clé publique est utilisée pour vérifier la signature de l’action et l’authentifier.

La signature de la somme de contrôle vérifie l’intégrité de l’action.

FS5. Protection contre les manipulations¶

Tous les binaires distribués par WAPT : l’installateur et les binaires inclus sont signés par Tranquil IT, avec un certificat EV Code-Signing délivré par une autorité reconnue par Microsoft. Lors des mises à jour, la signature du programme d’installation de l’agent est vérifiée par l’utilitaire waptdeploy. L’empreinte digitale du certificat de signature doit faire partie de la liste des certificats Tranquil IT compilée dans waptdeploy. waptdeploy vérifie également que l’empreinte digitale de l’installateur téléchargé correspond à celle fournie en tant qu’argument (argument –hash). L’argument –hash est stocké dans une GPO, et ne peut donc être modifié que par un administrateur de l’organisation.

Si un utilisateur utilise le libre-service pour désinstaller un paquet WAPT imposé par un administrateur, le paquet sera réinstallé lors de la prochaine mise à jour du système (par arrêt ou action explicite).

FS6. Exploitation forestière¶

Les processus de l’agent, du Serveur WAPT et du serveur NGINX https génèrent des traces de leurs opérations respectives dans des fichiers texte dont la lecture et l’écriture sont protégées par des ACL du système de fichiers. La console d’administration WAPT n’enregistre rien de son côté ; elle se contente d’interroger le serveur WAPT.

Le dernier état de chaque paquet installé est stocké dans une base de données locale de l’agent, protégée en écriture par les ACL du système de fichiers. Ces données sont envoyées au Serveur WAPT et stockées dans une base de données PostgreSQL, dont l’accès est limité au compte « wapt », propriétaire du processus du Serveur WAPT.

Lorsque l’agent envoie ses journaux au Serveur WAPT, il les signe avec sa clé privée. Le serveur vérifie l’authenticité et l’intégrité de ces données à l’aide du certificat et de la clé publique de l’agent stockés dans la base de données du serveur.

Ces informations sont accessibles via la console d’administration. Cependant, vous devez avoir le rôle d’administrateur ou de spectateur sur le serveur pour y accéder.

Fonctions non évaluées¶

Les fonctions énumérées ci-dessous sont actives dans la version du produit livrée pour évaluation, mais ne seront pas évaluées :

Restrictions fonctionnelles liées aux ACL de WAPT (l’évaluation est effectuée avec un compte disposant de l’ACL admin, c’est-à-dire des pleins droits). Cet élément est essentiellement organisationnel.

Préambule et définitions¶

Les fonctions énumérées ci-dessous nécessitent une configuration pour fonctionner. Une documentation spécifique est disponible si ces fonctions ne sont pas mises en œuvre. Ces fonctions sont les suivantes :

WADS (déploiement initial des postes de travail, équivalent de Microsoft MDT).
WAPT Windows Updates (équivalent de Microsoft WSUS).
Dépôts secondaires.

Matrices de couverture¶

Menaces et biens sensibles¶

La matrice suivante montre la couverture des menaces pesant sur les biens sensibles (les lettres D, I, C et A signifient respectivement Disponibilité, Intégrité, Confidentialité et Authenticité).

Couverture des biens sensibles par les menaces¶
	B1 Paquets WAPT	B2 Actions déclenchées sur le poste client à partir de la console	B3. Matériel cryptographique	B4. Communications	B5. Données d’inventaire	B6. Les journaux	B7. Valeurs de configuration	B8. Exécutables WAPT installés	B9. Système d’accueil
M01. Installation d’un paquet corrompu			D,I,C,A	I,C				I	D,I,C,A
M02. Modification des valeurs de configuration			D,I,C,A				I, D
M03. Accès illégitime	D		C		I,C	D	I,C	I
M04. Écoute réseau			C	C	C
M05. Modification du trafic réseau (type Man In the Middle)	D,I		C	D	D
M06. Altération des grumes						I, A, D
M07. Récupération du matériel cryptographique	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A
M08. Modification du matériel cryptographique	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A
M09. Déni de service				D	D	D			D
M10. Modification ou envoi d’une action non désirée sur le poste de travail			I,A				I		D,I
M11. Élévation des privilèges du poste de travail				C,I	I	I	I	D,I,C,A	D,I,C,A

Menaces et fonctions de sécurité¶

Couverture des menaces par les fonctions de sécurité¶
	FS1. Communications sécurisées	FS2. Identification, authentification et contrôle d’accès	FS3. Protection des données	FS4. Fonctions cryptographiques : Authenticité et intégrité	FS5. Protection contre les manipulations	FS6. Exploitation forestière
M01. Installation d’un paquet corrompu			X	X
M02. Modification des valeurs de configuration		X	X	X
M03. Accès illégitime		X		X
M04. Écoute réseau	X
M05. Modification du trafic réseau (type Man In the Middle)	X
M06. Altération des grumes	X			X		X
M07. Récupération du matériel cryptographique			X	X
M08. Modification du matériel cryptographique			X
M09. Déni de service		X	X
M10. Modification ou envoi d’une action non désirée sur le poste de travail	X		X	X
M11. Élévation des privilèges du poste de travail					X