A-IPS, le chaînon manquant. GS Days Avril Eric Garreau

Transcription

1 A-IPS, le chaînon manquant GS Days Avril 2013 Eric Garreau

2 SIEM : indispensable mais pas si simple... Les SIEM permettent de détecter les attaques low profile, mais leur efficacité dépend de : l'architecture du SIEM (corrélateurs intermédiaires?) la quantité des sondes (réseau, contrôle d'intégrité, analyse de logs,...) la qualité des règles déployées sur ces sondes La période de mise au point d'un SIEM est (très) longue, et son efficacité dépend de la pertinence des règles d'analyse comportementale : règles disponibles «sur étagère» quand il s'agit de surveiller des composants standards, règles «à paramétrer» quand il s'agit de surveiller des produits spécifiques (ou non standards). À défaut de disposer des bonnes compétences pour créer des règles pertinentes adaptées aux composants non-standards, on se contente souvent d'archiver tous les logs applicatifs au cas où ils pourraient servir un jour pour un forensics... Cette présentation propose une approche différente, qui a pour but de capturer la connaissance des développeurs pour livrer un système clés en main aux équipes IT, autorisant une détection pertinente des attaques applicatives L'objectif final de ce projet est de compléter les sondes SIEM habituelles par des sondes applicatives pertinentes, capables de détecter des anomalies comportementales 2

3 Mes plus plates excuses Il n'y a aucun exploit, aucune révélation croustillante,... C'est juste de la justification de besoin, De la pure formalisation de process logiciel,... Qui a pour objectif d'augmenter la sécurité en production,... En ajoutant de l'analyse comportementale pour les applications. 3

4 Au cas où... IDS : Intrusion Detection System IPS : Intrusion Prevention System IDPS : les deux font la paire N-IDPS network H-IDPS host A-IDPS application WAF : Web Application Firewall composant qui filtre les requêtes au niveau applicatif, protégeant le serveur SIEM : Security Information and Event Management supervision / corrélation des alertes de sécurité La présentation contient quelques termes «barbares»... 4

5 Le paradoxe ou la question, c'est selon Gemalto... évoque des cartes à puce IPS... évoque un univers IT Tout d'abord, une petite parenthèse : il n'y a pas que des cartes à puces chez Gemalto 5

6 Le paradoxe ou la question, c'est selon Gemalto... évoque des cartes à puce IPS... évoque un univers IT Plan plus classique ensuite : pourquoi? quoi? comment? avec quoi? 6

7 pourquoi? petites puces, et grands serveurs Les cartes sont produites dans plusieurs formats 7

8 pourquoi? petites puces, et grands serveurs Elles offrent la fonction «coffre-fort» dans de nombreux contextes 8

9 pourquoi? petites puces, et grands serveurs? On ne voit pas le «camp de base» avec lequel les cartes communiquent 9

10 pourquoi? plus c'est complexe,... Bienvenue de l'autre côté du miroir : cloisonnement et ségrégation obligatoires 10

11 pourquoi? plus c'est complexe (bis),... Des systèmes complexes et certifiés, avec toutes sortes de capteurs «IT» 11

12 pourquoi? et plus il faut avoir les yeux partout Mais avec la limite habituelle quand il s'agit de tracer des applications spécifiques 12

13 pourquoi? le classico : agents menaçants... insider qui prend son temps pour chercher... insider qui joue avec l'application... recherche manuelle de vulnérabilités... scan automatique de vulnérabilités... fuzzing pour chercher un DoS... prise d'empreintes scan de ports ouverts Pourtant tout est prévu dès la conception du système 13

14 pourquoi?... contre parades classification des données, analyse de risques secure by design... input validation, SAST, revue de code, PLAN + BUILD t DAST, pentests, revue des risques résiduels,... firewall, VLANs NIDPS, HIDPS... SIEM/LM (analyse des logs «bruts») + SIEM, corrélateur RUN t... accès sécurisé, détecteurs, caméras Et chaque équipe d'experts apporte les bonnes réponses 14

15 pourquoi? mais il reste le problème du «qui fait quoi»... quoi? RUN? BUILD? PLAN qui? DESIGN DEV PROD Chaque étape a ses propres experts cloisonnement du savoir 15

