Gérer efficacement sa surface d’exposition (Partie 2)

Dans l’article précédent Gérer efficacement sa surface d’exposition (Partie 1), nous avons utilisé l’outil Uncovery - Advanced EASM pour obtenir une vision précise de la surface d’exposition du système d’information. Les résultats ont montré 160 services exposés sur le réseau internet, à destination d’une population d’utilisateurs bien définie. Dans cet article, nous montrons comment utiliser Chimere afin de sécuriser l’intégralité de ces services, et de les faire disparaitre de la surface d’attaque, tout en les laissant accessibles aux collaborateurs.

Pour ce faire, nous utiliserons le mécanisme d’enrôlement automatique des services proposé par Chimere, puis nous connecterons le fournisseur d’identités de l’entreprise au Manager Chimere pour fournir l’accès utilisateurs à services.

Enregistrer les services sur Chimere

Depuis les résultats obtenus, voyons comment publier nos services. Dans un premier temps, nous installons l’agent de transfert Chimere au sein du SI. C’est lui qui fera le relais entre les applications à protéger et le réseau Chimere. Plusieurs architectures sont envisageables :

• Soit l’agent de transfert est installé sur chaque serveur portant une application à sécuriser (niveau de segmentation et de zero-trust optimal)
• Soit l’agent de transfert est installé sur une machine déportée qui peut atteindre les services à protéger sur le SI.

Dans notre cas, nous traitons un système d’information “à plat”, c’est à dire qui n’a pas encore de segmentations réseau (habituellement apportées par les pare-feu), et nous implémentons la deuxième solution.

Après avoir installé une machine Debian au sein du SI, nous installons l’agent de transfert via une ligne de commande :

bash

dpkg -i chimere-transfer-agent-linux-x64-2.3.0.deb

Installation de l'agent Chimere

Depuis l’interface du Manager Chimere, nous générons une nouvelle clé d’enrôlement que nous allons utiliser pour enregistrer nos services. N’oublions pas d’associer le droit de création des services sans quoi le manager refusera l’enrôlement.

Création de la clef d'enrôlement

Enfin, nous concevons le fichier de description des services. Ce fichier JSON permet d’indiquer à l’agent de transfert comment atteindre chaque service à protéger, la clé d’enrôlement à utiliser et également les groupes d’utilisateurs, et les noms de domaine à travers desquels les services seront rendus accessibles pour les utilisateurs.

Dans notre cas, les services à traiter sont en écoute sur les ports 80 et 443 à travers le réseau local sur la plage d’adresses 192.168.17.0/24.

Le fichier de description des services est conçu sur cette nomenclature:

services_description.json

{
  "registration_key": "", 
  "groups": ["all"]
  "services" : [
    {"name": "ERP", "ip_address": "192.168.17.1", "port": 80, "urls": ["erp.mycompany.com"]},
    {"name": "Documentation", "ip_address": "192.168.17.14", "port": 443, "urls": ["doc.mycompany.com"]},
    {"name": "Ressources Humaines", "ip_address": "192.168.17.27", "port": 443, "urls": ["rh.mycompany.com"]},
    ...
  ]
}

Cet extrait nous montre que les 3 services ci-dessous vont être déclarés sur le réseau Chimere :

• Un service “ERP” que l’agent peut atteindre sur le réseau local via 192.168.17.1:80 et que l’utilisateur pourra atteindre à distance via l’URL erp.mycompany.com
• Un service “Documentation“ que l’agent peut atteindre sur le réseau local via 192.168.17.14:443 et que l’utilisateur pourra atteindre à distance via l’URL doc.mycompany.com
• Un service “Ressources humaines“ que l’agent peut atteindre sur le réseau local via 192.168.17.14:443 et que l’utilisateur pourra atteindre à distance via l’URL rh.mycompany.com

Enfin, le group all indique que tous les utilisateurs enregistrés dans le manager Chimere de l’organisation peuvent atteindre ces services.

Il ne reste plus qu'à importer le fichier au sein de l’agent de transfert :

bash

chimere-service --input-file services_description.json

Chargement du fichier descriptif json

Jetons un oeil à l’interface du manager, les services ont bel et bien été déclarés et sont prêts à être atteints :

Services déclarés sur le Chimere Manager

Connecter les utilisateurs

Il ne reste plus qu'à permettre aux utilisateurs d’accéder aux services. Pour ce faire, nous partons d’une base d’utilisateurs déclarés dans Okta, et nous connectons le Manager Chimere avec le fournisseur d’identités. Dans l’interface Chimere, nous récupérons les informations à fournir à Okta, à savoir l’URL d’accès sur laquelle le fournisseur d’identité va s’authentifier, ainsi que le jeton SCIM.

Génération du token SCIM

On s’assure également que la case “jeton d’initialisation” est bien cochée, ce qui permettra au manager d’envoyer automatiquement les mails aux utilisateurs pour les inviter à rejoindre le réseau et l’organisation, puis on ajoute les utilisateurs depuis l’interface Okta :

Après 8 minutes, les 1223 utilisateurs ont été ajoutés au manager Chimere et sont prêts à accéder aux services :

Utilisateurs provisionnés dans le Chimere Manager

Depuis un poste utilisateur, essayons d’accéder aux services. Nous avons bien reçu le mail d’invitation :

Mail d'invitation pour rejoindre l'organisation

Et nous copions / collons le jeton d’initialisation dans l’agent utilisateur Chimere du poste, afin de rejoindre l’organisation, et de nous y connecter :

Ajout du token dans l'agent utilisateur

Connexion à l'organisation

C’est fait ! Nous obtenons la liste des services accessibles et il nous suffit d’ouvrir les URLs pour y accéder.

Qu’en est-il de la surface d’attaque ?

Il ne reste plus qu'à fermer l’exposition des services, puis à relancer un scan Uncovery pour s’assurer que les services ne sont plus exposés :

Rappel des services avant la "chimérisation" des services

Résultats après la "chimérisation"

En analysant les résultats, on remarque que les 160 services ont disparu d’internet. Nous avons considérablement réduit la surface d’attaque en traitant en quelques minutes l’ensemble des services à destination des collaborateurs, en les publiant à travers le réseau Chimere puis en enrôlant l’ensemble des utilisateurs pour leur fournir les accès.

Et ensuite ?

Nous avons réduit la surface d’attaque en rendant invisibles les services. Une prochaine étape pourrait être l’affinage des droits d’accès utilisateurs à applications. Lors de cette première implémentation, l’ensemble des collaborateurs de l’organisation sont en mesure d’accéder à l’intégralité des services traités. Mais cloisonner les droits d’accès et appliquer une politique de moindre privilège est facile à réaliser avec Chimere, et directement depuis le manager en :

• Créant des groupes d’utilisateurs
• Associant les utilisateurs à des groupes et les groupes à des services
• Observer la propagation et la révocation en temps réel des droits d’accès

Intéressés ? N’hésitez pas à nous contacter pour une démonstration ou inscrivez-vous à la newsletter pour ne pas manquer les prochains articles !

---

N’oubliez pas de vous inscrire à la newsletter Chimere pour ne pas manquer les prochains articles: