J’ai eu la chance de recevoir un eDrive SSD, le Crucial M500, en version 480 Go.  
Le descriptif et la présentation de ce modèle sont disponibles en ligne.

Tout d’abord, un peu de théorie. Si l’on souhaite utiliser un eDrive comme disque principal contenant à la fois le système d’exploitation et les données, il faut respecter deux pré-requis.  C'est-à-dire que pour déverrouiller, au démarrage de l’ordinateur, un volume contenant le système d’exploitation, il faut :

1. Un firmware UEFI 2.3.1 ; c’est le cas pour tous les systèmes certifiés Windows 8
2. Le support, par le firmware, de la commande EFI_STORAGE_SECURITY_COMMAND_PROTOCOL

Mon ordinateur portable de test est un Lenovo Twist, sur lequel j’ai monté le disque SSD Crucial M500. J’ai ensuite installé Windows 8. Avant d’activer BitLocker et afin d’être certain d’utiliser le chiffrement matériel, j’ai décidé d’appliquer un réglage très explicite :
« Ne pas utiliser le chiffrement au niveau logiciel BitLocker lorsque le chiffrement au niveau matériel n'est pas disponible. »

Pour cela, j’ai édité la stratégie de groupe locale.

• Exécuter l’éditeur de stratégie de groupe
  locale :
• Taper la combinaison de touches Win + R ;
• Entrer gpedit.msc et appuyer sur OK

• Dans l’éditeur de stratégie de groupe
  locale :
• Aller dans Configuration ordinateur > Modèles d’administration > Composants Windows > Lecteurs du système d’exploitation ;
• Ouvrir la catégorie « Configurer l'utilisation du chiffrement au niveau matériel pour les lecteurs du système d'exploitation » ;
• Décocher  « Utiliser le chiffrement au niveau logiciel BitLocker lorsque le chiffrement au niveau matériel n'est pas disponible » ;
• Cliquer sur OK 
• Appliquer la nouvelle stratégie :
  • Taper la combinaison de touches Win + R ;
  • Entrer cmd.exe et appuyer sur OK ;
  • Entrer la ligne de commande suivante et valider : gpupdate /force

Ensuite, j’ai tout simplement activé la protection BitLocker sur mon disque SSD M500, en allant dans le poste de travail, en sélectionnant le disque, clic-droit puis activer la protection
BitLocker.

La magie opère et le disque de 480 GO est instantanément chiffré avec des performances au top !!!
Pour s’en convaincre, on passe en ligne de commande « manage-bde –status », et se rend compte qu’il s’agit bien du chiffrement au niveau matériel, avec un protecteur TPM.
   
  
  

Malheureusement, mon ordinateur de test, modèle récent Lenovo Twist, ne supporte pas la commande  EFI_STORAGE_SECURITY_COMMAND_PROTOCOL.

Quand bien même j’arrive à activer instantanément le chiffrement matériel sur mon disque crucial M500, au prochain redémarrage,
le firmware n’arrive pas à déverrouiller le disque et l’ordinateur entre en mode de récupération BitLocker. Il faut alors déverrouiller manuellement le disque à l’aide d’un mot de passe de récupération BitLocker.

Heureusement, les utilisateurs n’entreront jamais dans ce cas de figure pour 2 raisons :

1. Lors du chiffrement BitLocker, l’assistant propose d’exécuter une vérification des prérequis
2. Si le chiffrement matériel n’est pas possible, alors BitLocker bascule automatiquement en mode chiffrement logiciel.
   Il est possible de modifier ce comportement à l’aide d’une stratégie de groupe GPO en décochant le paramètre Utiliser le chiffrement au niveau logiciel BitLocker
   lorsque le chiffrement au niveau matériel n'est pas disponible. (Comme détaillé au début du billet).

