Seminar Enginsight Intensivseminar Gesamtplattform

Seminar / Training

Inhaltsübersicht

1. Einordnung und Lernziele
2. Technische Bausteine
3. Schrittweise Umsetzung
4. Praxisübungen und Szenarien
5. Betriebsstandards und Qualitätssicherung
6. Fehleranalyse und Wiederherstellung
7. Zielgruppe und Voraussetzungen

Einordnung und Lernziele

Kapitelinhaltsverzeichnis: die gesamte Enginsight-Architektur und ihre Komponenten sicher einordnen; eine Laborumgebung vom Onboarding bis zur Security-Auswertung aufbauen; Angriffsfläche, Schwachstellen, Ereignisse und Risiken zusammenführen; Schutz-, Automations- und Response-Maßnahmen kontrolliert umsetzen; Betriebs-, Rollen-, Reporting- und Compliance-Prozesse gestalten.

Alle zentralen Funktionsbereiche der Plattform werden in einem verdichteten End-to-End-Szenario verbunden: Administration, Inventarisierung, Monitoring, Endpoint-Schutz, Schwachstellen, Websecurity, Pentest, Shield, FIM, SIEM, Automation, Incident Response und Compliance.

Begründung der Dauer: Fünf Tage sind die maximal sinnvolle Dauer und erforderlich, um alle übrigen Fachseminare zusammenfassend abzudecken, ohne praktische End-to-End-Übungen und einen belastbaren Betriebsentwurf zu streichen.

Die Lernziele werden über nachvollziehbare Sollzustände, praktische Konfigurationen und überprüfbare Kontrollpunkte bearbeitet.

• die gesamte Enginsight-Architektur und ihre Komponenten sicher einordnen
• eine Laborumgebung vom Onboarding bis zur Security-Auswertung aufbauen
• Angriffsfläche, Schwachstellen, Ereignisse und Risiken zusammenführen
• Schutz-, Automations- und Response-Maßnahmen kontrolliert umsetzen
• Betriebs-, Rollen-, Reporting- und Compliance-Prozesse gestalten
• einen realistischen Einführungs- und Optimierungsplan erstellen

Technische Bausteine

Kapitelinhaltsverzeichnis: Plattformbetrieb, Rollen, Mandanten und Alarmierung; Pulsar, Watchdog, Observer und Hacktor; IT-Inventarisierung, Asset-Kontext und Monitoring; Schwachstellen-, Update- und Konfigurationsmanagement; IDS/IPS, Mikrosegmentierung und File Integrity Monitoring.

Die technischen Inhalte werden nicht isoliert betrachtet. Jede Funktion wird in Datenfluss, Verantwortlichkeit, Schutzbedarf und nachgelagerte Betriebsprozesse eingeordnet.

• Plattformbetrieb, Rollen, Mandanten und Alarmierung
• Pulsar, Watchdog, Observer und Hacktor
• IT-Inventarisierung, Asset-Kontext und Monitoring
• Schwachstellen-, Update- und Konfigurationsmanagement
• IDS/IPS, Mikrosegmentierung und File Integrity Monitoring
• Websecurity und automatisierte Penetrationstests
• SIEM, Detection Use Cases, Threat Hunting und Incident Response
• API, Automation, Reporting und Compliance-Nachweise

Schrittweise Umsetzung

Kapitelinhaltsverzeichnis: Tag 1: Zielarchitektur, Rollenmodell und Plattformgrundkonfiguration erstellen; Tag 1: Pulsar, Watchdog, Observer und Hacktor im Labor anbinden; Tag 2: Asset-Inventar konsolidieren und Monitoring-Baseline aufbauen; Tag 2: Schwachstellen priorisieren und Update- sowie Härtungsprozess planen; Tag 3: IDS/IPS, Mikrosegmentierung und FIM für kritische Assets konfigurieren.

Der folgende Ablauf bildet einen wiederholbaren Labor- und Betriebsprozess. Jeder Schritt endet mit einem dokumentierten Prüfpunkt, bevor die nächste Stufe begonnen wird.

1. Schritt 1
   Tag 1: Zielarchitektur, Rollenmodell und Plattformgrundkonfiguration erstellen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
2. Schritt 2
   Tag 1: Pulsar, Watchdog, Observer und Hacktor im Labor anbinden. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
3. Schritt 3
   Tag 2: Asset-Inventar konsolidieren und Monitoring-Baseline aufbauen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
4. Schritt 4
   Tag 2: Schwachstellen priorisieren und Update- sowie Härtungsprozess planen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
5. Schritt 5
   Tag 3: IDS/IPS, Mikrosegmentierung und FIM für kritische Assets konfigurieren. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
6. Schritt 6
   Tag 3: Websecurity und Hacktor-Audit mit abgesichertem Scope durchführen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
7. Schritt 7
   Tag 4: SIEM-Datenquellen prüfen und einen Security Use Case entwickeln. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
8. Schritt 8
   Tag 4: Angriffsszenario analysieren, eindämmen und als Incident dokumentieren. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
