| Conférences

Programme :


Key note : Comment aider à protéger la Suisse des menaces cyber les plus sérieuses par Mauro Vignati, Agence Fédéral Suisse de renseignement

Le responsable du CERT du FIS (Federal Intelligence Service) a présenté le rôle du CERT, ses droits et ses contraintes notamment légales. Il a mis l’accent sur le fait que le FIS ne surveille pas le trafic des citoyens suisses et qu’il ne procède pas à des représailles (Cette dernière affirmation ne semble pas convaincre les participants).

Le rôle essentiel du CERT FIS est de superviser les menaces qui pèsent sur les infrastructures critiques suisses ainsi que les entreprises suisses. Il n’a pas vocation a remplacé les sociétés de service ou les DSI des sociétés. Ce sont ces dernières qui doivent définir une stratégie de sécurité claire et de l’appliquer.

Parmi les secteurs les plus ciblés :

  • Industrie pharmaceutique
  • Agro-alimentaire
  • Biotechnique
  • Armement
  • Institution internationale et association sportive (FIFA, comité international olympique, etc.)

Les menaces auxquelles le FIS fait face sont :

  • Terrorisme
  • Espionnage
  • Prolifération
  • Extrémisme politique (on peut le classer aussi dans la catégorie Terrorisme)
  • Attaque contre les infrastructure critique

La menace la plus importante est celle de l’espionnage (industriel et politique)

Parmi les groupes les plus actifs détectés en Suisse, on note :

  • APT3 : Biotechnique, chimie et agro-alimentaire
  • APT 10 : Plusieurs secteurs visible depuis 2006
  • Uroburos/Snake : Plusieurs secteurs visible depuis 2006

L’expert a terminé par des recommandation à la destination des entreprises :

  • Investir dans la formation des équipes techniques
  • Définir une politique de sécurité claire et l’appliquer (puits de logs , 2FA, etc).
  • Déterminer leurs assets critiques
  • Former leurs employées non-technique sur la sécurité informatique

Le chemin de l’application au serveur : Les surfaces d’attaques sur l’infrastructure médicale connectée par Denis Makrushin

Présentateur : Denis Makrushin est Hacktiviste passionné par la sécurité des réseau médical moderne.

Contacts : Twitter :@difezza / Email : denis@makrushin.com / Site : Makrushin.com

Présentation :

Denis a voulu attirer l’attention des participants en leurs posant les questions suivantes :

  1. Les attaques de sécurité touchant les réseaux médicaux tuent-elles plus que le cancer ?
  2. Les attaques de sécurité touchant les réseaux médicaux peuvent-elles tuer ?
  3. Les registres de santé des patients sont-ils stockés de manière sécurisé?

Après la session interactive, Denis a présenté des chiffres liés à la mortalité suite à des erreurs médicales. Ce qui sort le plus de ces chiffres, c’est que la plupart des morts peuvent être sauvés car leurs décès sont liés à des erreurs de diagnostic. Ces erreurs peuvent être évitées grâce à l’informatique.

L’usage croissant de l’informatique dans la santé a fait surgir de nouveaux protocoles (DICOM,MQTT), de nouveau équipements (PACS, MR, CT) et de nouveaux logiciels notamment libre (OpenEMR, openMRS).

Cependant, est-ce que cette infrastructure est sécurisé ? La réponse est non. Denis l’a montré en faisant des scan sur Shodan que plusieurs de ces machines sont reliées directement à internet sans aucun mécanisme de sécurité (parfois sans même un mot de passe). Les logiciels contiennent quant à eux des failles de types XSS, SQL injection, etc. De même, les protocoles ne présentent pas de garantie en terme de sécurité et ils sont vulnérable à des attaques de type DOS ou du spoofing.

Enfin, cette situation critique ne semble pas attirer l’attention des pouvoirs publics malgré l’appel récent de l’OMS (Organisation Mondiale de Santé).

Spyware, Ransomware et Worm : Comment éviter la prochaine tragédie sur les systèmes SAP par Jordan Santarsieri

Présentateur : Jordan Santarsieri est fondateur de la société Vicxer spécialisée dans les tests d’intrusion, remédiation et investigation sur les systèmes SAP. Il a fait plusieurs présentations à plusieurs conférences comme BlackHat, RootCon, YSTS, etc. Il a, à son actif plus de 1000 tests d’intrusions sur SAP.

Contact : Twitter : @jsantarsieri / site : vicxer.com (le site semble hors service lors de la conférence)

