mardi 20 août 2013

Review: The practice of network security monitoring

Je suis un fidèle lecteur de Richard Bejtlich et j'avais beaucoup aimé The art of network security monitoring. C'est pourquoi j'ai sauté sur son nouveau bouquin The practice of network security monitoring.

Pour tout vous dire, je l'ai reçu samedi et fini ce soir. Finalement autant parce que j'en attendais beaucoup que parce qu'il est creux. En effet une des idées que je défends et que Richard défend également est qu'il vaut mieux connaître des techniques et des stratégies que de savoir utiliser bêtement des outils.

Et son livre en est presque l'exemple opposé. Je vais un peu détailler les chapitres. (Le sommaire complet du livre est ici.)

Partie 1 (50 pages) : 
Chapitre 1 : On en retient qu'il n'y a pas de défense parfaite et qu'il faut monitorer son réseau pour savoir ce que fait le pirate, comment il est rentré et ce qu'il a volé. La sécurité est un cercle d'amélioration continu...

Chapitre 2 :  Le NAT c'est pas cool il faut sniffer là où ce n'est pas NATé donc derrière le firewall sur chaque patte interne alors que sans NAT on aurait pu sniffer simplement sur la patte externe.

Partie 2 (60 pages) :
J'installe Security Onion en local ou en distribué (juste des options à cocher lors de l'installation).

Partie 3 (70 pages) :
Très légère introduction pleine de capture d'écran aux outils suivants : tcpdump, dumpcap et tshark, Argus et Ra, Wireshark, Xplico, NetworkMiner, Squil, Squert, Snorby, ELSA.
Vous en apprendrez largement autant en cherchant chaque nom sur Google.

Partie 4 (120 pages) :
On commence enfin à voir de la valeur ajoutée.
Chapitre 9 : En 20 pages on a plein de définitions et le fonctionnement d'un CIRT. La finalité n'est pas de remonter des alertes, mais de traiter les alertes. C'est intéressant mais beaucoup trop court à mon goût.

Chapitre 10 : Compromission d'un serveur avec scan du réseau interne. Bonne démonstration de l'utilisation de Squil, Tshark et Bro. En plus macro on voit comment suivre les sessions pour identifier les rebonds et tracer les actions du pirate.

Chapitre 11 : Compromission d'un poste utilisateur et rebond sur un autre poste de travail. Belle démonstration de ELSA et Bro

Chapitre 12 : Comment dumper automatiquement les exe des communications réseau et envoyer manuellement les hash à virustotal.
Utilisation du module ATP1 (proof of concept) qui permet de rechercher des IOC (indicators of compromise) dans les différentes traces (DNS, certificats, MD5 de fichiers).
Utilisation de la MHR (malware hash registry) de la Team Cymru. qui fait un peu comme VirusTotal mais via des requêtes DNS.

Chapitre 13 : A l'instar du NAT, les proxy font sauter la correspondance des adresses IP. Bref il vaut mieux avoir accès aux logs du proxy.
Explication du mécanisme d'Offloading qui consiste à laisser la carte réseau calculer les checksums des paquets, ce qui fait que les tcpdump générés par le système d'exploitation sont à 0x0000. Ces fichiers sont parfois ignorés par les outils d'analyse dont Bro.

Conclusion : Ca va être compliqué avec le Cloud ?!

Bref, je n'ai trouvé que le chapitre 4 à mon goût, mais du coup c'est vraiment trop court pour assouvir ma faim. Je ne peux recommander ce livre qu'aux débutants qui auraient la volonté d'installer Security Onion, mais pas aux personnes qui connaissent le sujet et qui auraient voulu y découvrir de nouvelles techniques.

Update 22/08/13 : Un post sur le blog pauldotcom confirme exactement mon avis, mais en étant plus gentil.

jeudi 15 août 2013

La gestion risque/coût au quotidien

C'est étrange comment pour économiser quelques euros on peut intuitivement faire des paris et risquer de perdre plus.

Comme tous les 2 ans j'ai emmené ma voiture au contrôle technique et j'ai hésité à faire une pré-visite dans un garage. D'un côté je sais, je sens, qu'elle roule bien. Elle n'a que 7 ans. Il y a bien un impact sur le pare-brise, mais il est net et ne devrait pas se fissurer. Puis en fait la franchise est la même pour son remplacement ou pour une injection de résine... Alors ça peut attendre.

Bref je prends le risque d'emmener ma voiture directement au contrôle technique, mais je sais que je peux au moins contrôler les feux moi-même. Et ça n'a pas raté ! J'avais un feux de position et un feux de brouillard arrière grillés... Surtout que ça peut se changer tout seul. Bref je change les ampoules, mais le feux de brouillard ne veut rien savoir. Un tour sur Internet et je découvre d'une part qu'il n'est pas contrôlé et d'autre part... qu'il n'est pas utilisé, juste décoratif (pourquoi mettre une ampoule dans l'emplacement alors ?).

Résultat OK pour le contrôle technique. Ca aurait été bête de ne pas faire ce petit contrôle juste avant :)

