Moderne Softwareentwicklung und DevSecOps: Trotz Sicherheits-kontrollen bleibt das Risiko von Datenleaks

Auf einen Blick

Ganz egal wie viele Softwareentwickler in Ihrem Team arbeiten, und unabhängig davon, welche Prozesse und Richtlinien Sie festgelegt haben – die Entwicklung von Software bleibt angreifbar. Technische Daten wie Quellcode, Logindaten von Mitarbeitern und Partnern sowie die Sicherheitsinfrastruktur in Unternehmen können ungewollt offengelegt und als Einfallstor von Angreifern ausgenutzt werden.

Dieser Blog soll zeigen, warum moderne Softwareentwicklung trotz aller Sicherheitsmaßnahmen so oft mit technischen Datenleaks zu kämpfen hat. Was können Sicherheitsteams tun, um die ungewollt veröffentlichten Daten zuverlässig und schnell aufzuspüren? Die hier zusammengefassten Tipps und Tricks können Ihnen helfen, Ihre Angriffsfläche nachhaltig zu minimieren.

DevSecOps und eine neue Art der Softwareentwicklung

Geht es um Technologieprodukte, sind unsere Ansprüche in den letzten Jahren deutlich gestiegen: Wir wollen die neueste Version mit den neuesten Features – und das sofort und ohne Ausnahme. Die Auswahl ist riesig. Jedes Unternehmen arbeitet fieberhaft an der nächsten Innovation, um unseren Hunger nach digitalen und smarten Lösungen zu befriedigen.

Wie schnell und oft Unternehmen neue Produkte und Updates auf den Markt bringen, fällt den meisten Anwendern dabei oft gar nicht auf. Eine Untersuchung von Google fand heraus, dass die Top-Anbieter ihren Endanwendern mehrmals täglich Softwareupdates bereitstellen. Selbst Anbieter im unterem Marksegment stellen mindestens einmal im Monat bzw. einmal im Halbjahr ein Versionsupdate zur Verfügung. Die kontinuierliche Bereitstellung neuer Funktionen und Tools – sowie der damit verbundene Mehrwert für den Kunden – sind zentral für den Erfolg eines jeden Softwareprodukts.

Um dieses hohe Tempo auch über lange Strecken beibehalten zu können, entstanden in den letzten Jahren unterschiedliche Ansätze für die Softwarenentwicklung. Die Prozesse haben sich mit der fortschreitenden digitalen Transformation mehr und mehr in die Cloud verlagert. Auch die Zahl von Code-Plattformen ist deutlich gestiegen, nicht zuletzt da Softwareentwickler mehr denn je auf Kollaborationen und Open Source Software angewiesen sind. Zu den Best Practices, die eine schnelle und sichere Zusammenarbeit zwischen Softwareteams entlang des Software Development Life Cycle (SDLC) garantierten, gehören Developer Operations (DevOps) und Developer Security Operations DevOpsSec). Beide Ansätze sollen die Softwareentwicklung verbessern und die Effizienz, Flexibilität und Agilität steigern. Damit sind jedoch noch lange nicht alle Herausforderungen aus dem Weg geräumt – vor allem nicht was die Sicherheit von Software angeht.

Dieser Blog geht dabei einer auf den ersten Blick kuriosen Frage nach: Wie kommt es, dass trotz moderner Sicherheitspraktiken das Risiko von ungewollt veröffentlichten technischen Daten und Datenleaks größer ist als je zuvor? Lassen Sie uns dazu zunächst einen Blick auf DevOps und DevSecOps und ihre Bedeutung werfen.  

SOFTWAREENTWICKLUNG: FRAMEWORKS FÜR MEHR SICHERHEIT

Die reibungslose Zusammenarbeit zwischen Entwicklern und Systemadministration sowie die Sicherheit der Software hängt von zwei Faktoren ab: dem Reifegradmodell sowie dem Anteil von Software Engineering im Unternehmens. Dementsprechend unterschiedlich sind die Lösungsansätze. Grundsätzlich lässt sich jedoch folgende Unterscheidung treffen: DevOps behandelt die Zusammenarbeit während DevSecOps sich mit der Sicherheit auseinandersetzt.