Présentation :

Jordan a commencé par une présentation rapide mais complète des solutions SAP (Entreprise et solutions support) ainsi que l’historique de ces dernières.

Sur l’aspect technique, le framework NETWEAVER et les deux stacks ABAP et J2EE ont été expliquées. Il faut noter que chaque Stack a besoin de plusieurs services qui doivent communiquer entre eux à travers plusieurs protocoles et plusieurs ports ce qui augmente considérablement la surface d’attaque.

Une fois, SAP présentée, Jordan a présenté son projet ARSAP. En effet, lors de la création de Vicxer, la question de la visibilité commerciale a été critique : comment peut-on attirer des clients avec une approche pragmatique et cohérente ?

Le projet ARSAP consiste à scanner internet en utilisant des outils comme Shodan et des techniques de recherche comme Google Hacks pour déterminer les systèmes SAP accessibles directement depuis Internet. Toutes les briques de l’architecture SAP (ABAP, J2EE, etc.) ont été scannées.

Le résultat est hallucinant. Jordan et son équipe ont trouvé 14000 systèmes sur internet contenant des systèmes avec des vulnérabilités critiques comme RCE, Arbitrary File uploads, Directory Transversal et autre.

Une fois les résultats du projet ARSAP présentés, Jordan a détaillé quelques attaques qui peuvent être utilisées contre les systèmes SAP. Il a aussi détaillé comme se prémunir de ces attaques :

  1. Usage frauduleux des SAP GUI Scripts / Activer la notification lors de l’exécution des GUI script
  2. Remote code exécution via Java Invoker Servlet / Désactiver la fonctione Invoke Java Servlet
  3. Déchiffrement du SAP Secure Storage pour le vol des crédenciales / Protection de l’accés SAP J2EE Secure Storage
  4. Brute force via RFC / Eviter l’usage de RFC avec des crédentiales hard-codées.
  5. Mouvement Latéral via Master Password ou SOAPRFC / Utiliser une master password différente de tous les autres mots de passe/

La présentation c’est terminée par quelques recommandations comme l’intégration du système SAP au périmètre du SOC, faire des audits techniques régulièrement et l’utilisation de SAP web-dispatcher.

SD-WAN : Un autre chemin vers une Internet non-sécurisée par Denis Kolegov & Oleg Broslavsky

Présentateurs : Oleg est un ancien étudiant dans l’université publique de Tomsk. Il travaille actuellement pour BiZone comme développeur de logiciel. Il était le capitaine SiBears Denis est un enseignant chercheur à l’université publique de Tomsk et il travaille comme chercheur en sécurité à BiZone aussi.

Contacts : Twitter : @dnkolegov (Denis Kolegov) @yalegko (Oleg Broslavsky)

Liens utiles: https://github.com/sdnewhop/

Présentation:

Les SD-WAN (Software Defined – Wide Arean Network) sont à la mode depuis un moment. Ils apportent une agilité et une maniabilité que les réseaux classiques n’ont pas. Les éditeurs et les fournisseurs promettent aussi des réseaux plus sécurisés. En effet, la séparation entre le flux des données et celui de contrôle dans les SD-WAN permet théoriquement une meilleure gestion et par la suite une meilleure sécurité. Mais est-ce bien le cas dans la pratique ?

La réalité est tout autre. Les SD-WAN souffrent notamment de :

  • L’usage des technologies notamment open source non à jour
  • L’usage de mécanisme de cryptographie dépassé
  • L’absence de l’emploi des mécanisme de sécurité
  • L’utilisation de technologie avec des vulnérabilité connues.

Ces lacunes ont été montrées via des attaques pourtant classiques sur des réseaux de type SD-WAN :

  1. SQL injection
  2. CSRF
  3. L’upload de certificat
  4. Host Header Attack
  5. OS command Injection
  6. Différentes attaques sur les protocoles et les mécanismes de chiffrement (absence de control sur les mots de passe, mot de passe hard-codées, etc.)

La présentation a montré que la séparation seule entre le flux des données et le flux de contrôle ne garantie pas la sécurité des SD-WAN. Les éditeurs doivent implémenter des mécanismes de sécurité plus puissants pour avoir des produits matures en terme de sécurité.

Analyse de sécurité sur les surfaces d’attaques des clients Blockchain par Chen Nan & Kame Wang

Présentateurs : Chen NAN travaille au Zhanlu Lab de Tencent Inc. Il est passionné par les clients Blockchain, du kernel Windows et de la virtualisation. Il était présentateur à la 44con et CSS en 2018. Il a découvert plus de 10 vulnérabilités sur des clients BlockChain.

Kame WANG travaille aussi au Zhanku Lab de Tencent Inc. Il est membre de l’académie chinoise des sciences. Il était présentateur au ACM CSS 201 et au Tsec 2018. Ses sujets de recherches portent en plus de la blockchain sur la sécurité des mobiles et de l’analyse atomique des codes.

Contact : Twitter : @ZhanluLab

Présentation :

La Blockchain est une manière de stocker et d’échanger l’information sans un organisme ou organe de contrôle. Elle est basée sur un réseau distribué souvent de type peer-to-peer.

La Blockchain est définie par les composants suivants :

  • Compte : une paire de clé privé/publique
  • Adresse de compte : Le hash de la clé publique
  • La transaction : Une opération signé par la clé privée et publié sur le réseau P2P
  • Un block : L’ensemble des différentes transactions enregistrées.

La BlockChain est l’ensemble des blocks validés par les mineurs et horodatés.

Le but de la blockchain est de garantir l’intégrité des transactions en fournissant un workflow solide. Elle est utilisée dans plusieurs domaines (finance, hacking, etc.) mais elle a connu un essor avec les crypto-monnaies notamment Bitcoin.

Avec l’augmentation fulgurante de la valeur des bitcoin, plusieurs attaques ont été signalées :

  1. Contre les personnes possédants des bitcoin (des attaques même physique)
  2. Contre les réseaux de bitcoin
  3. Contre les plateforme de trading de bitcoin et autre crypto-monnaie

A cause du design de la BlockChain, les chercheurs ont recensé les surfaces d’attaques suivantes :

  1. L’interface RPC
  2. L’interface P2P
  3. Le Smart contract

Les chercheurs ont listé quelques scénarios d’attaque touchant les 3 surfaces citées auparavant comme par exemple :

  1. Attaque sur l’interface RPC pour voler la crypto-monnaie/ L’attaque est constituée de 3 étapes. La première consiste à vérifier que l’interface RPC de la cible est joignable. La seconde est l’obtention des informations du Wallet (portefeuille de la crypto-monnaie). La dernière étape est de commander la cible à envoyer son contenu. Pour que cette attaque réussisse, il faut que l’attaquant connaisse la clé du compte ou tout simplement que le compté ne soit pas verrouillé.
  1. Attaque sur le code source des clients : Les clients Blockchain sont des programmes comme n’importe quel autre programme. Il sont codés dans des langages comme C++,GO, Java etc. Ils sont alors vulnérables selon les langages utilisés à des différentes vulnérabilité (DOS, injection de code, Integer overflow,etc.)

Les chercheurs ont montré comment des techniques classiques comme le fuzzing ou l’audit de code ont permis la détection de vulnérabilité sur les clients BlockChain.

La présentation s’est terminée par :

  • Des statiques des attaques sur des plateforme blockchain (Ethereum).
  • Des exemples de code malveillant sur les plateformes (NEO et Ethereum) récupérés à l’aide des honeypots déployés par Zhanku Lab

La team Pentest & CERT

Boss of the SOC

Boss of the SOC est un challenge destiné aux équipes SOC/CERT. Il tourne autour de la maîtrise des outils Splunk (Splunk enterprise, Splunk Enterprise Security , UBA et Phantom).

Pendant le challenge, plusieurs questions sont posées. Ces questions détaillent les process de threat hunting et d’investigation d’incident de sécurité via les outils fournis. Chaque bonne réponse donne un nombre donné de point indexé avec la difficulté de la question. Les mauvaises réponses quant à elles, donnent droit à des points de pénalité. Il est aussi possible d’acheter à l’aide d’un certain nombre de points , des indices pour vous aider à obtenir les bonnes réponses.

Les scénarios couvrent par le challenge sont très réalistes comme :

  1. Infection par un trojan
  2. L’investigation sur des signatures réseau de malware
  3. Infection par un miner

Le challenge a duré 2H30. Plus de 40 équipes ont participé à cet évènement.


Keynote : Les châteaux du moyen Age et les serveurs modernes par Dr Christian Folini

