Qualys und Nexus Lifecycle

Integration der Sicherheit in einen früheren Prozessabschnitt

Strategien zur Abschaffung vermeidbarer Open-Source-Risiken: Ein Gespräch mit Andrew Wild, ehemals Chief Security Officer bei Qualys

Anlässlich des Gartner Security & Risk Management Summit im Juni 2014 rief Wayne Jackson, CEO von Sonatype, ein Team von erfahrenen Sicherheitsexperten zusammen, um über „Strategien zur Abschaffung vermeidbarer Open-Source-Risiken“ zu diskutieren. Andrew Wild, ehemals Chief Security Officer bei Qualys, teilte seine Erkenntnisse und Erfahrung zum Aufbau eines effektiven und sicheren Software Development Lifecycle, der auch die Vermeidung von Open-Source-Risiken berücksichtigt. Hier sind die Auszüge aus der Podiumsdiskussion.

Jackson: Die Sonatype Open Source Development and Application Security Survey 2014 hat gezeigt, dass die Anwendung der am häufigsten anvisierte Angriffsvektor ist. Dennoch wenden wir relativ wenig Zeit und Geld auf, um dieses Einfallstor zu sichern. Was denken Sie, warum das so ist und wie könnte sich das vielleicht ändern?

Wild: Ich denke, vieles davon hängt mit der Geschichte der Informationssicherheit in Unternehmen zusammen. Die Informationssicherheit hat jahrelang hart an ihrer Integration in die IT und das Geschäft gearbeitet. Aber die Integration mit der entwicklungstechnischen Seite war in vielen Unternehmen lange Zeit kein Schwerpunkt und deshalb sehen wir nun die Schwachstellen nicht, die vorhanden sind. Wir sehen nur die Exploits.

Jetzt bekommt das Thema langsam Aufmerksamkeit, aber die Tools haben oft Mängel oder werden gar nicht im Unternehmen bereitgestellt. Die Abteilung für Informationssicherheit hat nicht diese Art von Beziehung zum Entwicklungsteam, um diese in den Software Development Lifecycle (SDLC) zu integrieren oder sie bleiben einfach lieber bei dem, was sie am besten können: Budgetplanung für Firewalls und Endpunkt-Sicherheit.

Jackson: Es ist bemerkenswert, wie viele Menschen, teilweise in den höchsten Positionen, keine Ahnung vom Umfang ihrer Open-Source-Nutzung haben und ob sie überhaupt angreifbar sind.

Wild: Wir machen Fortschritte in Bezug auf das Sicherheitsbewusstsein und die Richtlinien. Es ist heute nicht ungewöhnlich, in den öffentlichen Erklärungen von börsennotierten Unternehmen zu lesen, dass der Einsatz von Open-Source-Software ein Risikofaktor ist und dass dies lizenzrechtliche Auswirkungen haben könnte. Wie dieses Risiko auf der einen Seite angegeben und offengelegt und auf der anderen Seite tatsächlich eingedämmt oder intern gehandhabt wird, das sind zwei völlig verschiedene Fragen, aber ich denke, das Thema wird immer präsenter. Es gibt ein mittlerweile ein Bewusstsein dafür, dass dies ein Risiko ist, das man in den Griff bekommen muss. Ich denke, in vielen Unternehmen ist dies jedoch eine Aufgabe von vielen, der leider nicht die Priorität eingeräumt wird, die sie eigentlich verdient. “

„Wir wollten Entwicklern Tools zur Verfügung stellen, die sie bei der Entscheidungsfindung hinsichtlich der Auswahl von Open-Source-Komponenten unterstützen.“
– Chief Security Officer, Qualys

Jackson: Die Menschen erkennen langsam, dass ihre Infrastruktur auf Open Source basiert. Von Menschen gemachte Richtlinien, die ältere Methoden nutzen – Whitelists und Blacklists erstellen, Freigaben anfordern etc. – werden dem einfach nicht gerecht, da zu viel Open Source dafür viel zu komplex ist.