Was ist DevOps? Was ist DevSecOps?

Der Bereich Software Engineering umfasst in jedem Unternehmen unterschiedliche Aufgabengebiete und ist damit Definitionssache. „Softwarenentwicklung“ reicht dabei vom Programmierer einer Anwendungen bis zum Verantwortlichen für die Bereitstellung der Software in der Cloud-Infrastruktur.

Eine wesentliche Aufgabe besteht daher darin, die verschiedenen Teams zusammenzubringen – kurz DevOps sicherzustellen. Die funktionsübergreifende Zusammenarbeit kann die Flexibilität und Agilität über alle Prozesse hinweg deutlich verbessern. Der Nachteil: Oft werden Sicherheitsfragen zu Gunsten abgestimmter und schneller Prozesse vernachlässigt. Diese Reibungspunkte können die Markteinführung eines Produkts deutlich verzögern.

So lästig sie auch scheinen mögen: Sicherheitsaspekte bei der Zusammenarbeit zwischen Development (Dev) und IT Operations (Ops) einfach zu ignorieren, ist keine gute Idee. Dafür gibt es schon zu viele andere Sicherheitsrisiken zu berücksichtigen, einschließlich Software-

Vulnerabilities und Programmfehler. Wer Sicherheitsvorgaben außen vor lässt, riskiert gravierende Mängel bei der Nutzererfahrung und hält die Tür für Angreifer offen. Um diese Art von Risiken zu entschärfen, heißt es daher, neben der Zusammenarbeit auch die IT- und Netzwerksicherheit einzubeziehen.

DEVOPS VS. DEVSECOPS

DevSecOps folgt hier dem DevOp-Ansatz und hat die Aufgabe, für eine kontinuierliche Cyber Security bei der Entwicklung von Software zu sorgen. Richtig angewandt, werden Sicherheitsmaßnahmen in jedem Schritt des SDLCs implementiert, ohne die Time-to-Market zu beeinträchtigen. Unterm Strich profitiert davon auch der Endanwender, nämlich höhere Verfügbarkeit der Anwendung, besseren Support und schnelle Behebung von Problemen.

DEVSECOPS TOOLCHAIN: DAS 1×1 DER SICHERHEITSKONTROLLEN

Die DevSecOps-Toolchain zeigt sehr schön, wie Sicherheit kontinuierlich über den Lebenszyklus eingebettet werden kann. Dabei gibt es unterschiedliche Interpretationen der Toolchain, die von Gartner bis SANS variieren. Im Folgenden wollen wir uns die SANS DevSecOps-Toolchain [Abbildung 1] genauer ansehen.

SICHERHEITSKONTROLLEN FÜR BESSERES DEPLOYMENT

Nach SANS sind Sicherheitskontrollen ein integraler Bestandteil der Toolchain, um die Häufigkeit und Kritikalität von Programmfehlern und Sicherheitslücken in Software zu minimieren. Allerdings sind nicht alle Sicherheitskontrollen tatsächlich 100% sicher – und müssen entsprechend gemanagt werden.

Die von SANS gelisteten Sicherheitskontrollen allein können technische Datenleaks im Bereich der Softwareentwicklung allerdings nur minimieren, wenn sie in der Praxis auch eingehalten werden. Das ist die eigentliche Herausforderungen für Softwareunternehmen – unabhängig wie sie im Detail DevOps und DevSecOps implementieren.

DIGITALES RISIKO IN DER SOFTWAREENTWICKLUNG

Was hat Softwareentwicklung mit digitalen Risiken zu tun? Als digitale Risiken lassen sich alle Daten bzw. Unternehmens-Assets definieren, die ungewollt im Open, Deep und Dark Web veröffentlicht werden. Dazu gehören neben sensiblen Dokumenten, personenbezogenen Daten auch Produktdesigns und Patente sowie Zugangsdaten. Deren Offenlegung verstößt in vielen Fällen gegen Datenschutz- und Compliance-Vorgaben und kann schwere Folgen für die Sicherheit und den Ruf der Organisationen haben.

