L'implémentation d'un SIEM est un grand projet qui peut engendrer des coûts élevés.
À l'aide d'ElasticSearch, il est possible d'en développer un à plus petit coût.
** Présenté pour le premier Meetup ElasticSearch de la ville de Québec **
2. GROUPE GERMAIN
HÔTELS
Groupe Germain Hôtels est une entreprise familiale canadienne
reconnue pour sa philosophie d’accueil exceptionnelle et pour le
style unique qui caractérise
ses hôtels.
Célébrant son 30e anniversaire en 2018, l’entreprise possède
et exploite les Hôtels Le Germain ainsi que
les Hôtels Alt et Alt+ à travers le Canada.
À propos
3. - 19 sites, chacun des sites est géré comme une entreprise distincte
- Point central au centre de données où les applications critiques sont hébergées
- Ajout de plateforme la plateforme cloud AWS
Plusieurs sources d’événements à intégrer au SIEM:
Amélioration de la visibilité sur l’infrastructure
Réseautique Machines virtuelles Services « On Prem » Services « Cloud »
Cisco ASA Windows Server Active Directory Office365
Cisco Firepower Windows 10 SMTP AWS
Cisco IOS Ubuntu Serveurs d’applications
Active Directory
Windows Server
Windows 10
4. -Événements Windows
-Événements d’Application, Sécurité et Système
-Audit d’événements Office365
-Événements VMware ESX et vSphere
-Événements dans des fichiers texte
-Événements d’équipement réseau par protocole SNMP et Netflow
Amélioration de la visibilité sur l’infrastructure
5. -Solution sélectionnée: ElasticSearch sur instances EC2 (AWS)
-Le côté Open Source d’ES nous permettait de faire un POC gratuit
-L’infrastructure cloud était plus facile à mettre en place
-Il est possible d’ajuster l’infrastructure rapidement (Scaling)
-Aucune gestion du hardware
Infrastructure sélectionnée pour le SIEM
6. -Notre déploiement actuel est séparé entre des instances EC2 et des machines virtuelles
dans notre centre de données.
Centre de données:
-5 nœuds pour recueillir les événements et les traiter (Logstash et Beats)
-1 nœud Wazuh pour la gestion de l’HIDS (Host-based Intrusion Detection System)
AWS :
-3 nœuds ElasticSearch sur une instance r5.xlarge (32gb de RAM)
-1 nœud Kibana sur une instance t3.small
Architecture actuelle – Déploiement hybride
9. -Winlogbeat pour les événements de Windows (Service sur l’agent)
-Metricbeat pour les métriques
-Stack Elastic
-Site web
- Filebeat pour les événements en format texte
- Équipements réseau
- Fichiers d’événements texte
-O365beat pour l’audit d’Office365 (« Beat » sur mesure)
-Logstash pour l’ingestion par SNMP
Expédition des données d’événements
10. -Traitement sommaire fait avec les « processeurs » sur les agents Winlogbeat,
Filebeat et O365Beat
-Certaines sources de données passent par un enrichissement plus complet avec
Logstash ou directement dans ElasticSearch
-Utilisation de plateformes d’OSINT (Open Souce INTelligence) pour enrichir les
événements.
Traitement de l’information et enrichissement
11. -Alertage par ElastAlert basé sur le type d’événement
-Tableaux de bords pour la conformité PCI-DSS et pour les opérations
-Elastic Maps pour afficher les connexions sur O365
-(En cours) Intégration de TheHive, pour le threat Management
-Recherche de données dans Discovery
Utilisation des données recueillies
17. -~30 jours de données en live
-Tâche journalière pour prendre un snapshot des index vers S3
-Gestion de la restauration des snapshots par Kibana
-(En cours) Cycle de vie dans S3 pour migrer les anciens index vers Glacier
Rétention des données d’événements
18. -Migration des champs vers ECS
-Index trop volumineux
-Sécurisation de Kibana (Avant ElasticSearch 7.1.0)
-Infrastructure bilingue
Problèmes rencontrés
19. -Quantité d’événements trop élevé pour être analysé par un humain
-Manque d’expertise et de ressources adaptées à notre environnement
-Problèmes de performance avec Logstash
Problèmes rencontrés
20. -Mise en place des fonctionnalités de la licence « Platinium »
-Migration d’ElastAlert vers Watcher pour l’alertage
-Mise en place d’un cluster de monitoring
-Développement de plus de tableaux de bord
-Migration vers Logstash en mode balance de charge
-Amélioration de l’enrichissement des données dans Logstash
Prochaines étapes
21. Olaf Hartong – Sysmon Modular | Configuration de Sysmon personnalisable
https://github.com/olafhartong/sysmon-modular
SwiftOnSecurity – Sysmon-Config | Configuration de Sysmon préconfigurée
https://github.com/SwiftOnSecurity/sysmon-config
Roberto Rodriguez et Jose Luis Rodriguez - Mordor | Source d’événements simulant plusieurs types d’attaques
https://github.com/hunters-forge/mordor
Roberto Rodriguez et Jose Luis Rodriguez – Threat Hunter Playbook | Collection d’information sur le Threat Hunting
https://threathunterplaybook.com/introduction
Florian Roth – SIGMA | Identification d’attaque basée sur des signatures génériques
https://github.com/Neo23x0/sigma
SOC Prime – Uncoder |Outil pour convertir des règles de format SIGMA vers d’autres SIEM
https://uncoder.io/#
MITRE – ATT&CK |Framework qui sert pour l’identification d’attaque basée sur différents types de techniques
https://attack.mitre.org/
Sources d’information pour débuter l’implémentation d’un SIEM
22. Roberto Rodriguez - The Hunting ELK (HELK) | Stack ElasticSearch sur mesure pour le Threat Hunting
https://github.com/Cyb3rWard0g/HELK
TheHive Project – TheHive (MISP/Cortex) | Plateforme de gestion de cas d’Indicident Response
https://thehive-project.org/
Santiago Bassett – Wazuh (HIDS) | Système de détection et d’Incident Response basé sur OSSEC
https://wazuh.com
Jose Antonio Izquierdo Lopez – OwlH| Système de gestion et visualisation d’IDS réseau
https://www.owlh.net/
Chris Hendricks – O365Beat | Beat pour transporter les logs d’audit d’Office365
https://github.com/counteractive/o365beat
Sources d’information pour débuter l’implémentation d’un SIEM