Wild: Eine meiner Prioritäten war die Schaffung von Transparenz. Bei Qualys haben wir einen Software Development Lifecycle definiert. Wir setzen auf eine agile Entwicklungsphilosophie, aber zwischen der Wahrnehmung des Sicherheitsteams und der Entwickler gab es eine große Diskrepanz. Sie haben darüber gesprochen, dass Entwickler nichts nachverfolgen oder wissen würden. Warum sollten sie auch? Sie haben die Software entwickelt und diese hat die Qualitätssicherung bestanden. Operations ist üblicherweise die Abteilung, die fortlaufend Schwachstellen überwacht und behebt. Das Operations-Team bekommt eine fertig kompilierte Menge Code zur Ausführung. Sie haben vielleicht nicht die detaillierten Einblicke in alle Komponenten, aus denen das System besteht. So entstehen potenzielle Kluften. Transparenz im Entwicklungsprozess zu schaffen – und potenziell verwendete Open-Source-Komponenten zu entdecken, bevor die Entwicklung abgeschlossen ist –ist etwas, das ich als sehr wichtig für unsere Fähigkeit erachtet habe, sicheren Code zu entwickeln.

Jackson: Sie schreiben ja auch den Code, der andere schützt.

Wild: Ja! Umso wichtiger, dass wir dabei keine Fehler machen. Nur, weil Sie ein Sicherheitsprodukt gekauft haben, sollten Sie nicht davon ausgehen, dass die Entwickler irgendetwas über Sicherheit auf Code-Ebene verstehen. Es ist wirklich schwierig, das richtig zu machen und sich nicht in falscher Sicherheit zu wiegen, nur weil „Security“ auf der Packung steht.

Jackson: Toyota hat einen Prozess, bei dem sie versuchen, ihre Lieferkette zu optimieren, indem sie darüber nachdenken, wie sie schneller mehr Produkte herstellen können, und zwar vorhersehbarer und langfristig effizienter. Wenn Sie sagen, dass Bewusstsein der erste Schritt ist, dann zeigen uns die Erkenntnisse aus der Lieferkettenphilosophie von Toyota, dass es um die Schaffung von Bewusstsein geht, damit die Mitarbeiter mit Entscheidungsbefugnis diese Entscheidungen in Echtzeit treffen können. Es gibt gewisse „Leitplanken“, um die Vorhersehbarkeit langfristig zu wahren und zu optimieren.

Wild: Im privaten Sektor reift das Drittanbieter-Risikomanagement sehr schnell, aber vielleicht nicht so schnell, wie es sollte. Aber ich habe in gerade in den drei Jahren, die ich bei Qualys war, immense Veränderungen hinsichtlich des Volumens und der Komplexität der Fragen erlebt, die von Kunden kommen, die nach dem Sicherheitsprogramm von Qualis fragen. Sie haben Fragen zum Software Development Lifecycle, wie er funktioniert, was wir haben, welche Kontrollmaßnahmen wir einsetzen und welche Open Source Software wir nutzen. Es wird also Teil des Einkaufs- und Beschaffungsprozesses, zumindest im privaten Sektor, und ich denke, das wird Auswirkungen haben. Wie sich das dann in tatsächlich umgesetzten Sicherheitsverbesserungen niederschlägt, bleibt abzuwarten, aber ich denke, es gibt gemeinsame Anstrengungen und einen Schub, der von der Weiterentwicklung und Reife des Drittanbieter-Risikomanagements ausgeht.

„Eine Bill of Materials, egal ob für die Open-Source-Komponenten oder die hauseigenen Komponenten, ist Teil der Gesamtstrategie bei großen Software-Projekten, um sicherzustellen, dass Sie zuverlässige und sichere Komponenten haben, die von Ihnen geprüft und als gut und akzeptabel befunden wurden. Die Wiederverwendung dieser Komponenten ist ein wichtiger Teil der Strategie.“

Im gewerblichen Bereich witzelten wir nach Enron immer darüber, dass wir nun endlich die Triebkraft für Qualität gefunden hätten: Das Gefängnis! Wir müssten die Leute ins Gefängnis schicken, damit sie sich wirklich Gedanken über Qualität machen. Ich denke, dasselbe passiert nun im Sicherheitsbereich. Ich sehe mir das Beispiel Target an – ich weiß, alle auf dieser Konferenz reden darüber, weil es meines Wissens das erste Mal ist, dass ein CEO wegen eines Datenschutzverstoßes seinen Hut nehmen musste. Ich denke, das wird in der Wirtschaft große Wellen hinsichtlich Sichtbarkeit und Bewusstsein für die Auswirkungen solcher Dinge schlagen. Wenn Sie Ihre Due Diligence oder Governance vernachlässigen, wird sich das zu einem gewaltigen Problem auswachsen.