9. Schritt 9
   Tag 5: API-gestützten Folgeprozess und wiederkehrendes Reporting aufbauen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
10. Schritt 10
    Tag 5: Compliance-Evidenzen erzeugen und End-to-End-Abnahme durchführen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
11. Schritt 11
    Betriebsrisiken, offene Punkte und Prioritäten in einen Maßnahmenplan überführen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.
12. Schritt 12
    Rollenbezogenen Ausbaupfad für vertiefende Fachseminare festlegen. Zunächst werden Ziel, Verantwortlichkeit und benötigte Eingaben festgehalten. Anschließend erfolgt die Umsetzung in der Laborumgebung mit minimal erforderlichen Rechten. Der Abschluss besteht aus Funktionsprüfung, Sicherheitskontrolle und Dokumentation des Sollzustands.

Praxisübungen und Szenarien

Kapitelinhaltsverzeichnis: vollständiges Onboarding eines kleinen hybriden Laborverbunds; risikobasierte Bearbeitung eines Schwachstellenpakets; Segmentierungs- und FIM-Schutz für ein kritisches Zielsystem; kombinierter Hacktor-, SIEM- und Incident-Response-Fall; Managementbericht und Audit-Evidenz aus demselben Datenbestand.

Die Übungen werden mit klar abgegrenzten Testdaten und Rückfalloptionen durchgeführt. Zu jedem Szenario gehören Ausgangslage, Arbeitsauftrag, erwartete Beobachtung, Prüfkriterium und dokumentierte Abweichung.

1. vollständiges Onboarding eines kleinen hybriden Laborverbunds
2. risikobasierte Bearbeitung eines Schwachstellenpakets
3. Segmentierungs- und FIM-Schutz für ein kritisches Zielsystem
4. kombinierter Hacktor-, SIEM- und Incident-Response-Fall
5. Managementbericht und Audit-Evidenz aus demselben Datenbestand
6. Abschlusslabor mit Fehlerdiagnose und kontrollierter Wiederherstellung

Betriebsstandards und Qualitätssicherung

Kapitelinhaltsverzeichnis: Komponentenverantwortung und Datenflüsse in einer Betriebsarchitektur dokumentieren; Änderungen über Pilot, Review und Freigabe kontrollieren; Alarm-, Ticket- und Eskalationswege regelmäßig testen; Security-Kennzahlen mit Maßnahmen und Eigentümern verbinden; Vertiefungsthemen nach Rolle und Risikoprofil priorisieren.

Die Überführung in den Regelbetrieb erfolgt über definierte Eigentümer, Freigaben, Messwerte und Review-Termine. Konfigurationen werden erst nach positiver Laborprüfung und dokumentierter Abnahme ausgeweitet.

• Komponentenverantwortung und Datenflüsse in einer Betriebsarchitektur dokumentieren
• Änderungen über Pilot, Review und Freigabe kontrollieren
• Alarm-, Ticket- und Eskalationswege regelmäßig testen
• Security-Kennzahlen mit Maßnahmen und Eigentümern verbinden
• Vertiefungsthemen nach Rolle und Risikoprofil priorisieren

Fehleranalyse und Wiederherstellung

Kapitelinhaltsverzeichnis: mehrere Komponenten melden denselben Sachverhalt unterschiedlich; Asset-Kontext fehlt bei einem kritischen SIEM-Ereignis; Schutzmaßnahme beeinflusst einen Geschäftsprozess; Automatisierung wird ohne ausreichende Vorprüfung ausgelöst; Compliance-Bericht lässt sich nicht bis zur technischen Evidenz zurückverfolgen.

Die Diagnose folgt einer festen Reihenfolge: Symptom eingrenzen, letzte Änderung bestimmen, Datenpfad prüfen, Berechtigungen kontrollieren, Gegenprobe ausführen und nur danach eine Änderung vornehmen. Jede Korrektur wird mit einem Negativ- und einem Positivtest verifiziert.

• mehrere Komponenten melden denselben Sachverhalt unterschiedlich
• Asset-Kontext fehlt bei einem kritischen SIEM-Ereignis
• Schutzmaßnahme beeinflusst einen Geschäftsprozess
• Automatisierung wird ohne ausreichende Vorprüfung ausgelöst
• Compliance-Bericht lässt sich nicht bis zur technischen Evidenz zurückverfolgen

Zielgruppe und Voraussetzungen

Kapitelinhaltsverzeichnis: Rollenprofil; erforderliches Vorwissen; Laborzugang; organisatorische Vorbereitung.

Teilnehmerkreis: Plattformverantwortliche, Senior Administration, Security Engineering, SOC, technische Beratung und angehende Enginsight-Generalisten.

Fachliche Voraussetzungen: Solide Kenntnisse zu Netzwerk, Servern, Clients und IT-Security; vorbereitete Laborumgebung und Bereitschaft zu umfangreichen Praxisübungen.

Für praktische Übungen werden administrative Rechte ausschließlich in der vorbereiteten Laborumgebung benötigt. Produktive Änderungen gehören nicht zum Seminarbetrieb.