Close
  • Français
  • English

16/05/2014Détecter les signaux faibles des cyberattaques… ou pourquoi vous devriez analyser vos logs ! [Par Charles Ibrahim, Bull]

On l’a dit : en matière de sécurité informatique, les attaquants ont souvent un coup d’avance sur les défenseurs, et le combat est inégal ; le défenseur devant protéger des milliers de systèmes tandis que l’attaquant n’en vise qu’un.

On le sait : les recherches de pointe dans le domaine des logiciels antivirus, des firewalls de nouvelle génération, ou des systèmes de détection d’intrusion, sont tout à fait nécessaires, mais parfois insuffisantes à maintenir l’assiégeant hors du périmètre à protéger.

On le vit : résoudre une violation de sécurité avérée prend du temps. La tâche est complexe et nécessite beaucoup de ressource, de temps et d’engagements qui donnent à l’attaquant d’autant plus de latitude pour agir dans le SI.

Cependant : « un seul combat est perdu d’avance, celui auquel on renonce ». Vaclav Havel ne songeait sans doute pas en particulier aux cyberattaques, mais la puissance de sa maxime doit certes se manifester dans la persévérance des cyberdéfenseurs à parer les cyberattaques.

C’est à ce titre que nous avons voulu expliquer une technique encore peu répandue pour éloigner les menaces qui pèsent sur les systèmes informatiques : la détection des « signaux faibles » d’attaques grâce à l’analyse de logs.

Il s’agit en fait bien plus que d’une « technique » : c’est un ensemble de technologies, de métiers, de processus, œuvrant de concert à prouver les attaques passées, et analyser l’état des systèmes actuellement en fonctionnement. L’analyse de signaux faibles mène par ailleurs à l’analyse prédictive, consistant à prédire d’éventuelles tentatives d’intrusions.

Le contexte de l’analyse de logs

On appelle « log » une ligne de texte brute constituée d’un ou plusieurs couples « clé = valeur ». Ces logs sont générés par une multitude d’équipements et logiciels, de l’application Android que vous avez utilisée ce matin dans le RER au serveur Web sur lequel fonctionne votre application de gestion du personnel, en passant par le firewall de votre data center. En fait, tous les équipements informatiques produisent des logs !

Ce qui va suivre s’applique ainsi, en particulier, aux fameux « objets connectés » : compteurs électriques intelligents, appareils électroménagers, voitures… nous nous étendrons davantage sur ce sujet dans un second article, le mois prochain.

En pratique, les logs sont la preuve la plus accessible des événements qui ont lieu sur une machine, et souvent la seule, vu l’impossibilité juridique[1] ou technique d’accéder au détail des communications depuis ou vers la machine concernée.

En particulier, ils permettent de démontrer qu’une attaque :

[list style=’square’]
[list_item] a eu lieu : par exemple, enregistrement de la connexion d’un utilisateur externe à un poste d’administration, et visualisation de requêtes d’exfiltration de données. [/list_item]
[list_item] est en cours : envoi massif de requêtes mal formées et sans attendre de réponse depuis une IP à la réputation douteuse. [/list_item]
[list_item] va se produire : scan de plusieurs machines d’administration sur des ports exotiques… [/list_item]
[/list]

Les logs enregistrent non seulement la survenue d’événements directement observables, par exemple « l’utilisateur A s’est connecté à la machine M », mais permettent également, en corrélant tous ces événements, de produire des « signaux » menant à la détection de tentatives d’intrusion. Par exemple : « l’utilisateur A a échoué 100 fois à se connecter à la machine M, puis a réussi » traduirait indirectement, mais avec une forte probabilité, une attaque par force brute du compte de l’utilisateur A.

La corrélation des divers événements enregistrés dans les logs, l’analyse comportementale de profils utilisateurs donnés, l’enrichissement des logs par des ressources extérieures et la visualisation des analyses résultantes : voilà des axes stratégiques majeurs de recherche pour la détection des cyberattaques.

Analysons nos logs, certes ! Mais comment ?

Par exemple en montant un Centre de Supervision de la Sécurité (CSS – ou en anglais : Security Operations Center : SOC), capable de répondre aux exigences citées plus haut : prouver le passé, gérer le présent, prédire l’avenir. Mais comment un tel CSS serait-il capable de mener à bien des tâches si ambitieuses ? C’est ce que nous nous proposons de synthétiser dans ce qui suit.

Une vision transversale et interdisciplinaire de la menace

Avant les machines, il y a les opérateurs et analystes. De ces derniers dépendent les capacités de détection d’un CSS : mathématiques pour les lois de corrélation, développement et administration système pour la pléthore d’outils à mettre en place et à maintenir, rétro-ingénierie et tests d’intrusion sur les machines surveillées, investigation numérique pour les enquêtes suivant la détection des attaques… sans oublier des compétences transversales de gestion de projet, de rigueur et de patience, de résistance au stress, notamment en cas de crise… la variété et la complémentarité des profils qu’on trouve dans un CSS fondent son efficacité, et rendent passionnant le travail en son sein.