En conclusion, si le firmware UEFI de votre ordinateur ne dispose pas de la  commande EFI_STORAGE_SECURITY_COMMAND_PROTOCOL,  
alors votre ordinateur ne pourra pas démarrer automatiquement sur un disque eDrive avec du chiffrement matériel. Par contre,  vous pourrez tout de même l'utiliser avec le chiffrement logiciel (BitLocker en mode classique).
Si vous souhaitez absolument tirer parti du chiffrement matériel alors il faudra utiliser votre eDrive comme un volume de données  fixes.  

Merci pour votre présence lors de la session “Qu’est-ce qu’un poste de travail sécurisé ?”
Le support de présentation est disponible ici :

https://www.box.com/s/dn7akqykczu0eyjtspxl

La session que j’ai animé aux Techdays 2011, sera bientôt disponible sous la forme d’un Webcast.

En attendant, le support de présentation PowerPoint est téléchargeable ici : https://www.box.net/shared/g1mzbraurq

[03/06/2011] : Le webcast est disponible ici :
https://www.microsoft.com/france/mstechdays/showcase/player.aspx?uuid=191512a4-c210-461b-bfae-1f7292b0d426&parcours=TD11_ENJEUX_SECURITE

La cryptographie asymétrique offre trois services de sécurité :

• Authentification
• Non-répudiation
• Confidentialité

La cryptographie asymétrique manipule des bi-clefs (clef privée/clef publique).

On chiffre les données avec la clef publique ; on déchiffre les données avec la clef privée associée.
On signe un message avec sa clef privée ; on vérifie la signature avec la clef publique associée.

Néanmoins, un problème reste à régler comment s’assurer qu’un clef publique appartient bien à un utilisateur ?
Il faut passer par un acteur intermédiaire qui va certifier la clef publique.

A quoi sert une autorité de certification ?

Une autorité de certification (AC) lie une clef publique à un sujet durant une période de validité.
(Le sujet est un utilisateur, un processus ou un ordinateur).

L’assertion « ce sujet détient bien cette clef publique » se traduit par la génération d’un certificat de clef publique.
En résumé, une autorité de certification offre un niveau d’assurance sur le certificat de clef publique que l’on utilise.

Dans le monde numérique, la confiance à un prix : voir les certificats SSL de type EV.
(La fameuse barre verte qui apparait dans le navigateur)

Qu’est-ce qu’une PKI ?

Une infrastructure de gestion de clefs publiques (Public Key Infrastructure) désigne une hiérarchie d’autorité de certification.

Note : On distingue les protecteurs nécessitant une interaction utilisateur, de ceux qui déverrouillent automatiquement un lecteur.

BitLocker propose 10 protecteurs. Sauf exception, ils peuvent être combinés entre eux.

1. TPM : TPM seulement
   Ce protecteur est automatiquement configuré par l'interface utilisateur par défaut lors de l’activation de BitLocker. Le mode TPM seul ne peut pas être configuré en combinaison avec d'autres protecteurs de type TPM. Il n’est pas possible de définir plusieurs protecteurs TPM.
   
2. TPMAndStartupKey : TPM + clef de démarrage
   Une clef USB doit être présente dans l’ordinateur lors du démarrage pour déverrouiller le volume. Il n’est pas possible de définir plusieurs protecteurs TPM + clef de démarrage.
   
3. TPMAndPIN : TPM + PIN (Il s’agit du protecteur recommandé par Microsoft)
   L’utilisateur doit saisir un code PIN composé de 4 à 20 chiffres. La longueur minimale peut être augmenté via GPO ou clef dans la base de registre. Il n’est pas possible de définir plusieurs protecteurs TPM + PIN.
   
4. TPMAndPINAndStartupKey : TPM + PIN + USB
   Combine la saisie d’un code PIN au démarrage avec l'exigence d'une clef de démarrage. Cette combinaison offre un niveau de protection très avancée. Il n’est pas possible de définir plusieurs protecteurs de ce type.
   
