ELK dans le cloud – Le SIEM par excellence ?

SIEM késako ?

Un SIEM (Security Information and event management) permet de corréler et centraliser les logs d’un parc aidant à l’analyse en temps réel et à la surveillance de différents incidents de sécurité. Il y a plusieurs phases (On ne les citera pas toutes):

• Collecte : Récupération des logs des équipements et des machines
• Normalisation : Ces logs sont stockés sous un format facilement lisible permettant de faire des recherches sur plusieurs critères
• Corrélation : Des règles qui permettent d’identifier un évènement qui a causé le déclenchement d’alertes
• Reporting : Visualisation et génération de dashboards et de rapports

Elastic Cloud on Kubernetes et son opérateur

Elastic Cloud automatise le déploiement, le provisionning (lol ! Pas on-premise), le management et l’orchestration des outils Elasticsearch, Kibana, Beats et bien d’autres que nous ne verrons pas ici.

Je pars du principe que vous avez déjà un cluster k8s avec un node d’au moins 8Go avec 2 CPU :)

Mon environnement sur VMware vSphere :

• CentOS 8 – Filebeat, Packetbeat, Auditdbeat et Metricbeat
• Windows 10 – Winlogbeat, Packetbeat
• Cluster k8s (Sur debian ou Ubuntu Server, il n’aime pas trop CentOS)

Je parle beaucoup mais comment qu’on installe ?

Tout d’abord, j’ai installé Elastic Cloud qui déploie un opérateur et des pods particuliers qui permettent l’installation d’Elasticsearch et ensuite Kibana:

kubectl apply -f https://download.elastic.co/downloads/eck/1.3.1/all-in-one.yaml 

Si vous n’êtes pas fans comme moi des longues commandes vous pouvez stocker la configuration dans un fichier .yaml (c mieu)

Un déploiement Elasticsearch pas si automatisé

J’ai suivi la doc ECK – https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-deploy-eck.html (à 3 pattes)

cat <<EOF | kubectl apply -f -
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 7.10.2
   nodeSets: 
   - name: default
   count: 1
   config:
     node.store.allow_mmap: false
   VolumesClaimTemplates:
     - metadata:
         name: elasticsearch-data
      spec:
          accessModes:
          - ReadWriteOnce
          resources:
             requests:
               storage: 10Gi
             storageClassName: standard
 EOF 

Encore une fois je préfère enregistrer dans un fichier yaml (quickstart-es.yaml). On va maintenant analyser notre déploiement :

kubectl get elasticsearch

Eh bah mince alors ça ne se déploie pas, pourquoi ?

En effet, je ne suis pas sur un cluster k8s managé comme sur Azure ou Google. Le provisionning ne se fait pas dynamiquement, je dois le faire manuellemennt (les joies des infra on-premise).

On va lé vérifier :

kubectl describe pod quickstart-es-default-0

Tout d’abord, il faut créer un StorageClass qui correspondra à celui de la configuration Elastic Cloud, mais je n’ai pas de provisionner étant donné que je ne suis pas dans le cloud. Comment faire ?
On va tout d’abord supprimer le déploiement Elasticsearch

kubectl delete -f quickstart-es.yaml

La documentation k8s et oui – https://kubernetes.io/docs/concepts/storage/storage-classes/#local

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

Cela m’a permis d’éviter un CrashLoopBackOff des pods.
Ensuite, il faut lier un volume persistent au claim (PVC) et au StorageClass.

 apiVersion: v1
 kind: PersistentVolume
 metadata:
   name: pv-volume-es
   labels:
     type: local
 spec:
   storageClassName: standard
   capacity:
     storage: 10Gi
   accessModes:
     - ReadWriteOnce
   hostPath:
     path: "/elasticsearch-data" 

On déploie à nouveau notre Elasticsearch

kubectl apply -f quickstart-es.yaml

Et là notre pod Elasticsearch est fonctionnel ! Maaaagic ?

Déploiement de Kibana

J’ai suivi la doc – https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-deploy-kibana.html (ça fonctionne lol)

cat <<EOF | kubectl apply -f -
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 7.10.2
  count: 1
  elasticsearchRef:
    name: quickstart
EOF

Kibana se déploie magiquement :)

Edition des services et magie du « cloude »

Je vais maintenant changer le type de service des déploiements Elasticsearch et Kibana. En effet, on utilise actuellement un service de type ClusterIP qui donne un accès seulement qu’à partir du cluster. J’utiliserais NodePort qui donne un accès à l’extérieur du cluster.
On vérifie donc les services :

kubectl edit service quickstart-es-http

Et là je modifie ClusterIP en NodePort. On effectue la même manip pour Kibana.

J’obtiens un port random, je contacte à partir de n’importe lequel de mes nodes ce port dans mon navigateur et voici qu’apparaît mes pages de login.
On est maintenant capable de contacter cette magnifique interface.

Et le SIEM dans tout ça ?

ENFIN ! Nous arrivons dans la partie la plus intéressante, celle qui concerne la capacité de détection du SIEM. C’est tout simple, il est intégré nativement à ECK. Nous avons justement un bloc « Security » dans l’image précédente. Vous cliquez dessus et serez dans la partie détection.

Il y a un panel de règles que nous pouvons activer par défaut. Celles-ci traitent différents cas allant de la détection de l’injection de processus sur Windows, à la détection des accès aux informations d’identifications chez différents fournisseurs cloud comme Azure, AWS, Alibaba etc..
Tout ça pour vous dire que les règles de détection sont variées. Vous pouvez également créer vos règles de détection qui peuvent être basées sur YARA, Sigma ou encore KQL (Kibana Query Language).

Comment générer des logs ?
En effet, Elastic a développé ce qu’on appelle des Beats qui sont des agents légers avec des fonctionnalités spécifiques. Par exemple, un Beat qui collectera les logs dans « /var/log », un autre qui va envoyer des traces réseaux etc…
Lien vers documentation : https://www.elastic.co/beats/

Comment détecter et réagir face aux menaces ?
Pour cela, il faut utiliser Elastic Agent en activant la fonctionnalité sécurité. Cet agent agira en tant qu’Endpoint Detection Response pour répondre à toute menace sur un poste. Il y a deux types de fonctionnement, l’un dit « Prevent » qui va détecter, bloquer et génerer une alerte et l’autre dit « Detect » qui va détecter et générer une alerte. Si vous êtes dans un lab, il vaudrait mieux privilégier l’option « Detect » qui permet ensuite d’analyser le comportement de la menace et « Prevent » en production. Néanmoins, cette technologie est toujours en BETA test, il vaut mieux attendre une sortie plus stable.

En conclusion, Elastic Cloud on Kubernetes est un SIEM complet, gratuit et open source permettant d’améliorer drastiquement son niveau de sécurité. La capacité de détection assez intéressante permet éventuellement de faire de la production même si cela n’est pas conseillé.
Même si ce n’est pas Splunk Entreprise ou QRadar, cet outil a tout pour être un SIEM de qualité ainsi un SOC pourrait faire des merveilles.