Examen de spécialiste agréé en sécurité de l'information, automne 2023 (Reiwa 5), question 2 de l'après-midi — Les fichiers qui sortent par le Wi-Fi invité

Clés USB interdites, enregistrement sur le disque local interdit, pièces jointes interdites, serveur de fichiers interne retiré. Même alors, une voie pour sortir les fichiers professionnels subsistait.

Ce que demande la question 2 de l’après-midi de l’examen de spécialiste agréé en sécurité de l’information, automne 2023 (Reiwa 5), ce n’est pas le nombre de contre-mesures, mais qui peut atteindre les fichiers, depuis quel appareil, par quelle voie. Les contre-mesures qui agissent sur un PC professionnel et celles qui arrêtent l’accès depuis un PC personnel doivent être considérées séparément.¹

Cet article est le deuxième d’une série qui fait suite à l’explication de la question 1 (XSS stocké). Chaque sous-question est suivie dans l’ordre « réponse modèle, puis l’évidence dans l’énoncé, puis le mécanisme », et les précautions pratiques qui dépassent les prémisses de l’examen sont rassemblées au chapitre 10. Les figures et tableaux du fascicule ne sont pas reproduits tels quels ; des schémas simplifiés et des résumés de notre fait sont utilisés à la place. Les sources et la portée de la citation et du résumé figurent à la fin.¹²

1. D’abord l’ensemble — séparer l’attaquant extérieur de l’employé

Cette question se met en place si on la lit en trois étapes.

Un attaquant extérieur doit voler des identifiants, alors qu’un employé peut se connecter avec son propre identifiant légitime. Le logiciel de prévention des fuites du PC professionnel n’a aucun effet sur le PC personnel que ce dernier utilise. De plus, ce que regarde la restriction par adresse IP source du service B, ce n’est pas l’appareil mais le point de sortie NAT. Cette différence est ce qui relie toute la question.

Aller d’une sous-question au chapitre dont on a besoin

