Bryan Batty ist Director of Product and Infrastructure Security bei der Bloomberg Industry Group, einer Tochtergesellschaft von Bloomberg L.P., bekannt für Bloomberg News und das Bloomberg Terminal. Der Fokus von Bloomberg liegt auf Nachrichten aus den Bereichen Recht, Steuern und Rechnungswesen sowie auf Steuer- und Buchhaltungssoftware.
Batty leitet die Teams für Produktsicherheit und Infrastruktur. Er arbeitet eng mit Entwicklern und den Infrastruktur-Teams zusammen, um zu garantieren, dass alles, was in die Produktion oder in den Betrieb geht, auch wirklich sicher ist – dabei geht es auch darum, nach vorhandenen Schwachstellen innerhalb der bestehenden Infrastruktur zu suchen.
Wir haben uns mit Bryan im Januar in Verbindung gesetzt, um in diesem vierteiligen Gespräch über den Prozess der Software-Entwicklung bei Bloomberg zu sprechen – insbesondere auch über die Verwaltung der Software Supply Chain. Dies ist Teil 1.
"Wenn man ein Tool wie Nexus Lifecycle von Sonatype nutzt, ist man auf der sicheren Seite. Man sieht sofort, um welche Version einer Komponente es sich handelt, ob sie eine entsprechende Lizenz hat, oder ob bekannte Schwachstellen vorhanden sind. Nexus Lifecycle weiß, welche Komponentenversionen frei von bekannten Schwachstellen sind. Sobald Sicherheitsprobleme auftreten, erkennt es die jeweiligen Schwachstellen." -- Bryan Batty
Ich habe im Jahr 2006 meinen Bachelor-Abschluss gemacht und wollte Programmierer werden, also Software entwickeln. Das hat mir wirklich Spaß gemacht. Wie das Leben so spielt, bin ich dann aber in die Sicherheitsbranche gerutscht. Ansonsten würde ich jetzt wahrscheinlich immer noch voller Leidenschaft Programme und Tools entwickeln. In den Sicherheitsbereich bin ich eigentlich direkt nach dem Einstieg in meine Karriere gekommen. Auf einer Konferenz von Microsoft, an der ich damals teilnahm, gab es einen Programmpunkt über SQL-Injection. Ich habe absolut gar nicht damit gerechnet, dass das so einfach geht.
In meiner Verblüffung fiel mir der Code ein, an dem ich damals gerade arbeitete. Ich dachte mir: „Hmm … den sollte ich mir vielleicht nochmal ansehen und überarbeiten.“ Ich beschloss, mich selbst zu hacken, und musste erkennen, dass mein Code totaler Mist war. Damals war das noch ein Kinderspiel. Man konnte Schwachstellen leicht ausnutzen, aber auch leicht beheben.
Definieren von Sicherheitsanforderungen
Mark Miller:
Die SQL-Injection ist nach wie vor Teil der OWASP Top 10.
Bryan Batty:
Ja, das ist verrückt. Schon seit 10 Jahren ist sie in den OWASP Top 10, oder? Ja, schon seit Beginn. Es ist erstaunlich, dass Entwickler von heute die Methode immer noch verwenden ... Ich denke, das hängt wahrscheinlich mit Bewusstsein und Bildung zusammen. Neue Entwickler, so wie ich damals, wollen ihre Programme einfach nur zum Laufen bringen. Wir bekommen etwas Bestimmtes aufgetragen und denken uns: "Okay, das kann ich entwickeln."
Wenn man „fertig“ ist, sollte das auch heißen, dass man Sicherheitsanforderungen berücksichtigt hat. Oft ist das jedoch nicht der Fall. bDenn das Thema Sicherheit wird gar nicht erst miteinbezogen. Mit der Definition von „fertig“ verbindet man oft nur eine gewisse Kreativität. Entwickler haben oft die Einstellung: "Okay, sobald meine Idee funktioniert, bin ich fertig." Aber nicht alle von ihnen denken so. Einige sind sehr wachsam und möchten sicherstellen, dass sie ihre Arbeit skalierbar, sicher und nachhaltig erledigen.
Mark Miller:
Der Punkt A9 der OWASP Top 10 lautet: „Nutzung von Komponenten mit bekannten Schwachstellen.“ Wie geht Ihr Team damit um?
Software Composition Analysis
Bryan Batty:
Das war etwas, worauf ich in meinem vorvorletzten Job gestoßen bin. Ich habe versucht, einen OWASP Dependency Check auszuführen. Die Terminologie hat sich ein wenig verändert. Ich glaube, in den letzten Jahren ist der Begriff “Software Composition Analysis” [SCA] für das Scannen von Drittanbieter-Bibliotheken und Open-Source-Bibliotheken auf Lizenzverletzungen und Sicherheitslücken in den Vordergrund gerückt. SCA prüft unter anderem die Code-Qualität und das Code-Alter der Bibliothek, die Sie verwenden.
Nachdem wir eine Zeit lang Software Composition Analysis Tools verwendet haben, wurde uns klar, auf wie viel Widerstand wir seitens der Entwickler stießen. Und wie kompliziert es sein kann, wenn die Bibliothek selbst schon sehr alt ist und bei einem Upgrade 30 Versionen durchlaufen muss. Entwickler haben Angst davor, dass sich dadurch Fehler einschleichen. Das geht auf den ursprünglichen Konflikt zwischen Dev und Ops zurück, also zwischen Software-Entwicklern und Systemadministratoren.
Das Ziel von Entwicklern ist es, immer wieder neue Funktionen zu veröffentlichen. Dabei geht es üblicherweise um gewisse Veränderungen. Systemadministratoren setzen hingegen auf Verfügbarkeit und Zuverlässigkeit. Sie wollen keine Veränderungen. Wenn etwas funktioniert, interessieren sie sich nicht dafür, neue Funktionen zu veröffentlichen.
Mit der Sicherheit verhält es sich ähnlich. Wenn wir darum bitten, dass etwas geändert wird, sagen Entwickler plötzlich: "Nein, der Code funktioniert." Im Grunde lassen sie die Sicherheit komplett außen vor und meinen: „Wir möchten unseren Code jetzt nicht ändern. Er funktioniert so, wie er ist. Wenn wir jetzt etwas aktualisieren, könnte es ja sein, dass sich dadurch irgendwelche Fehler in den Code einschleichen.“
Ich glaube, wenn es um die Entwicklung eines ganz neuen Programms geht, also ohne bereits bestehende Infrastruktur oder dergleichen, ist man auf der sicheren Seite, wenn man ein Tool wie Nexus Lifecycle von Sonatype nutzt. Man sieht sofort, um welche Version einer Komponente es sich handelt, ob sie eine Lizenz hat, die man verwenden will, oder ob bekannte Schwachstellen vorhanden sind. Nexus Lifecycle erkennt, welche Komponentenversionen keine bekannten Schwachstellen aufweisen. Wenn dann Sicherheitsprobleme aufgedeckt werden, weiß das Tool ganz genau, um welche Schwachstellen es sich handelt.
Was bestehende Anwendungen angeht, musste ich Entwickler immer zuerst davon überzeugen, mich ein Proof of Concept durchführen zu lassen. Ich musste ihnen dann immer beibringen, dass ich jetzt all ihre Bibliotheken von Drittanbietern scannen muss. Das Ergebnis waren dann 55 kritische Schwachstellen, 200 Schwachstellen mit hoher Priorität und 700 mit mittlerer. Da verfällt man in Schockstarre. Ich selbst bin in Schockstarre verfallen. Was mache ich jetzt? Wo soll ich beginnen? Bei so vielen Fällen … muss ich mit den kritischen beginnen. Aber davon gibt es 55, also …
Stärken der Software Supply Chain
Mark Miller:
Führen Sie uns durch den Prozess. Es gibt also 55 kritische Schwachstellen. Wo beginnen Sie?
Bryan Batty:
Nicht alle kritischen Fälle sind gleich. Also analysieren wir die Software aus dieser Perspektive. Software Composition Analysis Tools scannen Bibliotheken von Drittanbietern, aber keinen benutzerdefinierten Code. Entwickler sagen dann oft: „Na ja, wenn wir uns das genauer ansehen, steht da, dass diese Komponente nur dann eine Sicherheitslücke darstellt, wenn man nur Methode X verwendet. Wir nutzen Methode X aber nicht, also ist das eine Falschmeldung.“ So etwas bekommen wir immer wieder von Entwicklern zu hören.
Es stimmt schon, dass eine Schwachstelle nicht so kritisch ist, wenn der Code im Moment nichts mit dieser anfälligen Methode zu tun hat. Dennoch würde ich in diesem Fall nicht von einer Falschmeldung sprechen. Es ist keine Falschmeldung. Es handelt sich sehr wohl um eine Schwachstelle der verwendeten Open-Source-Software-Komponente.
Wir versuchen dann, die Komponente anzupassen und den Schweregrad zu mindern. Wenn es uns gelingt, die Wahrscheinlichkeit zu senken, dass diese Schwachstelle ausgenutzt wird, reduzieren wir dadurch gleichzeitig auch die Kritikalität. Wenn eine Komponente als kritisch eingestuft wird und wir sie dann neu klassifizieren, könnte sie dann auf eine Schwachstelle mit nur mittlerer oder sogar niedriger Priorität reduziert werden. Wir sehen uns dann auch an, ob es sich um eine interne oder eine externe Anwendung handelt.
Nutzung von Open-Source-Komponenten – damals und heute
Mark Miller:
Ich glaube nicht, dass sich Entwickler darüber im Klaren sind, dass eine neue Anwendung zu 80 % aus Open-Source-Komponenten besteht, und dass der Quellcode im Grunde alles zusammenhält.
Bryan Batty:
Meine Entwickler wissen das jetzt, aber auch erst, nachdem ich es ihnen immer und immer wieder gesagt habe.
Mark Miller:
Sie sind jetzt schon eine ganze Weile in der Branche aktiv. Schon seit über 12 Jahren. Wie haben sich diese Veränderungen auf Sie ausgewirkt? Früher machte sich noch jeder Sorgen um benutzerdefinierten Quellcode. Hat sich die Sorge heute auf Open-Source-Software-Komponenten verlagert?
Bryan Batty:
Aus geschäftlicher Sicht sind diejenigen, die neue Funktionen veröffentlichen, auf Marktanteil aus. Sie wollen sich von ihren Konkurrenten abheben. Wie das Programm entwickelt wurde, ist ihnen egal. Sie wollen nur, dass es so schnell wie möglich fertig ist. Also verlassen sie sich vollkommen auf Open-Source-Software, weil sie sich denken: „Wieso sollte ich etwas Neues entwickeln, wenn es das bereits gibt und ich es verwenden kann?“
Ein Entwickler braucht vier Stunden, um eine Open-Source-Bibliothek vollständig und fehlerfrei zu integrieren. Wenn er alles selbstständig programmiert, braucht er dazu drei Monate. Das sind jetzt nur ungefähre Zahlen, aber genau das ist der Grund, wieso man dazu verleitet ist, auf die Open-Source-Bibliothek zurückzugreifen. Sicherheit ist dabei Nebensache. Entwickler machen es sich gerne einfach, weil sie dann schneller zu anderen Funktionen übergehen können.
Sie verlassen sich voll und ganz auf Open-Source-Software. Meine Verpflichtung ist es, sie darauf aufmerksam zu machen, welche Gefahren und Risiken von der Nutzung gewisser Bibliotheken ausgehen, und wie wachsam man sein muss, um über Bibliotheken auf dem Laufenden zu bleiben. Ganz zu schweigen davon, dass wir darauf achten müssen, unsere Lizenzrichtlinien nicht zu verletzen und sichere Bibliotheken zu nutzen.
Mark Miller:
Bei bestimmten Arten von Lizenzen müssen Sie, wenn Sie der Software etwas hinzufügen, dies an die Community zurückgeben. Wie trägt Ihr Team diesem Umstand Rechnung? Wie gehen Sie vor?
Bryan Batty:
Wir verwenden jetzt Nexus Lifecyle. Das ist ein Produkt, das uns in vielen Belangen hilft. So kann ich jede Open-Source-Komponente auf Lizenzverletzungen scannen. Abgesehen davon bin ich so in der Lage, meine Mitarbeiter darauf aufmerksam zu machen, dass die Lizenz einer gewissen Komponente gegen Richtlinien verstößt. Dann erkläre ich ihnen, wie wir vorgehen müssen – also dass wir die Lizenz entweder austauschen oder das Programm auslizenzieren müssen.
Das war Teil 1 unseres Gesprächs mit Bryan Batty. In Teil 2 erläutert er, wie man bei der Entwicklung einer Anwendung das Thema Sicherheit von Beginn an effektiv berücksichtigt. In Teil 3 spricht er über Experimente sowie die Messung von Erfolg. In Teil 4 teilt er uns schließlich mit, wieso seine Wahl auf die Sonatype-Plattform fiel.
