Serveur d'impression

Azure Sentinel dans le monde réel – Examen de la virtualisation – Serveur d’impression

Le 31 juillet 2021 - 9 minutes de lecture


Azure Sentinel dans le monde réel

Les petites entreprises ont besoin des mêmes services de sécurité informatique que les grandes entreprises, mais sans le prix correspondant, explique Paul Schnackenburg. Il a donc décidé de « construire un SIEM pour les PME » avec un budget restreint.

À la mi-2019, nous avons examiné Azure Sentinel (alors récemment publié), la gestion des informations et des événements de sécurité basée sur le cloud (SIEM) de Microsoft. Dans cet article, je vais vous guider à travers un déploiement Sentinel dans le monde réel pour l'un de mes clients, les leçons apprises et quelques réflexions sur la cybersécurité des PME en général.

Coincé au milieu
Mon entreprise fournit des services informatiques aux PME depuis 1998, donc je connais intimement les défis et les limites de la "petite extrémité de la ville". Le passage au cloud est terminé pour la plupart de mes clients, certains étant encore dans un monde hybride avec quelques charges de travail sur site.

Tout comme les grandes entreprises, les PME ressentent la pression de la réduction des budgets informatiques, le défi de la pandémie de Covid et, surtout, l'évolution du paysage de la cybersécurité. Mais il n'y a aucun moyen qu'ils puissent se permettre une solution complète de détection et de réponse gérée (MDR), soutenue par un centre d'opérations de sécurité (SOC) 24/7/365.

Alors, je fais ce que je peux – je déploie un antimalware géré de manière centralisée sur chaque point de terminaison, je m'assure qu'ils disposent d'un pare-feu de classe affaires pour leurs bureaux, je dispense une formation de sensibilisation à la sécurité et des campagnes de phishing simulées et je configure leurs services cloud selon les meilleures pratiques. Je m'assure également qu'ils disposent de sauvegardes solides, avec des copies stockées hors site. Mais ma préoccupation est la même que pour de nombreuses grandes organisations, le manque de visibilité – si (quand) elles sont compromises, nous ne le saurons pas avant qu'il ne soit trop tard. C'est toujours le même dilemme : les PME ont besoin des mêmes services informatiques que les grandes entreprises, mais sans le prix correspondant.

Quand j'ai vu que Sentinel fournissait plusieurs sources de données gratuites (activité Azure, journaux d'audit Office 365 et alertes de la suite Microsoft 365 Defender) tant que je ne les conserve pas plus de 90 jours et que Sentinel a des connecteurs pour presque toutes les données source, j'ai décidé de voir si je pouvais "construire un SIEM pour les PME" avec un budget restreint.

Le client avec lequel j'ai commencé est une école indépendante avec environ 90 étudiants, de la 1re à la 12e, plus une vingtaine de membres du personnel. Ils ont Microsoft 365 A3 (équivalent à E3 dans le monde commercial) déployé pour tout le personnel et les étudiants et deux hôtes Dell Hyper-V sur site exécutant Windows Server 2019 avec un total de sept machines virtuelles. Le serveur le plus récent exécute toutes les machines virtuelles et l'ancien serveur se trouve dans un bâtiment séparé en tant que cible de réplique Hyper-V pour la reprise après sinistre. Les machines virtuelles sont deux contrôleurs de domaine, un serveur de fichiers/d'impression, une application LOB, Windows Server Update Services (WSUS), Microsoft Advanced Threat Analytics (ATA) et un serveur syslog Linux (plus sur ce dernier plus tard).

Connexion des sources de données
J'ai configuré un compte Azure pour le client, basé sur le même Azure Active Directory que leur locataire Microsoft 365, et déployé un espace de travail Log Analytics avec Azure Sentinel par-dessus dans la région Australie Est (j'utilise toujours https://www .azurespeed.com/ pour m'assurer que j'héberge des ressources dans la région la plus proche dans la mesure du possible). J'ai défini la rétention à 90 jours (car c'est gratuit), mais je sais que de nombreux professionnels de la sécurité s'étoufferont probablement avec leur café du matin en lisant cela car cela limite considérablement la capacité de trouver des intrus avec de longs temps de séjour – de nombreuses organisations (et cadres réglementaires ) nécessitent plusieurs années de conservation. Mais le but ici est de s'adapter à un petit budget et de fournir une visibilité pour attraper les méchants tôt, donc 90 jours c'est.

Ensuite, je configure les connecteurs de données (il y en a 116 parmi lesquels choisir au moment de la rédaction et d'autres sont ajoutés chaque semaine) – Azure AD, DNS, Office 365, événements de sécurité, Threat intelligence – TAXII et pare-feu Windows.

Deux d'entre eux sont de simples connecteurs cloud, fournissez simplement les informations d'identification de l'administrateur global (ou de l'administrateur de sécurité) et choisissez ce qu'il faut ingérer, voici la configuration pour AAD :