Digitale Risiken sind vielfältig, dynamisch und betreffen alle Abteilungen eines Unternehmens – auch das Software Engineering. So stößt unser Analystenteam bei Digital Shadows immer wieder auf sensible Daten, die im Rahmen der Softwareentwicklung ungewollt veröffentlicht und online gestellt werden.

WER IST FÜR DAS DIGITALE RISIKOMANGEMENT VERANTWORTLICH?

Wenn Daten rund um die Softwareentwicklung (z. B. Codesnippets) frei zugänglich im Netz stehen, lässt sich das in der Regel auf einen Fehler oder eine Nachlässigkeit auf Entwicklerseite zurückführen. Das Problem zu lösen, ist jedoch Aufgabe des Sicherheitsteams, deren To-Do-Liste damit nicht wirklich kürzer wird. An ihnen liegt es, proaktiv und frühzeitig zu erkennen, ob ein Mitarbeiter, ein Partner oder ein Dritter beispielsweise unautorisierte Commits (Softversionen) oder Quelltexte in Code-Repositories veröffentlicht hat. Diese technischen Datenleaks stellen für das Unternehmen sowie für die davon betroffenen Anwendungen und Systeme ein ernstes Risiko dar.

FOKUS AUF RISIKOMINIMIERUNG

Die Rolle von Kollaborationsplattformen und Code-Hostern im Netz ist hier nicht zu unterschätzen – vor allem wenn dort keine Kontrollen hinsichtlich Datenschutz und Privatsphäre vorhanden sind. GitHub bietet seit 2018 sogenannten „Token Scanning“-Services, um die unbeabsichtigte Veröffentlichung von technischen Zugangsdaten zu verhindern. GitHub ist jedoch nur eine von vielen Plattformen. Auch Webanwendungen wie GitLab, BitBucket, Azure und Stack Exchange, auf denen Entwickler und Programmierer Versionen managen, Fehler suchen und sich mit der Community austauschen, tragen hier eine gewisse Verantwortung. Das Risiko offengelegter technischer Daten zu minimieren, geht alle an.

Innerhalb von Organisationen gilt es, Sicherheitsrichtlinien klar zu positionieren und konsequent durchzusetzen. Gleichzeitig sollte auch auf Kundenseite ein Bewusstsein für potenzielle Risiken aufgebaut werden. Geschieht das nicht, ist es nur eine Frage der Zeit bis ein sensibler Code oder ein Authentifizierungsschlüssel im Netz auftaucht. Das Monitoring nach technischen Datenleaks ist dabei nicht zwangsläufig mit enormen Aufwand verbunden. Monitoring-Tools – wie Digital Shadows SearchLight zum Beispiel – überwachen und indizieren kontinuierlich Hunderte von Millionen Seiten, darunter GitHub und GitLab, und können unautorisierte Commits in Code-Repositories automatisch aufspüren und melden.

Die 4 gröSSten Risiken DER SOFTWAREENTWICKLUNG

1. Geleakte Authentifizierungsdaten

Shared Secrets werden in der Softwareentwicklung für die Authentifizierung eingesetzt – von Passwörtern über APIs bis hin zu Shared Secrets werden in der Softwareentwicklung für die Authentifizierung eingesetzt – von Passwörtern über APIs bis hin zu Zugriffsschlüsseln. Diese Art von geheimen und vertraulichen Daten haben eigentlich nichts in einem privaten Code-Repository verloren. Auf keinen Fall sollten sie aber in einem öffentlichen Repository landen.

In der Realität jedoch ist dies häufiger der Fall als man denkt. Sicherheitsexperten an der North Carolina State University fanden heraus, dass Secrets nahezu überall zu finden sind und über 100.000 Repositories betreffen. Auf GitHub werden so täglich Tausende neuer und einmaliger Codeschlüssel veröffentlicht, darunter APs und kryptographische Schlüssel. Das damit verbundene Sicherheitsrisiko ist durchaus bekannt. Auf Twitter kritisierten Anwender die Suchfunktion von GitHub, mit der User die Repositories nach Passwörtern durchsuchen können, und drängten auf neue Sicherheitsfeatures der Plattform.

