Interne Technologieentwicklung

Heute möchten wir hinter die Kulissen unseres Security Assessments blicken, doch was ist das überhaupt? Kurz zusammengefasst, wir versetzen Sie in die Lage, bewusste Entscheidungen zu treffen und Ihre nächsten Schritte auf einer soliden, risikobewussten Basis zu planen und effektiv umzusetzen. Wenn Sie mehr über das Security Assessment erfahren möchten, sind Sie hier an der richtigen Adresse.

In diesem Blog soll der Schwerpunkt jedoch auf der internen technischen Weiterentwicklung unserer Umgebungsanalyse liegen. Wir sind sehr daran interessiert, Feedback zu erhalten und über unseren Weg zu diskutieren. Vielleicht können wir uns noch weiter verbessern?

Das Security Assessment

Die Inhalte gliedern sich in drei wesentliche Säulen, die Teal Consultants mit unseren Kunden Schritt für Schritt durchgehen.

• • Zunächst legen wir großen Wert darauf, dass Sie verstehen, wie Angreifer vorgehen, und wie Sie sich theoretisch schützen können. Das stellt ein intensiver Know-How Transfer zu Beginn des Assessments sicher.
  • Zudem ist eine umfassende Analyse Ihrer Umgebung mit derzeit 37 spezifischen Sicherheitschecks enthalten. Technik ist aber nicht alles! Ihre Arbeitsweisen lernen wir mit Hilfe unseres umfangreichen Fragebogens besser kennen.
  • Ein detaillierter Abschlussbericht, der eine Risikoanalyse und eine darauf aufbauende Empfehlung mit passenden Maßnahmen enthält, vervollständigt unseren Ansatz.

Die Umgebungsanalyse

Zur Analyse Ihrer Umgebung führen wir verschiedene etablierte Werkzeuge und Eigenentwicklungen aus. Anders als klassische Software-Anbieter von Sicherheitstools verbleiben unsere Tools jedoch nicht in Ihrer Umgebung, sondern müssen ohne viel Installations- und Konfigurationsaufwand nutzbar sein und nach der Analyse auch wieder verschwinden. Das hat dazu geführt, dass wir zu Beginn simple PowerShell-Skripte verwendet haben, um diese Tools nacheinander auszuführen. Jedes Tool hat dann individuell die gesammelten Daten abgelegt. Diese haben wir danach zur Auswertung mitgenommen.

Kann man so machen, aber…

Dieses Vorgehen hat zu zahlreichen Problemen geführt, unter anderem…

• • …wurde das Skript über die Zeit immer länger und unübersichtlicher
  • … je nachdem, wer das Skript erweiterte, bzw. die Eigenheiten eines Tools hatten Einfluss auf den Code, der verwendet wurde
  • …war es schwer, einheitlich zu definieren, welche Tools auf welchen Systemen auszuführen waren
  • …war an ein einheitliches Logging oder Troubleshooting nicht zu denken

All das führte dazu, dass wir uns grundlegend neu aufstellen wollten. Deswegen haben wir in einem internen Projekt unseren „Wrapper“ grundlegend neu konzipiert und neu aufgebaut.

Die Geburt unseres neuen Wrappers

Wir freuen uns, unseren neuen Wrapper vorzustellen, ein Zeugnis für Innovation und zukunftsorientiertes Design. Dieses Werkzeug ist nicht nur ein Produkt; es ist eine Lösung, die darauf abzielt, Einfachheit, Skalierbarkeit und Wartbarkeit in den Vordergrund von Assessment-Analysen zu stellen.

Kernfunktionen des Wrappers: Vereinfachung und Sicherheit

Vereinfachte Auswertung: Unser Wrapper vereinfacht den Prozess der Durchführung von Auswertungen über Active Directories und stellt sicher, dass die Datenerfassung sowohl effizient als auch umfassend ist.

Anpassbare Architektur: Das modulare Design der Wrapper-Architektur garantiert Flexibilität und eignet sich für eine Vielzahl von Active-Directory-Szenarien mit Leichtigkeit.