Eine der Herausforderungen bei Gesetzen, Richtlinien und Governance ist, dass man sie nicht nur erlassen und dann darauf hoffen muss, dass sich die Menschen daran halten; man muss sie durchsetzen. Wir haben Verträge gesehen, in denen stand, man solle „mit agilen Methoden entwickeln.“ Healthcare.gov hatte dieses „mit agilen Methoden zu entwickeln“ in der Ausschreibung stehen. Aber die Leute, die das auf Behördenseite verwalten, wissen nicht, was das bedeutet oder wie sie es durchsetzen könnten. Wir müssen also auch die Beschaffung, das Projektmanagement und das Programm-Management bei den Behörden schulen, damit sie wissen, welche Fragen sie stellen müssen und wie sie feststellen können, ob das Geforderte auch wirklich getan wird. Denn oft wird es nicht getan.

Die Firmen tricksen die Behörden aus und bringen sie dazu, Dinge zu akzeptieren, die überhaupt nicht den Anforderungen entsprechen, aber die Behörden können das nicht überprüfen. Das ist also noch eine Sache, die wir nicht vergessen dürfen, wenn es um die Gesetzgebung geht.

Jackson: Wie wäre es, Open-Source-Sicherheit als Kultur in den Entwicklungsprozess einzubringen? Wir haben damit begonnen, die Leute zu ermutigen, mehr über den Aufbau einer Kultur nachzudenken, in der Entwickler einfach bessere Entscheidungen treffen können.

Wild: Viele Unternehmen haben ihren Entwicklern Richtlinien für das sichere Programmieren zur Verfügung gestellt. Das ist toll, wenn diese sich daran halten und die Richtlinien aktualisiert werden. Damit ist hoffentlich die Sicherheit des hauseigenen Codes gewährleistet. Aber was in diesen Unternehmen fehlt: Woher weiß ein Entwickler, wie man eine sichere Komponente auswählt? Wie weiß er, ob die Komponente anfällig ist? Welche Ressourcen hat er? Hat er einen Anreiz oder wird ihm aufgetragen, zur Sicherheit die Komponente zu überprüfen? Bekommt er Richtlinien zur Auswahl einer Komponente? Vielleicht wählt er die Komponente nur, weil sein Freund zwei Firmen weiter sagt, dass sie ganz toll ist, funktioniert und schnell ist; also nimmt er sie. Wir müssen den Entwicklern Tools zur Verfügung stellen, die sie bei der Entscheidungsfindung unterstützen, wenn es darum geht, welche Open-Source-Komponenten ausgewählt werden sollten. Die Sicherheit der Komponente sollte bei der Auswahl zu den berücksichtigten Faktoren gehören, genauso wie Support, Verständlichkeit, Dokumentation, Reaktionsfähigkeit und Leistung.

Jackson: Denken Sie bei Qualys über DevOps und Continuous Delivery nach?

Wild: Wir sind definitiv auf dem Weg zu DevOps. Ich meine, wenn man schon von einem Cloud-Bereitstellungsmodell mit nahezu kontinuierlichen Updates spricht, ist das der naheliegende Weg. Das verbessert unsere Effizienz und unsere Reaktionsfähigkeit. Wir werden für mehr Sicherheit in diesem Prozess sorgen und das ist meiner Meinung nach genau das, was DevOps mitbringt: eine Gelegenheit für die Sicherheitsexperten, in die DevOps-Community einzusteigen und eng mit ihnen zusammenzuarbeiten ... ich denke, man muss Teil dieses Prozesses sein und genau das tun wir bei Qualys.

VERTRIEB KONTAKTIEREN

Bereit, Sonatype auszuprobieren?

Schützen und automatisieren Sie Ihre Software-Supply-Chain.