Das „harmlose“ Teilen von Daten und das unbeabsichtigte Veröffentlichen von Commits, kann schwerwiegende Konsequenzen nach sich ziehen, wenn Angreifer die Daten in die Hände bekommen.

Wer sensible Daten auf GitHub aufspüren und verhindern möchte, dass dort vertrauliche Informationen (öffentlich) eingestellt werden, kann auf einige gute Open Source-Tools zurückgreifen. Dazu gehören beispielsweise Trufflehog, das darauf spezialisiert ist, Git-Repositories nach Shared Secrets zu durchsuchen

2. Offengelegte Infrastruktur

Quelltext, Codesnippets und Authentifizierungsdaten sind das eine. Genauso gefährlich kann es sein, wenn die Infrastruktur eines Unternehmens öffentlich und damit angreifbar wird. Je mehr Informationen über die Systeme und Sicherheitsmaßnamen eines Unternehmens bekannt sind, desto einfacher ist es für Angreifer, Schwachstellen auszukundschaften (Reconnaissance) und zielsichere Cyberattacken zu starten.

Bei der Beobachtung des Open, Deep und Dark Webs erfahren wir immer wieder, wie wichtig diese Feldrecherche für Cyberkriminelle tatsächlich ist. Der Post auf dem russischen Forum Exploit ist nur ein Beispiel dafür (Abbildung 2). Der Anbieter wirbt mit einer ganzen Liste von Subdomains eines Unternehmens. Die mehrfache Nennung von Elasticsearch lässt vermuten, dass das Unternehmen die Suchmaschine für ihr Datenmanagement und/oder ihre Datenspeicherung nutzt. Es gibt zwar keinen Hinweis, dass eine dieser Instanzen kompromittiert ist. Die penible Aufzählung der technischen Informationen scheint jedoch bei der Planung eines Cyberangriffs immerhin so nützlich zu sein, dass sich ein Verkauf lohnt.

3. Fehlerhafte Konfiguration

Eine der Kernfunktionen von DevSecOps besteht darin, die IT-Infrastruktur zu überwachen und zu verwalten. Diese Aufgabe erstreckt sich auf die Konfigurationsverwaltung aller Server in lokalen, Staging- und Produktionsumgebungen. Hier heißt es sicherzustellen, dass alle Server synchronisiert und durchgehend laufen.

Die Umsetzung dieser Aufgabe lässt allerdings zu wünschen übrig. So nimmt die Zahl an Konfigurationsfehlern in der IT nach einem Bericht von Verizon „2020 Data Breach Investigations Report“ kontinuierlich zu. Vor allem Datenbanken und File Storage sind oft nicht ausreichend geschützt und über Cloud Services oft frei zugänglich. Verizon nennt als Hauptursache Systemadministratoren, die den Zugriff auf File Storages – absichtlich oder unbeabsichtigt – öffentlich machen. Die Ursachen dieser Fehlkonfigurationen sind laut weiterer Untersuchungen unterschiedlich. In einer Umfrage wurde mangelndes Bewusstsein für Cloud-Sicherheit und -Richtlinien (52%), ein Mangel an adäquaten Kontrollen und Aufsicht (49%), zu wenig Zeit, um zu viele Cloud-APIs und Schnittstellen zu managen (43%) sowie ein fahrlässiges Verhalten von Mitarbeitern (32%) als Erklärung angegeben.

Digital Shadows stieß 2019 bei seiner Analyse „Too Much Information: The Sequel“ auf ein ganz ähnliches Bild. Insgesamt spürte das Photon Research Team 2,3 Mrd. vertrauliche Dokumente auf, die größtenteils auf falsch konfigurierte Cloud-Speicherdienste zurückzuführen waren.

Die Berichte zeigen, dass schwache Sicherheitskontrollen sowie ein unzureichendes Sicherheitsbewusstsein eine gewichtige Rolle bei Datenleaks spielen. 

4. Einfallstor für Angreifer

Geht es um öffentlich gewordene Daten, hört man immer wieder die Frage: „Ist das wirklich so schlimm? Was kann schon passieren, wenn ein Entwickler Daten auf einem Code Repository frei zugänglich macht?“

