Von Anfang an sicher

Shift Left Security: Apps frühzeitig absichern
Keine Kommentare

Bereits in frühen Phasen der Software-Entwicklung müssen Richtlinien und Kontrollen für Sicherheit implementiert werden. Oft stehen relativ neue Tools für Code-Scanning und automatisiertes Patching im Fokus. Meist ignoriert werden dagegen klassische Lösungen wie die Web Application Firewall (WAF), die seit langem für die Durchsetzung von Sicherheitsrichtlinien im Einsatz sind. Das gilt es beim Erstellen einer zeitgemäßen und zufriedenstellen IT-Sicherheitsstruktur zu beachten. Die organisatorischen Prozesse sind dabei zu optimieren.

Sicherheitsrichtlinien und -kontrollen sind bereits in frühen Phasen des Softwareentwicklungsprozesses zu implementieren und nicht erst, wenn die Anwendungen in Produktion gehen. Darüber besteht mittlerweile weitgehend Einigkeit. Allerdings hat es gedauert, bis sich diese Erkenntnis in den Unternehmen durchgesetzt hat. Der Grund dafür ist, dass Unternehmen ihre Apps und Infrastrukturen normalerweise zentral verwalten – durch ein NetOps-, IT- oder Infrastructure & Operations-Team. Bei diesem Modell ist es sinnvoll, Sicherheit am Rande der – ebenfalls zentral verwalteten – Infrastruktur zu konsolidieren, auf der die Apps bereitgestellt werden.

Digitale Transformation und Dezentralisierung

Im Zuge der digitalen Transformation sowie effizienter und agiler Arbeitsweisen, entstehen allerdings dezentrale Strukturen. Das gilt für die Entwicklung, für die zugrunde liegende Infrastruktur und den Betrieb. Auch die Apps sind zunehmend dezentral aufgebaut: Sie sind als Dienste, Endpunkte und Geräte gestaltet, die via APIs über das Netzwerk interagieren. Verwaltet werden sie oft von Dev- und DevOps-Teams, die außerhalb traditioneller und zentralisierter Infrastruktur-Teams agieren.

Diese Entwicklung hin zu dezentralen Strukturen veranlasst Unternehmen dazu, Sicherheit stärker anwendungsorientiert zu gestalten und sie früher im Entwicklungsprozess zu berücksichtigen. Nur hat die Dezentralisierung zu Kontroversen zwischen Dev- und DevOps-Teams auf der einen und Sicherheitsteams auf der anderen Seite geführt.

Das liegt zum großen Teil daran, dass die Transformation nicht in allen Teams im gleichen Tempo erfolgt. Sicherheit spielt sich heute in einem sehr großen Bereich mit schwer definierbaren schwer zu definierenden Angriffsflächen ab. Dieser Bereich besteht aus modernen App-Workloads, die an mehreren Standorten laufen, über (oft öffentliche) Netzwerke miteinander kommunizieren und Daten von Geräten und Nutzern weltweit abrufen.

Wenn Sicherheit an Bedeutung gewinnt, wächst auch der Kreis der Personen, mit denen die Security Teams interagieren. Viele von ihnen haben nur begrenzte Sicherheitskenntnisse – und die Security-Teams haben selbst nicht das Budget, um zu wachsen. Erschwerend kommt hinzu, dass viele der üblichen Legacy-Tools, mit denen die Sicherheitsteams arbeiten, nicht zu dem neuen Sicherheitskonzept passen. Sie lassen den Teams keine andere Wahl, als sie in die Pipeline einzupassen, obwohl sie nicht für Automatisierung und moderne Infrastrukturen ausgelegt sind. Die Tools bieten in der Regel auch keinen Self-Service, so dass Dev und DevOps, die schnell handeln müssen, Sicherheit bisweilen als Hindernis betrachten und oft versuchen, diese zu umgehen, indem sie auf Schatten-IT zurückgreifen.

Zu oft ist Sicherheit unterbrechungsgetrieben: Sicherheitsteams bestehen dann meist auf einen Stillstand der Entwicklung, während sie die Sicherheitsrichtlinien und -prozesse prüfen und bewerten. Dev und DevOps wollen ihre Entwicklung fortsetzen und gleichzeitig sicherstellen, dass dies auf eine sichere Weise erfolgt.

Die Denkweise anpassen

Mit Sicherheitstools, die als Code in die Pipeline eingefügt werden, lässt sich dies erreichen. Aber es erfordert auch, dass Sicherheitsteams ihre Denkweise über Sicherheitsverfahren für zunehmend dezentralisierte und verteilte Anwendungen ändern. Die Verfahren selbst müssen sich jedoch auch weiterentwickeln, viel anwendungsorientierter und von vorherein mitgedacht werden: Angefangen bei der Zielgruppe für die Anwendung, über die Art und Weise, wie die Applikation erstellt wird, bis hin zu den Umgebungen, in denen die Anwendung bereitgestellt wird, bis hin zu den Standard-Compliance-Anforderungen.

Eine Steuerungsebene für die Orchestrierung der Sicherheit über eine Vielzahl von Anwendungen kann in einer solchen Umgebung einen echten Mehrwert bieten. Sie macht es dem Security-Team leicht, angemessene Sicherheitsrichtlinien festzulegen. Diese werden dann auf Grundlage festgelegter Parameter an die zugrunde liegenden Anwendungen angepasst. Das Setzen von Leitplanken ermöglicht es Security, Dev und DevOps, mit minimaler Interaktion oder Unterbrechung zusammenzuarbeiten.

WAF als Lösung

Doch welche Tools und Ansätze eignen sich am besten für zeitgemäße IT-Security? Lösungen wie die WAF laufen dabei oft unter dem Radar – dabei eignen sie sich, um Unternehmen vor gezielten und sich ständig weiterentwickelnden Angriffen zu schützen. Allerdings muss eine geeignete WAF für moderne Infrastrukturen sowie DevOps-Pipelines optimiert sein und sich problemlos in verschiedenen Umgebungen bereitstellen lassen. Entsprechend sollte sie automatisierte Sicherheitskonfigurationen und -richtlinien bieten. Dann kann sie die Wirksamkeit von Security-Maßnahmen während der Build- und Testphasen prüfen, bevor die Anwendungen in einer Laufzeitumgebung ausgeführt werden.

Keine Einheitslösung

Wie immer beim Thema Anwendungssicherheit gilt: Einen allgemeingültigen Ansatz gibt es nicht. Die beste Struktur für Unternehmen umfasst mehrere Sicherheitsebenen. Der Schlüssel liegt darin, sicherzustellen, dass jede Sicherheitslösung effektiv in die Pipeline passt, und dass sich Entwicklungsteams und Sicherheitsteams mit effektiven Richtlinien über die Absicherung der Unternehmensanwendungen und APIs abstimmen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -