Sicherheit bei DevOps (DevSecOps)

Sicherheit ist ein wesentlicher Aspekt von DevOps. Aber wie kann ein Team wissen, ob ein System sicher ist? Ist es wirklich möglich, einen völlig sicheren Dienst anzubieten?

Leider lautet die Antwort nein. DevSecOps ist eine kontinuierliche und fortlaufende Aufgabe, die die Aufmerksamkeit aller Mitarbeiter in Entwicklung und IT-Betrieb erfordert. Die Arbeit ist zwar nie wirklich getan, aber die Praktiken, die Teams anwenden, um Verstöße zu verhindern und zu bewältigen, können dazu beitragen, dass die Systeme so sicher und widerstandsfähig wie möglich sind.

„Grundsätzlich gilt: Wenn jemand einsteigen will, wird er auch einsteigen...akzeptieren Sie das. Was wir unseren Kunden sagen, ist: Erstens, Sie sind im Kampf, ob Sie es glauben oder nicht. Zweitens: Sie sind mit ziemlicher Sicherheit infiltriert.“ -- Michael Hayden, ehemaliger Direktor der NSA und der CIA

Das Sicherheitsgespräch

Teams, die noch keine formale DevSecOps-Strategie haben, müssen so bald wie möglich mit der Planung beginnen. Anfangs kann es zu Widerständen von Teammitgliedern kommen, die die bestehenden Gefahren nicht richtig einschätzen. Andere haben vielleicht das Gefühl, dass das Team nicht für das Problem gerüstet ist und dass jede besondere Investition eine unnötige Ablenkung von der Bereitstellung von Features wäre. Es ist jedoch notwendig, mit dem Gespräch zu beginnen, um einen Konsens über die Art der Risiken zu erzielen, wie das Team sie abmildern kann und ob das Team Ressourcen benötigt, die es derzeit nicht hat.

Erwarten Sie, dass Skeptiker einige gängige Argumente vorbringen. Beispiel:

• Wie real ist die Bedrohung? Die Teams wissen oft nicht, welchen Wert die Dienste und Daten haben, die sie schützen sollen.
• Unser Team ist gut, richtig? Eine Sicherheitsdiskussion kann als Zweifel an der Fähigkeit des Teams, ein sicheres System zu entwickeln, wahrgenommen werden.
• Ich glaube nicht, dass das möglich ist. Dies ist ein häufiges Argument von Nachwuchstechnikern. Diejenigen mit Erfahrung wissen es in der Regel besser.
• Wir hatten noch nie eine Sicherheitsverletzung. Aber woher wissen Sie das? Wie können Sie das wissen?
• Endlose Debatten über den Wert. DevSecOps ist eine ernsthafte Verpflichtung, die als Ablenkung von der eigentlichen Arbeit empfunden werden kann. Die Investition in die Sicherheit sollte zwar mit anderen Anforderungen abgewogen werden, aber sie kann nicht ignoriert werden.

Der Mentalitätswandel

Die DevSecOps-Kultur erfordert eine wichtige Änderung der Denkweise. Sie müssen nicht nur Verstöße verhindern, sondern auch annehmen.

Komponenten der Sicherheitsstrategie

Es gibt viele Techniken, die bei der Suche nach sichereren Systemen eingesetzt werden können.

Verhindern von Sicherheitsverletzungen	Annehmen von Sicherheitsverletzungen
Bedrohungsmodelle	Übungen für den Ernstfall
Codebewertungen	Zentrale Sicherheitsüberwachung
Sicherheitstests	Penetrationstests für Livewebsites
Security Development Lifecycle (SDL)

Jedes Team sollte bereits über einige Praktiken zur Verhinderung von Sicherheitsverletzungen verfügen. Das Schreiben von sicherem Code ist zu einem Standard geworden, und es gibt viele kostenlose und kommerzielle Tools, die Sie bei statischer Analyse und anderen Sicherheitstestfeatures unterstützen.

