C&ESAR 2014 - J2

Après une demi-journée moyenne de conférence, nous voici reparti avec une présentation de l’utilisation de suricata pour la détection d’intrusion dans les systèmes industriels.

Détection d’intrusion dans les systèmes industriels

Suricata et le cas de modbus

Problématique de sécurité des systèmes industriels, et présentation de l’architecture SCADA, et des solutions de détection existante à base de superviseur SCADA de sécurité. Puis introduction d’une architecture de détection à base de sondes assez classique dans la SSI mais adapté à l’architecture des systèmes industriels. Le superviseur SCADA de sécurité permet de détecter les conséquences d’une attaque sur le système, l’IDS permet de détecter la cause de l’incident. Pour affiner la compréhension des échanges protocolaires modbus, un préprocesseur suricata à été écrit pour affiner la précision des règles, et faciliter leur écriture. La sonde à ensuite été testée en charge, et tiens très largement le volume d’échange requis. Les contributions serons bientôt intégrés dans les sources de suricata.

Sonde IDS durcie

Les sondes de sécurité posent plusieurs problèmes de sécurité, notamment du fait de la large surface d’attaque du fait du grand nombre de protocoles implémentés, et pour la performance, les sondes sont implémentées en C/C++ et la probabilité que le décodeur soit exempt de vulnérabilité est faible. Du coup une démarche de défense en profondeur va être appliqué sur les sondes pour réduire leur surface d’attaque et donc leur fonctionnalités. Afin de séparer l’administration de la remonté d’information, des VPN IPSEC sont employés, ce qui évite qu’un admin fasse fuiter sont mot de passe par erreur sur le réseau. Ensuite on durcit le système (ségrégation des droits, suppression de fonctions inutiles, patch GRSec, points de montages en lecture seule, etc…). Quand au logiciel(s) de détection, on peut les isoler entre eux, et voir les empêcher d’accéder au matériel (voir carrément lui empêcher d’accéder à la carte réseau, et le forcer à lire ses paquet autrement). Les linux containers LXC permettent d’effectuer ce cloisonnement, et un bridge pour éviter l’accès physique au réseau. Coté logs, l’IDS peut lire sa conf et écrire dans un répertoire de log spécifique avec des fichiers « virtuels » qui sont en fait des tubes nommés, ce qui reviens à avoir une diode logicielle. Coté performance, le résultat est plutôt acceptable sur un soc arm low cost: 21500 paquets par seconde. Si vous avez ce traffic sur votre réseau industriel, vous avez d’autres problèmes que la détection d’intrusion. 60% du CPU part dans le TAP logiciel.

Reconstruction de spécifications pour la détection d’intrusion web

Dans la détection d’intrusion, soit on cherche à détecter ce qui est interdit (approche par signatures) soit ce qui dévie de ce qui est autorisé (approche comportementale). Dans l’approche comportementale, la description du comportement attendue est très couteuse. Il faut donc assister au maximum cette tâche avec un mécanisme d’apprentissage, et permettre en suite l’affinage manuel de ces règles. Ici les technique de data-mining telle que le clustering et l’alignement de séquences viennent en aide à la génération des expressions régulières qui constituent les règles du WAF. Après étude, il s’avère que l’analyse de type est très efficace avec peu de données, mais la génération de règles par alignement détecte plus d’attaques, mais génère des faux positifs. Une approche hybride semble être une approche prometteuse.

Detection Analytics

Bon forcément, ça va causer « big data ». d’après l’orateur il est facile de détecter les menaces connues (et on y arrive pas forcément), pour détecter les attaques inconnues (comprenez des attaques qui matchent pas les signatures qu’on à dans nos AV/IDS), c’est beaucoup plus dur. Il est aussi possible pour l’attaquant d’exploiter schéma mental du défenseur et ses défaut. C’est pourquoi ils attaquent lorsque le réseau est le plus chargé, parce que les techniques actuelles sont vulnérables sous charge (ratio signal/bruit). L’approche consistant à stocker toutes les données et à les traiter par la suite n’est pas très efficace, beaucoup d’équipements génèrent des donnés non pertinentes quand aux problématiques de sécurité. Du coup l’analyse de ces données prend du temps, et souvent échoue à cause de la volumétrie. Les bases de données telle qu’elles existent actuellement ne sont pas adaptés à la problématique du traitement de logs volumineux. Les bases de donnés orienté colonnes (columnar) semblent adapté aux volumétries comme celles générés par DNS. Une autre solution consiste à dégager tout le traffic DNS qui correspond au fonctionnement interne de l’entreprise pour se concentrer sur les communications avec l’extérieur, dont les DNS générés dynamiquement par les algo de C&C. (zzzzZzzZZZ rien de neuf …)

Réagir après une attaque

Entre l’attaque, et l’éventuelle réponse, et l’enquête judiciaire, il y à un vide que l’orateur va tenter de combler. La première étape suite à une attaque, c’est la plainte sans laquelle l’enquête judiciaire ne peut avoir lieu. Il faut donc que l’entreprise réagisse aux attaques conformément à ces intérêts (juridiques ?). Il faut déjà distinguer entre la panne, la négligence et l’attaque. Souvent l’attaque est considérée initialement comme une panne. Il faut aussi que la legislation suive par rapport à la caractérisation de l’infraction (loi adéquate). Il faut aussi qu’il y ai une intention malveillante. En suite se pose le problème de la préservation de la preuve qui rentre en conflit avec la remise en fonction du service. Suite à l’intrusion il est intéressant d’analyser les causes, d’en tirer les conséquences et de diffuser l’information pour éviter que les attaquants puissent recycler leur mode opératoire. Les informations utiles sont sur le blog de l’orateur.

