Sicherheit in die Funktion während der Designphase integrieren

Es ist aufregend, wie verschiedene Disziplinen kombiniert werden können, um die Prozesse effizienter zu gestalten. Im Jahr 2009 wurde der Begriff DevOps geprägt, um die Reibung zwischen den Entwicklungs- und Betriebsteams anzugehen. Infolgedessen bewegte sich die Branche in Richtung der Zusammenlegung beider Teams, sodass das Entwicklungsteam für den gesamten Zyklus verantwortlich war, von der Codeerstellung bis zur Bereitstellung in der Produktion. Natürlich, wer könnte die Feinheiten besser verstehen als die Menschen, die sie entwickelt haben?

Nach diesem Wandel haben wir gesehen, dass Funktionen schnell ausgeliefert werden und die Markteinführungszeit für neue Funktionen drastisch gesenkt wurde. DevOps diente auch als Grundlage für viele andere Praktiken wie MLOps, DataOps, GitOps, und zweifellos sind viele weitere entstanden.

Heute werden wir über eine solche Praxis sprechen, die vielen von Ihnen bekannt sein könnte, genannt DevSecOps (Development Security Operations). Also, was ist DevSecOps?

Sicherheit wurde traditionell als nachträglicher Gedanke behandelt, wobei Teams zuerst Funktionen in die Produktion lieferten und dann hastig versuchten, Sicherheitsmaßnahmen während einer Sicherheitsüberprüfung oder eines Vorfalls zu implementieren. Mit dem Anstieg von Cybersecurity-, Lieferketten- und anderen komplexen Angriffen erkannte die Branche schnell, dass Sicherheit, wie Entwicklung und Betrieb, auch Teil des Prozesses sein sollte. Sie sollte so früh wie möglich in den Entwicklungslebenszyklus integriert werden, denn die nachträgliche Behandlung von Sicherheit kann teuer werden (sowohl aus architektonischer als auch aus betrieblicher Sicht).

Nun wollen wir besprechen, wie es in verschiedenen Phasen unseres Entwicklungslebenszyklus angewendet werden kann, damit der Code, den wir versenden, nicht nur effizient, sondern auch sicher ist. 

Normalerweise umfasst der Prozess des Versendens eines Features:

1. Entwicklung – wo das Feature gebaut wird
2. Verteilung – wo die Artefakte erstellt und für die Lieferung vorbereitet werden
3. Bereitstellung – wo das Feature veröffentlicht wird in die Produktionsumgebung

Lassen Sie uns die Schritte besprechen, die wir unternehmen können, um das Sicherheitsniveau des Features zu verbessern, das wir während der Entwicklungsphase erstellen.

In der Entwicklungsphase durchläuft ein Feature eine Designüberprüfung, die Codierung und dann eine Überprüfung des Pull Requests. Im Rahmen der Designüberprüfung diskutiert der Feature-Besitzer, wie die API-Verträge aussehen, welche Art von Datenbanken wir verwenden, Indizierungs- und Caching-Strategien, Benutzererfahrung usw. (keine erschöpfende Liste). In der Sicherheitskultur ist es auch wichtig, Bedrohungsmodellierung durchzuführen. 

Führen Sie Bedrohungsmodellierung durch

Einfach ausgedrückt, ist Bedrohungsmodellierung „der Prozess der Identifizierung von Schwachstellen, der Durchführung einer Risikobewertung und der Implementierung der empfohlenen Maßnahmen, damit die Sicherheitshaltung der Produkte/Organisation nicht kompromittiert wird“. Bedrohungsmodellierung ist „der Prozess, Schwachstellen zu identifizieren, eine Risikobewertung durchzuführen und die empfohlenen Maßnahmen umzusetzen, damit die Sicherheitshaltung der Produkte/Organisation nicht gefährdet wird“.

Lassen Sie uns anhand eines Beispiels verstehen. Stellen Sie sich vor, Sie entwickeln eine API, die:

• Produkte in Ihrem Produktkatalog auflistet.
• Nach einem Produkt oder einer Produktart sucht.

GET /api/products?search=laptop

​

Ein Bedrohungsmodell könnte wie folgt aussehen:

Diese sind etwas, woran wir denken können, wenn wir die Produktendpunkte betrachten. Das Beste daran ist, dass man kein Sicherheitsexperte sein muss, um diese Schwachstellen zu erkennen.

Tools wie Microsoft Threat Modeling Tools und OWASP Threat Dragons können helfen, sie zu identifizieren.

Beispiel eines Bedrohungsmodells im Microsoft Threat Modeling Tool

Analyseansicht

Die Analyseansicht des Bedrohungsmodellierungswerkzeugs zeigt verschiedene Angriffe, die auf die API stattfinden können.

Die Überprüfung des Bedrohungsmodells mit Ihrem Team kann als Brainstorming-Sitzung dienen, um so viele Sicherheitslücken wie möglich zu identifizieren und zu beheben.

• Schwache kryptografische Verwendungen. Zum Beispiel gilt die Verwendung von SHA1 oder MD5 als schwach.CA530 ist ein Beispiel für eine Warnung, die C# erstellt, wenn schwache Hash-Funktionen im Code verwendet werden.
• SQL-Injektionsangriffe. CA2100 überprüft beispielsweise, ob der Code anfällig für Injektionsangriffe ist
• Fest codierte Passwörter, schwache Authentifizierungs- und Autorisierungsmechanismen sowie Infrastrukturfehler können ebenfalls mit statischen Analysetools erkannt werden.

Es gibt auch bereits existierende Tools in diesem Bereich. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check und Snyk haben einige großartige Angebote in diesem Bereich.

Die Integration von statischer Analyse in Build-Pipelines ist ebenfalls wichtig. Es bietet Vorteile wie:

• Konsistente Erfahrung bei der Erkennung von Schwachstellen für Ihre Entwickler.
• Verbessert die Sicherheitslage Ihres Dienstes, da jeder Produktions-Deployment diese Schritte durchlaufen muss.

Code-Reviews aus sicherheitstechnischer Sicht

Während Code-Reviews traditionell darauf abzielen, Fehler zu identifizieren und bewährte Praktiken sicherzustellen, ist es wichtig, es auch aus sicherheitstechnischer Perspektive zu bewerten. Durch die Berücksichtigung der Sicherheitsimplikationen jedes Pull-Requests können Sie zukünftige Bedrohungen proaktiv verhindern und die Integrität Ihrer Anwendung schützen.

Zusammenfassung

Zusammenfassend ist es aufgrund der zunehmenden Komplexität der Cybersicherheitslandschaft wichtig, die Sicherheit bereits in den frühen Phasen zu berücksichtigen, anstatt sie aufzuschieben. Als Teil davon sollten Bedrohungsmodellierung und automatisierte statische Analyse in Ihren regelmäßigen Entwicklungszyklus integriert werden.

In den kommenden Artikeln werden wir besprechen, welche Sicherheitspraktiken wir während der Verteilung einbeziehen können, dazu gehören das Scannen von Container-Images, dynamische Anwendungssicherheitstests (DAST) und die Signierung von Artefakten zum Schutz des Dienstes vor Angriffen auf die Lieferkette.