Vielen Teams fehlt jedoch eine Strategie, die davon ausgeht, dass Systemverletzungen unvermeidlich sind. Die Annahme, dass eine Sicherheitslücke vorliegt, kann schwer einzugestehen sein, insbesondere bei schwierigen Gesprächen mit der Geschäftsleitung. Sie wollen das nicht alles während eines echten Sicherheitsnotfalls herausfinden.

Zu den allgemeinen Fragen, die man sich stellen sollte, gehören:

• Wie werden Sie einen Angriff erkennen?
• Wie reagieren Sie auf einen Angriff oder eine Penetration?
• Wie werden Sie sich von einem Angriff erholen, z. B. wenn Daten durchgesickert oder manipuliert worden sind?

Wichtige DevSecOps-Praktiken

Es gibt mehrere allgemeine DevSecOps-Praktiken, die für praktisch jedes Team gelten.

Konzentrieren Sie sich zunächst auf die Verbesserung von mittlere Zeit bis zur Entdeckung und mittlere Zeit bis zur Wiederherstellung. Diese Kennzahlen geben an, wie lange es dauert, bis eine Sicherheitsverletzung entdeckt wird, bzw. wie lange es dauert, sie zu beheben. Sie können durch laufende Tests der Sicherheitspläne vor Ort verfolgt werden. Bei der Bewertung potenzieller politischer Maßnahmen sollte die Verbesserung dieser Kennziffern ein wichtiger Aspekt sein.

Üben Sie Verteidigung in der Tiefe. Wenn es zu einem Einbruch kommt, können Angreifer Zugang zu internen Netzen und allem, was sich darin befindet, erhalten. Es wäre zwar ideal, Angreifer zu stoppen, bevor es so weit kommt, aber eine Politik, die davon ausgeht, dass es zu Sicherheitsverletzungen kommt, veranlasst die Teams, die Gefährdung durch einen Angreifer, der bereits eingedrungen ist, zu minimieren.

Und schließlich müssen Sie Ihre Verfahren und Umgebungen regelmäßig nach einem Einbruch bewerten. Nachdem ein Verstoß behoben wurde, sollte Ihr Team die Leistung der Richtlinien sowie die eigene Einhaltung der Richtlinien bewerten. Richtlinien sind am wirksamsten, wenn die Teams sie tatsächlich befolgen. Jeder Verstoß, ob real oder eingeübt, sollte als Chance zur Verbesserung gesehen werden.

Strategien zum Reduzieren von Bedrohungen

Es gibt zu viele Bedrohungen, um sie alle aufzuzählen. Einige Sicherheitslücken sind auf Probleme in Abhängigkeiten wie Betriebssystemen und Bibliotheken zurückzuführen, sodass Sie diese unbedingt auf dem neuesten Stand halten müssen. Andere sind auf Fehler im Systemcode zurückzuführen, die sorgfältige analysiert und behoben werden müssen. Schlechtes Geheimnismanagement ist ebenso wie Social Engineering die Ursache vieler Sicherheitsverletzungen. Es ist eine gute Praxis, über die verschiedenen Arten von Sicherheitslücken nachzudenken und darüber, was sie für das System bedeuten.

Angriffsvektoren

Stellen Sie sich ein Szenario vor, in dem sich ein Angreifer Zugang zu den Anmeldedaten eines Entwicklers verschafft hat. Was können sie tun?

Recht	Angriffs-
Können sie E-Mails versenden?	Phish-Kollegen
Können sie auf andere Rechner zugreifen?	Einloggen, mimikatz, wiederholen
Können sie die Quelle ändern	Code einspeisen
Können sie den Build/Release-Prozess ändern?	Code einschleusen, Skripte ausführen
Können sie auf eine Testumgebung zugreifen?	Wenn eine Produktionsumgebung eine Abhängigkeit von der Testumgebung eingeht, nutzen Sie sie aus
Können sie auf die Produktionsumgebung zugreifen?	So viele Möglichkeiten...