Erhöhte Sicherheit mit SMB-Shares: Sicherheit ist ein Eckpfeiler unseres Wrappers, der SMB-Shares nutzt, um alle Auswertungsergebnisse und Abhängigkeiten sicher zu halten, selbst bei Abstürzen oder Verbindungsverlusten.

PSSession Manager: Eine entscheidende Komponente, der PSSession Manager, orchestriert Sitzungen mit integriertem Logging, verwaltet Abhängigkeiten und konsolidiert Ergebnisse effektiv.

Die Stärke von PowerShell: Vergleich mit Bash

Beim Wechsel von Linux zu Windows war ich anfangs skeptisch gegenüber PowerShell. Doch es dauerte nicht lange, bis ich seine Einfachheit und Vielseitigkeit zu schätzen wusste. Die objektorientierte Natur von PowerShell machte die Handhabung komplexer Datenstrukturen zum Kinderspiel.

Als Beispiel, das die Benutzerfreundlichkeit von PowerShell unterstreicht, ist das Auflisten und Zählen von Dateien in einem Verzeichnis. Nehmen wir an, wir möchten die Anzahl der Textdateien in einem bestimmten Ordner ermitteln.

PowerShell:

In PowerShell ist dies mit einem einzigen Befehl möglich:

Dieser Befehl listet alle .txt-Dateien im Verzeichnis “C:\MeineDokumente” auf und gibt ihre Anzahl aus. Die Ausgabe ist klar und direkt, ohne dass zusätzliche Verarbeitungsschritte erforderlich sind.

Bash:

Im Vergleich dazu benötigt Bash mehrere Befehle, um das gleiche Ergebnis zu erzielen:

Hier verwendet „find“ eine Kombination aus Parametern, um die Dateien zu suchen, und „wc -l“ zählt sie. Dieser Prozess ist weniger intuitiv und erfordert ein tieferes Verständnis der Befehlszeilenoptionen.

Dieses Beispiel zeigt, wie PowerShell die Verwaltung von Dateisystemen vereinfacht, indem es leistungsstarke und benutzerfreundliche Cmdlets bereitstellt, die die Notwendigkeit für komplexe Befehlsketten eliminieren, die in traditionellen Shells wie Bash üblich sind.

Herausforderungen in der PowerShell-Entwicklung

Error Handling

Die PowerShell-Entwicklung bietet viele Vorteile, doch sie konfrontiert Entwickler auch mit Herausforderungen, insbesondere im Bereich des Error Handlings. Fehlermeldungen in PowerShell sind oft kryptisch und inkonsistent, was die Fehlersuche zu einer Geduldsprobe macht.

Ein Beispiel hierfür ist ein Skript, das versucht, eine Verbindung zu einem nicht erreichbaren Netzwerkpfad herzustellen, und PowerShell gibt lediglich aus:

„Fehler: Netzwerkpfad nicht gefunden“.

Ohne spezifische Hinweise bleibt der Entwickler ratlos, ob das Problem bei der Netzwerkverbindung, den Berechtigungen oder einem anderen Aspekt liegt.

Die Dokumentation für PowerShell und .NET wird dann zum unverzichtbaren Leitfaden, um die Bedeutung hinter den Fehlercodes zu entschlüsseln und Lösungswege zu finden.

Eine Verbesserung des Error Handlings könnte durch präzisere Fehlermeldungen und bessere Diagnosewerkzeuge erreicht werden, die Entwicklern helfen, Probleme effizienter zu lösen.

Die Grenzen der objektorientierten Programmierung in PowerShell

Die Herausforderungen, die PowerShell in Bezug auf die objektorientierte Programmierung (OOP) präsentierte, zwangen uns dazu, unser Entwicklungsmodell mehrmals zu überdenken und anzupassen. Obwohl PowerShell die OOP-Merkmale des .NET-Frameworks effektiv nutzt, stießen wir auf Grenzen beim nativen Erstellen von Klassen und Schnittstellen. Diese Beschränkungen veranlassten uns häufig, auf Sprachen wie C# auszuweichen, um unsere Ziele zu erreichen. Diese Notlösungen waren zwar wirksam, bedeuteten jedoch einen Kompromiss und waren weit entfernt von der idealen, nahtlosen Entwicklungserfahrung, die wir anstrebten.