16 pourquoi? et au final il y a un petit trou dans la raquette BUILD RUN classification des données, analyse de risques secure by design input validation, SAST, revue de code, DAST, revue des risques résiduels, pentests,... description pertinente des comportements anormaux firewall, VLANs NIDPS, HIDPS SIEM/LM (analyse des logs «bruts») analyse pertinente des événements et décision selon impact SIEM, corrélateur accès sécurisé, détecteurs, caméras La PROD pourrait détecter un «low profile» si le DEV décrivait ce qui est anormal 16

17 quoi? le besoin en image Rien de nouveau : il faut une sonde applicative qui reporte les alertes au SIEM 17

18 quoi? le besoin en image quoi? qui? Deux problèmes : «a-t-on les bonnes info?» et «qui les comprend?» 18

19 quoi? à la recherche d'un critère non intrusif, Une application validée qui fonctionne normalement n'a pas de raison de produire des logs 19

20 quoi? à la recherche d'un critère non intrusif,... try again warn Une application validée détecte et tolère les maladresses 20

21 quoi? à la recherche d'un critère non intrusif,... don't! error Une application validée détecte et bloque les requêtes invalides, et ça se voit... 21

22 quoi? à la recherche d'un critère non intrusif,... error Une application mal validée va sans doute mal réagir, mais ça va se voir... 22

23 quoi? à la recherche d'un critère non intrusif,... fatal Une application très mal validée peut aussi mourir, et on est sûr que ça va se voir... 23

24 quoi? à la recherche d'un critère non intrusif,... don't! don't!... Si une application très mal validée n'intercepte pas une mauvaise requête, elle va permettre à l'attaquant d'aller «tatonner» au niveau supérieur, où ça va aussi se voir... 24

25 quoi? à la recherche d'un critère non intrusif, Et même le pire des cas : après avoir «tatonné», l'attaquant peut enfin réussir à injecter une mauvaise requête qui va sembler normale, et retourner un leak 25

26 quoi? pas de nouvelle, bonnes nouvelles... Une application validée qui fonctionne normalement n'a pas de raison de produire des logs avec des erreurs... Un attaquant qui «tatonne» va forcément produire des logs anormaux quelque part Sans surprise, les logs applicatifs sont une mine d'or pour qui sait les lire... 26

27 quoi? qui fait quoi? sait... quoi comment qui DEV PROD Les spécialistes PROD savent (et peuvent) programmer les sondes applicatives Les spécialistes DEV savent (et peuvent) interpréter les logs spécifiques 27

28 quoi? qui fait quoi? sait... quoi comment qui DEV PROD Chercher une méthode pour donner la connaissance à l'autre équipe 28

29 quoi? Grââl à cinq pattes DEV Essayer de «capturer du savoir» des équipes de DEV dans un composant qui sera livré «clés en main» aux équipes de PROD PROD 29

30 comment? les bonnes personnes au bon moment Objectif : capturer du «savoir DEV» sans imposer un «outil de PROD» c'est faisable, puisque c'est du déjà vu... Les spécialistes DEV considèrent que la PROD n'est pas leur métier 30

31 comment? les bonnes personnes au bon moment Objectif : capturer du «savoir DEV» sans imposer un «outil PROD» c'est faisable, puisque c'est du déjà vu... il suffit d'ajouter un prérequis non fonctionnel et de décrire l'interface Les spécialistes DEV sont habitués à coder en s'appuyant sur des interfaces 31

32 comment? les bonnes personnes au bon moment Objectif : capturer du «savoir DEV» sans imposer un «outil PROD» c'est faisable, puisque c'est du déjà vu... il suffit d'ajouter un prérequis non fonctionnel et de décrire l'interface «supervisable» implémenter et valider une interface d'état (HA) Les applicatifs sont validés pour être pilotables par le système Haute Disponibilité 32

33 comment? les bonnes personnes au bon moment Objectif : capturer du «savoir DEV» sans imposer un «outil PROD» c'est faisable, puisque c'est du déjà vu... il suffit d'ajouter un prérequis non fonctionnel et de décrire l'interface «supervisable» implémenter et valider une interface d'état (HA) «monitorable» implémenter et valider des compteurs (QoS) Les applicatifs sont validés pour être «observés» par le système de monitoring 33

