/SOC-projet-M1

Projet de Master 1 Cybersécurité à YNOV Campus orienté SoC - SOAR

Primary LanguageDockerfileApache License 2.0Apache-2.0

SOC-projet-M1

Projet de Master 1 Cybersécurité à YNOV Campus orienté SoC - SOAR

liens du git https://github.com/Nadror/SOC-projet-M1

Sommaire

  • Contexte /Introduction
  • Schéma Logique ou Schéma Infra
  • Etat de l'art / Justification du projet
  • Description Mise place + Doc d'install + doc fonctionnelle
  • Problème Rencontré / Solution apporté / Explication du problème
  • Ouverture du projet / Axe d'amélioration pour le futur
  • Conclusion (Apport du projet en matière de compétences technique et softskill)
  • Annexe tiers.

Introduction

Lors de l’année 2021-2022 M1 nous avons eu un choix à faire entre plusieurs idées de projet orienté Cybersécurité (Outils de pentest, exchange honeypot, SoC…)

Plusieurs choix s'offre à nous au niveau SoC :

Mise en place d'une infrastructure d'entreprise avec SIEM IDS Honeypot pour Lab de test de détection pour la blue Team

Monter un outil d'hardening d'os.

Dev d'un Honeypot Exchange pour récupérer des payload via un serveur Exchange

Mise en place d'une solution pour réaliser des campagnes de Threat hunting

Nous avons donc décidé pour cette année de reprendre le projet de SoC pour approfondir les connaissances et ajouter un aspect d'automatisation autour de notre SIEM (ELK) pour avoir quelque chose qui se rapproche au mieux d’un SoC type d’une entreprise.

DIAS Steven ainsi que MOUCHAGUE Lucas nous ont demandés d'approfondir le système d’alerting et de workflow.

Schéma de l’infrastructure

Machine IP Port
TheHIVE 192.168.1.51 9000
Cortex 192.168.1.56 9001
MISP 192.168.1.43 443
ELK 192.168.1.39 9200 / 5601
CAPEv2 192.168.1.50 8000
Rsynd(sync) 192.168.1.55 -
Shuffle 192.168.1.54 3443
Cowrie 54.38.231.** (Pf) 22 (NAT)

Workflow Shuffle

  1. Récupération des champs "alerts" sur ELK"
  2. Création d'une alerte sur TheHIVE
  3. Ajouter l'IP en tant "type" IP sur l'alerte crée précédemment
  4. Création d'un CASE basé sur l'alerte crée sur TheHIVE
  5. Récupération de l'artefact dans le case crée précédemment
  6. Analyzer lancé sur la cortex (Abuse_IPDB, GeoIP, MISP)
  7. Création d'une analyse sur la CAPEv2 via analyzer Cortex (Cuckoo_analyzer)

Etat de l’art - Justification du projet

Pour ce projet de cette année 2022 nous avons choisi de continuer dans la même optique que notre projet précédent c'est-à- dire de mettre en place un SOC opensource.

Mais cette fois si, ce SOC sera plus orienté sur la réponse à incident, un concept qui devient de plus en plus important pour analyser et traiter efficacement par des équipes spécialisées les événements d'équipements de protection verbeux tels que des EDR (antivirus basé sur de l’analyse comportementale recommandé par l’anssi) ou encore pour faire de la recherche d’indice de compromission et partager les informations.

Le choix du projet nous a paru pertinent surtout dans cette période de covid et de conflit entre l’ukraine et la russie qui peut aboutir sur une cyber guerre.

Description - Mise place

Nous avons mis en place ce projet sur un serveur de virtualisation proxmox qui nous permet d’avancer sur plusieurs projets en même temps. Ce serveur possède 64 Go ram ainsi que 2TO d'espace disque en nvme.

Logiciels :

SURICATA > ELK > SHUFFLE > THEHIVE > CORTEX > MISP COWRIE > ELK > SHUFFLE > THEHIVE > CORTEX > MISP

Notre infrastructure dans un premier temps analyse les paquets entrants grâce à l'iDS Suricata qui fonctionne avec les règles de snort et ET (proofpoint). Si un paquet est tag comme malveillant, il est alors envoyé grâce à un rsync relié à un agent filebeat dans le SIEM ELK.

Le SIEM dispose d'un Shuffle qui permet d'automatiser un workflow en fonction de certains événements, comme par exemple le déclenchement d'un ticket référençant une menace détecté en amont par le suricata ou le CowriePot sur la plateforme Thehive pour les équipes de réponse à incident.

Ensuite les équipes pourront déclencher des analyses grâce aux modules "analysers" installés sur la cortex comme une analyse sandbox sur Capev2 ou sur Virustotal ou de la vérification de réputation d'ip malveillante avec AbuseIPDB.

En dernier point se trouve un MISP afin de partager l'information traités entre les différentes organisations.

Documentation d'installation

Documentation fonctionnelle

Evenement déclancheur : connection ssh malveillante sur le honey pot. Cowrie

Analyse et envoie de log sur la ELK:

Déclanchement d'un ticket sur thehive :

Déclanchement des analysers cortex :

Difficultés rencontrés

  • Notre principale difficulté a été sur le debut du projet, en effet nous n'avions pas encore assez de RAM pour mettre en place toute l'infrastructure. Nous avons donc acheté un serveur dédié pour y remedier.

  • Nous avons egalement eu du mal à appréhender le workflow entre les differentes composantes du projet.

  • Trouver un outil adapté pour le workflow

  • Agréger les logs dans la ELK

Ouverture du projet / Axe d'amélioration pour le futur

En axe d'amélioration nous devons uniformiser nos efforts et travailler davantage sur l’automatisation de déploiement de l’infrastructure et des logiciels comme par exemple avec terraform ou vagrant.

Mettre en place davantage de fonctionnalité sur le Sandbox CAPEv2 pour avoir des plus d’informations et faire remonter des rapports sur une VM Threat Intel.

Utiliser davantage les intégrations ELK comme ELK Agent et le système de fleet. Plus création de pipelines personnalisés Logstash pour pouvoir les examiner sur Kibana.

Conclusion

Pour conclure le projet nous à permis d'avoir un meilleur aperçu sur le monde de la réponse à incident et du partage d'information.

Mais également d'un point de vu plus technique, de decouvrir des applications opensources et de créer un workflow cohérent entre celles-ci.

Notre labo en ce procedé permetera certainement aux équipes de réponses à incident de mieux s'organiser et de gagner du temps lors du traitement des alertes afin de mettre toutes les chances de leur coté pour intervenir à temps face aux menaces les plus destructives.