Présentateur : Christian Folini est un doctorant en histoire médiévale et ancien président de la compagnie de Saint George, une entreprise spécialisée dans les reconstructions historiques datant du Moyen Age. Il est aussi auteur du livre ModSecurity Handbook 2. Il était co-dirigent du projet OWASP ModSecurity Core Rule Set. Il a plus de 10 ans d’expérience dans le domaine de la sécurité informatique.

Contact : Twitter @ChrFolini

Présentation :

Les places fortes du Moyen Age et les serveurs modernes se ressemblent plus qu’on ne le pense. En effet, il font tous les deux face aux mêmes problèmes et ils sont gérés tous les deux par des équipes réduites en nombre.

En effet, il suffit d’une seule faille dans un système de sécurité de n’importe quelle nature (militaire ou informatique ) pour que ce dernier s’écroule. L’analogie utilisée entre le cheval de Troie historique et les nouveaux Trojan (appelé aussi des chevaux de Troie) est frappante.

En ce qui concerne la menace du DOS, elle est fortement semblable à la menace d’un siège lent au Moyen Age. Les serveurs modernes tout comme les anciens châteaux doivent être capable d’encaisser des attaques de type DOS tout en maintenant un niveau minimal de service.

Enfin, la menace d’une APT est la plus critique. N’importe quel adversaire ayant l’envie, la détermination et les ressources nécessaires risque de prendre le contrôle de sa cible si cette dernière n’est pas suffisamment protégée et que ses défenseurs ne sont pas suffisamment entraînés.

Après des siècles de perfectionnement et avant l’invention de la guerre mécanique moderne, les châteaux médiévaux ont réussi à répondre à ces problèmes grâce à :

  1. La flexibilité des techniques utilisées
  2. La redondance des fronts défensifs
  3. La réduction de la surface d’attaque

Les équipes de sécurité IT moderne doivent s’inspirer des bâtisseurs des châteaux forts du moyen Age. Pour cela, il faut :

  1. Garder à jour les mécanismes de sécurité
  2. Connaître son réseau pour mieux le protéger
  3. Auditer régulièrement les mécanismes de sécurité afin de détecter toute éventuelle faille (avant que quelqu’un d’autre ne la détecte).

Cependant, les bâtisseurs du moyen Age avaient accès à des ressources importantes. En effet, la survie de tout un peuple dépendait souvent de ces fortifications. Malheureusement, les équipes modernes IT n’ont pas accès à un tel budget et doivent souvent faire avec des budgets très limités.

Voici les robots que vous cherchez, cas pratique d’investigation numérique sur des périphériques Android par Elena Kovakina

Présentateur : Elena Kovakina travaille chez Google au sein de l’équipe Detection&Response (l’équivalent du CSIRT). Elle a analysé des malware sur Android pendant plus de 5 ans.

Lien utile : https://bit.ly/2Wcfpi9

Présentation :

Afin de comprendre comment les malwares fonctionnent sur Android, il faut déjà s’attarder sur l’architecture de l’OS. Android est un système basé sur le Kernel Linux avec une contrainte majeur :

Le système doit fonctionner sur des périphérique très variable du smartphone à des voitures ou des smart-TV.

Ainsi, le système doit incorporé à la fois les contrôles hardwares et les drivers. Un Framework Java et l’Android Runtime (environnement d’exécution) permettent l’exécution des appli.

Etant donné qu’Android se base sur Linux, les dossiers intéressants à investiguer sont pratiquement les mêmes (/boot, /system, /recovery, /data, etc.)

Il faut noter que les app sont traitées comme des utilisateurs avec des UID propre à chaque appli.

Les app sont classées de la manière suivante :

  • Application système : elles font parties du système lui-même et elles sont souvent préinstallées. Elles ont souvent des accès à privilège
  • Application utilisateur : Installées par l’utilisateur lui-même ou par le constructeur. Elles ont un accès minimal
  • Application root : Installées par l’utilisateur root. Elles sont rares et pas présentes sur la plupart des périphériques.

Pour obtenir l’accès root, il existe deux solutions : Installer un ROM custom ou utiliser des apps et des exploits. Bien évidemment, il est plutôt recommandé d’installé un ROM custom au lieu d’installer des application pas forcément non-malveillante pour avoir les accès root.

Etant donné que la récupération des logs est vraiment délicate et pas toujours efficace sur Android, l’analyse du Bug Report (rapport de plantage) est une alternative très intéressante lors de l’analyse forensique. Il faut noté qu’Elena a fourni une cheatsheet (voir lien cité auparavant) pour réaliser des tâches comme la capture d’un snapshot mémoire ou le dump des logs système.

Les Bug Reports contiennent des informations intéressantes sur :

  1. La géolocation
  2. Le paramétrage de l’app
  3. Les téléchargement et les comptes
  4. Des messages différents (rapport de santé, logs de service, etc.)

L’utilité des Bug Reports a été montré pendant la prestation via une démo .

Vulnérabilités de l’implémentation mobile de OAuth 2.0 par Nikita Stupin

Présentateur : Nikita Stupin travaille chez mail.ru comme Analyste sécurité. Il a participé au programme Bug Hunter de Github, Airbnb, Yandex et Semrush. Il est aussi le doyen de l’université interne de mail.ru appelée GeekBrains. Cette université est spécialisée dans la sécurité informatique.

Contacts : n.stupin@corp.mail.ru / Twitter : @nikitastupin

Présentation :

OAuth 2.0 est un protocole d’autorisation permettant à une application tier d’accéder à des services http d’une manière illimitée. Il est utilisé souvent dans le cadre des déploiements SSO (Single Sign On) permettant d’authentifier l’utilisateur sans que ce dernier ne tape plusieurs fois son mot de passe. Il permet ainsi l’amélioration de l’expérience utilisateur surtout sur les smartphones.

Lors d’un déploiement de type OAuth 2.0, l’application interagie avec le navigateur afin que la requête d’autorisation passe par ce dernier au lieu de passer directement par l’application. Ceci simplifie les interactions entre l’application, le périphérique et le serveur d’autorisation.

Cependant, la livraison du code ou du token d’accès continu a posé problème. En effet, une application malveillante installée sur le périphérique peut intercepter le token d’accès et l’utiliser. La solution qui consiste à utiliser l’AppLink pour garantir que seule une application donnée peut accéder à des token d’accès spécifique est lourde à maintenir.

La solution la plus efficace contre ce type d’attaque est la PKCE (Proof Key for Code Exchange). Le client (l’application entre autre) doit envoyer un code_vérifier à chaque requête vers le serveur d’autorisation ou le serveur d’accès (celui qui délivre le token d’accès).

Afin que la PKCE soit efficace, il faut :

  • Utiliser un seul code_verifier par utilisateur
  • Vérifier que le code_verifier n’est ni vide ni absent
  • Vérifier que le code_verifier est aléatoire, suffisamment long et unique
  • Utiliser des mécanisme puissant comme sha256

Le stockage des tokens d’accès sur le périphérique doit aussi être sécurisé. Les développeurs des applications doivent vérifier la sécurité des conteneurs de token et éviter de les transmettre en clair dans les requêtes réseau.

Enfin, si OAuth 2.0 n’est pas bien implémenté (longueur de 256 bits minimum, vérification de l’état des flux de travail à chaque interaction, etc), d’autres vulnérabilités comme le CSRF (Cross-site request forgery) peuvent être présentes.

Attaquer le Secure Boot : Simulation pour améliorer les mécanismes de défense par Niek Timmers et Martjin Bogaard.

Présentateurs : Martjin et Niek sont deux analyste sécurité chez riscure, une société hollandaise spécialisée dans le sécurité des périphériques connectés.

Contacts : Email : martjin@riscure.com niek@riscure.com / Twitter : @jmartijnb @tieknimmers

Lien utile: https://www.riscure.com/uploads/2017/09/Controlling-PC-on-ARM-using-Fault-Injection.pdf

Présentation :

Chaque périphérique embarquée est composée de :

  1. Un disque
  2. Une chipset contenant le processeur, la SDRAM, la ROM et l’OTP
  3. Une Flash contenant le kernel et le code de démarrage (boot code).

Le secure permet de garantir l’intégrité du code et des données stockées dans la mémoire non volatile (notamment le code de démarrage). Cependant, si un pirate réussi à bypasser le secure code, il aura des accès à hauts privilèges au système surtout s’il réussi son attaque pendant les premières phases du démarrage.

La puissance du secure boot réside dans l’emploi de mécanisme de cryptographie efficace. Toute mauvaise implémentation rend ce système inopérant et vulnérable (CVE-2018-18440 par exemple).

Mais est-ce que le secure boot est efficace contre les attaques physiques ? L’équipe de riscure a montré que le secure boot reste inefficace contre certaines attaques physiques comme l’injection de défaut dans la tension électrique (Voltage Fault Injection). Cette attaque consiste a faire varier subitement et rapidement la tension d’alimentation de la chipset. Cette dernière peut fonctionner d’une manière inattendue permettant le bypass du secure boot.

