Sicherheit in DevOps (DevSecOps)

Sicherheit ist ein wichtiger Bestandteil von DevOps. Aber wie weiß ein Team, ob ein System sicher ist? Ist es wirklich möglich, einen völlig sicheren Service zu liefern?

Leider ist die Antwort nein. DevSecOps ist ein kontinuierlicher und fortlaufender Aufwand, der die Aufmerksamkeit aller in Entwicklungs- und IT-Vorgängen erfordert. Während der Job nie wirklich getan wird, können die Praktiken, die Teams verwenden, um Verstöße zu verhindern und zu behandeln, helfen, Systeme zu produzieren, die so sicher und robust wie möglich sind.

Grundsätzlich, wenn jemand eindringen will, werden sie es schaffen... akzeptiere das. Was wir den Kunden sagen: Nummer eins, du bist mittendrin, ob du es dachtest oder nicht. Zweitens, Sie sind fast sicher kompromittiert." - Michael Hayden, ehemaliger Direktor der NSA und CIA

Das Sicherheitsgespräch

Teams, die nicht über eine formale DevSecOps-Strategie verfügen, werden empfohlen, so bald wie möglich mit der Planung zu beginnen. Zunächst kann es Widerstand von Teammitgliedern geben, die die vorhandenen Bedrohungen nicht vollständig schätzen. Andere sind vielleicht der Meinung, dass das Team nicht gut genug gerüstet ist, um das Problem zu bewältigen, und dass jede spezielle Investition eine verschwenderische Ablenkung von der Bereitstellung neuer Funktionen wäre. Es ist jedoch notwendig, die Unterhaltung zu beginnen, um einen Konsens hinsichtlich der Art der Risiken zu schaffen, wie das Team sie mindern kann und ob das Team Ressourcen benötigt, die sie derzeit nicht haben.

Gehen Sie davon aus, dass Skeptiker einige gängige Argumente mitbringen, z. B.:

• Wie real ist die Bedrohung? Teams schätzen häufig nicht den potenziellen Wert der Dienste und Daten, die sie schützen.
• Unser Team ist gut, richtig? Eine Sicherheitsdiskkssion kann als Zweifel an der Fähigkeit des Teams zur Erstellung eines sicheren Systems wahrgenommen werden.
• Ich denke nicht, dass das möglich ist. Dies ist ein gängiges Argument von Nachwuchsingenieuren. Diejenigen mit Erfahrung wissen in der Regel besser.
• Wir wurden nie gehackt. Aber wie wissen Sie? Woran würden Sie das erkennen?
• Endlose Debatten über Wert. DevSecOps ist ein ernstes Engagement, das als Ablenkung von der Kernfunktion wahrgenommen werden kann. Während die Sicherheitsinvestitionen mit anderen Bedürfnissen ausgeglichen werden sollten, kann sie nicht ignoriert werden.

Die Denkweisenverschiebung

DevSecOps-Kultur erfordert einen wichtigen Wandel in der Denkweise. Sie müssen nicht nur Verstöße verhindern , sondern auch davon ausgehen .

Komponenten der Sicherheitsstrategie

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

Jedes Team sollte bereits über mindestens einige Praktiken zum Verhindern von Verstößen verfügen. Das Schreiben von sicherem Code ist zu einem Standard geworden, und es gibt viele kostenlose und kommerzielle Tools, die bei statischen Analysen und anderen Sicherheitstests helfen.

Viele Teams fehlen jedoch an einer Strategie, die davon ausgeht, dass Systemverletzungen unvermeidlich sind. Wenn Sie davon ausgehen, dass Sie gehackt wurden, kann es schwer sein, dies einzugestehen, insbesondere wenn Sie schwierige Gespräche mit dem Management führen, aber diese Annahme kann Ihnen helfen, Fragen zur Sicherheit zu einem für Sie passenden Zeitpunkt zu beantworten. Sie möchten es nicht alles während eines echten Sicherheitsnotstands herausfinden.

Häufige Fragen, die Sie durchdenken sollten, umfassen:

• Wie erkennen Sie einen Angriff?
• Wie reagieren Sie, wenn ein Angriff oder eine Penetration vorhanden ist?
• Wie werden Sie sich von einem Angriff erholen, z. B. wenn Daten durchgesickert oder manipuliert wurden?

Wichtige DevSecOps-Methoden

Es gibt mehrere gängige DevSecOps-Methoden, die für praktisch jedes Team gelten.

