Protect - Wie wird das System abgesichert?

Im vorigen Beitrag haben wir mit dem Exchange-Zwischenstopp beschrieben, wie wir das Thema Datenhaltung und Datenaustausch bearbeiten. Das führt uns nun fast unweigerlich zum Zwischenstopp Protect.

In diesem Zwischenstopp liegt der Fokus voll auf Security relevante Themen und die Einführung von DevSecOps basierend auf dem unternehmensspezifischen SSDLC mithilfe der Ideen aus Team Topologies.

Was kann ich mir von diesem Zwischenstopp erwarten?

Im Protect-Zwischenstopp sind folgende Themen enthalten:

• Secure Software Development Lifecycle (SSDLC)

• Peer & User Authentifizierung

• Autorisierung

• Identity Provider

• Data-in-Motion absichern

• Data-at-Rest absichern

• Secrets

• Zertifikate

Ein häufiges Problem in der Softwareentwicklung besteht darin, dass sicherheitsrelevante Aktivitäten bis zur Testphase aufgeschoben werden. Oftmals bis zu einer relativ späten Phase des Software Development Lifecycles (SDLC), in der ein Großteil der kritischen Design- und Implementierungsprozesse bereits abgeschlossen ist.

Probleme, die in dieser späten Phase des SDLC-Prozesses entdeckt werden, führen häufig zu Verzögerungen beim Produktionsgang. Zu diesem Zeitpunkt sind Probleme zeitaufwändiger und teurer zu beheben, da sie eine Neuentwicklung und erneutes Testen erfordern können.

Die Implementierung effektiver Sicherheitsprozesse erfordert von den Teams einen „Shift Left“, wobei Sicherheitsbelange in sämtlichen Phasen des SDLC berücksichtigt werden müssen, und zwar vom Beginn bis zum Ende des Umsetzungsvorhabens. Ein Vorgehen das diesem Paradigma folgt nennt man einen Secure Software Development Lifecycle (SSDLC).

Das hört sich in der Theorie recht einfach an, ist aber bei der praktischen Umsetzung eine große Herausforderung. Vorallem die zusätzliche kognitive Last, die auf Entwicklungsteams abgeladen wird ist gewaltig, da nicht jeder Entwickler automatisch auch eine Sicherheitsexperte ist.

Um das "Shift Left" der Security-Themen also tatsächlich zu erreichen, ist es erforderlich diese iterativ und in kleinen Schritten einzuführen und zum anderen entsprechendes Tooling bereit zu stellen, welches die Teams optimal unterstützt (bspw. Snyk).

Warum soll ich bei diesem Zwischenstopp halt machen?

Abgesicherte Software Systeme und Prozesse helfen dabei die Risiken zu minimieren, dass Daten manipuliert oder gestohlen werden können. Was wiederrum das Vertrauen in das Software System, aber auch in das Unternehmen selbst stärkt. Gerade Vertrauen ist in der Regel entscheinend ob ein Unternehmen langfristig erfolgreich ist. Und Vertrauensverlust tritt schneller ein, als das Vertrauen aufgebaut werden kann.

Wie bereits beschrieben, steigern sich die Kosten oftmals exponentiell zum Zeitpunkt innerhalb des Softwarelebenszyklus wann ein Problem gefunden wird. Es ist also essentiell, eventuelle Probleme so früh wie möglich zu erkennen und zu beheben.

Ein weiterer, nicht außer Acht zu lassender Punkt, ist die Compliance mit regulatorischen Vorgaben, die natürlich ebenfalls sicherheitsrelevante Ausprägungen beinhalten können. Eine Nichteinhaltung dieser kann zu negativen Konsequenzen für das gesamte Unternehmen führen.

Wie läuft dieser Zwischenstopp ab?

Die OWASP bietet mit der OWASP Security Culture ein Rahmenwerk für die Einführung von Security-Prozessen in den Entwicklungsprozess. Wie bereits eingang erwähnt, erzeugt die Einführung dieser Konzepte jedoch zusätzliche kognitive Last innerhalb eines DevOps-Teams.

Das bedeutet, dass die DevOps-Teams vorallem am Start der Einführung viel Unterstützungsleistung benötigen. An dieser Stelle kommen die Ideen aus Team Topologies zum Einsatz, um die DevOps-Teams zu DevSecOps-Teams weiter zu entwickeln.

Auf Security fokussierte Enabling Teams unterstützen, indem die Security Champions innerhalb des DevSecOps-Teams behutsam in die Aufgabe eingeführt werden. Damit ändert sich auch der Fokus von Security-Teams. Diese stellen Security Aspekte nicht mehr am Ende eines Entwicklungszyklus sicher, sondern arbeiten aktiv mit und werden so aus Entwicklersicht zu “Enablern” statt “Security Gatekeepern“.

Damit nun ein unternehmensweiter Austausch jeglicher Mitarbeiter mit Fokus auf Security stattfinden kann, bietet sich die Etablierung einer "Community of Security Practice" an. Diese Community dient zum Wissenaustausch, aber auch zur iterativen und laufenden Weiterentwicklung des SSDLC bzw. von Security-Richtlinien/Vorgaben.

Um diesen Zwischenstopp noch weiter zu vertiefen, werden wir in den nächsten Posts zum einen beschreiben wie Snyk als Tool dabei unterstützt ein "Shift Left" von Security-Themen zu schaffen und zum anderen wie die Themen Secrets & Zertifikate State-of-the-Art von HashiCorp Vault abgedeckt werden.

Abschließend wollen wir an der Stelle noch auf einem Post zum Thema Service Mesh hinweisen:

https://www.fullstacks.eu/post/interact-servicemesh-und-multicloud-demystified-teil2

In diesem Post wird nämlich darauf eingegangen, wie ein Zero-Trust Ansatz mithilfe eines Service Mesh und Mutual Authtentication implementiert werden kann 😎.