5. StartupKey : Clef de démarrage
   Ce protecteur n’est pas accessible avec l’interface graphique. Il doit être configuré avec l’outil en ligne de commande manage-bde ou via un appel WMI. Uniquement disponible lorsqu’une puce TPM est absente du système.
   
6. RecoveryKey : Clef de récupération
   Une clef de récupération est similaire à une clef de démarrage, mais elle peut être sauvegardée dans Active Directory. De plus, une clef de démarrage et une clef de récupération sont listées sous la même dénomination comme clef externe (External Key) avec le même conteneur de fichier .BEK.
   
7. ExternalKey : Clef externe
   Une clef externe est généralement utilisable dans le scénario de déverrouillages automatique de lecteur de données fixes ou amovibles. Dans ce cas, la clef externe est stockée dans la base de registre à cet emplacement : HKLM\SYSTEM\CurrentControlSet\Control\FVEAutoUnlock\{Volume ID}
   (Cette clef est protégée lorsque le système est alimenté électriquement par une ACL qui ne permet qu'au compte SYSTEM d'y accéder). La base de registre étant stockée sur le volume du système d’exploitation qui est intégralement chiffré.
   
8. RecoveryPassword : Mot de passe de récupération
   Le mot de passe de récupération peut être enregistré dans un dossier, imprimé ou sauvegardé dans Active Directory, le tout configurable par une stratégie de groupe. Avec l’outil manage-bde ou appel WMI, il est possible de spécifier un mot de passe de récupération.
   
9. Certificate : Agent de récupération
   Ce protecteur n’est pas accessible avec l’interface graphique. Il doit être configuré avec une stratégie de groupe ou bien avec l’outil en ligne de commande manage-bde ou via un appel WMI. Le lecteur n’est accessible seulement si l’on possède la clef privée associée au certificat de clef publique.
   
10. ClearKey : Clef en clair
    Ce protecteur n’est pas listé en tant que protecteur avec l’interface graphique ou l’outil en ligne de commande manage-bde. Néanmoins ce protecteur est ajouté lorsque l’on décide de suspendre temporairement le chiffrement BitLocker sur la partition du système d’exploitation.

Il suffit d’exécuter cette ligne de commande avec des privilèges administrateur :

schtasks /create /tn "Update FEP 2010" /tr "'C:\Program Files\Microsoft Security Client\Antimalware\MpCmdRun.exe' -SignatureUpdate" /sc minute /mo 15 /rl Highest /F

1. Suspend BitLocker Protection :

manage-bde -protectors -disable %systemdrive%

2. Delete Recovery Password :

manage-bde -protectors -delete %systemdrive% -type RecoveryPassword

3. Add a new Recovery Password :

manage-bde -protectors -add %systemdrive% -RecoveryPassword

4. Backup the new Recovery Password :

manage-bde -protectors -adbackup %systemdrive% -ID KeyProtectorID

5. Enable BitLocker Protection :

manage-bde -protectors -enable %systemdrive%

En guise d’introduction : de l’authentification à l’autorisation !

Il est nécessaire de bien faire la distinction entre l’autorisation et l’authentification. L’authentification est le processus par lequel on s’assure qu’un sujet est bien celui qu’il prétend être. Le processus d’authentification peut mettre en jeu un ou plusieurs facteurs authentifiant. Lorsque l’on combine plusieurs facteurs on parle d’authentification forte. Les facteurs sont classés en trois catégories :

• Ce que l’on connait. (mots de passe)
• Ce que l’on possède. (cartes, tokens)
• Ce que l’on est. (méthodes biométriques)

L’authentification permet de s’assurer de l’identité d’un sujet, avec un degré de certitude très variable. Par exemple, une authentification reposant uniquement sur la connaissance d’un mot de passe est jugée moins sûr qu’une authentification par le biais de la prise d’empreinte de la rétine. De plus, on admettra qu’il est plus facile de voler un mot de passe qu’une caractéristique biométrique.