Connecteur Azure AD
[Click on image for larger view.] Connecteur Azure AD

La plupart des connecteurs sont fournis avec des classeurs pour la visualisation ; voici un classeur pour Office 365 :


Connecteur Azure AD
[Click on image for larger view.] Cahier d'activités Office 365

Ceux-ci vous permettent de visualiser et d'explorer l'activité normale de vos utilisateurs, dans ce cas ce qu'ils font sur OneDrive, Exchange, SharePoint et Teams.

Les connecteurs DNS, événements de sécurité et pare-feu Windows reposent sur les données de journal des machines virtuelles et des hôtes sur site. Sur chacun d'eux, j'ai installé l'agent de surveillance Microsoft (MMA) et je les ai configurés avec l'ID de l'espace de travail et la clé primaire de l'espace de travail Log Analytics. Il s'agit d'une installation simple Si vous avez des serveurs qui n'ont pas de connectivité Internet, vous pouvez utiliser la passerelle Log Analytics pour proxy les téléchargements, mais ce n'est pas un problème pour ce client. Si je devais le refaire, j'opterais plutôt pour le nouvel agent de surveillance Azure (AMA) car il s'agit du futur agent de collecte de journaux sur Windows et Linux. L'un des avantages de l'AMA réside dans les règles de collecte de données qui vous permettent de filtrer pour ne collecter que des entrées de journal spécifiques à l'aide de requêtes XPath, mais heureusement, le connecteur d'événements de sécurité avec MMA vous permet de filtrer les événements minimaux ou communs (ou tous). J'ai choisi Commun.

Encore une fois, dans un monde idéal, je déploierais également l'agent sur tous les points de terminaison client pour une visibilité complète de tous les événements de sécurité sur tous les nœuds (ce que je ferai chez mon prochain client qui n'a que 10 appareils clients et un serveur de fichiers NAS), mais chez ce client, je devrai surveiller attentivement le coût d'ingestion avant d'étendre la collecte de journaux.

Le dernier connecteur de données est Threat Intelligence — TAXII, qui est un moyen d'ingérer des données TI dans Sentinel. Sur la base de cet article de blog, je me suis connecté au flux d'informations gratuit d'Anomali pour obtenir des données sur les nouveaux domaines/IP de ransomware, les domaines de malware, les nœuds TOR, les serveurs C2 et les hôtes compromis.


Flux de renseignements sur les menaces
[Click on image for larger view.] Flux de renseignements sur les menaces

Règles, requêtes de journal et classeurs
Une fois que les données sont dans Sentinel, il est temps de les extraire pour détecter toute activité suspecte. Sentinel est livré avec des centaines de modèles de règles d'analyse intégrés. J'ai parcouru la liste (filtrage sur la gravité élevée et moyenne) pour commencer et je les ai tous activés qui reposaient sur les connecteurs de données dont nous disposons.

Voici un exemple d'une de ces règles – Connexions RDP rares – qui identifie lorsqu'une connexion nouvelle ou inhabituelle est établie avec l'un de nos serveurs (RDP n'est disponible que sur le réseau interne).


Règle d'analyse - Connexion RDP rare
[Click on image for larger view.] Règle d'analyse – Connexion RDP rare

J'ai configuré la plupart de ces règles pour qu'elles s'exécutent une fois par jour pour générer des alertes.

Lorsque vous essayez de comprendre les données dont vous disposez, vous pouvez utiliser les journaux pour explorer les différentes sources de données et tables. Ici, je regarde les données provenant du pare-feu Windows sur les serveurs.


Requête de journal - Pare-feu Windows
[Click on image for larger view.] Requête de journal – Pare-feu Windows

La plupart des connecteurs sont livrés avec un ensemble de classeurs, ce qui est une autre façon de visualiser les données. Voici le classeur des protocoles non sécurisés, qui regroupe les protocoles hérités utilisés par AD et AAD au cours des sept derniers jours.


Cahier d'exercices - Visualisation des protocoles non sécurisés
[Click on image for larger view.] Cahier d'exercices – Visualisation des protocoles non sécurisés

Automatisation
Les alertes dans le portail sont excellentes : une fois que vous les voyez, vous pouvez lancer une enquête pour déterminer s'il s'agit vraiment d'un problème malveillant nécessitant une enquête plus approfondie ou d'un faux positif bénin. Mais comme mentionné, il n'y a que moi et j'ai certainement mieux à faire que de rester assis et de regarder une interface utilisateur de portail toute la journée. Chaque règle d'alerte a la possibilité de configurer une réponse automatisée lorsqu'elle est déclenchée, mais je ne voulais pas avoir à la configurer et à la maintenir pour chaque règle, j'ai donc créé une seule application logique qui capte toute alerte et me l'envoie par e-mail ( et le professeur d'informatique local à l'école).

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.