lundi 10 juin 2013

Bloquer les APT: mission (im)possible - Partie 4/4

Du hack à l'APT - Partie 1/4
 Introduction : les menaces aveugles et massives du passé
 Ces menaces ont évoluées et sont devenues plus dangereuses

La cible et les 4 cavaliers de l'AP(T)ocalypse - Partie 2/4
 Une cible visée
 La stratégie d'attaque: Les 4 cavaliers de l'AP(T)ocalypse

La persistance de l'APT et l'accès aux données - Partie 3/4
 Persistance et implantation profonde
 Accès au données: espionnage et/ou destruction

Bloquer les APT: mission (im)possible - Partie 4/4
Dans la littérature fantastique le personnage du loup-garou ou du vampire revient souvent. C'est une ennemi très rapide, d'une force herculéenne, très intelligent et qui survit admirablement bien à toutes les tentatives de destruction tout en réussissant à se fondre dans la foule sans se faire reconnaître. Ce qui ressemble finalement à la menace APT. Pour les loups-garous et les vampires, il existe heureusement la fameuse "silver bullet", la balle en argent qui permet de les stopper à coup sûr.
Et contre les APT, qu'avons nous?

1/ A défaut de "silver bullet", une "kill chain"?
Disons le rapidement, il n'existe aujourd'hui pas de "silver bullet" contre les APT, à la manière dont on nous vendait l'antivirus, le firewall ou l'UTM il y a quelques années. Par contre surgit l'idée de Kill Chain, concept tiré d'un document de Lockheed Martin en 2010. Le principe en est le suivant: puisqu'une intrusion APT est une succession d'évènements, essayons de bloquer l'APT à chacun de ses pas.

Le document présente une méthode en 7 étapes pour l'attaquant, et propose 6 modes de défense pour chacune des étapes, à mettre en grille:
Je propose à mon tour une autre Kill Chain, basée sur les cheminements de l'attaquant étape après étape:
(Edit 16/06/2013 : modification kill chain)

En rouge, les actions de l'attaquant, en bleu le factuel ou la victime, et en vert les défenses possibles. Si une flèche repart du vert, c'est que la défense est contournable. Je n'ai pas voulu faire de la publicité pour un produit ou pour un autre, donc aucune entreprise n'est citée nommément.

Pour les notes:
[1] Le désarmement peut être un changement de format. Toutes les pièces jointes d'email pdf sont imprimées en jpg, puis assemblées en pdf et remis dans le mail initial. Ou il peut s'agir d'un nettoyage, i.e. aucun applet java autorisé dans les pages web et nettoyage au niveau réseau.
[2] Et un exploit kernel veut dire une exploitation mémoire (ou pas), à la manière de l'exploit au dessus.
[3] Des VM à usage unique. La VM est lancée, lit un mail, une PJ ou browse une page web, puis est détruite.
[4] Les IOC de Mandiant par exemple
[5] Les analyses réseaux internes n'existent pas, les analyses réseaux en sortie ne sont que rarement faite.
[6] L'attaquant sait qu'il sera détecté tôt ou tard et ne veut pas que l'on puisse facilement remonter à lui ou connaître ses objectifs.

Ce schéma met en exergue quatres choses. La première, c'est qu'il n'existe pas grand chose côté USB. Pourquoi il n'existe pas encore de vrai firewall pour l'USB? Actuellement, on a du tout ou rien. Ce sont des ports USB bloqués au BIOS, ou un filtrage des VendorId/deviceId uniquement. Contre le BYOD, rien. Un filtrage/conformance des trames USB à la manière des firewalls serait un gros plus. (permettant le DLP, le chiffrement à la volée, la configuration centralisée, etc..) [Voir Note 1]

Le second point concerne la cassure au niveau de l'installation du RAT. Il y a vraiment une bascule à ce niveau là. Une fois installé, on peut le détecter et essayer de faire du damage control, mais c'est trop tard. Il est donc à mon avis essentiel de pouvoir remonter le fil de l'attaque pour les diagnostiquer au plus tôt. Ces deux étapes peuvent même être menées par des équipes différentes: des personnes plantent des RAT, d'autres les exploitent.

Un troisième point concerne l'absence de "Déception" dans les défenses. Dans le monde du réseau, les honeypots ont fourni beaucoup d'information; je n'ai pas connaissance (mais je me trompe peut-être) de systèmes d'honeypot contre les APT. (on peut imaginer des faux 'high profiles' qui seront des cibles d'APT, puis des mails, des machines, des réseaux, des processus, des fichiers, etc..)

Un dernier point concerne l'envoi du contenu à la victime. Depuis 2004 on entend parler peu ou prou des mêmes méthodes: mail, page web et USB. Existe t'il un autre moyen? [Voir Note 2]

Bloquer les APT, mission (im)possible? Mission certainement difficile, mais qui demande de gros moyens, un suivi régulier et une intelligence de corrélation d'évènements, on retrouve là les travers de la fameuse "sécurité est un échec"...

2/ Et demain?
Les APT sont des menaces difficiles à contrer simplement. On peut se concentrer sur les défenses, mais on entend de plus en plus parler de l'option offensive, ou hackback. Les US à ce sujet mettent en place une communication toute entière tournée vers les hackback. Il ne se passe pas une semaine sans qu'on entende parler d'une cible américaine qui vient de se faire piller des informations vitales, que c'est scandaleux, qu'il faut réagir face à ça, qu'il est nécessaire de faire quelque chose. A mettre en relation avec les échos des piratages français qui peinent à émerger sur les sites de news en ligne.

Le hackback est-il la seule suite logique à la cyberdéfense? Je ne sais pas, mais je trouve la situation intéressante. Lorsque les APT étaient connus et réservés aux états et grandes entreprises et tout allait bien. Maintenant que les APT sont connus et disponibles à tout un chacun (disposant de moyens raisonnables), les APT sont le grand méchant loup de la sécurité informatique et les gentils pays touchés par le fléau veulent réagir durement, cf les USA qui veulent que les APT soit considérés comme des actes de guerre, permettant des réponses physiques. [Voir Note 3]

Je disais dans un de mes anciens post de blog:
-Dans quelle mesure les cyberattaques vont-elles modifier les pouvoirs de la police étatique vis à vis de l'Internet et par là même rogner sur les libertés d'Internet?
-La "police du net" restera t'elle longtemps l'apanage des sociétés privées alors que l'État est de plus en plus impliqué dans la protection de son cyberterritoire et de ses intérêts
-Est-ce la fin d'un Internet anonyme et sans frontières?
je crois que ces questions restent d'actualité

-----
[Note 1] Je n'étais pas présent au SSTIC 2013, mais il me semble qu'une des conférences a fait mention de filtres USB (?!). Je lirais les actes avec interêt :)
[Note 2] Les confs de sécurité parlent de plus en plus du hack matériel: nos machines sont-elles piégées dès leur conception? Autre chose?
[Note 3] A l'image de l'arme nucléaire? Ceux qui l'ont l'utilisent pour faire de la dissuasion, mais sont les premiers à interdire sa prolifération..