Die Antwort: Wenn die Daten in die falschen Hände geraten, kann in der Tat sehr viel passieren, wie die folgenden Beispiele zeigen. 

Daten-Erpressung

2017 verschafften sich Angreifer Zugriff auf nicht authentifizierten Installationen von MongoDB, löschten die komplette Datenbank und hinterließen lediglich ein Lösegeldschreiben mit der klaren Botschaft: „Wer seine Daten zurückhaben wollte, sollte zahlen“. Wie weitere Nachforschungen von Digital Shadows zeigten, handelte es sich dabei mit großer Wahrscheinlichkeit nicht um einen klassischen Ransomware-Angriff. Vielmehr deutete alles auf Erpressung hin, da von den gelöschten Daten nicht einmal ein Backup erstellt wurde.

Ransomware-Attacken

Im bereits erwähnten Report “Too Much Information“ analysierte Digital Shadows, wie Cyberkriminelle exponierte Daten für ihre Angriffe nutzen. 17 Millionen Dateien, die sich als Backup in Cloud-Speicherdiensten befanden, wurden mit Hilfe von Ransomware verschlüsselt. Bei zwei Millionen kam dabei „NamPoHyu“, einer Variante der „Megalocker“ Ransomware, zum Einsatz.

Laut dem Sicherheitsspezialisten Vinny Troia konnte der Hacker „GnosticPlayers“ gültige Accounts von Entwicklern identifizieren, indem er via Credential Stuffing die HTTP-basierte API-Authentifizierung knackte. Dabei nutze er eine Sicherheitslücke der GitHub-Konfiguration aus und fügte mit Hilfe des Befehlszeilen-Tools von GitHub den Konten eigene SSH-Schlüssel zu.

Threat Intelligence & DevSecOps: Angriffsfläche minimieren

Sicherheitskontrollen sowie entsprechende Lösungen helfen, diese Herausforderungen proaktiv anzugehen und Risiken auf ein Minimum zu halten. Die Liste ist zu lang, um auf alle im Detail einzugehen. Threat Intelligence jedoch nimmt als eine der wichtigsten Grundvoraussetzungen für sichere Softwareentwicklung einen Sonderplatz ein.  

Threat Intelligence hilft Sicherheitsteams zunächst dabei, ein geeignetes und auf das Unternehmen abgestimmtes Threat Modell zu entwickeln. Die umfassenden Informationen über digitale Risiken, Bedrohungsakteure, Techniken und Tools können bereits früh bei der Anforderungsanalyse sowie der Design/Planungsphase von Software im Code berücksichtigt werden. SANS empfiehlt Threat Intelligence insbesondere bei der Beantwortung der folgenden zwei Fragen: 

• Verändert sich die Angriffsfläche (z. B. durch neue Ein-/Ausgangspunkte, neue Benutzerrolle)?
• Verändern sich der Technologie-Stack oder die Sicherheitskontrollen der Anwendung?

Zum anderen schafft Threat Intelligence – insbesondere das Tracking von Vulnerabilities und Exploits – ein grundlegendes Verständnis darüber, ob die Software verwundbar und anfällig für Angriffe ist.

MONITORING-TOOL: SEARCHLIGHT

Für das Aufspüren und Entschärfen von DevSecOps-Risiken hat Digital Shadows seine Monitoring-Lösung für das Open, Deep und Dark Web um neue Funktionen erweitert. Neben exponierten Code und Shared Secrets in öffentlichen Repositories können Unternehmen nun auch über die „Unauthorized Commit“-Alerts in SearchLight Aktivitäten in öffentlichen Code-Repositories verfolgen. Sicherheitsteams gewinnen so einen schnellen Überblick über Zeitpunkt und Quelle von unautorisierten Veröffentlichungen und können so das Risiko technischer Datenleaks intern bewerten und entschärfen.

Durch das Monitoring von Software-Vulnerabilities bleiben Entwicklerteams zudem immer über die neuesten Schwachstellen und Exploits auf dem Laufenden (Abbildung 4).

