Cédric Pernet est expert en « Threat Intelligence » et en réponse à incident. Il a exercé son activité d’incident responder au sein du CERT Lexsi puis du CERT Société Générale. Il travaille aujourd’hui au sein du CSIRT AIRBUS Defence & Space – CyberSecurity (ex-CASSIDIAN CyberSecurity).
Qualys Magazine : De quoi parle-t-on exactement lorsque l’on parle d’Incident Response ?
Cédric Pernet : Dans le milieu informatique il s’agit bien sûr de « réponse à incident de sécurité informatique » . La notion d’incident est variable, mais une définition acceptable serait, si l’on s’en réfère au NIST, « une violation ou une menace de violation imminente de la politique de sécurité informatique, de la politique d’utilisateurs, ou des pratiques de sécurité » . On pourrait évoquer à titre d’exemple les attaques par déni de service, les infections par malware, le vol de données, etc.
La réponse à incident consiste donc à qualifier l’incident (sa réalité et ses impacts potentiels, principalement) puis à le résoudre.
Cette résolution suit un cycle de plusieurs phases, qui sont :
- La préparation : il s’agit ici de tout ce qui précède l’incident et qui permet de procéder à sa résolution plus rapidement. A titre d’exemple, dans le cas d’un déni de service distribué (DDoS), il pourrait s’agir de disposer à l’avance des coordonnées des bons interlocuteurs dans les différentes cellules IT de l’entreprise afin d’obtenir les logs rapidement, de pouvoir modifier des règles sur un routeur, etc.
- L’identification : cette phase met en œuvre tous les moyens à la disposition de l’entreprise pour détecter l’incident, le confirmer et le qualifier rapidement.
- Le confinement : permet d’éviter que l’incident ne se propage. Il pourrait s’agir d’isoler un réseau s’il est infecté par un malware de type ver par exemple.
- La remédiation : Cette étape a pour objectif de lutter contre l’incident et y mettre un terme. Il peut s’agir de la neutralisation d’un malware et de la désinfection, de la mise à jour de règles sur des outils de détection, du changement de paramètres sur un pare-feu, d’analyse inforensique poussée, etc…
- La remise en état : Il s’agit de remettre état tout le système d’information une fois que l’incident a été résolu. C’est à ce stade qu’il faut également restaurer des fichiers, déployer des correctifs de sécurité, etc… Et également surveiller le système pour s’assurer de la non-reprise de l’incident.
- Le débriefing : Cette phase est trop souvent négligée lors d’une réponse à incident, parce qu’elle intervient après que tout soit réglé. Elle revient à faire le point avec tous les acteurs qui ont été concernés par la réponse à incident, afin d’en tirer les leçons des erreurs commises et d’améliorer le processus de réponse pour mieux traiter le prochain incident du même type.
Qualys Magazine : On entend beaucoup parler d’Incident Response aujourd’hui. Serait-ce devenu le nouveau terme à la mode ?
Cédric Pernet : Je ne pense pas qu’il s’agisse d’un buzzword. On parle de CSIRT (Computer Security Incident Response Team) ou de sa variante CERT® (Computer Emergency Response Team) depuis de nombreuses années déjà (la seule différente entre CSIRT et CERT® réside dans le fait que CERT est une marque déposée et qu’il faut faire une demande validée par le CERT/CC pour s’en servir)
Le premier CERT® (le CERT/CC) existe depuis 1988 par exemple, ce n’est donc pas tout récent… Ceci dit, c’est vrai qu’on entend beaucoup plus parler de CERT® et de CSIRT depuis quelques années en France.
En réalité les équipes d’Incident Response (IR) ont plus ou moins toujours existé, sauf qu’elles ne s’appelaient pas comme ça et qu’elles n’étaient pas vraiment structurées. On avait plutôt des « personnes clef » à contacter dans l’entreprise quand quelque chose de grave arrivait. Mais le besoin de répondre aux incidents a quant à lui toujours existé.
Ce qui est relativement nouveau, en fait, c’est surtout le partage de l’information entre différentes cellules de type CSIRT. A l’heure actuelle, répondre à des incidents de sécurité « seul dans son coin » reste possible mais peu efficace. Une réponse à incident sera forcément plus rapide et plus efficace si d’autres équipes qui ont vécu le même incident partagent leur savoir. C’est notamment l’un des buts poursuivis par le FIRST (Forum for Incident Response and Security Teams) qui regroupe différentes structures CSIRT dans le monde.
Par ailleurs de plus en plus d’ « incident responders » partagent leurs outils sur GitHub, et on ne peut que se réjouir d’un tel comportement.
Tout ce partage, dans une communauté aussi restreinte, est très encourageant et très motivant. Certaines équipes ont cependant parfois un peu de mal à faire comprendre à leur hiérarchie que ce partage est important et qu’il ne trahira rien sur leurs clients ou sur leur structure.
Mais il est vrai qu’il est parfois difficile pour quelqu’un extérieur à notre métier de comprendre comment des équipes travaillant dans des entreprises très concurrentielles peuvent échanger des informations sur des incidents. Et pourtant cela se fait très bien et sans rien trahir…
Qualys Magazine : Quel est le profil-type du Responder ?
Cédric Pernet : Les profils sont variés. Mais il s’agit évidemment de passionnés de sécurité informatique, généralement des consultants en sécurité informatique ou des « pentesteurs » (spécialistes des tests d’intrusion, ndlr).
Si je peux me permettre d’élargir un peu la question, ce n’est pas forcément lebackground qui est important lorsque l’on recrute un incident responder, mais plutôt son état d’esprit et sa personnalité. Les qualités importantes pour être un bon incident responder sont la disponibilité, la curiosité, l’envie de comprendre…
Mais l’incident responder doit aussi posséder des qualités de vulgarisation et d’adaptation à son environnement. Parce que c’est une chose d’être capable par exemple d’expliquer à un autre technicien qu’il faut bloquer tel ou tel port TCP. Mais expliquer une menace complexe à un RSSI en est une autre. Et je ne parle même pas du degré de précaution qu’il faut déployer lorsqu’il faut gérer une conférence avec les métiers et leur expliquer pourquoi une réponse à incident aura des conséquences sur leur activité.
Finalement l’incident responder doit certes être capable de gérer la dimension technique, mais aussi la composante humaine !
Qualys Magazine : Quelles compétences sont les plus recherchées dans cette profession ?
Cédric Pernet : Le profil type n’existe probablement pas car la réponse à incident intervient sur tous les aspects de la sécurité informatique.
Ce n’est d’ailleurs pas un hasard si l’on parle presque toujours d’une équipe de réponse à incident : l’individu est au second plan. C’est justifié par le fait qu’une réponse à incident nécessite de multiples compétences différentes. Je parlerais donc plutôt de compétences d’équipe, réparties entre les individus qui la composent.
Ces compétences intègrent une bonne connaissance en administration système, en réseau, en inforensique, en rétro-ingénierie, en scripting, une très bonne culture générale de la sécurité informatique, mais aussi cette capacité à communiquer avec les autres que j’évoquais précédemment.
Un esprit d’analyse rapide est un plus appréciable, ainsi qu’une bonne résistance au stress. Une bonne équipe de réponse à incident doit aussi compter des spécialistes de l’investigation numérique et de la cybercriminalité, et enfin de la «threat intelligence » (la connaissance de la menace).
Qualys Magazine : Vers quoi peuvent évoluer les responders dans la suite de leur carrière ?
Cédric Pernet : Ces profils peuvent évoluer dans toutes les branches de la sécurité informatique. Certains responders apprécient d’être dans la technique et y restent, quitte à changer d’entreprise lorsqu’on les pousse à prendre des responsabilités de management.
D’autres évoluent en prenant en charge des structures de type CSIRT, ou deviennent RSSI. Il est même envisageable de se diriger vers des cellules de lutte anti-fraude en ligne, ou devenir formateur en incident response … Tout est possible, vraiment.
Qualys Magazine : Comment s’organise une équipe d’IR dans l’entreprise ?
Cédric Pernet : De nombreuses questions se posent lors de la création d’une telle équipe. La plus importante est peut-être de savoir selon quels horaires elle fonctionnera. S’il y a besoin de travailler en 24/7 cela augmente alors forcément le nombre d’incident responders (et donc le coût et la complexité des processus de travail, ndlr)
Se pose ensuite la question de la répartition géographique : l’équipe sera-t-elle localisée en un point central ou répartie sur le globe lorsque l’entreprise est internationale ?
Ensuite, il faut composer une équipe qui réunit toutes les qualités et compétences complémentaires dont nous avons parlé. Si ce n’est pas possible (à cause d’un problème de budget par exemple) il peut être envisagé de disposer d’une équipe « minimale » constituée d’une ou deux personnes, avec la possibilité de faire intervenir ponctuellement d’autres employés choisis pour leurs compétences particulières.
Dans la plupart des cas, les équipes d’IR comprennent entre quatre et six personnes, avec un responsable d’équipe.
Enfin, pour ce qui est du placement de l’équipe dans la structure de l’entreprise, elle dépend généralement d’un DSI ou d’un RSSI.
Qualys Magazine : Avec quels autres acteurs de l’entreprise l’équipe d’IR doit-elle collaborer ?
Cédric Pernet : L’équipe ayant pour but de répondre aux incidents de sécurité informatique, elle a bien sûr tout intérêt à entretenir des relations très proches avec tous les acteurs de la sécurité du SI et de l’IT, que ce soit pour que ces derniers lui signalent un incident ou pour l’aider à en résoudre un. Une relation privilégiée est notamment nécessaire avec le (ou les) RSSI de l’entreprise.
D’autres collaborateurs sont également très utiles à une équipe d’IR : les juristes, qui apporteront le volet juridique nécessaire à certaines interventions (procéder à l’analyse du poste de travail d’un employé, par exemple), le service de communication, qui participera à la valorisation de l’équipe vers l’externe si une telle volonté existe, ou encore les commerciaux si l’équipe externalise ses services.
En plus de ces contacts internes, il y a également des contacts externes : les autres CSIRT/CERT, les services de Police et de Gendarmerie, les autres chercheurs en sécurité informatique…
Qualys Magazine : Avec quels outils travaillent les Responders ?
Cédric Pernet : De nombreux outils et équipements sont utiles pour la réponse à incident. Il y a bien sûr les équipements déjà installés dans le SI, tels que les IDS/IPS, les outils de monitoring divers et variés du SOC lorsqu’il y en a un, les consoles d’administration des anti-virus, etc…
Mais aussi une foule d’outils spécifiques à l’équipe : il faut de l’outillage pour parcourir et analyser efficacement des millions de lignes de logs, des outils pour les investigations inforensiques sur une machine ou sur tout un parc (voire sur des smartphones), un sniffer réseau, une sandbox d’analyse de malware, un désassembleur, de nombreuses machines virtuelles, des outils de chiffrement (pour les mails de l’équipe, pour des conteneurs chiffrés) et même un bon tableur et un bon logiciel de traitement de texte ! Parce que une équipe de réponse à incident doit savoir présenter ses résultats de façon compréhensible et ne pas se contenter de montrer des extraits de journaux ou, pire, des captures d’écran d’un désassembleur…
En fait il est difficile d’être exhaustif dans cette liste d’outils car il en existe des centaines, gratuits ou affreusement chers, qui remplissent plus ou moins bien leur fonction et dont le choix dépend aussi de l’individu qui les utilisera. L’un va préférer inspecter un fichier PCAP avec Wireshark, alors que l’autre ne voudra que tcpdump…
Enfin, si l’équipe est amenée à se déplacer sur différents sites, il est fortement recommandé de disposer d’un « jump bag », un gros sac lourd censé contenir tout ce dont un incident responder pourrait avoir besoin en déplacement : des pages man imprimées, des CDs vierges, un ordinateur portable d’intervention avec tous les outils installés, testés et à jour, de la connectique et des câbles à foison, hub USB, hub Ethernet, write blocker, pince coupante, scotch, clefs USB avec diverses distributions Linux, un gros disque dur pour stocker éventuellement une image de disque entière, les adresses et téléphones des contacts indispensables, des fiches de bonnes pratiques, etc…
Pour l’anecdote j’ai connu un incident responder qui avait mis un miroir de dentiste et une lampe torche dans son « jump bag », au cas ou il aurait à brancher un câble Ethernet derrière un serveur collé à un mur… (Julien, si tu me lis…)
Qualys Magazine : Que fait une équipe d’IR quand il n’y a pas d’incidents à traiter ?
Cédric Pernet : Effectivement, l’un des défis d’une telle équipe consiste à justifier son budget et son existence lorsqu’il n’y a pas eu d’incident pendant plusieurs mois…
L’une des erreurs fréquente consiste à ne communiquer qu’en cas d’incident. En réalité l’équipe doit être visible en permanence et elle doit se donner les moyens de l’être.
Dans la pratique, cela peut être en communiquant régulièrement par une veille technologique ou par l’émission de bulletins d’alertes basés sur les menaces externes, comme par exemple des vulnérabilités massivement exploitées sur Internet ou des campagnes de phishing pouvant cibler les employés de l’entreprise, etc…
Certaines équipes en profitent également pour former d’autres employés à divers aspects de la réponse à incident : analyse de malware, inforensique, cybercriminalité, par exemple.
Enfin, il est possible de faire de la sensibilisation en entreprise : bonnes pratiques de sécurité, sensibilisation au spear phishing, etc.
Pour ce qui est des activités « non visibles » de l’équipe, mais pourtant essentielles, il y a un gros travail de maintient de l’expertise technique, qui nécessite une bonne veille et beaucoup de temps passé à tester les outils, sur différentes configurations. Certaines équipes en profitent également pour développer leurs propres scripts et outils.
Enfin, il y a un travail de collaboration et d’échanges avec les autres structures CSIRT, qui demande du temps.
Qualys Magazine : La réponse à incident est un projet à réaliser plutôt en interne, ou qui peut être externalisé ?
Cédric Pernet : Il n’y a pas de bonne réponse ici. Une grande entreprise peut vouloir se doter d’une structure de réponse à incident complète en interne, alors qu’une entreprise de taille plus réduite aura du mal à justifier du budget associé.
L’idéal serait d’avoir un cœur de structure CSIRT en interne, en charge de la coordination des incidents de sécurité, et de déléguer en externe tout domaine de compétence qui n’est pas du ressort de l’entreprise.
Il faut reconnaître que les attaques sont de plus en plus complexes et le niveau d’expertise requis pour délivrer une bonne qualité de réponse et d’analyse devient de plus en plus élevé. Il n’est donc pas forcément stupide pour une entreprise de déléguer à un tiers de confiance certains domaines d’expertises technologiques. Je pense notamment à la gestion d’incidents de type « attaques APT » qui nécessitent une forte expérience qui ne peut pas s’improviser pendant un incident.
La meilleure solution à mon sens est un mélange entre coordinateurs internes et experts externes.
Qualys Magazine : Quelles ressources sont-elles nécessaires pour se doter d’une équipe de réponse aux incidents ?
Cédric Pernet : Les ressources nécessaires sont de plusieurs types. Des hommes, tout d’abord. Des profils techniques dans tous les cas, mobilisés à temps plein ou ponctuellement.
Ensuite, il faut des processus adaptés : des méthodologies de réactions, des fiches de contact, des directives internes permettant de légitimer la position et le fonctionnement de l’équipe.
Enfin, il faut doter cette équipe des outils adaptés, mais pas uniquement des outils techniques. Un laboratoire et des logiciels d’analyse sont nécessaires, mais il faut aussi penser à un bureau dédié, des moyens de communication dédiés…
L’activité de réponse sur incident est très documentée sur Internet, il est donc assez simple de se mesurer par rapport aux bonnes pratiques et de viser un point d’excellence. Tout cela a bien sûr un coût et atteindre un certain niveau de qualité exigera un vrai budget. En conséquence, il est logique de voir surtout des grosses entreprises matures sur le plan de la sécurité se doter de structures de réponse sur incident.
Qualys Magazine : Comment positionner l’équipe de réponse à incident vis-à-vis du SOC (Security Operations Center) de l’entreprise ?
Cédric Pernet : Il peut arriver qu’une équipe de réponse à incident joue également le rôle de SOC. Cependant, le travail d’un SOC consiste plutôt à superviser pour détecter les incidents, qui sont ensuite signalés à l’équipe CSIRT/CERT®.
Qualys Magazine : Une équipe d’IR doit-elle toujours être affiliée à un CSIRT/CERT® public ?
Cédric Pernet : Pas forcément. Je suppose qu’il doit exister dans certaines entreprises des équipes qui travaillent uniquement en interne et ne sont pas visibles sur la place publique, mais je n’en connais pas personnellement.
A partir du moment où une telle équipe est montée, l’étape suivante consiste naturellement à se structurer en CSIRT/CERT, et si possible de rejoindre le FIRST.
Cela permet de devenir plus visible et de valoriser le travail de l’équipe. La création d’un nouveau CSIRT/CERT® est d’ailleurs toujours saluée dans la communauté.
En plus de valoriser l’image de l’entreprise, cela contribue aussi à être informé sur les incidents plus tôt, que ce soit par les autres CSIRT, par les salariés ou par des internautes qui ne manquent pas de relever la page « Contacter le CSIRT » sur le site de l’entreprise.
Source : Qualys
No comments:
Post a Comment