34 comment? les bonnes personnes au bon moment Objectif : capturer du «savoir DEV» sans imposer un «outil PROD» c'est faisable, puisque c'est du déjà vu... il suffit d'ajouter un prérequis non fonctionnel et de décrire l'interface «supervisable» implémenter et valider une interface d'état (HA) «monitorable» implémenter et valider des compteurs (QoS) «filtrable» (implémenter et) valider des règles pour un WAF Les applicatifs sont validés pour fonctionner derrière un Reverse Proxy filtrant 34

35 comment? les bonnes personnes au bon moment Objectif : capturer du «savoir DEV» sans imposer un «outil PROD» c'est faisable, puisque c'est du déjà vu... il suffit d'ajouter un prérequis non fonctionnel et de décrire l'interface «supervisable» implémenter et valider une interface d'état (HA) «monitorable» implémenter et valider des compteurs (QoS) «filtrable» (implémenter et) valider des règles pour un WAF «sécurisable» le petit nouveau Les applicatifs sont validés pour remonter des alertes comportementales au SIEM 35

36 comment? rendre à César...???????????? Chaque équipe projet utilise un format différent, et il faut partir du principe qu'il est impossible d'uniformiser les logs (l'usage de bibliothèques externes complique un peu plus les choses) 36

37 comment? rendre à César... API framework de «sécurisation»???????????? Fournir aux équipes un kit simple à installer, qui offre une API pour créer des règles, et qui contient déjà le moteur qui sait se connecter au SIEM en PROD 37

38 comment? rendre à César... API framework de «sécurisation»???????????? Les développeurs vont pouvoir valoriser leur savoir et écrire des règles pertinentes, et l'ensemble pourra être intégré à la partie «sécurité» de la campagne de validation 38

39 comment? rendre à César... API package de «sécurisation»???????????? Une fois finalisé, le «package» peut être livré clés en main à la PROD 39

40 avec quoi? small is beautiful Pack logiciel qui offre une interface standard avec le SIEM faciliter l'intégration en PROD KISS : plus c'est simple, et moins on a de dépendances limiter les risques d'incompatibilité en PROD (keep it simple and stupid) Utilisable par N++ équipes pendant la phase DEV disponibilité en dehors du contexte de PROD, i.e. sur d'autres sites pas trop cher à l'unité svp (N++ équipes de dev, valid, intégration, etc...) simple à installer et à intégrer dans une chaîne de validation Critères retenus pour le kit de sécurité 40

41 avec quoi? small is beautiful SIEM (the boss) IDMEF (RFC4765) Applications Sensors SIEM local Hardened Pare-feu OS (H/N)IPS La meilleure interface avec un SIEM est un SIEM (connexion hiérarchisée des SIEM) 41

42 avec quoi? small is beautiful (and powerful) SIEM (the boss) IDMEF (RFC4765) Applications Sensors SIEM local + Hardened Pare-feu OS (H/N)IPS corrélateur La présence d'un corrélateur permet même d'envisager un blocage comportemental 42

43 avec quoi? pré-corréler pour épargner le SIEM local logs logs sort sort filter + append + check flush ( N) La couche de persistance est un ennemi du système en cas de burst d'alertes 43

44 avec quoi? Le prototype SecBox implémenté Alert NIDS/NIPS FireWall S y n p r o x y Sensor Network Prelude SIEM Snort Correlator Sensor X Plugin X Plugin Y Plugin Z WAF Product X (gwaf) application-specific awareness HIDS/HIPS FreeBSD Hardened Operating System Applicatif retenu : le WAF (apache+mod_security+configuration spécifique) Deux sondes comportementales : «scan de vulnérabilités» et «recherche manuelle» 44

45 avec quoi? généralisation du pattern + géométrie variable X X X X OS α WAF + VHosts OS β J2EE + apps DB + instances Étapes suivantes : - projets pilotes complets (solutions nouvelles ou existantes) - validation des sondes par pentests «low profile» - généralisation du process 45

46 Merci! à Julien Vignolles, qui a réalisé le prototype «SecBox» à C.S., pour avoir remis prelude-oss à la disposition de tous eric.garreau@gemalto.com 46