Titre trop long…

(et le plan est pas mieux…). un coup de hype cycle gartner pour indiquer que le SIEM sort du trou des illusion et une tentative d’explication sur les freins au déploiement de telles solution dans les entreprises. (omg filez moi un décodeur !!!) (buzzword overflow…). Il y à du chemin à faire avant qu’experts et décideurs parlent le même langage.

GSEC/Prelude: le SIEM de confiance

Prelude est un soft open-source de corrélation d’évènement de sécurité et de gestion de logs. Autour de ce coeur là se construit des SIEM pro, dont prelude est le moteur. Il existe aussi une version Prelude Entreprise avec tout les trucs chouettes. L’effort est donc mis sur les problématiques de visualisation de l’information qui font l’objet des développements coûteux (oui les IHM c’est compliqué à développer, et ça coute cher…). Le SIEM pour l’instant reste un outil d’expert, mais il a vocation à se démocratiser. Pour ce faire il faut standardiser les API et les formats d’échange, simplifier son déploiement et sa mise en oeuvre.

Sécurité, SIEM et Visualisation

La visualisation est une problématique ancienne permettant de donner du sens aux données. En sécurité, la visualisation est utilisée pour combler un fossé entre analyse manuelle et analyse automatique. L’analyse manuelle c’est lent, l’analyse automatique c’est bête. Les objectifs de cette visualisation sont la surveillance, l’analyse et le reporting. Lorsqu’on surveille, on veut une corrélation rapide pour réagir promptement sauf que ça passe pas à l’échelle… Bon le rendu est parfois très abscons. Pour l’analyse, les problématiques sont très différentes parce qu’on à le temps de faire des recherches, et donc on peut revenir plusieurs fois sur sa visualisation pour l’affiner et obtenir in fine l’histoire de l’attaque. (une présentation très visuelle qu’il est difficile de retranscrire textuellement). Le reporting, souvent négligé est un outil de communication permettant de raconter l’histoire de l’attaque. Nombre des outils présentés proviennent du workshop vizsec. Les sources de la présentation sont en ligne.

Conception Dynamique de réponses dynamiques non-contradictoires face à des attaques simultanés.

A partir d’un ensemble de descripteurs d’attaques décrit dans un langage de logique de 1er ordre incluant des pre/post conditions décrivant ce qui est nécessaire à chaque attaque (pré-condition), et les effets obtenus (post-condition). Il est possible lors de l’observation d’un évènement de sécurité correspondant à une attaque donnée d’obtenir par résolution des contrainte l’ensemble des scénarii d’attaques possibles. Lorsque l’état du système modélisé est mis à jour à partir des informations remontés, l’ensemble des scénarii d’attaque sont mis à jour dynamiquement.  Les attaques sont issues de la NVD avec leur scoring associé, qui en suite est pris en compte dans la génération des scénario de réponse. Il s’agit donc d’un système d’aide à la décision orienté graph d’attaque et réponses associé. (reste à savoir comment prendre en compte les 0days dans la modélisation… ).

Remédiation des chemins d’attaque logique par la simulation de topologies de systèmes d’information.

Ici les graph d’attaques sont utilisés pour modéliser les actions possibles de l’attaquant. L’objectif est d’empêcher l’attaquant d’exploiter les vulnérabilités sur les systèmes. L’approche se veut pro-active. Un graph d’attaque logique est un graph et/ou orienté à plusieurs étapes représentant l’état de l’attaquant ou les actions qu’il peut effectuer. MulVAL est un moteur de graph d’attaques open-source adapté à la modélisation et l’analyse de ce type de graph. Un chemin d’attaque est un extrait du graph d’attaque. Afin d’éviter toute explosion combinatoire, l’opérateur peut choisir le ou les chemins qui lui semblent les plus probables pour atteindre la cible. C’est un moyen de réduction de la complexité des graph d’attaque. Les préconditions sont les seuls points sur lesquels ont peut agir pour bloquer l’accès à une cible à l’attaquant dans son graph d’attaque. La protection de la cible consiste à sélectionner les remédiations qui corrigent les pré-conditions de l’attaque. La remédiation mise en œuvre peut se faire par-exemple par filtrage ou découpage topologique (défense en profondeur ?).

Architecture big-data bio-inspirée pour la détection d’anomalie.

…

Automatiser la construction de règles de corrélation: pré requis et processus

Comment détecter dans un flux d’évènements et d’alertes une attaque complexe ? La corrélation visant à réduire le nombre d’alertes et à leur donner du sens. Les règles de corrélations se forment sous forme d’un automate et d’un langage de description d’attaques. La topologie du système est bien entendu requise pour que les règles de corrélation soit pertinentes. L’inventaire du parc et des services fonctionnant sur le parc est aussi nécessaire. Enfin il faut des évènements issu de sondes de supervision. Il faut en suite représenter le scénario d’attaque: ici un arbre d’attaque dont la racine représente l’objectif. Le scénario est enrichis par les informations issus de la topologie et de l’inventaire des services qui sont les acteurs possibles du scénario. Se pose en suite la question des observateurs potentiels. Une fois déterminé qui peut détecter quoi en fonction de la topologie, on va réduire l’ensemble des messages possible issu des sondes correspondant aux actions redoutés observables. Tout ceci de façon automatique en prolog à partir du moment ou les prérequis sont remplis et décrits (topologie, inventaire et arbre d’attaque simple).