8 commentaires:

  1. Texte extrêmement pertinent notamment pour deux constats partagés qui pourtant sont de bonnes pistes pour prévenir et détecter pas mal d'attaques : l'absence de solution flexible pour gérer les medias amovibles (SAS ou autre), et la faible utilisation de solutions N-IDS - malgré une offre importante sur le powerpoint.

    L'absence d'offre existante rend délicat le travail de conviction (pour avoir des budgets, faire des essais), car ce ne sont pas des solutions "éprouvées", un vraie problème de poule et d'oeuf car les secteurs "sensibles" qui ont les moyens budgétaires sont aussi les plus réticents à utiliser des solutions non éprouvées...

    Tout témoignage / partage d'information sur ces travaux serait le bienvenu !

    RépondreSupprimer
  2. @Patrice Bock : merci pour le commentaire.
    Concernant les solutions N-IDS, quelle est leur efficacité? Ceux qui sont signature-based vont être capable de bloquer les attaques de masse, avec un temps de retard. C'est un peu le syndrome de l'antivirus, à mon avis.
    Et surtout, ceux qui les mettent en place lisent-ils les logs de ces sondes? (mais c'est un autre débat)

    RépondreSupprimer
  3. Très bon article. J'ajouterai qu'il faut sécuriser les données critiques dans des bulles de confiance, sur lesquelles il n'est pas possible de rebondir même si un poste utilisateur ou un serveur en DMZ se fait compromettre. Car comme tu le dis très bien, être sur de ne pas se prendre un RAT est une douce utopie ;-)

    RépondreSupprimer
  4. @Thibaut Gadiolet: merci
    j'ai du mal à saisir le concept de "bulles de confiance". Si les données sont déconnectées du réseau, elles ne sont pas vraiment utilisables.
    Si elles sont utilisables, elles sont accessibles, donc compromettables :)

    Et si on parle crypto comme bulle de confiance, on peut malheureusement aussi vite l'oublier, cf la conf RSA de cette année qui dit que la crypto est battue en brèche dès que les postes de travail ne sont plus de confiance, ce qui est le cas avec les APT.

    RépondreSupprimer
  5. Manque tout simplement un SIEM pour interpréter de multiples signaux faibles détectés par les différents équipements de sécurité. Différents événements, anodins quand ils sont isolés, prendront tous leurs sens une fois accolé (corrélé) ensemble. Dans le concret il faut élaborer des scénarios suffisamment large mais significatif pour espérer remonter THE APT qui vous prendra pour cible au moment opportun. Social engineering, attaque par clef USB ou encore intrusion sur mobile devrait logiquement être privilégié dans les attaques ciblées. D'ailleurs quels entreprises essaye de tracer les attaques par social engineering aujourd'hui ?

    RépondreSupprimer
  6. @Anonyme: J'aime bien l'idée du SIEM, mais je ne suis pas convaincu de son efficacité. On lui demande d'interpréter de multiples signaux faibles alors qu'on ne voit pas des signaux forts. Lors de l'attaque RSA un rapport faisait mention d'un programme appelant son C&C plus de 10000 fois par jour (!). Et c'est resté non détecté.

    Le tracking du social engineering est une idée effectivement intéressante. J'update mon schéma de KillChain dès que possible.

    RépondreSupprimer
  7. Par bulles de confiance, j'entends un périmètre restreint sur lequel tu appliques la défense en profondeur. Ex: Tes Domain Controller
    S'ils sont administrés sur un VLAN dédié, avec authent forte depuis des postes hardenés par une population rstreinte. Que tes DC sont eux-mêmes hardenés, avec un Av à jour, etc...
    Je suis d'accord avec toi que le risque 0 n'existe pas, mais de cette manière, via le cloisonement, le monitoring, la gestion des droits, les mises à jour, etc... tu parviens à un risque quasi nul.
    --> C'est le principe des bulles de confiance
    Le problème est que pour déployer ce type d'architecture c'est couteux. C'est pourquoi on ne peut souvent le faire que sur les assets critiques au détriment du reste.
    Pour moi c'est la seule manière de "défier" les attaques ciblées. Après y a l'offensif, la contre-intelligence etc... mais c'est pas près d'être légal ;-)

    RépondreSupprimer
  8. @Thibaut Gadiolet: Merci pour la précision.

    RépondreSupprimer