Konzentrieren Sie sich zuerst auf die Verbesserung der mittleren Zeit zur Erkennung und der mittleren Zeit für die Wiederherstellung. Diese Metriken geben an, wie lange es dauert, eine Verletzung zu erkennen und wie lange die Wiederherstellung dauert. Man kann sie durch laufende Live-Tests von Websites für Sicherheitsreaktionspläne nachverfolgen. Bei der Bewertung potenzieller Richtlinien sollte die Verbesserung dieser Metriken ein wichtiger Aspekt sein.

Üben Sie die Verteidigung im Detail. Wenn ein Sicherheitsvorfall auftritt, können Angreifer Zugriff auf interne Netzwerke und alles in ihnen erlangen. Obwohl es ideal wäre, Angreifer zu stoppen, bevor es so weit kommt, führt eine Strategie, die von Sicherheitsverletzungen ausgeht, dazu, dass Teams bestrebt sind, die Gefährdung durch einen Angreifer zu minimieren, der bereits eingedrungen ist.

Führen Sie schließlich regelmäßige Bewertungen nach der Verletzung Ihrer Praktiken und Umgebungen durch. Nachdem eine Verletzung behoben wurde, sollte Ihr Team die Leistung der Richtlinien sowie ihre eigene Einhaltung bewerten. Richtlinien sind am effektivsten, wenn Teams sie tatsächlich befolgen. Jede Verletzung, ob real oder praktiziert, sollte als Möglichkeit zur Verbesserung angesehen werden.

Strategien zur Minderung von Bedrohungen

Es gibt zu viele Bedrohungen, um sie aufzuzählen. Einige Sicherheitslücken sind auf Probleme in Abhängigkeiten wie Betriebssystemen und Bibliotheken zurückzuführen, sodass es wichtig ist, diese aktuell zu halten. Andere sind auf Fehler im Systemcode zurückzuführen, die eine sorgfältige Analyse erfordern, um sie zu finden und zu beheben. Schlechtes geheimes Management ist die Ursache vieler Verstöße, wie social engineering. Es ist eine bewährte Methode, über die verschiedenen Arten von Sicherheitslöchern und das, was sie für das System bedeuten, nachzudenken.

Angriffsvektoren

Betrachten Sie ein Szenario, in dem ein Angreifer Zugriff auf die Anmeldeinformationen eines Entwicklers erhalten hat. Was können sie tun?

Wie kann Ihr Team gegen diese Vektoren verteidigen?

• Geheime Schlüssel in geschützten Tresoren speichern
• Entfernen lokaler Administratorkonten
• SAMR einschränken
• Anmeldedaten-Schutz
• Entfernen von Dual-Homed-Servern
• Einzelne Abonnements
• Mehrfaktor-Authentifizierung
• Arbeitsstationen mit privilegiertem Zugriff
• Erkennen mit ATP und Microsoft Defender für Cloud

Verwaltung von Geheimnissen

Alle geheimen Schlüssel müssen in einem geschützten Tresor gespeichert werden. Geheime Schlüssel sind:

• Kennwörter, Schlüssel und Token
• Speicherkontoschlüssel
• Zertifikate
• Anmeldeinformationen, die auch in freigegebenen Nichtproduktionsumgebungen verwendet werden

Sie sollten eine Hierarchie von Tresoren verwenden, um die Duplizierung geheimer Schlüssel zu vermeiden. Überlegen Sie auch, wie und wann geheime Schlüssel aufgerufen werden. Einige werden während der Bereitstellung zur Erstellung von Umgebungskonfigurationen verwendet, während andere zur Laufzeit aufgerufen werden. Bereitstellungsgeheimnisse erfordern typischerweise eine neue Bereitstellung, um neue Einstellungen zu übernehmen, während Laufzeitgeheimnisse nach Bedarf abgerufen und jederzeit aktualisiert werden können.

Plattformen verfügen über sichere Speicherfunktionen zum Verwalten von geheimen Schlüsseln in CI/CD-Pipelines und Cloudumgebungen, z. B. Azure Key Vault und GitHub-Aktionen.

Hilfreiche Tools

• Microsoft Defender für Cloud eignet sich hervorragend für generische Infrastrukturwarnungen, z. B. für Schadsoftware, verdächtige Prozesse usw.
• Quellcodeanalysetools für statische Anwendungssicherheitstests (SAST).
• GitHub advanced security für die Analyse und Überwachung von Repositories.
• mimikatz extrahiert Kennwörter, Schlüssel, Pincodes, Tickets und vieles mehr aus dem Speicher des lsass.exeSubsystems "Lokale Sicherheitsbehörde" unter Windows. Er erfordert nur Administratorzugriff auf den Computer oder ein Konto mit aktivierten Debugberechtigungen.
• BloodHound erstellt ein Diagramm der Beziehungen innerhalb einer Active Directory-Umgebung. Das rote Team kann verwendet werden, um Angriffsvektoren zu identifizieren, die schwer schnell zu erkennen sind.