Les mécanismes de défense contre ce genre d’attaque sont souvent coûteux et par la suite ne sont disponibles que sur certains équipements haut de gamme.

Cependant, comment déterminer à quel moment une VFI ou glitch permet de bypasser le secure boot ? Pour cela, il est nécessaire de simuler le comportement des chipset. Devant les différentes difficultés techniques et le cahier de charges nécessaires, l’équipe de riscure a décidé de développer elle-même le simulateur baptisé FiSim

La recherche des menaces : une approche orientée donnée par Roberto Rodriguez & Jose Luis Rodriguez

Présentateur : Roberto Rodrgiuez est un Threat Hunter chez SpecterOps spécialisé dans la détection des menaces de type APT. Ancien Threat Hunter dans l’armée américaine, il a développé pas mal d’outil et projet open source en relation avec le sujet comme HELK et OSSEM

Jose Luis Rodriguez est un étudiant en sécurité informatique chez Nova Comm. Il a participé au développement de HELK et OSSEM

Contacts : Twitter : Roberto (@Cyb3rWard0g) / Jose (@Cyb3rPandaH)

Présentation:

Le threat hunting ou la chasse aux menaces est l’activité la plus passionnante pour un analyste. En effet, qui n’aime pas trouver des signes de compromission menant à la découverte d’une attaque de type APT ? Cependant, sans méthodologie claire, le threat hunting devient une tâche exorbitante et frustrante comme la recherche d’une aiguille dans une botte de foin.

Le problème est que la plupart des analystes pensent en terme de logs. Or, chercher un indice dans des tera de logs est une tâche quasi impossible.

La solution est plutôt d’adopter une approche orientée donnée. Au lieu de se focaliser sur les logs, il faut se focaliser sur la donnée. Cette approche est composée des étapes suivantes :

  1. Définir un but clair pour la détection : Il faut définir ce que l’on cherche (signe de mouvement latéral, exécution de commande powershell, etc.). Pour cela, une connaissance détaillée des assets et leurs criticités est nécessaire.
  2. Définir un modèle d’attaque possible  : Appliquer l’ensemble des connaissances liées aux TTP de l’adversaire en relation avec le but défini. Le modèle doit être simple et précis à la fois pour une implémentation facile
  3. Simuler l’attaque : il s’agit d’appliquer le modèle trouver dans la phase 2 dans un environnement de test similaire à la production. Le but est de voir quel type d’événements l’exécution d’une telle attaque génèrent.
  4. Définir le modèle de détection : Relier les TTP de la phase 2 avec les événements de la phase 3
  5. Valider le modèle de détection : implémenter le modèle de phase 4 dans la production et détecter les éventuels faux positifs afin de les écarter.
  6. Documenter le modèle en question : pour tracker toute éventuelle évolution dans les TTP ou les modèles d’attaque et de détection.


Les outils OSSEM,MORDOR,HELK et Threat Hunter playbook (présents dans https://github.com/Cyb3rWard0g) permettent de réaliser l’ensemble du process

A l’attention de la blue team : conseils de l’équipe forensic pour élargir vos capacités d’investigation par Joe Gray

Présentateur : Ancien employé dans les sous-marins de l’US navy, Joe Gray est un architecte de sécurité sénior chez IBM. Il a plusieurs certifications comme CISSP-ISSMP, GSNA, GCIH et OSWP

Lien utile : https://advancedpersistentsecurity.net

Présentation :

Lors de la préparation de sa certification du GCFA, Joe Gray a remarqué que plusieurs aspects du DFIR peuvent être aussi appliqué en amont d’un incident et non pas seulement après. Couplé à des bonnes sources de threat intelligence, l’analyse de la RAM, Prefetch, Process, DLL et autres artifactes permet d’accélérer la détection et le traitement des incidents. Cependant, cette approche nécessite des outils de type EDR afin de l’implémenter dans le cadre d’une approche proactive.

La plupart des SOC se focalisent sur les logs notamment système en oubliant que l’activité réseau peut être source de détection. Ceci est dû à la complexité du stockage des pcap et autre évidence réseau. Cependant, l’emploi des mécanismes comme NetFlow peut fournir des indicateurs intéressants notamment pour les attaques de type exfiltration de données.


@ Zakaria