Wie kann sich Ihr Team gegen diese Vektoren schützen?

• Geheimnisse in geschützten Tresoren aufbewahren
• Lokale Administratorkonten entfernen
• SAMR einschränken
• Credential Guard
• Dual-Homed-Server entfernen
• Getrennte Abonnements
• Multi-Factor Authentication
• Arbeitsstationen mit privilegiertem Zugriff
• Erkennung mit ATP & Microsoft Defender für Cloud

Verwaltung von Geheimnissen

Alle Geheimnisse müssen in einem geschützten Tresorraum aufbewahrt werden. Zu den Geheimnissen gehören:

• Kennwörter, Schlüssel und Token
• Speicherkontoschlüssel
• Zertifikate
• Zugangsdaten, die auch in gemeinsam genutzten Nicht-Produktionsumgebungen verwendet werden

Sie müssen eine Hierarchie von Tresoren verwenden, um die Verdoppelung von Geheimnissen zu vermeiden. Überlegen Sie auch, wie und wann auf Geheimnisse zugegriffen wird. Einige werden bei der Erstellung von Umgebungskonfigurationen zur Verteilungszeit verwendet, während auf andere zur Laufzeit zugegriffen wird. Bereitstellungsgeheimnisse erfordern in der Regel eine neue Bereitstellung, um neue Einstellungen zu übernehmen, während auf Laufzeitgeheimnisse bei Bedarf zugegriffen wird und sie jederzeit aktualisiert werden können.

Plattformen verfügen über sichere Speicherfunktionen für die Verwaltung von Geheimnissen in CI/CD-Pipelines und Cloud-Umgebungen, wie Azure Key Vault und GitHub Actions.

Nützliche Tools

• Microsoft Defender for Cloud eignet sich hervorragend für allgemeine Infrastrukturwarnungen, z. B. für Malware, verdächtige Prozesse usw.
• Quellcode-Analysetools für statische Sicherheitstests von Anwendungen (SAST).
• GitHub advanced security zur Analyse und Überwachung von Repos.
• mimikatz extrahiert Passwörter, Schlüssel, Pincodes, Tickets und mehr aus dem Speicher von lsass.exe, dem Local Security Authority Subsystem Service unter Windows. Es erfordert lediglich administrativen Zugriff auf den Rechner oder ein Konto mit aktiviertem Debug-Recht.
• BloodHound erstellt ein Diagramm der Beziehungen innerhalb einer Active Directory-Umgebung. Es kann vom roten Team verwendet werden, um Angriffsvektoren zu identifizieren, die schwer zu erkennen sind.

Übungen für den Ernstfall

Eine gängige Praxis bei Microsoft ist die Durchführung von War-Game-Übungen. Dabei handelt es sich um Sicherheitstests, bei denen zwei Teams die Aufgabe haben, die Sicherheit und die Richtlinien eines Systems zu testen.

Das Team red übernimmt die Rolle eines Angreifers. Sie versuchen, reale Angriffe zu modellieren, um Sicherheitslücken zu finden. Wenn sie diese ausnutzen können, zeigen sie auch die möglichen Auswirkungen ihrer Verstöße.

Das Team blue übernimmt die Rolle des DevOps-Teams. Sie testen ihre Fähigkeit, die Angriffe des roten Teams zu erkennen und darauf zu reagieren. Dies trägt dazu bei, das Situationsbewusstsein zu verbessern und die Bereitschaft und Wirksamkeit der DevSecOps-Strategie zu messen.

Entwickeln Sie eine Strategie für Kriegsspiele

