Le trou comme outil de sécurité – 2, ou comment attraper l’APT « avec des appâts vivants »

(merci à Sergey G. Brester pour l'idée du titre sebres)

Chers collègues, le but de cet article est de partager l'expérience d'un test d'un an d'une nouvelle classe de solutions IDS basées sur les technologies Deception.

Afin de maintenir la cohérence logique de la présentation du matériel, j'estime qu'il est nécessaire de commencer par les prémisses. Donc le problème :

1. Les attaques ciblées constituent le type d'attaque le plus dangereux, même si leur part dans le nombre total de menaces est faible.
2. Aucun moyen efficace garanti de protection du périmètre (ou un ensemble de tels moyens) n'a encore été inventé.
3. En règle générale, les attaques ciblées se déroulent en plusieurs étapes. Le franchissement du périmètre n'est qu'une des premières étapes, qui (vous pouvez me jeter des pierres) ne cause pas beaucoup de dégâts à la « victime », à moins bien sûr qu'il s'agisse d'une attaque DEoS (Destruction de service) (crypteurs, etc. .). La véritable « douleur » commence plus tard, lorsque les ressources capturées commencent à être utilisées pour pivoter et développer une attaque « en profondeur », et nous ne l’avons pas remarqué.
4. Puisque nous commençons à subir de réelles pertes lorsque les attaquants atteignent enfin les cibles de l'attaque (serveurs d'applications, SGBD, entrepôts de données, référentiels, éléments d'infrastructure critiques), il est logique que l'une des tâches du service de sécurité de l'information soit d'interrompre les attaques avant ce triste événement. Mais pour interrompre quelque chose, il faut d’abord s’en rendre compte. Et le plus tôt sera le mieux.
5. Par conséquent, pour une gestion réussie des risques (c'est-à-dire réduire les dommages causés par des attaques ciblées), il est essentiel de disposer d'outils qui fourniront un TTD (temps de détection) minimum - le temps écoulé entre le moment de l'intrusion et le moment où l'attaque est détectée). Selon le secteur et la région, cette période est en moyenne de 99 jours aux États-Unis, de 106 jours dans la région EMEA et de 172 jours dans la région APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
6. Qu'offre le marché?
   • "Bacs à sable". Encore un contrôle préventif, qui est loin d’être idéal. Il existe de nombreuses techniques efficaces pour détecter et contourner les sandbox ou les solutions de liste blanche. Les gars du « côté obscur » ont toujours une longueur d’avance ici.
   • UEBA (systèmes de profilage des comportements et d'identification des écarts) - en théorie, peut être très efficace. Mais, à mon avis, cela se situe dans un avenir lointain. En pratique, cela reste très coûteux, peu fiable et nécessite une infrastructure informatique et de sécurité de l’information très mature et stable, qui dispose déjà de tous les outils permettant de générer des données pour l’analyse comportementale.
   • Le SIEM est un bon outil d’investigation, mais il n’est pas capable de voir et de montrer quelque chose de nouveau et d’original en temps opportun, car les règles de corrélation sont les mêmes que celles des signatures.

7. Il existe donc un besoin pour un outil qui :
   • travaillé avec succès dans des conditions d'un périmètre déjà compromis,
   • détecté les attaques réussies en temps quasi réel, quels que soient les outils et vulnérabilités utilisés,
   • ne dépendait pas des signatures/règles/scripts/politiques/profils et autres éléments statiques,
   • ne nécessitait pas de grandes quantités de données et leurs sources pour l'analyse,
   • permettrait de définir les attaques non pas comme une sorte de notation des risques résultant du travail des « meilleures mathématiques au monde, brevetées et donc fermées », qui nécessitent une enquête plus approfondie, mais pratiquement comme un événement binaire - « Oui, nous sommes attaqués » ou « Non, tout va bien »,
   • était universel, efficacement évolutif et réalisable à mettre en œuvre dans n'importe quel environnement hétérogène, quelle que soit la topologie de réseau physique et logique utilisée.

Les solutions dites de tromperie se disputent désormais le rôle d'un tel outil. C’est-à-dire des solutions basées sur le bon vieux concept des pots de miel, mais avec un niveau de mise en œuvre complètement différent. Ce sujet est définitivement à la hausse maintenant.

Selon les résultats Sommet Gartner sur la gestion de la sécurité et des risques 2017 Les solutions de tromperie sont incluses dans le TOP 3 des stratégies et outils dont l'utilisation est recommandée.

Selon le rapport TAG Cybersécurité Annuel 2017 La tromperie est l'une des principales directions de développement des solutions IDS Intrusion Detection Systems).

Toute une section de ce dernier Rapport Cisco sur l'état de la sécurité informatique, dédié au SCADA, s'appuie sur les données de l'un des leaders de ce marché, TrapX Security (Israël), dont la solution fonctionne dans notre zone de test depuis un an.

TrapX Deception Grid vous permet de chiffrer et d'exploiter les IDS massivement distribués de manière centralisée, sans augmenter la charge de licence et les exigences en matière de ressources matérielles. En fait, TrapX est un constructeur qui vous permet de créer à partir d'éléments de l'infrastructure informatique existante un grand mécanisme de détection des attaques à l'échelle de l'entreprise, une sorte d'« alarme » de réseau distribué.

Structure de la solution

Dans notre laboratoire, nous étudions et testons constamment divers nouveaux produits dans le domaine de la sécurité informatique. Actuellement, environ 50 serveurs virtuels différents sont déployés ici, y compris les composants TrapX Deception Grid.

Donc, de haut en bas :

1. TSOC (TrapX Security Operation Console) est le cerveau du système. Il s'agit de la console centrale de gestion à travers laquelle s'effectuent la configuration, le déploiement de la solution et toutes les opérations quotidiennes. Puisqu'il s'agit d'un service Web, il peut être déployé n'importe où : sur le périmètre, dans le cloud ou chez un fournisseur MSSP.
2. TrapX Appliance (TSA) est un serveur virtuel auquel nous connectons, via le port trunk, les sous-réseaux que nous souhaitons couvrir par la surveillance. De plus, tous nos capteurs réseau « vivent » ici.

   Notre laboratoire a déployé un TSA (mwsapp1), mais en réalité il pourrait y en avoir plusieurs. Cela peut être nécessaire dans les grands réseaux où il n'y a pas de connectivité L2 entre les segments (un exemple typique est « Holding et filiales » ou « Siège social et succursales de la banque ») ou si le réseau comporte des segments isolés, par exemple des systèmes de contrôle de processus automatisés. Dans chacune de ces branches/segments, vous pouvez déployer votre propre TSA et le connecter à un seul TSOC, où toutes les informations seront traitées de manière centralisée. Cette architecture vous permet de créer des systèmes de surveillance distribués sans avoir besoin de restructurer radicalement le réseau ou de perturber la segmentation existante.

   Nous pouvons également soumettre une copie du trafic sortant à la TSA via TAP/SPAN. Si nous détectons des connexions avec des botnets connus, des serveurs de commande et de contrôle ou des sessions TOR, nous recevrons également le résultat dans la console. Network Intelligence Sensor (NIS) en est responsable. Dans notre environnement, cette fonctionnalité est implémentée sur le pare-feu, nous ne l'avons donc pas utilisée ici.

3. Application Traps (Full OS) – pots de miel traditionnels basés sur des serveurs Windows. Vous n'en avez pas besoin de beaucoup, puisque l'objectif principal de ces serveurs est de fournir des services informatiques à la couche suivante de capteurs ou de détecter les attaques sur les applications métiers qui peuvent être déployées dans un environnement Windows. Nous avons un de ces serveurs installé dans notre laboratoire (FOS01)

   

4. Les pièges émulés sont le composant principal de la solution, qui nous permet, à l'aide d'une seule machine virtuelle, de créer un « champ de mines » très dense pour les attaquants et de saturer le réseau de l'entreprise, tous ses vlans, avec nos capteurs. L'attaquant voit un tel capteur, ou hôte fantôme, comme un véritable PC ou serveur Windows, serveur Linux ou autre appareil que nous décidons de lui montrer.

   
   
   Pour le bien de l'entreprise et par curiosité, nous avons déployé « une paire de chaque créature » - des PC et serveurs Windows de différentes versions, des serveurs Linux, un guichet automatique avec Windows intégré, SWIFT Web Access, une imprimante réseau, un Cisco interrupteur, une caméra IP Axis, un MacBook, un appareil PLC et même une ampoule intelligente. Il y a 13 hôtes au total. En général, le fournisseur recommande de déployer de tels capteurs à hauteur d'au moins 10 % du nombre d'hôtes réels. La barre supérieure correspond à l'espace d'adressage disponible.

   Un point très important est que chacun de ces hôtes n'est pas une machine virtuelle à part entière nécessitant des ressources et des licences. Il s'agit d'un leurre, d'une émulation, d'un processus sur le TSA, qui possède un ensemble de paramètres et une adresse IP. Par conséquent, avec l’aide d’un seul TSA, nous pouvons saturer le réseau avec des centaines de ces hôtes fantômes, qui fonctionneront comme capteurs dans le système d’alarme. C’est cette technologie qui permet d’étendre de manière rentable le concept de pot de miel à toute grande entreprise distribuée.

   Du point de vue d'un attaquant, ces hôtes sont attrayants car ils contiennent des vulnérabilités et semblent être des cibles relativement faciles. L'attaquant voit les services sur ces hôtes et peut interagir avec eux et les attaquer à l'aide d'outils et de protocoles standards (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus, etc.). Mais il est impossible d’utiliser ces hôtes pour développer une attaque ou exécuter son propre code.

5. La combinaison de ces deux technologies (FullOS et pièges émulés) nous permet d'obtenir une probabilité statistique élevée qu'un attaquant rencontre tôt ou tard un élément de notre réseau de signalisation. Mais comment s’assurer que cette probabilité soit proche de 100 % ?

   Les jetons dits Déception entrent dans la bataille. Grâce à eux, nous pouvons inclure tous les PC et serveurs existants de l'entreprise dans notre IDS distribué. Les jetons sont placés sur les vrais PC des utilisateurs. Il est important de comprendre que les tokens ne sont pas des agents qui consomment des ressources et peuvent provoquer des conflits. Les jetons sont des éléments d’information passifs, une sorte de « fil d’Ariane » pour le camp attaquant qui le conduit dans un piège. Par exemple, les lecteurs réseau mappés, les signets de faux administrateurs Web dans le navigateur et les mots de passe enregistrés pour eux, les sessions ssh/rdp/winscp enregistrées, nos pièges avec commentaires dans les fichiers hôtes, les mots de passe enregistrés en mémoire, les informations d'identification des utilisateurs inexistants, le bureau. fichiers, ouverture qui déclenchera le système, et bien plus encore. Ainsi, nous plaçons l’attaquant dans un environnement déformé, saturé de vecteurs d’attaque qui ne constituent pas réellement une menace pour nous, bien au contraire. Et il n’a aucun moyen de déterminer où l’information est vraie et où elle est fausse. Ainsi, nous garantissons non seulement une détection rapide d’une attaque, mais nous ralentissons également considérablement sa progression.

Un exemple de création d'une interruption réseau et de configuration de jetons. Interface conviviale et aucune édition manuelle des configurations, scripts, etc.

Dans notre environnement, nous avons configuré et placé un certain nombre de ces jetons sur FOS01 exécutant Windows Server 2012R2 et un PC de test exécutant Windows 7. RDP s'exécute sur ces machines et nous les « suspendons » périodiquement dans la DMZ, où un certain nombre de nos capteurs (pièges émulés) sont également affichés. Nous sommes donc confrontés à un flux constant d'incidents, naturellement pour ainsi dire.

Voici donc quelques statistiques rapides pour l’année :

56 208 – incidents enregistrés,
2 912 – hôtes sources d’attaque détectés.

Carte d'attaque interactive et cliquable

Dans le même temps, la solution ne génère pas une sorte de méga-log ou de flux d'événements, ce qui prend beaucoup de temps à comprendre. Au lieu de cela, la solution elle-même classe les événements par types et permet à l'équipe de sécurité de l'information de se concentrer principalement sur les plus dangereux - lorsqu'un attaquant tente d'activer des sessions de contrôle (interaction) ou lorsque des charges utiles binaires (infection) apparaissent dans notre trafic.

Toutes les informations sur les événements sont lisibles et présentées, à mon avis, sous une forme facile à comprendre même pour un utilisateur ayant des connaissances de base dans le domaine de la sécurité de l'information.

La plupart des incidents enregistrés sont des tentatives d'analyse de nos hôtes ou de connexions uniques.

Ou tente de forcer brutalement les mots de passe pour RDP

Mais il y a eu aussi des cas plus intéressants, notamment lorsque des attaquants ont « réussi » à deviner le mot de passe de RDP et à accéder au réseau local.

Un attaquant tente d'exécuter du code à l'aide de psexec.

L'attaquant a trouvé une session enregistrée, ce qui l'a conduit dans un piège sous la forme d'un serveur Linux. Immédiatement après la connexion, avec un ensemble de commandes prédéfinies, il a tenté de détruire tous les fichiers journaux et les variables système correspondantes.

Un attaquant tente d'effectuer une injection SQL sur un pot de miel qui imite SWIFT Web Access.

En plus de ces attaques « naturelles », nous avons également effectué un certain nombre de nos propres tests. L’un des plus révélateurs consiste à tester le temps de détection d’un ver de réseau sur un réseau. Pour ce faire, nous avons utilisé un outil de GuardiCore appelé Singe d'infection. Il s'agit d'un ver de réseau qui peut pirater Windows et Linux, mais sans aucune « charge utile ».
Nous avons déployé un centre de commande local, lancé la première instance du ver sur l'une des machines et reçu la première alerte dans la console TrapX en moins d'une minute et demie. TTD 90 secondes contre 106 jours en moyenne...

Grâce à la possibilité d'intégration avec d'autres classes de solutions, nous pouvons passer d'une simple détection rapide des menaces à une réponse automatique.

Par exemple, l'intégration avec les systèmes NAC (Network Access Control) ou avec CarbonBlack vous permettra de déconnecter automatiquement les PC compromis du réseau.

L'intégration avec les sandbox permet aux fichiers impliqués dans une attaque d'être automatiquement soumis pour analyse.

Intégration McAfee

La solution dispose également de son propre système de corrélation d’événements intégré.

Mais nous n'étions pas satisfaits de ses capacités, nous l'avons donc intégré à HP ArcSight.

Le système de ticket intégré aide le monde entier à faire face aux menaces détectées.

La solution ayant été développée « dès le départ » pour les besoins des agences gouvernementales et d'un grand segment d'entreprises, elle met naturellement en œuvre un modèle d'accès basé sur les rôles, une intégration avec AD, un système développé de rapports et de déclencheurs (alertes d'événements), une orchestration pour grandes structures de holding ou prestataires MSSP.

Au lieu d'un CV

S'il existe un tel système de surveillance qui, au sens figuré, couvre nos arrières, alors avec la compromission du périmètre, tout ne fait que commencer. Le plus important est qu’il existe une réelle opportunité de faire face aux incidents de sécurité de l’information, et non de s’occuper de leurs conséquences.

Source: habr.com