Interview: Codebasis effektiv absichern

Kerr Koehler, Code ist überall und damit ein Gefahrenherd für Security-Fehler. Warum ist die Code- und Anwendungssicherheit gerade jetzt so ein Thema?

Jochen Koehler: In den meisten Unternehmen spielt sich das Thema Cybersecurity auf drei Ebenen ab: Die erste Ebene, die Sicherheit der lokalen IT-Infrastruktur, haben die meisten Unternehmen mittlerweile abgehakt und im Griff. Bei der zweiten, der Cloud-Sicherheit, sind sie gerade dabei, sie zu bewältigen. Nun wird die dritte Ebene, die Applikationssicherheit, immer dringlicher. Es wird immer deutlicher, dass sowohl auf der On-Premises-Infrastruktur als auch in der Cloud vor allem eines läuft: Code. Und genau dessen Sicherheit wurde bisher eher stiefmütterlich behandelt.

Was sind die Gründe dafür, Code als potenzielles Einfallstor für Cyberangriffe so zu vernachlässigen?

Das liegt unter anderem daran, dass die IT-Security-Abteilung und die Entwicklungsabteilung in der Regel komplett unterschiedliche Wege gehen. Das ist nicht neu, wird aber immer problematischer, da die Anzahl der Anwendungen rapide steigt. Anwendungssicherheit ist zudem der Bereich im Softwarelebenszyklus, für den es die wenigsten Standards und allgemeine Best Practices gibt. Junge Entwickler sind heute überdies kaum noch an ihre Unternehmen gebunden, wenn sie nicht ohnehin als Freelancer arbeiten, und das spiegelt sich auch in ihrer Arbeitsweise wider: Sie sitzen irgendwo auf der Welt, bauen Code – teilweise selbst, teilweise via Glue Code aus Public Libraries – und dann wird es im Repository deployt. Es gibt sehr wenig Verbindlichkeit, da man sich auf Prozesse zur Absicherung verlässt. Diese Unverbindlichkeit steht in krassem Gegensatz zur absoluten Verbindlichkeit der Security-Abteilung, und es ist sehr schwierig, diese unterschiedlichen Herangehensweisen miteinander in Einklang zu bringen. Hinzu kommt, dass es in vielen Unternehmen nicht ein einziges Entwicklungsteam gibt, sondern für jede Anwendung ein eigenes. In großen Konzernen gibt es nicht selten eine dreistellige Zahl von Teams, die ihre Anwendungen schreiben, losgelöst vom ganzheitlichen Sicherheitskonzept. Diese jahrelange Vernachlässigung müssen die Unternehmen nun schnell aufholen.

Was muss sich konkret ändern? Müssen sich Security-Teams und Entwickler an einen Tisch setzen?

Sie sollten beginnen, endlich und endgültig das Silo-Denken aufzubrechen. Viele IT-Teams arbeiten bereits nach DevOps-Methoden, vereinen also Entwicklung und IT-Betrieb – allerdings fehlt ein echter Bezug zur Sicherheit, wenn sie sich ausschließlich auf die Funktionalität fokussieren. Organisatorisch gesehen müssen sich bestenfalls DevSecOps-Teams als neuer Standard etablieren, also die Erweiterung von DevOps-Teams um mindestens einen Spezialisten, beispielsweise einen AppSec-Manager, der die Schnittstelle zur IT-Security-Abteilung bildet und sowohl sicherheitstechnisches Fachwissen als auch Programmierfähigkeiten in sich vereint. Und natürlich braucht es auch das entsprechende Tooling.

Nutzen Entwicklungs- und DevOps-Teams denn keine Security-Tools?

Doch, natürlich. Zum Teil sogar viel zu viele und jedes Team innerhalb eines Unternehmens hat seine eigenen. So kommt es, dass in vielen Firmen ein regelrechter Wildwuchs an Security-Tools zum Einsatz kommt und teilweise sogar mehrfach für die gleiche Funktionalität bezahlt wird. Besonders klug ist das auch im Hinblick auf die Sicherheit nicht, da viele Tools nicht richtig miteinander kommunizieren und sich so jedes Team nur um seine eigenen Findings kümmert, wodurch sich wiederum Sicherheitslücken einschleichen können.

