Anmerkung der Redaktion: Dies ist Teil 3 des vierteiligen Gesprächs mit Bryan Batty, Director of Product and Infrastructure Security bei der Bloomberg Industry Group. In Teil 2 sprach er über Pipelines und SBOMs. In diesem Abschnitt erläutert Bryan laufende Experimente und erklärt, wie der Erfolg geglückter Initiativen gemessen werden kann.
"Wenn wir in der Lage sind, diese Werte zu senken, dann werden wir irgendwann weniger Zeit mit dem Beheben von Sicherheitslücken verbringen und stattdessen mehr Zeit in die Integration von Sicherheitsstrukturen für unsere Anwendungen investieren können." -- Bryan Batty
Aus Überraschungen lernen
Mark Miller:
Was haben Sie kürzlich erfahren, das Sie überrascht hat?
Bryan Batty:
Meine Güte. Ich bin 2019 zum ersten Mal Vater geworden. Da gibt es so einige Dinge, bei denen ich sagen würde: „Wow, wer hätte gedacht, dass ich das schaffe!“ Aber ich nehme stark an, dass sich Ihre Frage auf die Technologie bezieht. Der Hack von Capital One hat mich überrascht. Die Bank ist führend bei der Einführung der Cloud-Technologie und ein Vorreiter bei Sicherheitsfragen. Als ich das gesehen habe, war ich schon sehr schockiert.
Mark Miller:
Hat auch Ihr Team darüber nachgedacht, ob das in irgendeiner Form zu Nachwirkungen für Ihr Unternehmen führen könnte?
Bryan Batty:
Ach, ich glaube jeder, der in dieser Branche auch nur ansatzweise etwas zu sagen hat, hat sich darüber Gedanken gemacht – sicherlich jedes Technologieunternehmen. Es geht hier um verschiedene Verschlüsselungsmethoden und wir wissen, dass wir zurzeit noch nicht sehr weit vorangeschritten sind, was die Cloud betrifft. Aber wir sind auf einem guten Weg. In den vergangenen anderthalb Jahren haben wir große Fortschritte gemacht.
Der Hack von Capital One hat sich zu Beginn unserer Einführungsphase zugetragen. Früh genug, dass wir nicht dazu gezwungen waren, Tausende und Abertausende von S3-Buckets zu überprüfen, um zu ermitteln, was los war. Wir sind gerade mit der Entwicklung beschäftigt. Also ist das eine gute Gelegenheit für uns, unsere derzeitigen Verfahren zu überprüfen.
Mit räumlicher Nähe experimentieren
Mark Miller:
Woran arbeitet Ihr Team in diesem Jahr? Was möchten Sie erreichen?
Bryan Batty:
Ich habe vorhin schon kurz das Experiment erwähnt, Sicherheitsexperten mit Entwicklern zusammenzubringen. Das ist ein Bereich, in dem wir jetzt stark vorankommen.
Mark Miller:
Im gleichen Raum? Am selben Tisch?
Bryan Batty:
Ja, beim gleichen Sprint-Meeting. Sie müssen nicht unbedingt rund um die Uhr da sitzen, aber sie sollten schon an denselben Sprint-Planungseinheiten teilnehmen, genauso wie bei Backlog-Grooming-Sessions oder Sprint-Reviews. Wir möchten, dass Sicherheitsexperten mit Entwicklern zusammenarbeiten und vielleicht sogar einige Code-Check-ins durchführen. Ich weiß aber nicht, ob alle Sicherheitsexperten damit einverstanden wären.
Ich weiß auch nicht, ob überhaupt alle Lead Developer damit einverstanden wären. Aber ich stelle mir vor, in ferner Zukunft in der Lage zu sein, Mitarbeitern verschiedene Rollen zuzuweisen. In einem Unternehmen, in dem ich früher einmal gearbeitet habe, haben wir das ausprobiert. Ich war im „DevOps-Team“. Ich wusste, dass das ein Anti-Pattern ist, aber so war es nun einmal. Das Anti-Pattern war, dass wir ein separates DevOps-Team hatten. In Wirklichkeit waren wir ein Ops-Team, Infrastrucutre-as-Code.
Die Entwickler veröffentlichten die Funktionen in der Produktionsumgebung. Es gab einige Entwickler, die in unser Team wechselten. So wurden wir dann zu einem Entwicklerteam. Es war also eine gewisse Rotation festzustellen. Das war durchaus ein gutes Experiment, aber in der Praxis funktioniert das nicht so richtig. Denn die Menschen tun das, was sie tun möchten, und das aus einem bestimmten Grund. Sie wollen sich auf ihre Arbeit konzentrieren.
Ein Ruby-Entwickler will ein Ruby-Entwickler sein. Ein solcher Entwickler interessiert sich nicht unbedingt für Aufrufinformationen. Genauso verhält es sich auch mit Sicherheitsexperten und Mitarbeitern aus dem AppSec-Bereich, die das adaptieren. Vielleicht wegen der Pen-Testings. Ich bin zu diesem Bereich gestoßen, weil ich Entwickler war. Ich gehörte eher zu den Verteidigern als zu den Stürmern. Ich war ein Entwickler, der zu einem Verteidiger geworden ist. Ich glaube, ich kann leichter in diese Rolle schlüpfen als andere. Ich habe jedoch viel Widerstand erlebt.
Messen was funktioniert
Mark Miller:
Wenn es darum geht, Sicherheitsaspekte im Entwicklungsbereich zu berücksichtigen, versuche ich immer, den entsprechenden Maßstab zu finden. Am Ende des Tages muss man dem Unternehmen immer beweisen können, dass die vorgeschlagene Lösung besser ist als das, was man bisher gemacht hat. Welchen Maßstab nutzt man, um sagen zu können, dass etwas funktioniert? Wann weiß ich, ob mein Team erfolgreich mit dem Thema Sicherheit umgeht?
Bryan Batty:
Wir fangen gerade erst an, die durchschnittliche Zeit zu erfassen, die wir benötigen, um Schwachstellen zu beheben. Wir erhalten jetzt die ersten Ergebnisse. Ich denke, wir messen das ungefähr seit dem Ende des ersten Quartals 2019. Jetzt sehen wir langsam, wie lange es durchschnittlich dauert, bis eine Sicherheitslücke behoben ist.
Das ist etwas, das wir wirklich beschleunigen können. Wir können einsehen, seit wann ein Security-Ticket schon einem Team zugewiesen ist. Ich kann dieses Team also direkt ansprechen und es darauf aufmerksam machen, dass es daran jetzt schon sehr lange arbeitet. Wenn wir es schaffen, hier schneller zu werden, müssten wir weniger Zeit dafür aufwenden, Sicherheitslücken zu entfernen. So hätten wir wiederum mehr Zeit dafür, Sicherheitselemente von Beginn an in die Anwendungen zu integrieren.
Mark Miller:
Wie messen Sie Nacharbeit? Wenn man alles richtig gemacht hat, braucht es gar keine Nacharbeit mehr. Nacharbeit könnte z. B. so aussehen: Man baut bewusst eine bekannte Schwachstelle ein (sei es innerhalb oder außerhalb des Codes). Dann wird das Programm später von jemand anderem überprüft, der dann zu der Erkenntnis kommt, dass das Ding von Anfang an schlecht war. Das ist Teil der Schwachstellenbehebung. Aber die Entwickler konzentrieren sich eher darauf, die nächsten Features oder Funktionen in diese Anwendung einzubauen.
Aus Sicht der Sicherheit: Welche Priorität hat diese Nacharbeit bzw. dieses Bestreben, Schwachstellen zu beseitigen?
Bryan Batty:
Da gibt es einige Überlappungen. Eine Schwachstelle könnte bereits existieren, während wir arbeiten. Es könnte sich aber auch um eine neu entdecke Schwachstelle handeln. Das ist nicht unbedingt Nacharbeit. Das ist nur etwas, das man tun muss, weil niemand von vornherein wusste, dass es sich um eine Schwachstelle handelt.
Würden Entwickler qualitative Codes schreiben, gäbe es keinen Bedarf für ein Team, das sich um die Sicherheit von Anwendungen kümmert. Andererseits wäre das dann wie noOps. Das ist noSec. Wissen über Sicherheit und entsprechende Fähigkeiten sind im gesamten Unternehmen verteilt. Dann gibt es nicht so viel, was das Sicherheitsteam tun muss, wenn es überhaupt eines gibt.
Das ist ein Anti-Pattern. So etwas entwickelt sich manchmal auf ganz natürliche Weise. Manche Entwickler leisten hervorragende Arbeit und ich möchte ihnen das sicherlich nicht aberkennen. Einen Entwickler, der sehr auf Sicherheit bedacht ist, aber trotzdem weiterhin seiner eigenen Rolle nachgehen möchte, werde ich dafür sicher nicht bestrafen. Wenn wir zusammen erfolgreiche Arbeit leisten wollen, müssen sie sich von mir helfen lassen. Kooperative Leute machen meinen Job um einiges leichter. Sie sind es, die großartige Anwendungen entwickeln. Meine Aufgabe ist es dabei, den Prozess zu überwachen und weiterhin für Aufklärung zu sorgen.
In meinem Unternehmen haben wir Entwicklerteams mit unterschiedlichen Kompetenzniveaus, was die Sicherheit betrifft. Eines meiner Teams hat sich einmal unsere Tools angesehen und meinte dann: "Hey, das sieht gut aus." Ich werfe einmal wöchentlich einen Blick darauf. Und ich werde gewarnt, wenn eine kritische Komponente auftaucht, aber das ist fast nie der Fall. Mit anderen Teams muss ich viel mehr Zeit verbringen. Da ist es notwendig, mehr Wissen über Sicherheit zu vermitteln bzw. ein größeres Bewusstsein dafür zu schaffen.
Anerkennen konkurrierender Ziele
Bryan Batty:
Wenn es überhaupt kein AppSec-Team gäbe, wäre das eine sehr, sehr schlechte Sache. Wer kümmert sich im Endeffekt darum? Ein Entwickler? Dessen Ziel ist es, Funktionen zu entwickeln. Er will seinem Vorgesetzten gefallen, sich von ihm auf die Schulter klopfen lassen und Funktionen veröffentlichen.
Das Ziel dieses Vorgesetzten oder Geschäftsführers ist der Umsatz. Er versucht, Marktanteile zu gewinnen und möchte sich von seinen Konkurrenten abheben, um den Ruf des Unternehmens kontinuierlich zu verbessern. Da spielt Sicherheit überhaupt keine Rolle. Wenn es jetzt aber um den Ruf geht … kommen wir der Sache schon ein bisschen näher. Denn wenn ein Sicherheitsverstoß vorliegt, ist der gute Ruf dahin.
Das ist für das Unternehmen schon von Belang, weil es nicht in eine Situation wie Capital One damals geraten will. Die Bank prangte damals auf den Titelseiten und war in aller Munde. Ähnlich wie bei Equifax. Es muss also zumindest eine Person geben, deren einzige Aufgabe darin besteht, für die Sicherheit einzutreten und den Fortschritt in diesem Bereich zu überwachen. Natürlich ist es etwas Großartiges, wenn sich die Entwicklerteams selbst um die Sicherheit kümmern können und auch richtig hart dafür arbeiten. Aber dabei handelt es sich nicht um eine ihrer Prioritäten.
Mark Miller:
Dafür werden sie nicht bezahlt.
Bryan Batty:
Ja, ganz genau. Die Vergütung steht immer im Vordergrund. Sie arbeiten auf den Gehaltszuschuss am Ende des Jahres hin. Man könnte vielleicht überprüfen, wie viele Sicherheitslücken eine Person innerhalb eines Jahres behoben hat. Aber auch welche Art von Sicherheitslücken. Es geht ja nicht immer nur um die Menge. Um den Wert der Sicherheitsbemühungen zu messen, geht es nicht nur darum, wie viele Lücken man behoben hat, aber das wäre zumindest einmal ein Anfang. Es könnte ein Programm geben, bei dem Entwickler für solche Dinge anerkannt werden. Diese Anerkennung könnte dann direkt mit ihrer Vergütung in Zusammenhang stehen.
Das war Teil 3 unseres Gesprächs mit Bryan Batty. Lesen Sie in Teil 1, wie er die Nutzung von Software Composition Analysis (SCA) Tools beschreibt. In Teil 2 spricht Bryan über die Möglichkeiten, die Sicherheit zu einem integralen Bestandteil der Software Supply Chain zu machen. In Teil 4 teilt er uns schließlich mit, wieso seine Wahl auf die Sonatype-Plattform fiel.