Le processus d’authentification est nécessaire dans la sécurité d’un système mais ne permet aucunement de restreindre ni de définir le périmètre d’action d’un sujet. L’authentification s’attache à contrôler l’accès au système et non pas l’accès aux éléments du système (logiciels et matériels). La notion d’autorisation commence à se dessiner.

Quelles sont les opérations qu’un utilisateur peut effectuer sur le système informatique ?
Comment restreindre l’accès à des données confidentielles ?

Pour répondre à ces questions, il faut avoir défini au préalable des autorisations. Les mécanismes de contrôle d’accès permettent de faire respecter la politique de sécurité mise en place. Nous allons définir le contrôle d’accès comme un mécanisme visant à protéger les ressources du système contre un accès inapproprié ou non désiré.

Les systèmes d’exploitation utilisent le contrôle d’accès afin de protéger des ressources comme les fichiers, les processus, la mémoire...

Nous allons expliquer les trois niveaux d’abstraction régissant le contrôle d’accès :

• La politique de contrôle d’accès.
• Le modèle de contrôle d’accès.
• Le mécanisme de contrôle d’accès.

La politique de contrôle d’accès

Une politique de contrôle d’accès définit les droits, les interdictions, les informations auditées ainsi que les personnes habilitées à modifier la politique de contrôle d’accès. Au sein d’une entreprise, une politique peut permettre à des partenaires d’accéder au système d’information : une politique peut s’appliquer de manière globale et être distribuée sur différents serveurs. On peut noter que chaque entreprise, chaque organisation possède sa propre politique de contrôle d’accès, ceci est dû à de nombreux facteurs comme la culture d’entreprise, la volonté d’ouverture, l’analyse de risque, la criticité du secteur, les lois en vigueur. Certaines politique d’accès seront plutôt axées sur le niveau de confidentialité des données comme pour le secteur militaire. Dans le secteur commercial, on privilégiera en premier l’intégrité des ressources. De plus, les politiques de contrôle d’accès sont par définition dynamiques. Elles s’adaptent au fil du temps en fonction des lois du marché, des normes de régulations ou bien de la stratégie de l’entreprise.

Modèle de contrôle d’accès

La politique de contrôle d’accès est une vue haute et abstraite du contrôle d’accès. Un niveau intermédiaire permettant de faire le pont entre la politique et son implémentation est le modèle de contrôle d’accès. Le modèle va permettre de supporter la politique définit. En ayant formalisé un modèle, on va pouvoir décrire les différentes propriétés de sécurité du modèle. Par exemple le modèle RBAC (Role Based Access Control) donne la possibilité de séparer les rôles qu’une personne peut endosser à un instant t. Le modèle DAC (Discretionnary Access Control) donne la possibilité au propriétaire de la ressource de gérer lui-même les autorisations. Le modèle MAC (Mandatory Access Control) quant à lui permet de garantir la confidentialité des données. Il existe ainsi différents modèles qui sont plus ou moins adaptés à la politique de sécurité de l’entreprise.

Depuis 50 ans, plusieurs modèles de contrôle d’accès ont été successivement proposés. On peut citer DAC, MAC, RBAC, TBAC, TMAC ou encore ORBAC. A chaque fois, un nouveau modèle est apparu pour répondre soit à des problématiques d’ordre militaire, soit à des problématiques du monde civil. On considère souvent que le domaine militaire nécessite un fort degré de confidentialité, tandis que les systèmes civils recherchent à garantir un niveau d’intégrité.

Le mécanisme de contrôle d’accès