Kriegsspielübungen

Eine gängige Praxis bei Microsoft ist die Teilnahme an Kriegsspielübungen. Hierbei handelt es sich um Sicherheitstests, bei denen zwei Teams mit dem Testen der Sicherheit und Richtlinien eines Systems beauftragt werden.

Das rote Team übernimmt die Rolle eines Angreifers. Sie versuchen, reale Angriffe zu modellieren, um Lücken in der Sicherheit zu finden. Wenn sie sie ausnutzen können, zeigen sie auch die potenziellen Auswirkungen ihrer Sicherheitsverletzungen.

Das blaue Team übernimmt die Rolle des DevOps-Teams. Sie testen ihre Fähigkeit, die Angriffe des roten Teams zu erkennen und darauf zu reagieren. Dies hilft, das Situationsbewusstsein zu verbessern und die Bereitschaft und Effektivität der DevSecOps-Strategie zu messen.

Entwickeln einer Strategie für Kriegsspiele

Kriegsspiele sind effektiv bei der Härtung der Sicherheit, da sie das rote Team motivieren, Probleme zu finden und auszunutzen. Es wird wahrscheinlich viel einfacher sein als erwartet früh. Teams, die nicht aktiv versucht haben, ihre eigenen Systeme anzugreifen, sind sich im Allgemeinen nicht über die Größe und Menge der Sicherheitslücken, die Angreifern zur Verfügung stehen, bewusst. Das blaue Team könnte zunächst demoralisiert sein, weil sie wiederholt überfahren werden. Glücklicherweise sollte sich das System und die Praktiken im Laufe der Zeit weiterentwickeln, sodass das blaue Team konsequent gewinnt.

Vorbereiten auf Kriegsspiele

Vor dem Start von Kriegssimulationen sollte das Team alle Probleme beheben, die sie bei einer Sicherheitsprüfung finden können. Dies ist eine großartige Übung, die vor dem Versuch eines Angriffs durchgeführt werden sollte, da sie eine Grundlage von Referenzerfahrungen für alle bietet, anhand derer nach dem späteren Auffinden des ersten Exploits verglichen werden kann. Beginnen Sie mit der Identifizierung von Sicherheitsrisiken über eine manuelle Codeüberprüfung und statische Analysetools.

Organisieren von Teams

Rote und blaue Teams sollten nach Spezialität organisiert werden. Ziel ist es, die fähigsten Teams für jede Seite zu erstellen, um so effektiv wie möglich auszuführen.

Das rote Team sollte einige sicherheitsorientierte Ingenieure und Entwickler enthalten, die tief mit dem Code vertraut sind. Es ist auch hilfreich, das Team mit einem Penetrationstestspezialisten zu erweitern, wenn möglich. Wenn es keine Internen Spezialisten gibt, bieten viele Unternehmen diesen Service zusammen mit Mentoring an.

Das blaue Team sollte aus betriebsorientierten Ingenieuren bestehen, die ein tiefes Verständnis der Systeme und der zur Verfügung stehenden Protokollierung haben. Sie haben die beste Chance, verdächtiges Verhalten zu erkennen und zu adressieren.

Ausführen von Frühkriegsspielen

Erwarten Sie, dass das rote Team in den frühen Kriegsspielen effektiv ist. Sie sollten durch ziemlich einfache Angriffe erfolgreich sein, z. B. durch die Suche nach schlecht geschützten Geheimschlüsseln, SQL-Einfügungen und erfolgreichen Phishingkampagnen. Nehmen Sie sich viel Zeit zwischen Runden, um Korrekturen und Feedback zu Richtlinien anzuwenden. Dies variiert je nach Organisation, aber Sie möchten die nächste Runde erst starten, wenn jeder davon überzeugt ist, dass die vorherige Runde im vollen Umfang ausgeschöpft wurde.

Laufende Kriegsspiele

Nach einigen Runden muss sich das rote Team auf komplexere Techniken verlassen, z. B. cross-site scripting (XSS), Deserialisierungs-Exploits und Technische Systemrisiken. Das Einbringen von externen Sicherheitsexperten in Bereichen wie Active Directory kann hilfreich sein, um mehr verdeckte Exploits anzugreifen. Bis zu diesem Zeitpunkt sollte das blaue Team nicht nur eine gehärtete Plattform um sich zu verteidigen haben, sondern sollte auch eine umfassende, zentralisierte Protokollierung für die forensische Analyse nach einem Einbruch nutzen.

