Klicken Sie, um die PDF-Version zu lesen
Absicherung Ihrer Dev's Workstation
Sie wollen nicht der Entwickler sein, der das Unternehmen mit Malware infiziert oder die Eintrittsquelle für einen Angreifer ist. Wie können wir sicher bleiben und trotzdem einen zufriedenen CISO haben, der die Sicherheitsregeln und -vorschriften einhält?
(Und natürlich eine voll funktionsfähige DevOps-Workstation).
Lernen Sie in unserem DevOps Bootcamp, wie Sie sichere Software mit sofortigen Feedback-Schleifen erstellen und diese mehrmals täglich in die Produktion überführen und dabei sicher und konform bleiben.
Auf dem Weg zum Kaninchenbau
Lassen Sie uns einen Ausflug in den Kaninchenbau machen, was typischerweise nach einem Datenschutzverstoß/Sicherheitsvorfall passiert. Die Geschäftsleitung oder ein CISO könnte Sie bitten, die Local Admin-Berechtigungen von Ihrem Laptop zu entfernen.
Ohne Local Admin ist die Installation und Aktualisierung einiger Software schwieriger, so dass wir uns auf ein Support-Team verlassen müssen, das (schnell) neue Softwareversionen für die Entwickler verpackt. Das verlangsamt sich natürlich, da das Support-Team nicht mit allen verpackten Anwendungsaktualisierungen Schritt halten kann.
Dann finden "sie" heraus, dass die Entwickler immer noch eine Menge portabler Anwendungen* (für deren Ausführung keine Administratorrechte erforderlich sind) betreiben.
Dies führt zu einem vollständigen "Application Allowlisting "** Szenario, bei dem nur eine Handvoll genehmigter Anwendungen ausgeführt werden darf. Dies verlangsamt natürlich die Produktivität der Entwickler, da keine kompilierte ausführbare Datei ausgeführt werden kann und jedes verwendete Tool zunächst vom Sicherheitsteam genehmigt werden muss.
Es wurde eine Lösung entwickelt, bei der die Entwickler von einer VM oder einem Docker-Container aus arbeiten. Dieser wiederum kann vom Entwickler für alle möglichen Dinge genutzt werden, einschließlich alltäglicher Aufgaben wie das Lesen seiner E-Mails oder die Installation von nicht arbeitsbezogener Software.
Schließlich finden "sie" heraus, dass der VM/Docker-Container mit Vollzugriff von den Entwicklern für alle Arten von Software verwendet wird. Sie verlangen, dass die Local Admin-Berechtigungen von dieser VM/Docker entfernt werden... und wir fangen wieder von vorne an.
Treten Sie einen Schritt zurück: Blick auf das Risikomanagement
Wenn wir einen Blick auf die Entwicklerpopulation werfen, können wir sie in mehrere Gruppen einteilen:
- Entwickler/Beitragende zum Code (Niedrige Privilegierte Konten)
- Projekt-/Pipeline-Administratoren (Mittel-/Hochprivilegierte Konten)
- Produktionszugang (Hochprivilegierte Konten)
Wir möchten Privileged Identity Management (PIM) für die Konten mit mittleren/hohen Privilegien und für den Produktionszugang verwenden, so dass jedes Mal, wenn ein Benutzer diese Berechtigungen benötigt, eine Erhöhung erforderlich ist. Dies wäre auch die Gruppe von Personen, die mit den sensibelsten Geheimnissen und geistigem Eigentum/Handelsgeheimnissen arbeiten.
Damit hat die Entwicklergruppe Zugriff auf den Quellcode, der in einer typischen Organisation keine militärischen Geheimnisse oder extrem vertraulichen Quellcode enthält. Unsere DevOps-Pipeline und das Vier-Augen-Prinzip beim Check-in/Merge bieten uns bereits eine gute erste Verteidigungslinie.
Wie wir in "Down the rabbit hole" gesehen haben, funktioniert das Blockieren (oder auch Application Allowlisting genannt) nicht bei allen Entwicklern sehr gut, so dass wir einen anderen Ansatz wählen müssen: Erkennung.
Mit Detection können die Entwickler alles, was sie wollen, auf ihren Laptops ausführen. Dazu steht ein fortschrittliches "Endpoint Detection and Response (EDR)"-Tool zur Verfügung, das bösartiges Verhalten erkennt. Das EDR-Tool kann verdächtige Prozesse/Speicherinjektionen erkennen und Verbindungen zu verdächtigen IP-Adressen aufspüren. Es funktioniert, indem es ungewöhnliches Verhalten auf dem System untersucht.
Wenn sich das EDR-Tool im Erkennungsmodus befindet, wird die Produktivität der Entwickler nicht beeinträchtigt, wie es im Blockiermodus der Fall wäre, der für normale Benutzer verwendet wird.
Das größte Risiko besteht in der Regel in nicht gepatchter Software, die häufig Ziel von Phishing-Angriffen ist. Unsere beste Verteidigungslinie beginnt natürlich mit der Aufklärung der Entwickler, indem wir sie darüber informieren, dass sie selbst angegriffen werden.
Eine der Möglichkeiten besteht darin, die gesamte Software auf dem Rechner des Entwicklers zu patchen, und zwar in Verbindung mit der Erkennungsfunktion eines EDR, die eine gute Verteidigungslinie darstellen sollte.
Hier kommen die Wirtschaftsprüfer
Die Geschäftsleitung/der CISO stimmt dem Vorschlag zu, wie Sie Ihren Entwicklerarbeitsplatz absichern können, aber schon bald stellen sie Fragen wie diese:
Ist der IT-Auditor mit dieser Situation zufrieden, wie halten die Entwickler ihre Rechner auf dem neuesten Stand und wie passt das mit den Unternehmensrichtlinien zusammen, die alles verbieten, und vieles mehr.
Wie können wir diesem Kaninchenbau entkommen?
Wenn wir einen Blick auf die internationale Norm ISO 27001 werfen, gibt es in Anhang A ein eigenes Kapitel (14) über Softwareentwicklung [1].
Wie bei allen Standards ist es sehr wichtig, sie zu lesen und die verschiedenen Begriffe zu verstehen, wie z.B. " müssen", "sollten", "berücksichtigen", "abhängen", "angemessen", usw.
In A.14.2.6 Sichere Entwicklungsumgebung sollten wir zum Beispiel die Sensibilität der Daten, Risikobewertungen und geschäftliche/rechtliche Anforderungen berücksichtigen. Zurück zu unserer ursprünglichen Vermutung: Wenn der Entwickler nicht mit Live-Produktionsdaten arbeitet und nicht an extrem wertvollem Code arbeitet, müssen wir nicht die gleichen Schritte unternehmen, die wir zum Schutz unserer sensiblen Daten/Dokumente unternehmen. Der Standard besagt, dass wir die Umgebung angemessen schützen müssen und sie nicht um jeden Preis einschränken dürfen!
Wir müssen den Code als "intern" und nicht als "streng geheim" einstufen, denn die Geheimnisse sollten nicht für alle Entwickler zugänglich sein. Mit dem Konzept des unternehmensinternen Quellcodes (interner Open Source) sollte fast der gesamte Quellcode nicht sensibel sein. So können Sie sich auf die wirklich sensiblen Teile konzentrieren, wie die DevOps-Pipeline oder das einzelne Team, das den Code Ihrer Geschäftsgeheimnisse verwaltet.
Lösungen
Wie können wir unser "Problem" lösen?
Schulung und Bewusstseinsbildung sollten immer an erster Stelle stehen, sonst ist es, als würde man die Stühle auf der Titanic umstellen. Darüber hinaus benötigen wir eine Kombination aus Werkzeugen und Prozessen.
Werkzeugbau
Es gibt mehrere Möglichkeiten, das Problem zu beheben:
- Identitätsschutz (AAD P2-Funktion);
- Privilegierte Identitätsverwaltung (AAD P2-Funktion);
- Defender for Endpoints (früher bekannt als Defender ATP, nicht zu verwechseln mit Defender Antivirus, das ein völlig anderes Produkt ist).
Mit Identity Protection können wir bedingte Zugriffsregeln festlegen, die auf risikoreichem Verhalten basieren, z. B. einem fremden Anmeldeort, einem Wechsel des Browsers oder einem plötzlichen Ortswechsel während einer Sitzung.
Privileged Identity Management ist das, was wir brauchen, wenn wir unsere Berechtigungen erhöhen müssen, um eine mittel- oder hochprivilegierte Aktion auszuführen. Dies ist das Least Privileged-Konzept: führen Sie nicht standardmäßig als hochprivilegiertes Konto aus.
Das letzte ist Defender for Endpoints - dies ist ein Endpoint Detection & Response (EDR) Tool, das verdächtiges Verhalten auf dem Rechner erkennen kann, wie verdächtige IP-Verbindungen, laufende Prozessänderungen, aber auch anfällige installierte Software. EDR kombiniert Alarmierung (und Blockierung/Quarantäne) mit Funktionen zum Schwachstellenmanagement, um die Endpunkte zu schützen.
Prozesse
Die folgenden Prozesse sind relevant:
- die Entwickler bei SOC-Warnungen als vorrangig zu untersuchende Mitarbeiter zu kennzeichnen.
- Patching und informieren den Entwickler automatisch über ungepatchte Software und Pakete.
- Das Security Operations Center mit Kenntnissen über die Entwicklung.
Wann immer ein Sicherheitswarnhinweis vom Security Operations Center (SOC) verarbeitet wird, sollten die Warnhinweise für Entwickler Vorrang vor den Untersuchungen für normale Benutzer im Unternehmen haben. Dadurch wird sichergestellt, dass verdächtiges Verhalten, wie z.B. Pakete/Skripte, die zusätzliche Inhalte aus dem Internet herunterladen, vorrangig untersucht wird.
Die beste Verteidigung besteht darin, den Rechner auf dem neuesten Stand zu halten (siehe: Hintergrundinformationen zum Patchen). Tools wie Defender for Endpoint können die anfällige Software erkennen, so dass ein Workflow oder vorzugsweise eine Automatisierung abläuft, um den Entwickler direkt über die Probleme auf seinem Rechner zu informieren. Diese direkte Feedbackschleife ist viel besser als ein monatlicher Bericht über den Zustand aller Rechner, der an den CISO geschickt wird.
Der letzte Erfolgsfaktor ist ein SOC-Team, das über Entwicklungskenntnisse verfügt. Wie sonst lässt sich eine Reihe verdächtiger Aktivitäten, gefolgt von einer Flut von Netzwerkverbindungen, auf einen Angriff oder nur auf das verwendete Test-Runner-Framework zurückführen?
Bewährte Verfahren: Hintergrundinformationen zum Patchen und Entfernen von Local Admin
Wir alle wissen, dass wir unsere Software patchen müssen, aber nur, wenn wir nicht gerade mitten in einer Refactoring-Sitzung sind.
Kombinieren Sie dies mit der Ausführung als lokaler Administrator und Sie haben eine potenzielle Katastrophe vor sich.
Aber was genau ist die Auswirkung des Entfernens von Local Admin? Laut dieser Studie[2] würden von den 192 kritischen Sicherheitslücken in Windows 102 durch das Entfernen der Local Admin-Berechtigungen gestoppt werden.
Eine weitere bewährte Methode zur Verringerung der Wahrscheinlichkeit der Verbreitung von Angriffen ist die Systemhärtung (insbesondere das Blockieren der Erstellung von Prozessen aus Office oder über WMI, die sehr häufig von Malware verwendet werden). Das Center for Internet Security(www.cisecurity.org) gibt Ihnen Empfehlungen, wie Sie Ihr System abhärten können. Wenn Sie das Endpoint Detection and Response (EDR)-Produkt einsetzen, erhalten Sie dort auch Empfehlungen, wie Sie die Sicherheit Ihres Systems erhöhen können.
Aber wenn wir uns die Gesamtzahl der kritischen Sicherheitslücken (192) ansehen, werden nur 2,5 % in freier Wildbahn genutzt, um Rechner zu übernehmen. Damit bleiben immer noch 5 kritische Punkte übrig, die durch Patches auf Ihrem Rechner behoben werden können.
Es gibt keine Entschuldigung dafür, Ihr System nicht zu patchen.
Schnelles Patchen ist die beste Verteidigung gegen fast alle Bedrohungen, also zögern Sie die Installation dieser Patches nicht lange hinaus.
Zusammenfassung
Patchen, patchen, patchen, patchen Sie einfach Ihre Rechner, keine Ausreden! Kombinieren Sie dies mit einem Warnsystem des EDR, bei dem Sie als Entwickler direkt über veraltete Software und fehlende Betriebssystem-Updates informiert werden.
Führen Sie Ihren DevOps-Arbeitsplatz nicht standardmäßig als Administrator aus, sondern als normaler Benutzer, und stellen Sie sicher, dass Sie das Local Admin-Konto verwenden können, um Ihre Berechtigungen vorübergehend auf Local Admin zu erhöhen. (Stellen Sie nur sicher, dass Sie/der Entwickler sich nicht mit diesem Konto anmelden können).
Wenden Sie Härtungsmaßnahmen auf dem System an, so dass z.B. das Auslösen von Prozessen durch Office-Anwendungen oder WMI (bekannte Malware-Techniken) blockiert wird. Dies wird auch als Reduktion der Angriffsfläche bezeichnet.
Aktivieren Sie eine Überwachungssoftware, die Ihnen hilft, verdächtiges Verhalten zu erkennen, verbunden mit einer direkten Rückmeldung an den Entwickler. Die Endpoint Detection and Response-Tools können Sie auch über verdächtige Aktionen informieren.
Legen Sie im SOC-Team eine Priorität für Sicherheitswarnungen für Entwicklerrechner und -konten fest, so dass Warnungen mit hoher Priorität von einem Team von SOC-Analysten mit Entwicklerwissen untersucht werden.
Aber das Wichtigste von allem ist kontinuierliches Training und Bewusstsein!
- Portable Apps sind ausführbare Dateien, die von einem Benutzerordner aus gestartet werden können, der nur Lesezugriff hat oder nicht verwaltet wird. Beispiele hierfür sind die Benutzerinstallation von Chrome oder Tools wie TeamViewer portable oder 7-Zip portable.
** Jede Änderung (durch einen Angreifer oder ein Software-Update) führt dazu, dass der Hash-Wert ungültig wird und die Anwendung blockiert wird.
Autor Erik Oppedijk (Berater bei Xpirit).
[1] ISO 27001 - Anhang A.14: Systembeschaffung, Entwicklung und Wartung
Verfasst von
Erik Oppedijk
Contact