Le modèle de contrôle d’accès ne définit pas de quelle manière il va être implémenté. Le modèle reste indépendant des différentes implémentations possibles. Par contre, le mécanisme de contrôle d’accès permet de réaliser la politique définit au préalable. A ce niveau, le niveau d’abstraction est faible ; la technicité est forte. Les mécanismes de contrôle d’accès peuvent être classés de nombreuses façons et ont un support réduit des politiques. En général, des attributs de sécurité sur les utilisateurs et les ressources sont conservés dans le système. Les attributs de sécurité sur les ressources peuvent être des étiquettes de sécurité ou bien des listes de contrôles d’accès. Pour déterminer si un utilisateur à la permission de faire une opération sur une ressource, le mécanisme peut par exemple vérifier que le couple identité utilisateur-opération est inclus dans la liste de contrôle d’accès de la ressource. Les mécanismes de contrôle d’accès différent selon leur habilité à fournir des rapports et à administrer les droits d’accès.

• Forefront Endpoint Protection 2010 (FEP 2010) : Gamme Entreprise
• Windows Intune Malware Protection : Gamme TPE et PME
• Microsoft Security Essentials (MSE 2.0) : Gratuit, pour les TPE et les particuliers

Néanmoins, techniquement, ces trois produits partagent le même moteur anti-malware “Microsoft Malware Protection”.
Ainsi, il est intéressant de savoir que le moteur “Microsoft Malware Protection” est administrable en ligne de commande à l’aide de “MpCmdRun.exe”.

Windows Remote Shell utilise Windows Remote Management (WinRM) qui est l’implémentation de WS-Management.
Les services WS-Management (Web Services for Management) permettent l'exécution de commandes et de scripts à distance. Les communications sont chiffrées et authentifiées, limitant ainsi les risques en matière de sécurité.

Les administrateurs peuvent utiliser l'outil de ligne de commande Windows Remote Shell pour obtenir des données de gestion (des informations, par exemple, sur des objets tels que les disques, les adaptateurs réseau, les services ou les processus) auprès d'ordinateurs locaux et distants.
Si l'ordinateur exécute une version du système d'exploitation Windows qui inclut Windows Remote Management, les données de gestion sont fournies par Windows Management Instrumentation (WMI).

L’administrateur à l’aide de Windows Remote Shell ouvre un interpréteur en ligne de commandes, puis exécute des requêtes WMI à l’aide de l’outil wmic.exe.

1. Afin d’utiliser Windows Remote Shell à distance, il est nécessaire de créer un « écouteur » sur l’ordinateur à administrer à l’aide de la commande suivante :

winrm quickconfig

2. Le texte suivant s’affiche :

WinRM n'est pas configuré pour la gestion à distance de cet ordinateur.

Les modifications suivantes doivent être effectuées :

Créez un écouteur WinRM sur https://* pour accepter les demandes de la gestion des services Web sur toutes les adresses IP de cet ordinateur.

Activez l'exception de pare-feu WinRM.

Effectuer ces modifications [o/n] ?

3. Taper la lettre o, pour terminer, le texte suivant s’affiche:

WinRM a été mis à jour pour la gestion à distance.

Écouteur WinRM créé sur https://* pour accepter les demandes de la gestion des services Web sur toutes les adresses IP de cet ordinateur.

Exception de pare-feu WinRM activée.

4. WinRM est correctement configuré et en attente de connexion distante.

5. Sur un poste Windows 7, par exemple, il faut ajouter l’adresse IP de l’ordinateur à administrer en tant qu’hôte de confiance :

winrm set winrm/config/client @{TrustedHosts="10.0.0.2"}

6. Il est alors de se connecter à l’ordinateur distant et de lancer un interpréteur de commandes :

winrs -r:https://<FQDN Serveur CORE> cmd

Note : dans cet exemple, les commandes ainsi que les résultats sont transmis en clair sur le réseau.

Lorsque WinRS est utilisé pour administrer un serveur distant, les limitations suivantes doivent être prises en compte :

• Les commandes WinRS ne peuvent être exécutées qu’à partir d’un ordinateur sous Windows Vista ou supérieur.
• Les commandes produisant des messages comme «  Press any key to continue » ne sont pas supportés.
• Pour des raisons de sécurité, veillez à utiliser uniquement WinRM avec un écouteur HTTPS.