Wie Unternehmen Threat Intelligence nutzen, hängt auch von der Implementierung des DevSecOps-Ansatzes ab und unterscheidet sich von Branche zu Branche. Dabei ist es wichtig, die Suchkriterien passgenau auf das Unternehmen abzustimmen. Von den Vorteilen einer umfassenden Threat Intelligence profitieren beispielweise der Einzelhandel, der Finanzsektor, aber auch Technologieanbieter, Telekommunikationsunternehmen und der Energiesektor.

EXTERNE INFORMATION FÜR BESSERE DEVSECOP

Wie alles im Bereich Sicherheit, muss auch DevSecOps derzeit mit den Herausforderungen rund um die digitale Transformation kämpfen. Die Perimeter-Grenze verschwimmt, während die Angriffsfläche kontinuierlich wächst. Die Zahl an exponierten Daten wächst. Das hohe Tempo in der Softwareentwicklung ist nur in Kollaboration mit Partnern und mit Hilfe von Tools möglich. Das erhöht wiederum das Risiko, dass technische wie personenbezogene Daten öffentlich werden – ob aus Unwissenheit, Sorglosigkeit oder mit Absicht bleibt dahingestellt. Wer seine Software schützen und sensible Daten im Unternehmen halten möchte, sollte daher fünf Grundregeln beherzigen:

• Stichwort Monitoring: Halten Sie proaktiv Ausschau nach öffentlich gewordenen technischen Daten und Codes. Es gibt eine ganze Reihe von Monitoring-Tools, die Ihnen dabei helfen, Unternehmens-Assets in öffentlichen Repositories wie GitHub, BitBucket oder GitLab aufzuspüren. Nur einige Beispiele: SearchLight erkennt technische Datenleaks – z. B. wenn ein Mitarbeiter für die Registrierung auf einer Plattform die Firmen-Email verwendet. GitHound verhindert, dass sensible Daten preisgegeben werden. Mit TruffleHog lassen sich Repositories auf Shared Secrets untersuchen.

• Nutzen Sie Threat Intelligence nur im Kontext. Nicht alle Bedrohungen, Hackergruppen, Malware-Varianten und Betrugsmaschen sind für jedes Unternehmen gleich relevant. Daher heißt es, die gesammelten Informationen in einen Kontext zu setzen, zu bewerten und so die Risiken auszumachen, die für Sie, Ihr Unternehmen und Ihre Sicherheitsarchitektur tatsächlich zur Bedrohung werden können.

• Identifizieren Sie die Schwachstellen und Sicherheitslücken Ihrer Software. Das Sammeln von Daten aus unterschiedlichen Quellen im Open, Deep und Dark Web verschafft nicht nur einen gründlichen Überblick aller Angriffspunkte Ihres Netzwerks. Die Auswertung ermöglicht es zudem, das Risikopotential zu ermitteln, Maßnahmen zu priorisieren und Ressourcen entsprechend einzuteilen. Statt einer Flut von CVEs (Common Vulnerabilities and Exposures) können sich Sicherheitsteams so auf wenige, dafür aber relevante, Bedrohungen konzentrieren.

• Sorgen Sie für ein höheres Sicherheitsbewusstsein. Vorsichtmaßnahmen im Umgang mit Daten werden oft als selbstverständlich vorausgesetzt. In den meisten Fällen ist jedoch noch viel Aufklärungsarbeit zu leisten. Klare Richtlinien, transparente Kommunikationswege und Schulungen sind daher ein gutes Mittel ein einheitliches Verständnis von Sicherheit herzustellen.

• Einfache Handhabung hat Priorität. Auf Tools und Plattformen wie GitHub oder GitLab kann heute kein Entwickler mehr verzichten. Umso wichtiger ist es, dass dort die Sicherheitsprotokolle eingehalten und die Konfigurationen so eingestellt werden, dass nur das veröffentlicht wird, was auch öffentlich sein darf.

Weitere Infos für DevSecOps

Sind Sie neugierig geworden, wie Sie DevSecOps in Ihr Unternehmen implementieren können? Dann lohnt sich ein Klick auf die folgenden Infos:

• Blog: DevSecOps: Continued database exposures point to growing challenges 
• Produktdatenblatt: Data Leakage
• Produktdatenblatt: Data Leakage Detection Capabilities

Case Study: Detecting Unauthorized Code Commit