Sentinel Repositories (Preview)

Ich zeige auch, was ich in meiner Demo-Umgebung geändert habe, weil ich die Microsoft Sentinel-Architektur normalerweise etwas anders strukturiere. Gebt mir gern Feedback oder ladet das angepasste Skript für eure Umgebung herunter.

Das neue Feature

IaC ist einer der wichtigsten Schritte auf dem Weg in die Cloud. Denkt in jedem Prozessschritt des CAF (Cloud Adoption Framework) daran, später eine IaC-Architektur umzusetzen.

Es gibt verschiedene Möglichkeiten, IaC in Azure umzusetzen, zum Beispiel

• PowerShell
• ARM
• Bicep
• Terraform
• Ansible
• …

In diesem Blogbeitrag konzentriere ich mich auf ARM und Bicep, und ihr könnt diese Templates aus meinem GitHub-Repo herunterladen.

Okay, kommen wir zum Feature selbst. Microsoft hat das Feature „Repositories“ für GitHub und Azure DevOps als Source Control für Microsoft Sentinel implementiert. Ihr findet das Feature, wenn ihr die Sentinel-Ansicht öffnet.

Die Konfiguration ist ziemlich einfach: Klickt auf „Add new“, legt den Repository-Namen und die Source Control (GitHub oder Azure DevOps) fest, klickt dann auf Authorize und wählt euer Repository aus.

Neues Repository hinzufügen

Name und Source Control festlegen und autorisieren

Repository auswählen, Branch festlegen, Content-Typen festlegen und auf Create klicken

Das war’s schon :), aber was passiert im Hintergrund?

Es wird eine Azure App Registration hinzugefügt, die mit „Azure Sentinel Content Deployment App“ beginnt

Der App werden die RBAC-Berechtigungen „Microsoft Sentinel Contributor“ und „Log Analytics Contributor“ zugewiesen

Es wird ein GitHub Actions Secret mit den Informationen aus der Azure App erstellt

Dem Repository wird eine GitHub Action mit einem benutzerdefinierten PowerShell-Skript hinzugefügt

Wirklich einfach, aber für meine Umgebung nicht ausreichend, denn ich trenne SIEM- und SOAR-Dienste immer in unterschiedliche Azure-Ressourcengruppen. Der Grund dafür ist, dass ich so die RBAC-Berechtigungen besser handhaben kann und einen besseren Überblick über meine Ressourcen habe. Das habe ich also im Deployment-Prozess geändert.

Ich habe die Automation-Ressourcengruppe zur YML-Datei hinzugefügt

Ich habe die Möglichkeit ergänzt, die Templates nach Funktionalität zu sortieren

Erstellt Ordner im GitHub-Repository, um nach Funktionalität zu trennen

Abschnitt im Deployment-Skript „azure-sentinel-deploy.ps1“ hinzufügen/aktualisieren

Fügt die Variable für die Automation-Ressourcengruppe hinzu

Fügt eine Hashtable hinzu, um die richtige Ressourcengruppe für die Dienste festzulegen

Aktualisiert die Parameter der Funktion „AttemptDeployment“

Aktualisiert den Deployment-Prozess innerhalb der Funktion „AttemptDeployment“

Aktualisiert die „main“-Funktion

Das war’s: Jetzt könnt ihr alle eure Templates nach Funktionalität auf verschiedene Ordner aufteilen und die Playbooks zusätzlich in eine andere Ressourcengruppe bereitstellen. Der nächste Schritt ist, alle meine ARM-Templates in Bicep-Module zu überführen, weil sie dort viel einfacher zu lesen und zu schreiben sind.

Zum Schluss

Ich liebe das neue Feature, Repositories zu Microsoft Sentinel hinzuzufügen, aber für meine Umgebungen und die meiner Kunden gibt es noch Verbesserungspotenzial.