Runspaces und OOP: Eine Herausforderung meistern

In PowerShell sind Runspaces ein grundlegendes Konzept für die parallele Ausführung von Aufgaben, was für die Verbesserung von Leistung und Effizienz wesentlich ist. Die OOP-Einschränkungen in PowerShell stellen jedoch eine einzigartige Herausforderung dar, wenn es darum geht, diese Runspaces vorzubereiten, insbesondere bei der Verwendung von Job-Runspaces.

Das Hauptproblem ergibt sich aus der Tatsache, dass das native Erstellen von Schnittstellen oder Klassen nicht auf die gleiche Weise unterstützt wird, wie bei traditionelleren OOP-Sprachen. Dies bedeutet, dass Entwickler oft Umwege finden müssen, um OOP-Prinzipien zu implementieren oder zu umgehen.

Die GetPreparationScript-Methode: Ein praktischer Workaround

Der Ansatz beinhaltet die Verwendung einer Methode, GetPreparationScript, um Vorbereitungsskripte und Werte zurückzugeben, die in die Laufzeit übergeben werden können. Diese Methode ist besonders nützlich für lokale Jobs, bei denen keine Sitzung im Voraus vorbereitet werden kann. Hier ist ein genauerer Blick auf den Workaround:

Dieser Skriptblock ist so konzipiert, dass er mit Parametern zurückgegeben wird, was ihn für lokale Jobs geeignet macht, bei denen keine PSSession vorbereitet werden kann. Er überprüft geschickt, ob die aktuelle Sitzung auf dem lokalen Rechner ist, und weist den Modulpfad entsprechend neu zu. Dann erstellt er ein neues PSDrive mit den angegebenen Parametern.

Fazit: Schnellere, stabilere Analysen für eine effizientere Risiko Mitigation

Mit dem neuen Wrapper ist es gelungen, die Stabilität und Geschwindigkeit einer Umgebungsanalyse maßgeblich zu verbessern. Hat es in älteren Versionen noch Stunden gedauert, bis alle Ergebnisse eingesammelt wurden, können wir mit der neuen Technologie die verschiedenen Skripte parallel starten und somit maßgeblich Zeit gewinnen.

Jede Kundenumgebung ist anders und auch heute müssen wir gelegentlich Fehler troubleshooten und beseitigen. Dies ist aber durch ein einheitliches Logging viel einfacher möglich.

Durch die Standardisierung ist es heute jedem Mitarbeiter möglich, ein neues Assessment/einen neuen Prüfpunkt zu definieren und schnell umzusetzen. Die Tage, an denen nur 1-2 Leute mit „Coding“-Skills das Assessment erweitern konnten, sind vorbei. Das hilft uns enorm, uns auf den eigentlichen Zweck, nämlich die Erweiterung des Assessments durch neue Prüfpunkte, zu konzentrieren.

Was zu Beginn gar nicht beabsichtigt war, sondern sich als weiterer Mehrwert etabliert hat, ist die SW-Verteilung in kritischen Bereichen. In unseren AD-Tiering-Projekten werden zu Beginn T0-Systeme definiert. Man kommt zwangsläufig zu der Frage: Wie kann man SW auf diese Systeme bringen bzw. installieren? Die etablierten SW-Deployment-Werkzeuge sind meistens im T1-Bereich angesiedelt und können deswegen nicht dafür herangezogen werden. Details zu diesem Thema in unserer Blog-Serie ESAE Deep Dive. Mit dem neuen Wrapper können jedoch nicht nur Assessments ausgebracht und ausgeführt werden. Am Ende ist der Wrapper ein Werkzeug, um Sources zu kopieren bzw. Dinge auf ein oder mehreren Remotesystemen auszuführen. Wir setzen den Wrapper bereits bei einigen Kunden genau zu diesem Zweck ein.

Zusammenfassend zeigt sich, dass wir mit der Umstellung nicht nur unser Assessment verbessert, sondern auch ein weiteres „Asset“ für unsere Beratungstätigkeiten entwickelt haben.