Puis viennent les méthodes de travail, normes mises en œuvre[2], et autres outils formels définissant le fonctionnement d’un CSS[3]. Concernant ce point, nous souhaitons insister sur une caractéristique très concrète de la gestion des incidents, bien qu’en général fort peu discutée : la segmentation de cette gestion en « niveaux ».

La plupart des organisations recrutent ainsi des profils traitant les menaces au niveau 1 (création de tickets de sécurité suite à la remontée d’alertes par les équipements de sécurité), puis d’autres profils pour le niveau 2 (corrélation des alertes précédentes afin d’en extraire des tendances et détecter les incidents passés, présents, ou futurs), et enfin de niveau 3 (recherche sur les lois de corrélation mises en œuvre, et sur les outils propres à implémenter ces lois).

Or, nous estimons que cette segmentation est nuisible à l’intérêt des salariés, faire par exemple du « niveau 1 » toute la journée étant rébarbatif à la longue. Elle est en outre très lourde, la nécessité de transmettre des alertes sur plusieurs niveaux ralentissant d’autant le processus d’analyse des logs. Elle est enfin peu efficiente, puisque la valeur ajoutée qu’apportent les analystes en cybersécurité se trouve souvent à l’interface des 3 niveaux, ainsi et surtout que dans leur conceptualisation globale du contexte de l’incident.

Traiter l’analyse de logs de façon transversale, du niveau de la prise en compte brute des logs générés par les équipements de sécurité à la recherche sur les méthodes d’analyse employées, nous paraît donc bien plus intéressant que de segmenter les tâches.

Et cela n’empêche pas de coopérer : la gestion « verticale » (aux 3 niveaux) d’un incident doit ainsi être complétée par une approche « horizontale », consistant à faire intervenir différents spécialistes à chaque niveau.

Enfin, le client n’a dans cette approche qu’un seul interlocuteur par ticket, d’où une réduction du temps de résolution de l’incident.

L’intelligence des données

« La connaissance s’acquiert par l’expérience, tout le reste n’est que de l’information. » (Albert Einstein)

Ce qui compte, c’est la corrélation ! Des logs entre eux, mais aussi et surtout des logs avec les informations extérieures, dans le but de restituer l’information la plus complète possible sur l’origine, la cible, le mobile, et le mode opératoire d’une ou plusieurs attaques. Et malgré quelques annonces, tout ou presque semble à faire dans le domaine.

Par exemple : admettons qu’une alerte d’infection soit remontée pour une machine donnée. Quelle est son adresse IP ? À quelle organisation appartient-elle ? Quelle est sa localisation, son propriétaire, la fonction de ce dernier au sein de l’organisation ? Mêmes questions pour les éventuels noms de domaines ou IP ayant émis les charges malveillantes… du renseignement sur sources (plus ou moins) ouvertes, en somme.

Par conséquent, une veille active sur les sites d’informations spécialisés, réseaux sociaux et forums de hackers, ainsi que sur les lieux de discussion des cybercriminels, peuvent fournir des signaux à même d’enrichir les signaux plus directs que constituent les logs.

En somme, un CSS se propose de réaliser rien de moins qu’une analyse des logs à la lumières des sources d’informations extérieures, et une production d’indicateurs fiables car mesurables sur les probabilités de cyberattaques passées, présentes, et à venir !

Les normes et outils de la détection

Côté normes

L’Institut Européen des Standards de Télécommunication (European Telecommunications Standards Institute – ETSI[4]), organisme de normalisation dans le domaine des télécommunications, a notamment produit des indicateurs de sécurité de l’information[5].

De façon générale, la gestion des incidents de sécurité dans les systèmes d’information est régie par la norme ISO 27035[6]. Comme tout ensemble de principes, cette norme précède sans doute notre action, mais ne la constitue pas : les modalités pratiques de la détection des Attaques Persistantes Avancées (Advanced Persistent Threats – APTs) sont par exemple loin d’y être décrites…

Détecter des attaques de façon rigoureuse est un sujet de recherche à part entière, passionnant autant que complexe. On notera plusieurs travaux sur le sujet, notamment l’ensemble CAPEC[7], STIX[8], CYBOX[9], MAEC[10], TAXII[11] du MITRE[12], visant respectivement à fournir : une liste publique des modèles d’attaques connus, un langage standardisé pour la représentation structurée de l’information sur les cyber-menaces, un langage structuré pour la description des événements « cyber », un langage pour le codage et la transmission d’informations intègres et détaillées sur les logiciels malveillants, ainsi enfin qu’un ensemble de services pour l’échange d’informations sur les cyber-menaces.