Kriegsspiele sind ein wirksames Mittel zur Verbesserung der Sicherheit, da sie das rote Team dazu motivieren, Probleme zu finden und auszunutzen. Am Anfang wird es wahrscheinlich viel einfacher sein als erwartet. Teams, die noch nicht aktiv versucht haben, ihre eigenen Systeme anzugreifen, sind sich in der Regel nicht bewusst, wie groß und zahlreich die Sicherheitslücken sind, die Angreifern zur Verfügung stehen. Das blaue Team könnte anfangs demoralisiert sein, da es immer wieder überfahren wird. Glücklicherweise müssen sich das System und die Praktiken im Laufe der Zeit so entwickeln, dass das blaue Team immer gewinnt.

Vorbereitungen für Kriegsspiele

Bevor die Kriegsspiele beginnen, sollte sich das Team um alle Probleme kümmern, die es in einem Sicherheitspass finden kann. Dies ist eine großartige Übung, die vor einem Angriffsversuch durchgeführt werden sollte, da sie eine Basiserfahrung liefert, mit der sich alle vergleichen können, wenn der erste Exploit später gefunden wird. Beginnen Sie mit der Identifizierung von Schwachstellen durch eine manuelle Codeüberprüfung und statische Analysetools.

Organisieren Sie Teams

Rote und blaue Teams müssen nach Spezialgebieten organisiert werden. Ziel ist es, für jede Seite die fähigsten Teams zusammenzustellen, um so effektiv wie möglich zu arbeiten.

Dem roten Team müssen einige sicherheitsbewusste Ingenieure und Entwickler angehören, die mit dem Code bestens vertraut sind. Es ist auch hilfreich, das Team mit einem Spezialisten für Penetrationstests zu verstärken, falls möglich. Wenn es im Unternehmen keine Fachleute gibt, bieten viele Unternehmen diese Dienstleistung zusammen mit der Betreuung an.

Das blaue Team sollte aus Ingenieuren bestehen, die sich mit dem Betrieb auskennen und ein tiefes Verständnis für die verfügbaren Systeme und die Protokollierung haben. Sie haben die besten Chancen, verdächtiges Verhalten zu erkennen und darauf zu reagieren.

Frühe Kriegsspiele durchführen

Erwarten Sie, dass das rote Team in den ersten Kriegsspielen erfolgreich sein wird. Sie müssen in der Lage sein, durch relativ einfache Angriffe erfolgreich zu sein, z. B. durch das Auffinden schlecht geschützter Geheimnisse, SQL-Injection und erfolgreiche Phishing-Kampagnen. Nehmen Sie sich zwischen den Runden ausreichend Zeit, um Korrekturen vorzunehmen und Feedback zu den Maßnahmen zu geben. Dies ist von Organisation zu Organisation unterschiedlich, aber Sie müssen die nächste Runde erst dann beginnen, wenn alle sicher sind, dass die vorherige Runde voll ausgeschöpft wurde.

Laufende Kriegsspiele

Nach einigen Runden muss das rote Team auf ausgefeiltere Techniken zurückgreifen, z. B. Cross-Site-Scripting (XSS), Deserialisierungsexploits und technische Systemschwachstellen. Die Hinzuziehung von externen Sicherheitsexperten für Bereiche wie Active Directory kann hilfreich sein, um obskure Sicherheitslücken zu schließen. Zu diesem Zeitpunkt sollte das blaue Team nicht nur über eine gehärtete Plattform zur Verteidigung verfügen, sondern auch eine umfassende, zentralisierte Protokollierung für die Forensik nach einem Einbruch nutzen.

„Verteidiger denken in Listen. Angreifer denken in Diagrammen. Solange dies der Fall ist, gewinnen die Angreifer.“ -- John Lambert (MSTIC)

Mit der Zeit wird das rote Team viel länger brauchen, um seine Ziele zu erreichen. Wenn dies der Fall ist, müssen oft mehrere Schwachstellen entdeckt und miteinander verknüpft werden, um eine begrenzte Wirkung zu erzielen. Durch den Einsatz von Echtzeit-Überwachungstools sollte das blaue Team beginnen, Versuche in Echtzeit zu erkennen.