Pour la préparation à l’examen, posez d’abord les prémisses au chapitre 2, puis passez à la sous-question à résoudre. Si le but est une revue de conception en pratique, commencez par la comparaison des contre-mesures au chapitre 11 et la liste de contrôle au chapitre 12, et vérifiez les conditions et exceptions au chapitre 10.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (24 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Les prémisses de la question — ce que l’entreprise M protégeait et ce qu’elle autorisait

2.1. L’incident de l’année précédente et les contre-mesures déjà prises

L’entreprise M est une filiale de l’entreprise L, une société d’habillement de 100 employés. Son immeuble de bureaux donne sur une grande rue passante du centre de Tokyo. L’année précédente, un employé a enregistré des fichiers de conception de produits depuis le serveur de fichiers interne sur une clé USB et les a emportés chez un concurrent. Suivant les consignes de sa société mère, l’entreprise M a déjà achevé la revue suivante.¹

Ce sont des contre-mesures cohérentes qui bouchent les deux bouts de la voie de l’année précédente « serveur de fichiers interne vers clé USB ». Mais les restrictions sur le PC n’atteignent que les PC professionnels sur lesquels ce logiciel est installé.

2.2. Les règles ne couvrent pas de la même façon la salle de réunion et l’espace de bureaux

Il y a trois règles de sécurité.

Le LAN sans fil des employés est disponible dans l’espace de bureaux, et les LAN sans fil des employés et des invités sont tous deux disponibles dans la salle de réunion. Le projecteur de la salle de réunion a été configuré pour que les appareils apportés par les visiteurs (PC, tablettes, smartphones) et les PC professionnels se connectent au LAN sans fil invité afin de s’en servir.

2.3. Les réseaux sont séparés, mais la sortie vers Internet est la même

En ne transcrivant que les parties nécessaires à l’explication, la configuration est la suivante.

flowchart LR
    subgraph M["Réseau interne de l'entreprise M"]
        direction TB
        G["LAN sans fil invité<br/>192.168.10.0/24<br/>(AP de la salle de réunion seulement)"]
        E["LAN sans fil des employés<br/>192.168.20.0/24<br/>(espace de bureaux et salle de réunion)"]
        S["Réseau serveurs<br/>192.168.30.0/24<br/>DHCP, DNS, annuaire"]
        FW["FW<br/>Le NAT traduit la source<br/>vers une seule adresse<br/>IP globale"]
        G --> FW
        E --> FW
        S --> FW
    end
    FW --> B["Service B<br/>(stockage cloud)"]
    FW --> I["Internet"]

Figure 1 : Schéma simplifié de la configuration de l’entreprise M. Les réseaux invité, employés et serveurs sont séparés, mais le trafic vers Internet passe par le NAT du même pare-feu.

2.4. La « connexion » et le « partage externe » du service B sont des portes distinctes

Il y a deux façons d’utiliser le service B.

Le lien de partage n’est divulgué ni au demandeur ni au responsable. Il contient une chaîne aléatoire difficile à deviner, et il expire au bout d’un jour. En revanche, le destinataire externe peut télécharger sans se connecter. Ne laissez pas la restriction de connexion des identifiants employés se substituer à l’explication de l’usage du lien de partage.

Prenant cette configuration comme donnée, M. Y du service des systèmes d’information et M. S, spécialiste agréé en sécurité de l’information de la société mère L, traitent l’attaquant extérieur, puis l’employé, puis les contre-mesures supplémentaires, dans cet ordre.

3. Questions 1(1) et 1(2) — même après connexion à un faux AP, la connexion à un faux site est arrêtée

3.1. Question 1(1) : se connecter au LAN sans fil exige encore un identifiant et un mot de passe

Réponse modèle : les blancs a et b sont « identifiant » et « mot de passe » (dans n’importe quel ordre).²

Le premier scénario que M. Y envisage est celui d’un visiteur qui a déjà utilisé le LAN sans fil invité et qui, un jour ultérieur, se reconnecte depuis les abords de l’entreprise M et atteint le service B. Comme l’immeuble donne sur une grande rue, il faut tenir compte de la possibilité que le signal radio sorte des locaux.

WPA2-PSK est un schéma dans lequel tout le monde détient la même clé pré-partagée. Il n’y a aucun moyen de ramener une seule partie déjà informée à l’état de ne plus la connaître ; la révoquer, c’est changer la clé pour tout le monde. Mais se connecter au LAN sans fil et se connecter au service B sont deux choses distinctes. Un attaquant extérieur n’a pas l’identifiant et le mot de passe d’un employé.

3.2. Question 1(2) : le certificat d’un faux site échoue sur l’émetteur et le nom de serveur

Le scénario suivant est une attaque qui prépare un faux AP configuré à l’identique du LAN sans fil invité et un faux site à la même URL que le service B, puis falsifie les paramètres DNS pour voler les identifiants. Le but est qu’un PC professionnel d’employé se connecte par erreur au faux AP.

Un faux AP qui utilise le même SSID et la même clé pré-partagée s’appelle un evil twin. Ce que WPA2-PSK confirme, c’est que l’autre côté connaît la même clé. Sans la clé, la procédure de connexion ne peut pas aboutir, mais un attaquant qui connaît la clé remise aux visiteurs peut dresser un AP difficile à distinguer du vrai.

Même ainsi, se connecter à l’URL du service B en HTTPS fait intervenir la validation du certificat serveur. En remplissant les blancs, le détail d’erreur donné à la figure 2 du fascicule donne les quatre éléments suivants.

• Ce certificat serveur n’est pas un certificat serveur émis par une autorité de certification de confiance (blanc c)
• Le nom de serveur inscrit sur ce certificat serveur diffère du nom de serveur auquel on se connecte (blanc d)
• Ce certificat serveur a été révoqué
• Ce certificat serveur a expiré

Ce que la question 1(2) demande d’écrire, ce sont les deux premiers éléments ci-dessus (c et d, 40 caractères ou moins chacun, dans n’importe quel ordre). Les items révocation et expiration sont donnés dans l’énoncé dès le départ.²

sequenceDiagram
    autonumber
    participant U as PC professionnel de l'employé
    participant F as Faux AP et faux site<br/>(attaquant)
    participant B as Service B (authentique)

    Note over F: Dresse un AP avec le même SSID et<br/>la même clé pré-partagée que le LAN sans fil invité
    U->>F: Se connecte par erreur au faux AP
    Note over F: Falsifie le DNS pour pointer le nom de domaine<br/>du service B vers le faux site
    U->>F: Se connecte à l'URL du service B en HTTPS
    F-->>U: Certificat serveur du faux site
    Note over U: La validation échoue<br/>- Non émis par une autorité de certification de confiance<br/>- Le nom de serveur du certificat diffère de la destination
    Note over U: Affiche une erreur indiquant que la connexion n'est pas sécurisée<br/>L'écran de connexion n'est jamais affiché
    Note over U,B: Il n'y a d'emblée aucune communication avec<br/>le véritable service B

Figure 2 : Même après une connexion au faux AP, la validation du certificat serveur HTTPS demeure. Authentifier le LAN sans fil et confirmer le site atteint sont des étapes distinctes.

3.3. Ne pas s’arrêter à « erreur de certificat » — dire ce qui a été validé

Avec un certificat auto-signé, la chaîne ne peut pas être remontée jusqu’à une racine de confiance. Même si l’attaquant obtient légitimement un certificat pour son propre domaine (b-service.example.net, par exemple), il ne correspondra pas au nom de domaine du service B. Sous les prémisses de la question, l’attaquant ne contrôle pas le domaine du service B et ne peut donc pas obtenir un certificat légitime pour ce nom, et c’est le fondement de la réponse.

La validation du chemin de certification est décrite dans RFC 5280 et la correspondance des noms dans RFC 6125.³⁴

Le commentaire de notation de l’IPA dit ce qui suit à propos de la question 1(2).⁵

Le taux de bonnes réponses à la question 1(2) était faible. Même si un attaquant prépare un faux site, la validation du certificat serveur échoue tant que l’accès se fait en HTTPS. Valider un certificat serveur est une connaissance de base pour sécuriser les communications, aussi souhaitons-nous que les candidats la comprennent bien, jusqu’aux éléments précisément validés.

Ce qui est demandé n’est pas seulement le résultat « une erreur s’affiche », mais si l’on peut nommer spécifiquement l’émetteur et le nom. En pratique, toutefois, l’implémentation de la vérification de révocation et le magasin de confiance de l’appareil doivent aussi être vérifiés. Le point que les quatre éléments n’agissent pas toujours avec la même certitude est traité aux sections 10.1 et 10.2.

4. Question 1(3) — HSTS réécrit HTTP en HTTPS avant l’envoi

4.1. La réponse va de « réécrire » à « recevoir le certificat »

La sous-question demande, en 60 caractères ou moins, comment le navigateur se comporte jusqu’à juste avant l’affichage de l’erreur lorsqu’un employé connecté au faux AP saisit par erreur l’URL du service B en http://.

Réponse modèle : « Il remplace l’accès HTTP par un accès HTTPS et se connecte. Il reçoit ensuite un certificat serveur du faux site. »²

HSTS (HTTP Strict Transport Security) est un mécanisme par lequel le navigateur mémorise un en-tête Strict-Transport-Security reçu en HTTPS et, dès lors, se connecte à cet hôte en HTTPS. Il est spécifié dans RFC 6797.⁶

L’accès à un hôte HSTS connu se déroule dans l’ordre suivant.

1. Dans le navigateur, le schéma de l’URL est remplacé de http par https. Si le port 80 était indiqué explicitement, il est converti en 443.
2. Il se connecte en HTTPS. Dans cette question, toutefois, le DNS a été falsifié, donc la destination est le faux site.
3. Il reçoit un certificat serveur du faux site.
4. La validation du certificat échoue, produisant l’erreur du chapitre 3.

Il ne s’agit pas d’envoyer une requête HTTP en clair puis de basculer. Le remplacement est achevé avant que quoi que ce soit ne sorte sur le réseau. Comme la sous-question ne demande que ce qui se passe jusqu’à juste avant l’erreur, la réponse modèle ne décrit que jusqu’à l’étape 3.

4.2. HSTS a aussi pour rôle de ne pas laisser ignorer l’avertissement et continuer

La section 8.4 de RFC 6797 exige que, si une erreur survient lors de l’établissement d’un transport sécurisé avec un hôte HSTS connu, la connexion soit interrompue, que l’erreur soit un avertissement ou fatale. La section 12.1 décrit cela comme « No User Recourse ».⁶

Pour une erreur de certificat ordinaire, la plupart des navigateurs offrent un chemin via « Avancé » et « Continuer ». Pour un hôte où HSTS est actif, cette échappatoire ne doit pas être proposée à l’utilisateur. Couper le réflexe de cliquer tout de suite à travers une erreur de certificat est ce qui compte comme défense contre les faux sites.

4.3. La prémisse est que le navigateur détient un enregistrement HSTS valide

Le fait que HSTS soit configuré sur le site ne protège pas à lui seul le premier accès depuis chaque appareil. Normalement, le navigateur doit avoir atteint le site authentique en HTTPS et reçu l’en-tête.

L’enregistrement est indisponible pour le premier accès depuis un nouveau PC professionnel, lorsqu’il a été effacé avec un profil de navigateur reconstruit ou des données de navigation vidées, ou lorsque le max-age de l’enregistrement a expiré. Ce qui comble le premier accès, c’est la liste de préchargement HSTS du navigateur. Les exigences d’inscription et la difficulté du retrait sont expliquées à la section 10.3.

5. Question 2(1) — même la fonction de partage légitime devient une voie d’exfiltration si personne ne vérifie le destinataire

5.1. Le fondement de la réponse est que les responsables ne vérifient pas le destinataire

À partir d’ici, le sujet est un employé titulaire d’un identifiant légitime. La question 2(1) demande, en 40 caractères ou moins, comment la fonction de partage peut être détournée pour qu’un fichier devienne téléchargeable depuis l’extérieur de l’entreprise M.

Réponse modèle : « Indiquer l’adresse e-mail personnelle de l’employé comme adresse e-mail du destinataire externe. »²

Le service B a une approbation du responsable, et le lien de partage n’est divulgué ni au demandeur ni au responsable. Il y a aussi une chaîne difficile à deviner et une expiration d’un jour. Même ainsi, faire du destinataire sa propre adresse personnelle signifie que l’on reçoit soi-même le lien en tant que destinataire externe. Il n’est pas besoin de deviner le lien ni de joindre un fichier à un e-mail depuis le PC professionnel.

Dans l’énoncé, M. Y répond qu’il y a des responsables qui ne vérifient pas l’adresse e-mail du destinataire ni le fichier. Ce qui manque n’est pas le mécanisme d’approbation lui-même, mais la prémisse opérationnelle que l’approbateur vérifie le destinataire.

5.2. L’existence de l’approbation et le contrôle de son contenu sont des questions distinctes

Un workflow d’approbation suppose que l’approbateur regarde ce qui est approuvé. Si personne ne regarde, cela cesse d’être un mécanisme pour bloquer un partage inapproprié et devient une voie de livraison du lien.

En pratique, le nombre d’approbations, le matériau avec lequel l’approbateur juge, les délais métier et la revue a posteriori des résultats d’approbation se conçoivent ensemble. Un tableau de revue concret est donné à la section 10.4.

6. Question 2(2) — un PC personnel atteint le service B depuis la salle de réunion

6.1. Ce que les deux partagent, c’est de ne pas utiliser le PC professionnel

Apporter un PC personnel n’était interdit que dans l’espace de bureaux ; on peut l’apporter dans la salle de réunion. Les méthodes 1 et 2 de l’énoncé sont toutes deux des voies qui téléchargent les fichiers sur un PC personnel et emportent le PC lui-même.

La destination du téléchargement échappe au contrôle du logiciel de prévention des fuites. Interdire les clés USB et l’enregistrement local sur le PC professionnel n’a aucun effet sur cette voie.

6.2. Question 2(2) : ce qui est modifié est l’adresse MAC

Réponse modèle : le blanc e est « adresse MAC ».²

Dans la méthode 1, l’adresse MAC de l’interface sans fil du PC personnel est changée pour celle d’un PC professionnel. Comme l’employé est utilisateur d’un PC professionnel, il est en position de connaître la clé pré-partagée. Une adresse MAC peut de même être changée dans les paramètres de l’appareil ou les propriétés du pilote, et comme elle n’est pas chiffrée dans les trames du LAN sans fil, les recevoir à proximité suffit à connaître une adresse enregistrée.

Masquer le SSID n’est pas non plus une contre-mesure contre l’apprentissage du SSID à partir de l’échange qui a lieu lorsqu’un appareil se connecte. Le filtrage par adresse MAC et un SSID masqué peuvent servir de rangement qui réduit les connexions accidentelles, mais ce ne sont pas un mécanisme pour authentifier quelqu’un qui se connecte volontairement.

6.3. La méthode 2 consiste simplement à se connecter au LAN sans fil invité

En utilisant la clé pré-partagée remise aux visiteurs, un employé aussi peut connecter un PC personnel au LAN sans fil invité. Il ne reste plus qu’à se connecter au service B avec son propre identifiant et à télécharger.

Pourquoi la restriction « seulement depuis l’adresse IP globale de l’entreprise M » laisse-t-elle passer ? La réponse est dans la configuration NAT du pare-feu.

L’adresse IP source que voit le service B est la même dans tous les cas. Cette configuration à elle seule ne peut pas distinguer un PC professionnel sur le LAN des employés d’un PC personnel sur le LAN invité.

Une restriction par adresse IP source n’autorise pas un appareil, mais tout ce qui partage ce point de sortie. Cela ne dit pas que la restriction est inutile ; il faut savoir ce qu’elle autorise réellement et la superposer à l’authentification d’appareil et à l’authentification d’utilisateur. Des exemples pratiques sont donnés à la section 10.5, et les contre-mesures de la question aux chapitres 8 et 9.

7. Questions 3(1) à 3(4) — EAP-TLS et le TPM limitent les appareils qui peuvent se connecter

7.1. Question 3(1) : entre l’AP et le serveur d’authentification, c’est RADIUS

Comme contre-mesure à la méthode 1, le LAN sans fil des employés passe à EAP-TLS et un serveur d’authentification est mis en place. La question 3(1) demande le protocole sur UDP que le serveur d’authentification utilise avec EAP, et la réponse modèle est « RADIUS ».²

Entre le PC professionnel et l’AP, c’est IEEE 802.1X (EAP over LAN) ; entre l’AP et le serveur d’authentification, c’est RADIUS. RADIUS est spécifié dans RFC 2865 et la procédure EAP-TLS dans RFC 5216. Lorsque le serveur d’authentification est construit sur Windows Server, Network Policy Server (NPS) tient ce rôle.⁷⁸⁹

Dans la dernière ligne du tableau, ce contre quoi le client valide un certificat, c’est le serveur d’authentification, pas l’AP. Configurer côté client quelle autorité de certification et quel nom de serveur faire confiance fait partie de la prémisse ; choisir EAP-TLS ne suffit pas à soi seul. La section 10.6 entre dans le détail.

7.2. Question 3(2) : ce qui est protégé est la clé privée, pas la clé publique

Un serveur d’AC est nouvellement installé pour émettre des certificats clients, et ils sont placés sur les PC professionnels par la fonction du serveur d’annuaire plutôt qu’à la main par les employés. Le blanc f est ce qui correspond à ce certificat et est protégé par le TPM, et la réponse modèle est « clé privée ».²

La clé publique est contenue dans le certificat et est une information que l’on peut remettre à l’autre côté. Ce que l’authentification prouve, c’est la possession de la clé privée correspondante. La possession se montre en signant avec cette clé, donc si la clé privée est dupliquée, un autre appareil peut utiliser le même identifiant.

Le commentaire de notation de l’IPA souligne aussi l’importance de distinguer la clé privée des autres éléments.⁵

Le taux de bonnes réponses à la question 3(2) était assez élevé, mais on a vu des réponses telles que « clé publique » et « certificat serveur ». La PKI est une technologie importante qui sous-tend un large éventail de technologies de sécurité, aussi souhaitons-nous que les candidats comprennent bien où et comment elle est utilisée.

7.3. Question 3(3) : la stocker dans le TPM pour qu’elle ne puisse pas être extraite du PC professionnel

Le blanc g demande, en 20 caractères ou moins, le but du stockage dans le TPM. La réponse modèle est « pour qu’elle ne puisse pas être extraite du PC professionnel ».²

Si la clé privée est laissée sur l’appareil sous forme de fichier, c’est une donnée que l’on peut copier. Copiez-la sur un PC personnel et ce PC passe l’authentification comme un PC professionnel. On croit avoir fermé la méthode 1 (usurpation d’adresse MAC), mais elle est simplement remplacée par une « usurpation de certificat ».

Le TPM peut générer une clé à l’intérieur de lui-même et la détenir dans un état où elle ne peut pas être extraite. Les opérations telles que la signature s’exécutent dans le TPM, et la clé elle-même n’est remise ni au système d’exploitation, ni aux applications, ni à un logiciel malveillant. Le résultat est que la clé privée est épinglée à un seul composant physique dans une seule machine.

Pour l’implémenter sous Windows, spécifiez Microsoft Platform Crypto Provider comme fournisseur de stockage de clés (KSP) dans le modèle de certificat. Ce fournisseur protège les clés à l’aide du TPM, et il ne peut pas être sélectionné tant que « Allow private key to be exported » est coché dans le modèle de certificat¹⁰. C’est la contrainte évidente : il n’y a aucun intérêt à protéger une clé que l’on peut exporter de toute façon.

Le rôle du TPM en tant que composant est traité sous l’angle du chiffrement de disque dans le guide pratique de BitLocker. L’idée de ne jamais laisser une clé privée quitter l’appareil est la même pensée que derrière la conception de l’authenticator expliquée dans Pourquoi les passkeys sont-elles sûres ?.

7.4. Question 3(4) : expliquer ensemble la cible de distribution et la protection de la clé

Cette sous-question demande, en 40 caractères ou moins, pourquoi M. S a répondu qu’il n’y avait pas de problème si cette méthode de stockage était utilisée.

Réponse modèle : « Parce que les identifiants qu’exige EAP-TLS ne peuvent être stockés que sur un PC professionnel. »²

Le raisonnement est le suivant.

1. Les certificats clients sont distribués depuis le serveur d’annuaire vers les PC professionnels et ne passent jamais par les mains des employés.
2. La clé privée correspondante est protégée par le TPM de sorte qu’elle ne puisse pas être extraite du PC professionnel.
3. Comme les identifiants ne peuvent pas être déplacés vers un PC personnel, usurper une adresse MAC ne passera pas l’authentification EAP-TLS.

Ce qui compte, c’est la condition « si cette méthode de stockage est utilisée ». Remettez la clé privée comme un fichier copiable et la même conclusion ne tient plus. En revanche, ce que le TPM arrête, c’est la duplication de la clé ; emporter l’appareil lui-même, l’usurpation de l’utilisateur et un logiciel malveillant sur l’appareil sont des problèmes distincts. La section 10.7 expose les limites.

8. Question 3(5) — changer la sortie NAT pour le LAN sans fil invité seulement

Deux propositions répondent à la méthode 2 : changer la configuration NAT, et séparer le réseau invité sur un autre service de LAN sans fil (service D).

La question 3(5) demande, en 70 caractères ou moins, ce qu’il faut changer dans la configuration NAT. L’essentiel de la réponse modèle est de « faire de l’adresse IP source utilisée pour accéder à Internet depuis le LAN sans fil invité une adresse IP autre que l’adresse IP globale actuellement utilisée ». L’énoncé désigne l’adresse actuelle par a1.b1.c1.d1.²

Ce n’est pas un changement de la restriction d’adresse IP côté service B. Seul le LAN sans fil invité est traduit vers une autre adresse IP globale, ce qui le sort du périmètre autorisé existant.

Ce qui rend cette proposition possible, c’est que le masque de sous-réseau côté WAN du pare-feu de la question est 255.255.255.248 (/29), donc plus d’une adresse IP globale est disponible. La même proposition est-elle disponible en pratique dépend du contrat de ligne ; s’il n’y a qu’une adresse IP globale, cette proposition est hors jeu. Dans ce cas, considérez la proposition d’isolement du chapitre suivant.

9. Questions 3(6) et 3(7) — isoler le réseau invité et supprimer aussi l’ancienne configuration

9.1. Ce qui a été adopté, c’est le service D, qui va directement sur Internet par une SIM

Ce que l’entreprise M a finalement choisi, c’est le service D. Un routeur D en location est placé dans la salle de réunion, avec ses fonctions de serveur DHCP et de serveur cache DNS activées. Les appareils apportés par les visiteurs se connectent à Internet par la SIM du routeur D sans passer par le réseau de l’entreprise M. Le projecteur est aussi changé pour se connecter par un câble HDMI plutôt que par le LAN sans fil invité.

flowchart LR
    subgraph M["Réseau interne de l'entreprise M (après les contre-mesures)"]
        direction TB
        E["LAN sans fil des employés<br/>EAP-TLS + RADIUS<br/>clé privée dans le TPM"]
        S["Réseau serveurs"]
        FW["FW"]
        E --> FW
        S --> FW
    end
    subgraph K["Salle de réunion"]
        T["Appareils apportés par les visiteurs"]
        D["Routeur D<br/>directement sur Internet par une SIM"]
        T --> D
    end
    FW --> B["Service B"]
    D --> I["Internet"]

Figure 3 : Schéma simplifié de la configuration après les contre-mesures. Le côté employés renforce l’authentification d’appareil, et le côté invité est séparé sur une voie qui n’utilise pas la même sortie que l’entreprise M.

9.2. Question 3(6) : la destination devenue inutile est le serveur DNS

La sous-question demande lesquels des serveurs de l’entreprise M les appareils des visiteurs cessent d’utiliser : le serveur DHCP, et le serveur du blanc h. La réponse modèle est « DNS ».²

Parce que le routeur D fournit lui-même les deux fonctions, les appareils des visiteurs n’ont plus besoin de parler aux serveurs DHCP et DNS du réseau serveurs de l’entreprise M.

9.3. Question 3(7) : item 1 du tableau 3, et items 1 et 4 du tableau 4

La sous-question demande de lister tous les numéros d’item à supprimer de chacun des paramètres d’interface VLAN du pare-feu et de ses paramètres de filtrage.²

La configuration du SSID invité est aussi supprimée de l’AP. Notez toutefois que les numéros d’item à écrire pour la question 3(7) sont ceux des tableaux 3 et 4 ci-dessus. Ne les confondez pas avec la suppression du SSID sur l’AP.

Le commentaire de notation de l’IPA dit ce qui suit à propos de la question 3(7).⁵

Le taux de bonnes réponses à la question 3(7) était élevé. Répondre exigeait de comprendre l’ensemble des paramètres de filtrage du pare-feu et l’impact de la revue de l’environnement LAN sans fil, et cela a été compris de façon appropriée.

Le pare-feu de cette question évalue les règles à partir du plus petit numéro d’item et applique la première qui correspond. Ce n’est toutefois pas une spécification commune à tous les produits. Le danger des suppressions oubliées et les différences entre schémas d’évaluation sont traités à la section 10.8.

10. Notes pratiques — ne pas généraliser telles quelles les réponses de l’examen

À partir d’ici, des points à confirmer séparément des réponses aux sous-questions elles-mêmes. Ce chapitre pose les conditions dans lesquelles certificats, HSTS et authentification d’appareil prennent effet, et les voies qui restent dans l’exploitation quotidienne.

10.1. La vérification de révocation des certificats varie en fiabilité d’un navigateur à l’autre

À ce stade, il vaut la peine de séparer la réponse d’examen du comportement réel des navigateurs. Les quatre éléments de la section 3.3 sont ce que la figure 2 de l’énoncé liste comme « le détail de l’erreur qui peut s’afficher » ; il ne faut pas les lire comme signifiant que chaque navigateur contrôle les quatre avec la même fiabilité.

L’émetteur, le nom de serveur et la date d’expiration peuvent tous se décider à partir d’informations déjà en main dès l’arrivée du certificat, donc ils sont toujours validés. Ces trois-là sont aussi ce qui arrête l’attaque dans cette question.

La seule vérification de révocation est d’une autre nature. Le fait qu’un certificat a été révoqué n’est pas écrit dans le certificat, donc d’autres informations doivent être récupérées, ce qui le rend dépendant de l’implémentation et de la configuration.

• Chrome ne fait normalement pas de vérifications OCSP ou CRL en ligne. Il distribue à la place une liste limitée appelée CRLSet, dont l’objet principal est de bloquer rapidement des certificats en urgence, et seule une partie de ce qui figure dans la liste de révocation d’une AC y entre¹¹
• Même dans les implémentations qui interrogent OCSP, une configuration qui laisse passer la connexion lorsqu’aucune réponse n’est obtenue (soft-fail) est largement utilisée

Ne faites donc pas de « si la clé privée fuit, il suffit de révoquer » le pilier de vos contre-mesures. La révocation est quelque chose qu’il faut faire, mais ce n’est pas un mécanisme garanti de prendre effet dans le navigateur de chaque utilisateur. Le raccourcissement des durées de validité des certificats ces dernières années est en partie la réponse de l’industrie au fait que la révocation n’est pas fiable. Lorsque vous soupçonnez une fuite de clé de votre côté, il faut avancer le remplacement du certificat et l’invalidation de ce que cette clé protégeait (sessions, clés API, etc.) en parallèle du dépôt de la demande de révocation.

10.2. Vérifier le contenu du magasin de confiance, et le domaine que l’utilisateur visait

Ce qui suit est hors de l’énoncé. La première ligne du tableau de la section 3.3 dépend de ce à quoi cet appareil fait confiance. La liste des émetteurs de confiance est détenue par le navigateur ou l’OS ; sous Windows, c’est le magasin de certificats Autorités de certification racines de confiance.

Autrement dit, le premier contrôle passe dans des situations comme celles-ci.

• Le certificat racine d’une autorité de certification interne (une AC privée) est distribué aux PC professionnels, et la clé privée de cette AC, ou sa procédure d’émission de certificats, a été prise par un attaquant
• Un proxy ou un produit de sécurité qui inspecte le trafic a installé son propre certificat racine sur l’appareil pour terminer TLS, et ce produit ou son exploitation a été pris par un attaquant
• Quelqu’un, dans le passé, a enregistré une exception, ou a mis un certificat auto-signé dans les racines de confiance, parce que « une erreur de certificat n’arrêtait pas d’apparaître »

Le troisième cas se voit vraiment sur le terrain : quelque chose ajouté à la main une fois pour faire disparaître l’erreur de certificat d’un système interne, et qui continue de vivre dans une image héritée du PC d’un employé parti. Le contenu du magasin Autorités de certification racines de confiance est la déclaration même de qui cet appareil croit, donc faites-en un objet d’inventaire. Décider ce qui doit aller dans quel magasin est traité dans le guide pratique du magasin de certificats Windows.

La deuxième vérification (concordance du nom de serveur) a une précaution pratique distincte. Un certificat est impuissant contre une attaque où l’utilisateur lit mal le nom de domaine. Si un attaquant enregistre un domaine confusément proche tel que b-serv1ce.example.com et obtient légitimement un certificat pour ce domaine, le navigateur n’affiche aucune erreur. Ce qu’un certificat garantit, c’est que « le nom de serveur de la destination et le nom de serveur du certificat concordent », pas que « ce nom de serveur est la partie que l’utilisateur visait ». Le mécanisme qui ne laisse pas cette dernière étape aux yeux de l’utilisateur est celui qui vérifie l’origine dans l’authenticator, comme le font les passkeys (WebAuthn). Cela est traité dans Pourquoi les passkeys sont-elles sûres ?.

10.3. Avant d’utiliser le préchargement HSTS, vérifier l’impact sur les sous-domaines et le retrait

Ce qui comble ce trou du premier accès, c’est la liste de préchargement HSTS. Si le domaine figure sur la liste intégrée d’avance dans le navigateur, HTTPS est imposé même pour un hôte jamais visité.

Si vous envisagez d’enregistrer votre propre site, toutefois, vérifiez d’abord les conditions. Les exigences d’enregistrement sont les suivantes¹².

• Servir un certificat valide
• Si l’on écoute sur le port 80, rediriger de HTTP vers HTTPS sur le même hôte
• Servir tous les sous-domaines en HTTPS (y compris www si un enregistrement DNS existe pour lui)
• Renvoyer sur le domaine de base un en-tête Strict-Transport-Security avec un max-age de 31536000 secondes (un an) ou plus, plus includeSubDomains et preload

Ce qui entre en jeu, c’est le troisième, combiné à includeSubDomains. Si un vieux sous-domaine interne n’est qu’en HTTP, ou n’a pas de certificat préparé, il devient injoignable dès l’enregistrement. Inventoriez tous les sous-domaines avant d’enregistrer.

Et le retrait n’est pas simple. Les demandes de suppression sont en général acceptées, mais il faut des mois pour que le changement atteigne les navigateurs des utilisateurs, et il n’y a pas de garantie pour les navigateurs autres que Chrome¹². Il est plus sûr d’aborder le préchargement comme un paramètre que l’on ne peut pas simplement annuler en cas d’erreur.

Vu du côté consommateur, si un service cloud utilisé pour le travail prend en charge HSTS est un point raisonnable à ajouter à la liste de sélection.

10.4. Concevoir le matériau de jugement de l’approbateur, et la revue qui suit l’approbation

Lorsque l’approbation devient une formalité en pratique, la cause est en général l’une des suivantes.

Ce qui manque surtout à l’entreprise M dans cette question, ce sont les deux derniers. Une fois un mécanisme pour accorder l’approbation en place, il faut aussi un mécanisme pour regarder ensuite ce qui a été approuvé. Pouvoir seulement lister combien de partages externes sont allés vers des domaines de messagerie gratuite dans un mois rend déjà cette technique bien plus facile à repérer.

Le tableau d’ensemble de là où une PME devrait commencer est traité dans Sécurité des PME : par où commencer ?.

10.5. Déterminer ce qu’une restriction par adresse IP source autorise, en partant du point de sortie

Ce schéma revient encore et encore hors de l’examen aussi. Une restriction par adresse IP source ne signifie pas « depuis cet appareil seulement ». Elle signifie « depuis tous ceux qui sortent par cette adresse IP globale ». Voici des cas typiques où le périmètre que l’on croit avoir autorisé et le périmètre réellement autorisé divergent.

Cela ne dit pas qu’une restriction par adresse IP source est sans intérêt. Cela dit de ne pas utiliser la restriction toute seule, comme une seule couche. Ce n’est qu’en resserrant par adresse IP, puis en superposant un mécanisme qui identifie l’appareil lui-même (un certificat client ou un certificat d’appareil) et un mécanisme qui identifie l’utilisateur (l’authentification à plusieurs facteurs) que l’on peut exprimer « cette personne, sur cet appareil ». Les contre-mesures des chapitres 7 à 9 suivent la même pensée.

10.6. En EAP-TLS, ce que l’on valide est le serveur d’authentification

La dernière ligne du tableau comparatif de la section 7.1 demande une note. En EAP-TLS, ce contre quoi le client valide un certificat, c’est le serveur d’authentification, pas l’AP. L’AP n’est qu’un authenticator qui relaie l’échange EAP ; le client ne confirme pas l’identité de l’AP lui-même.

Cela reste une protection contre l’evil twin du chapitre 3, parce que le matériau de clés généré seulement une fois l’authentification réussie n’est remis qu’à un AP légitime qui détient le secret partagé RADIUS. Un AP qu’un attaquant a dressé tout seul ne peut pas mener la procédure jusqu’au bout s’il n’a pas derrière lui un serveur d’authentification légitime. La structure est que ce que le client valide directement, c’est le serveur d’authentification, et que la légitimité de l’AP s’en déduit indirectement.

Cela vient toutefois avec une condition. Tant que le client n’est pas configuré pour savoir de quelle autorité de certification et sous quel nom de serveur il fera confiance à un certificat serveur, il ne peut pas faire la différence lorsqu’un attaquant dresse son propre serveur d’authentification. Des configurations où EAP-TLS a été déployé mais où la validation du certificat serveur est désactivée dans le profil client existent vraiment. Une fois déployé, vérifiez jusque-là.

10.7. Le TPM ne résout ni l’abus de l’appareil lui-même ni l’authentification de l’utilisateur

D’un autre côté, mettre la clé dans le TPM ne rend pas tout sûr. Tout ce que le TPM garantit, c’est que « la clé n’est pas dupliquée sur un autre appareil ». Il ne protège pas contre ce qui suit.

• L’appareil lui-même emporté. Emporter le PC professionnel, c’est emporter le TPM avec. Les règles de l’entreprise M interdisent de sortir un PC professionnel des locaux, mais une règle et une contrainte technique sont deux choses. Le chiffrement du disque (y compris l’authentification avant le démarrage) et un processus opérationnel pour révoquer le certificat en cas de perte sont nécessaires à part
• L’usurpation de l’utilisateur. Le TPM identifie l’appareil, mais il ne garantit rien sur qui le manœuvre. L’authentification de l’utilisateur est nécessaire à part
• Un logiciel malveillant qui s’exécute sur l’appareil. La clé privée ne peut pas être lue, mais le code qui s’exécute sur cet appareil peut encore demander au TPM de signer. La duplication de la clé est empêchée, pas l’abus pendant que cet appareil est sous le contrôle de quelqu’un d’autre

10.8. Supprimer les anciennes autorisations. Vérifier le schéma d’évaluation de chaque produit de pare-feu

Le taux de bonnes réponses à cette sous-question était élevé, mais peu d’organisations vont aussi loin en pratique. Le travail pour mettre en place un nouveau mécanisme a un budget et une échéance ; le travail pour supprimer une ancienne configuration n’en a ni l’un ni l’autre. Et ce que l’on oublie de supprimer se manifeste de façons comme celles-ci.

Le pare-feu de cette question utilise le schéma d’évaluer les règles à partir du plus petit numéro d’item et d’appliquer la première qui correspond (l’énoncé le dit explicitement). Sous ce schéma, laisser une règle d’autorisation désuète près du haut revient à laisser ouvert un trou qui empêche le trafic d’atteindre jamais la règle de refus à la fin.

Ne généralisez toutefois pas ce schéma d’évaluation à tous les pare-feu. La façon de décider diffère selon le produit.

Quel que soit le schéma, le fait que laisser des autorisations inutilisées en place est dangereux ne change pas. Ce qui change, c’est pourquoi c’est dangereux et comment le corriger. Vérifiez quel schéma utilise votre propre matériel, puis ajoutez à l’inventaire périodique la question de savoir si la source et la destination existent encore.

La question du pare-feu côté hôte — comment gérer les règles entrantes dont une application métier a besoin — est traitée dans Windows Defender Firewall et les applications métier.

11. Faire correspondre les contre-mesures aux voies et revoir l’ensemble

11.1. Jusqu’où les contre-mesures existantes atteignaient-elles ?

HTTPS et HSTS arrêtent la voie vers le faux site que l’énoncé pose. Ajouter encore des restrictions d’exploitation sur le PC professionnel, en revanche, laisse en place les voies qui utilisent un appareil non géré ou la fonction de partage légitime.

11.2. Quelles voies les contre-mesures supplémentaires ferment-elles ?

Beaucoup des contre-mesures dépassées interdisent un moyen, telles que les clés USB ou les pièces jointes. La contre-mesure qui a fonctionné et les contre-mesures supplémentaires changent la voie ou la nature de l’identifiant. Bloquer les clés USB laisse l’exfiltration debout tant qu’une voie vers les fichiers reste, et allonger une clé pré-partagée ne l’empêche pas d’être un secret partagé.

12. Une liste de contrôle à appliquer à sa propre configuration

1. Pouvez-vous écrire vos contre-mesures d’exfiltration comme des voies plutôt que comme des moyens ? Au lieu d’une liste de moyens tels que clés USB, pièces jointes et webmail, dressez la liste des appareils et des réseaux qui peuvent atteindre les fichiers professionnels. Si une seule voie laisse un appareil non géré les atteindre, une interdiction du moyen sera contournée
2. Les règles d’apport et de sortie d’appareils se limitent-elles à un lieu ? « Interdiction d’apporter des appareils dans l’espace de bureaux » autorise la salle de réunion, l’accueil et les espaces partagés. Vérifiez si le zonage physique et le zonage réseau s’alignent
3. Pouvez-vous dire ce qu’une restriction par adresse IP source autorise réellement ? Comptez tout ce qui sort par cette adresse IP globale : Wi-Fi invité, réseau visiteurs, VPN intersites, passerelles d’agrégation pour le télétravail, environnements de test
4. Les identifiants du LAN sans fil sont-ils propres à chaque appareil ? Une clé pré-partagée est un secret partagé que tout le monde détient à l’identique, donc si une personne la fuit, celle de tout le monde fuit, et l’on ne peut pas non plus bloquer une seule machine
5. Comptez-vous le filtrage par adresse MAC et un SSID masqué parmi les contre-mesures ? Tous deux sont un rangement qui réduit les connexions par erreur, pas une authentification
6. La clé privée du certificat client est-elle dans un état où elle ne peut pas quitter l’appareil ? Une clé privée laissée comme fichier peut être dupliquée. Spécifiez un fournisseur de stockage de clés qui utilise le TPM, et n’autorisez pas l’exportation
7. Les clients passés à EAP-TLS valident-ils le certificat du serveur d’authentification ? Désactivez cela et la résistance à un faux serveur d’authentification est perdue
8. Les utilisateurs peuvent-ils passer une erreur de certificat serveur en cliquant sur « Continuer » ? Configurez HSTS sur vos propres sites. Ne laissez pas les erreurs de certificat des systèmes internes non corrigées et n’apprenez pas aux utilisateurs qu’une erreur est quelque chose que l’on clique pour avancer
9. Inventoriez-vous le contenu du magasin Autorités de certification racines de confiance ? Ce qui s’y trouve est précisément l’ensemble des parties à propos desquelles l’appareil déclare « un certificat émis par cette autorité compte comme authentique »
10. L’approbateur du flux d’approbation reçoit-il de quoi juger ? Et quelqu’un regarde-t-il ensuite les résultats d’approbation ? Examinez une liste périodique des partages envoyés vers des domaines externes et des adresses de messagerie gratuite
11. Supprimez-vous la configuration des voies retirées ? Interfaces VLAN, règles de filtrage, SSID, entrées de liste d’autorisation. Traitez la suppression comme le travail pour mettre quelque chose de nouveau, et donnez-lui aussi une échéance

Conclusion — écrire une liste de voies, pas une liste de contre-mesures

Si la question 1 demandait à quelle étape de quelle attaque on arrête, la question 2 demande quel périmètre une contre-mesure donnée protège.

Le logiciel de prévention des fuites va jusqu’au PC professionnel, l’interdiction d’apporter des appareils va jusqu’à l’espace de bureaux, le filtrage par adresse MAC va jusqu’à quelqu’un qui n’usurpe pas. Ce qu’une restriction par adresse IP source autorise, c’est tous ceux qui sortent par la même adresse IP globale. Vérifiez le périmètre de chaque contre-mesure individuelle et les trous aux jointures apparaissent.

L’entreprise M est une entreprise qui avançait des contre-mesures après l’incident de l’année précédente. Des trous restent non pas parce que les responsables n’ont pas assez essayé, mais parce qu’ajouter des contre-mesures une à une rend les écarts entre leurs périmètres difficiles à trouver. La façon de lire à ramener dans son propre travail est celle de M. Y et de M. S : séparer l’attaquant extérieur de l’employé, et vérifier les voies vers les fichiers une à une.

Sources et portée de la citation et du résumé

La question traitée ici est la suivante.

Source : automne 2023 (Reiwa 5), examen de spécialiste agréé en sécurité de l’information, après-midi, question 2

L’IPA indique que, sauf disposition contraire de la loi, aucune autorisation ni redevance d’usage n’est requise pour les questions d’examens passés qu’elle publie. Elle n’a toutefois pas renoncé au droit d’auteur : elle exige que la source soit indiquée sous la forme « année fiscale, session, catégorie d’examen, créneau, numéro de question, etc. », et que toute modification partielle d’une question soit indiquée comme telle¹³.

Cet article ne reproduit pas les figures et tableaux imprimés dans le fascicule tels quels. Dans la mesure nécessaire pour expliquer les mécanismes, ils sont remplacés par des schémas simplifiés et des résumés que nous avons produits. Les textes des sous-questions et les réponses modèle sont aussi traités sous forme de résumé. Le fascicule original, les réponses modèle et le commentaire de notation se téléchargent gratuitement sur les pages de l’IPA, donc il est recommandé de les lire ouverts à côté^{1 2 5}.

Tableau de recoupement du fascicule et de cet article

Domaines de conseil associés

KomuraSoft LLC prend en charge les revues de conception fondées sur une configuration existante de réseau et d’appareils, et la mise en œuvre de la distribution de certificats et de la protection des clés dans les environnements Windows.

• Conseil technique et revue de conception
• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Nous avons interdit la connexion de clés USB et l'enregistrement sur le disque local. Pourquoi peut-on encore sortir des fichiers ?

Parce que ce qui a été interdit, c'est une capacité du PC professionnel fourni par l'entreprise, pas la voie d'accès à l'endroit où se trouvent les fichiers. L'employé de cette question utilise son propre PC personnel. Sans toucher du tout au PC professionnel, il connecte ce PC personnel au LAN sans fil de la salle de réunion, se connecte au stockage cloud (service B) avec son propre identifiant, télécharge les fichiers, et repart avec le PC personnel lui-même. Les paramètres du logiciel de prévention des fuites installé sur le PC professionnel n'ont aucun effet sur un PC personnel. L'entreprise M interdisait bien d'apporter des PC personnels, mais l'interdiction ne couvrait que l'espace de bureaux ; la salle de réunion en était exclue. Bloquer les moyens un par un (clés USB, pièces jointes, webmail) laisse l'exfiltration debout tant qu'il reste une voie vers les fichiers.

Le service B était restreint de sorte que la connexion n'était possible que depuis l'adresse IP globale de l'entreprise M. Pourquoi le LAN sans fil invité passe-t-il ?

Parce que le trafic du LAN sans fil invité passe lui aussi par le NAT du même pare-feu et est traduit vers la même adresse IP globale avant de sortir vers Internet. Du point de vue du service B, l'accès depuis un PC professionnel à l'intérieur de l'entreprise et l'accès depuis un PC personnel connecté au LAN sans fil invité dans la salle de réunion apparaissent comme la même adresse IP source. On ne peut pas les distinguer. Une restriction par adresse IP source doit se comprendre comme un paramètre qui autorise non pas seulement cet appareil, mais tous ceux qui partagent ce point de sortie. Wi-Fi invité, VPN intersites, passerelles d'agrégation pour le télétravail : tout ce qui sort par la même adresse IP globale entre dans le périmètre autorisé.

Le LAN sans fil des employés avait un filtrage par adresse MAC. N'est-ce pas une contre-mesure ?

Non. Une adresse MAC peut être librement réécrite côté appareil. La méthode 1 de cette question consistait à changer l'adresse MAC de l'interface sans fil du PC personnel pour celle d'un PC professionnel enregistré, puis à se connecter. Comme les adresses MAC des trames du LAN sans fil circulent sans chiffrement, recevoir le signal à proximité suffit aussi à connaître une adresse MAC enregistrée. Il en va de même pour le masquage du SSID. Même avec la diffusion du SSID désactivée, le SSID apparaît dans l'échange qui a lieu lorsqu'un appareil se connecte. Le filtrage par adresse MAC et un SSID masqué peuvent réduire les connexions accidentelles, mais ce ne sont pas un mécanisme d'authentification qui arrête une connexion volontaire.

Même si un faux point d'accès et un faux site sont mis en place, pourquoi peut-on dire que l'employé ne sera pas trompé ?

Parce que tant que la connexion se fait en HTTPS, le faux site ne peut pas passer la validation du certificat serveur. La figure 2 de l'énoncé liste quatre éléments comme détail de l'erreur qui peut s'afficher : non émis par une autorité de certification de confiance ; le nom de serveur inscrit sur le certificat diffère de celui auquel on se connecte ; révoqué ; et expiré. L'attaquant ne peut pas obtenir un certificat légitime pour le nom de domaine du service B, donc un certificat auto-signé échoue sur le premier point, et un certificat obtenu légitimement pour le propre domaine de l'attaquant échoue sur le second. Selon le commentaire de notation de l'IPA, le taux de bonnes réponses à la sous-question portant sur ce contenu de validation était faible. Notez que les quatre éléments n'agissent pas avec la même force. Ce qui arrête l'attaque, ce sont les deux premiers (émetteur et nom) plus la date d'expiration, que les navigateurs valident toujours. La vérification de révocation, elle, dépend de l'implémentation et de la configuration. Chrome, par exemple, est conçu pour ne pas faire de vérifications OCSP ou CRL en ligne dans les circonstances normales, et utilise à la place une liste limitée appelée CRLSet dont l'objet principal est le blocage d'urgence. Ne supposez pas que révoquer un certificat garantit de le bloquer. Et si le certificat racine d'une autorité interne a été distribué aux PC professionnels, et que la clé privée de cette autorité ou sa procédure d'émission a été prise par un attaquant, le premier contrôle passe aussi.

Que se passe-t-il si l'URL est saisie par erreur en http:// ? Que fait concrètement HSTS ?

Le navigateur remplace HTTP par HTTPS avant de se connecter, donc le résultat est encore une erreur de certificat serveur. HSTS est un mécanisme par lequel le navigateur mémorise le contenu d'un en-tête reçu la dernière fois qu'il s'est connecté à ce site en HTTPS. RFC 6797 exige que, lorsqu'une URL pour l'hôte cible contient le schéma http, l'agent utilisateur le remplace par https, et convertisse le port 80 en 443 s'il était indiqué explicitement. Autrement dit, la requête HTTP en clair disparaît avant d'atteindre le réseau. Plus important encore, si la validation du certificat échoue lors d'une communication avec un hôte pour lequel HSTS est actif, la spécification exige que la connexion soit interrompue, que l'erreur soit un avertissement ou fatale. Elle indique explicitement qu'il ne faut pas proposer à l'utilisateur un choix du type cette connexion n'est pas sécurisée, continuer quand même. Cela dit, HSTS suppose que le navigateur a atteint au moins une fois le site authentique en HTTPS et a reçu l'en-tête. Il n'a aucun effet si le tout premier accès depuis un appareil neuf va directement vers un faux site. Ce qui comble ce premier accès, c'est la liste de préchargement intégrée au navigateur.

Que change le stockage de la clé privée d'un certificat client dans le TPM ?

La clé privée ne peut plus être extraite de ce PC professionnel. Une clé privée laissée sur l'appareil sous forme de fichier peut être copiée vers un PC personnel, et ce PC passe alors l'authentification comme un PC professionnel. Si la clé est générée à l'intérieur du TPM et laissée dans un état où elle ne peut pas être exportée, les opérations telles que la signature s'exécutent entièrement dans le TPM, et la clé elle-même n'est remise ni au système d'exploitation ni à un logiciel malveillant. Résultat : seuls les PC professionnels fournis par l'entreprise peuvent passer l'authentification EAP-TLS. C'est pourquoi M. S a pu dire qu'il n'y avait pas de problème si cette méthode de stockage était utilisée. Pour l'implémenter sous Windows, spécifiez Microsoft Platform Crypto Provider comme fournisseur de stockage de clés du modèle de certificat, et configurez le modèle pour ne pas autoriser l'exportation de la clé privée. Notez toutefois que tout ce que le TPM protège, c'est que la clé n'est pas dupliquée sur un autre appareil ; cela ne change pas le fait que quiconque détient l'appareil peut s'en servir. La perte ou le vol de l'appareil exige le chiffrement du disque et la révocation du certificat, préparés à part.

Que faut-il retenir de cette question pour sa propre pratique ?

Quatre choses. Premièrement, penser les contre-mesures d'exfiltration en termes de voies, pas de moyens. Bloquer les clés USB, les pièces jointes et le webmail un par un ne sert à rien s'il reste un appareil capable d'atteindre les fichiers. Deuxièmement, écrire ce qu'une restriction par adresse IP source autorise réellement. Si le Wi-Fi invité ou un VPN utilise le même point de sortie, il entre aussi dans le périmètre autorisé. Troisièmement, faire de l'authentification du LAN sans fil un identifiant par appareil. Une clé pré-partagée est un secret partagé identique pour tout le monde, donc si une personne la fuit, celle de tout le monde fuit. EAP-TLS avec des certificats clients, dans une configuration qui ne laisse jamais la clé privée sortir du TPM, fixe l'identifiant à l'appareil. Quatrièmement, supprimer la configuration dont on ne se sert plus. La dernière sous-question de ce problème demande de lister tous les paramètres d'interface VLAN et toutes les règles de filtrage du pare-feu restant après le retrait du LAN sans fil invité ; selon le commentaire de notation de l'IPA, le taux de bonnes réponses était élevé, pourtant peu d'organisations vont aussi loin en pratique.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.