Si cet ensemble d’outils formels nous fait progresser dans les actions concrètes à mettre en œuvre pour détecter nos cyberattaques, ce n’est pas encore avec les schémas du STIX qu’on résout les intrusions de la cellule APT1[13].

Ceci nous amène à la question des outils à mettre en œuvre pour :

[list style=’square’]
[list_item] rassembler les données [/list_item]
[list_item] les corréler et produire des indicateurs sur les logs stockés [/list_item]

[list_item] visualiser ces indicateurs de façon claire, interactive, et idéalement en temps (quasiment) réel. [/list_item][/list]

Côté outils

Première étape avant l’analyse : rassembler les logs. Il s’agit d’une problématique davantage « Big Data » que sécurité, donc sur laquelle nous ne nous étendrons pas. Simplement, mentionnons qu’il est intéressant de penser, dès cette étape, aux performances et possibilités de visualisation offertes par le système mis en œuvre. Notamment si vous choisissez Apache Hadoop, il vous faudra choisir une distribution qui orientera les outils utilisables « au-dessus » de cette distribution. Une liste des distributions Hadoop est disponible ici : comme vous pouvez le constater, si de nombreux systèmes d’exploitation « Big Data » ont pour noyau l’éléphant Hadoop, c’est un vrai zoo qui s’offre à la vue des architectes sécurité pour bâtir une infrastructure d’analyse de logs. Un excellent article synthétise les caractéristiques de plusieurs distributions Hadoop disponibles, et les extensions (Hive, Pig, …) qui les accompagnent.

Au sortir du Congrès Big Data 2014[14], force est cependant de constater que la dimension « sécurité » du Big Data n’a pas été abordée (pas une seule fois !), ni a fortiori la détection de menaces via l’analyse de logs.

Quelques éditeurs se lancent dans les SIEM (Security Information Event Management) orientés Big Data[15], mais les offres restent rares. Un CSS devra donc passer par le développement interne d’outils spécifiques de visualisation de ces analyses.

On en revient ici à la complémentarité des fonctions au sein d’un CSS, puisque le développement de tels outils de visualisation produira autant de valeur ajoutée qu’il nécessitera de dialogues entre les différentes spécialités du CSS, notamment entre développeurs, experts sécurité, et mathématiciens/statisticiens.

D’ailleurs, les SIEM ne sont pas les seuls outils permettant de faire de l’analyse de formes d’attaques : des stations d’analyse comportementale dédiées (et françaises !) montrent une réelle maîtrise dans l’art de la reconnaissance de formes (de menaces). Elles constituent ainsi un outil de haut niveau à tous les sens du terme pour la détection des signaux faibles de cyberattaques.

Conclusion

Preuve accessible et parfois unique des alertes de sécurité informatique, les logs permettent de mettre en avant des anomalies menant à l’identification de probables cyberattaques.

La corrélation des divers événements enregistrés dans les logs, l’analyse comportementale de profils utilisateurs donnés, l’enrichissement des logs par des ressources extérieures et la visualisation des analyses résultantes permettent, par exemple au sein d’un Centre de Supervision de la Sécurité, de détecter des signaux faibles car indirects et peu nombreux, de tentatives ou succès d’exploitation de failles.

L’analyse des logs nécessite un investissement depuis l’infrastructure technique jusqu’à la réflexion mathématique, mais elle commence à faire ses preuves dans la production d’indicateurs fiables car mesurables des probabilités de cyberattaques passées, présentes, et à venir !

Je tiens à remercier Barbara Louis-Sidney et Guillaume Rossignol pour leur relecture et les conseils qu’ils m’ont prodigués dans la rédaction de cet article.

 

Charles Ibrahim, analyste cybersécurité.

@Ibrahimous

http://fr.linkedin.com/pub/charles-ibrahim/17/203/1a1

 


[1] Ne pas hésiter à réviser les lois défendues par la CNIL : http://www.cnil.fr/vos-obligations/vos-obligations

[2] Notamment la très connue ISO 27001, mais aussi la plus pertinente, dans ce contexte, ISO 27035.

[3] Méthode de qualification des incidents, procédure de gestion des incidents et des vulnérabilités du périmètre surveillé, organisation des rapports et comptes-rendus…

[12] organisation à but non lucratif financée par, et travaillant pour le gouvernement américain. Gère trois centres de recherche et développement : pour le département de la défense (“DOD Command, Control, Communications and Intelligence FFRDC“), pour la Federal Aviation Administration (the Center for Advanced Aviation System Development), et pour l’Internal Revenue Service (the Center for Enterprise Modernization).

[14] qui s’est tenu au CNIT les 1er et 2 avril

[15] Par exemple, Pravail Security Analytics d’Arbor Networks, RSA Security Analytics de RSA, ou encore McAffee