Welcher Weg führt aus diesem Cybersecurity-Dilemma?

Eine sinnvolle Maßnahme ist der Einsatz einer ASPM-Lösung, also einer Software für das Application Security Posture Management. Sie dient sozusagen als Plattform, auf der alle relevanten Informationen für die Anwendungssicherheit zusammenlaufen, indem Unternehmen die vorhandenen Code-Security-Tools mit ihr verknüpfen. ASPM-Lösungen schaffen dann im ersten Schritt das Allerwichtigste: Visibilität über die IT-Sicherheitslandschaft – eben jene unersetzbare Security Posture. Die IT-Security-Abteilung sieht dann sofort, welche der gefundenen Schwachstellen im Kontext mit anderen wichtigen Faktoren die größte Relevanz haben.

Lässt sich das Risiko einer Anwendung für die Gesamtinfrastruktur einordnen?

Typische Faktoren sind beispielsweise die Kritikalität einer Anwendung oder die Eintrittswahrscheinlichkeit eines Angriffs. Darauf basierend können die IT-Sicherheitsexperten dann die Maßnahmen zur Behebung priorisieren. Gute ASPM-Lösungen bieten auch ein eigenes, natives Tooling an, das alle relevanten Bereiche im Software Development Lifecycle, kurz SDLC, abdeckt, während sich andere darauf beschränken, Daten zu sammeln, aggregieren, konsolidieren und vielleicht visualisieren.

Ein weiteres Merkmal einer guten ASPM-Lösung ist deren Integrierbarkeit in die IDEs der Entwickler. Sie erhalten auf diese Weise alle relevanten Informationen über die Sicherheit ihres Codes direkt in ihrer gewohnten Entwicklungsumgebung, ohne zusätzliche Tools verwenden zu müssen. Die IT-Security-Abteilung hingegen hat zu jeder Zeit eine holistische Übersicht über die aktuelle Sicherheitslage aller Unternehmensanwendungen.

Wie sollten Unternehmen vorgehen, wenn sie eine ASPM-Lösung implementieren wollen?

Eine Sache, die Unternehmen definitiv beachten müssen, ist wohl allgemeingültig für die Einführung neuer, grundlegender Softwarelösungen: Sie sollten nicht alles auf einmal lösen wollen. Gute ASPM-Lösungen haben alles an Bord, was Unternehmen brauchen. Auf dem Papier ist das auch gut so, aber in der Praxis lassen sich nicht alle etablierten Sicherheitsprozesse einfach mit einem Klick umstellen. Wer das versucht, wird auf massiven Widerstand stoßen. Das Zauberwort heißt hier Optionalität. Wichtig ist zunächst, dass sich die ASPM-Lösung für die Sichtbarkeit mit dem Heiligtum der Entwicklungsabteilung – dem Git-System – verbinden kann, und zwar möglichst nahtlos. Anschließend besteht die Option, nach und nach die verwendeten Secure Development Tools durch die von der ASPM-Lösung nativ bereitgestellten zu ersetzen, oder eben die Drittanbieter-Tools zu integrieren. Günstiger ist natürlich die Nutzung der nativen Tools, aber es ist niemandem geholfen, wenn es zu Zerwürfnissen innerhalb der Abteilungen kommt.

Spielt KI auch eine Rolle im Zusammenhang mit ASPM?

Wie die meisten Sicherheitstools nutzen auch ASPM-Lösungen KI. Künstliche Intelligenz kann beispielsweise von Vorteil sein, wenn es darum geht, dem Entwickler zuzuarbeiten und verbesserten Code zu generieren. Aber natürlich ist auch dieser Code mit einer gewissen Vorsicht zu genießen und darf nicht einfach blind übernommen werden. KI kann zudem für die Change-Impact-Analyse eingesetzt werden, also der Analyse von Code-Änderungen hinsichtlich ihrer Auswirkungen auf Sicherheit und Compliance. Und natürlich bei der Identifikation von Schwachstellen und deren Behebung. Künstliche Intelligenz ist nicht umsonst ein viel diskutiertes Thema, doch gerade im Bereich der Anwendungssicherheit wird die Technologie zukünftig einen noch größeren Impact haben.

Jochen Koehler

ist Vice President of Sales EMEA bei Cycode.