Verteidiger denken in Begriffen von Listen. Angreifer denken in Diagrammen. Solange dies wahr ist, gewinnen Angreifer." - John Lambert (MSTIC)

Im Laufe der Zeit wird das rote Team viel länger brauchen, um seine Ziele zu erreichen. In diesen Fällen ist es häufig erforderlich, mehrere Sicherheitsrisiken zu ermitteln und zu verketten, um begrenzte Auswirkungen zu haben. Durch die Verwendung von Echtzeitüberwachungstools sollte das Blue Team Versuche in Echtzeit erfassen.

Leitlinien

War-Spiele sollten nicht kostenlos sein. Es ist wichtig zu erkennen, dass das Ziel darin besteht, ein effektiveres System zu erzeugen, das von einem effektiveren Team ausgeführt wird.

Verhaltenskodex

Nachfolgend sehen Sie einen Beispielcode für verhalten, der von Microsoft verwendet wird:

1. Die roten und blauen Teams werden keinen Schaden anrichten. Wenn das Potenzial, Schäden zu verursachen, erheblich ist, sollte es dokumentiert und behoben werden.
2. Das rote Team sollte nicht mehr Kompromisse eingehen als nötig, um die Zielressourcen zu sichern.
3. Common Sense-Regeln gelten für physische Angriffe. Während das rote Team ermutigt wird, mit nicht-technischen Angriffen wie Social Engineering kreativ zu sein, sollten sie keine gefälschten Badges drucken, Menschen belästigen usw.
4. Wenn ein Social Engineering-Angriff erfolgreich ist, geben Sie nicht den Namen der Person offen, die kompromittiert wurde. Die Lektion kann geteilt werden, ohne ein Teammitglied zu entfremden oder peinlich zu machen, mit dem alle zusammenarbeiten müssen.

Einsatzregeln

Hier sind Beispielregeln für das Engagement, das von Microsoft verwendet wird:

1. Wirken Sie sich nicht auf die Verfügbarkeit eines Systems aus.
2. Greifen Sie nicht auf externe Kundendaten zu.
3. Schwächen Sie keine bestehenden Sicherheitsschutzmaßnahmen für einen Dienst.
4. Führen Sie keine destruktiven Aktionen gegen Ressourcen aus.
5. Schützen Sie Anmeldeinformationen, Schwachstellen und andere wichtige Informationen, die erhalten wurden.

Ergebnisse

Alle sicherheitsrelevanten Risiken oder Erkenntnisse sollten in einem Backlog von Reparaturelementen dokumentiert werden. Teams sollten ein Service Level Agreement (SLA) definieren, um festzulegen, wie schnell Sicherheitsrisiken behoben werden. Schwerwiegende Risiken sollten so bald wie möglich behoben werden, während kleinere Probleme eine Frist von zwei Sprints haben können.

Dem gesamten Unternehmen sollte ein Bericht mit den ermittelten Erkenntnissen und Sicherheitsrisiken vorgelegt werden. Es ist eine Lernmöglichkeit für alle, also machen Sie es optimal.

Gelernte Erkenntnisse bei Microsoft

Microsoft praktiziert regelmäßig Kriegsspiele und hat auf dem Weg viele Lektionen gelernt.

• Kriegsspiele sind eine effektive Möglichkeit, DevSecOps-Kultur zu ändern und die Sicherheit im Vordergrund zu halten.
• Phishingangriffe sind für Angreifer sehr effektiv und sollten nicht unterschätzt werden. Die Auswirkungen können begrenzt werden, indem der Produktionszugriff eingeschränkt und eine Zwei-Faktor-Authentifizierung erforderlich wird.
• Die Steuerung des Engineering-Systems führt zur Kontrolle von allem. Achten Sie darauf, den Zugriff auf den Build-/Release-Agent, die Warteschlange, den Pool und die Definition streng zu steuern.
• Üben Sie die Verteidigung im Detail, um angreifern dies zu erschweren. Jede Grenze, die sie überwinden müssen, bremst sie aus und bietet eine weitere Gelegenheit, sie zu erwischen.
• Überqueren Sie niemals Vertrauensbereiche. Die Produktion sollte sich niemals auf irgendetwas im Test verlassen.

Nächste Schritte

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