PS : j'ai pris une ampoule Norauto et non Philips pour gagner 5€. Là encore je prends un risque, mais d'un autre côté ils les vendent par pack de 2. J'ai une marge de manœuvre :D

Pentest sur la production ou non ?

Un nouvel appel d'offre tombe, on nous propose d'auditer un système de gestion de chèques. Il est demander de faire des tests de corruption de données. "Avez-vous des questions ? - Oui, s'agira-t-il d'un système en production ? - Tout à fait cela sera en production."

Très bien monsieur le client ! Vos désirs seront nos ordres. Il n'est évidemment pas de notre ressort de contredire le client surtout dans un appel d'offre... Mais juste juste pour rappel, ce n'est pas parce qu'on est assuré professionnellement pour ce type d'activité qu'on sera tenu responsable en cas d'incident. En effet le client est responsable de ce qu'il demande de faire sur son SI. Le pentester doit rappeler les risques et le client valide (accepte de prendre la responsabilité). Lorsqu'on veut faire un débordement de tampon, on pose la question avant le test en précisant que le service peut devenir instable et qu'il faudra peut-être le relancer par la suite. Le pentester se dégage alors de toute responsabilité si le client accepte de faire le test.

Cela étant dit, pourquoi les clients nous demandent de faire des tests en production ? Est-ce mieux ou moins bien que sur un système en pré-production ?

Je vois plusieurs raisons à ce problème :
  • On n'a pas de pré-production :)
    Une recette alors ? Euh chez le prestataire chargé du développement, mais on n'y a pas accès.
    Il y a effectivement encore beaucoup de systèmes gérés à l'arrache sans environnements de pré-production et recette. Comment font les équipes pour être sûres qu'une mise à jour fonctionnera correctement ? Ca pourrait être une vulnérabilité à mettre dans notre rapport...
    Alors faites bien une sauvegarde avant l'audit et chaque soir. Oui, il faut le rappeler... Et donnez-nous un contact à appeler si le système devient indisponible.
    Bref on bosse sur un système vivant, mais avec beaucoup de contraintes et de risques.
  • On a un système qui vient d'être livré (en production) et pas encore d'utilisateurs, donc aucun impact sur la production. Sauf qu'il est vierge... Les bases de données sont vides.
    Dans certains cas cela n'est pas gênant, mais de plus en plus de fonctions ne sont accessibles que lorsque des données sont présentes en base. Il faut demander à ce que de fausses données soient présentes ou bien une copie de la production.
    Il m'est arrivé plusieurs fois récemment de faire un pentest à la fin du développement d'un projet, avant qu'il soit mis en production. Il n'y a rien de pire que de tester un système vierge, par exemple un site de recrutement dans lequel il n'y a pas d'offre d'emplois et aucun profil de candidat... Il faut alors se palucher les modes d'emploi et découvrir le fonctionnement du site.
    Encore pire, le système était en cours de livraison. Les fonctions arrivaient les unes après les autres. Le lundi on voyait une page d'erreur avec un mot de passe en clair, puis le mardi une nouvelle partie du site apparaît à la place...
  • On a bien un système en pré-production, mais il n'est pas interfacé avec le même annuaire et avec les mêmes webservices.
    A la rigueur on peut travailler en pré-production, puis faire les tests de contournement d'authentification en production.
  • On a un système en production avec des données similaires à la production et toutes anonymisées.
    Voilà, on y est. C'est le Paradis. Sauf que j'en ai entendu parler et je ne l'ai jamais vu :)
Bref, le pentester a beaucoup de donne volonté, mais si on ne lui donne pas les bonnes conditions pour réaliser tous les tests correctement, il va éviter de faire ceux qui peuvent secouer la production comme une blind SQL injection ou alors il va rater des fonctions car elles n'étaient pas activées faute de données disponibles. Et on ne pourra pas le tenir responsable.

Alors cher client, si tu veux rentabiliser ton audit en optimisant le temps de travail des auditeurs pour qu'ils trouvent le plus possible de vulnérabilités, prépare leur un beau terrain de jeu en pré-production avec des données représentatives.

lundi 12 août 2013

Si c'est pas malheureux :-/

Bonjour M. xxx,
Nous avons été en contact en début d’année pour un poste d’ingénieur sécurité au sein de yyy.
Le process n’avait pas abouti car vous aviez préféré donner suite à une proposition de collaboration d’un de nos concurrents.
Néanmoins, j’avais vraiment apprécié nos échanges et je me permets donc de revenir vers vous aujourd’hui afin de vous demander si vous connaissez dans votre entourage des profils qui seraient susceptibles d’être intéressés par nos offres d’emploi. Ma cible première, concerne des candidats avec 3-6 ans d’expérience en sécurité réseau.
Je vous remercie beaucoup pour votre retour et pour votre aide,

Bien cordialement,

zzz | Chargée de Recrutement

------------------

J'en ai encore la larme à l'œil de cet appel en détresse. Comment transformer des candidats qui ne sont pas venus en chasseurs de tête gratuits ???
Un chasseur de tête est généralement payé entre 10 et 30% du salaire annuel du recruté alors qu'une cooptation peut aller de 300€ à 1500€.
Bref du gros foutage de gueule de SSII.