Richtlinien

Kriegsspiele müssen kein Spiel für alle sein. Es ist wichtig zu erkennen, dass das Ziel darin besteht, ein effektiveres System zu schaffen, das von einem effektiveren Team betrieben wird.

Verhaltenskodex

Hier finden Sie ein Beispiel für einen von Microsoft verwendeten Verhaltenskodex:

1. Sowohl das rote als auch das blaue Team werden keinen Schaden anrichten. Ist das Schadenspotenzial erheblich, sollte es dokumentiert und angegangen werden.
2. Das rote Team sollte nicht mehr gefährden als nötig, um die Zielobjekte zu erbeuten.
3. Für physische Angriffe gelten die Regeln des gesunden Menschenverstands. Das rote Team darf zwar bei nichttechnischen Angriffen, wie z. B. Social Engineering, kreativ sein, sollte aber keine gefälschten Ausweise drucken, Personen belästigen usw.
4. Wenn ein Social-Engineering-Angriff erfolgreich ist, müssen Sie den Namen der Person, die kompromittiert wurde, nicht preisgeben. Die Lektion kann weitergegeben werden, ohne ein Teammitglied zu entfremden oder in Verlegenheit zu bringen, mit dem alle weiter zusammenarbeiten müssen.

Regeln für den Einsatz

Hier finden Sie einige Beispiele für die von Microsoft verwendeten Verhaltensregeln:

1. Sie beeinträchtigen nicht die Verfügbarkeit eines Systems.
2. Greifen Sie nicht auf externe Kundendaten zu.
3. Schwächen Sie die vorhandenen Sicherheitsvorkehrungen bei keinem Dienst erheblich.
4. Führen Sie nicht absichtlich zerstörerische Aktionen gegen Ressourcen durch.
5. Schutz von Anmeldedaten, Schwachstellen und anderen wichtigen Informationen.

Ergebnisse

Etwaige Sicherheitsrisiken oder gewonnene Erkenntnisse müssen in einem Reparaturstau dokumentiert werden. Die Teams müssen eine Dienstleistungsvereinbarung (Service Level Agreement, SLA) darüber treffen, wie schnell Sicherheitsrisiken behoben werden. Schwerwiegende Risiken müssen so schnell wie möglich angegangen werden, während für geringfügige Probleme eine Frist von zwei Sprints gilt.

Der gesamten Organisation sollte ein Bericht mit den gewonnenen Erkenntnissen und den gefundenen Schwachstellen vorgelegt werden. Es ist eine Lernchance für alle, also machen Sie das Beste daraus.

Lektionen bei Microsoft gelernt

Microsoft übt regelmäßig Kriegsspiele und hat dabei viel gelernt.

• Kriegsspiele sind ein wirksames Mittel, um die DevSecOps-Kultur zu verändern und die Sicherheit in den Vordergrund zu stellen.
• Phishing-Angriffe sind für Angreifer sehr effektiv und müssen nicht unterschätzt werden. Die Auswirkungen können durch eine Beschränkung des Produktionszugangs und eine Zwei-Faktor-Authentifizierung begrenzt werden.
• Die Beherrschung des technischen Systems führt zur Beherrschung von allem. Achten Sie darauf, dass der Zugriff auf den Build/Release-Agent, die Warteschlange, den Pool und die Definition streng kontrolliert wird.
• Üben Sie die Verteidigung in der Tiefe, um es Angreifern schwerer zu machen. Jede Grenze, die sie überschreiten müssen, verlangsamt sie und bietet eine weitere Gelegenheit, sie zu fangen.
• Überschreiten Sie niemals den Bereich des Vertrauens. In der Produktion sollte man nie auf einen Test vertrauen.

Nächste Schritte

Erfahren Sie mehr über den Lebenszyklus der Sicherheitsentwicklung und DevSecOps auf Azure.