Wir müssen über das Blocken und „Shift Left Security“ sprechen – Lacework

An die Sicherheitsbranche: Wir müssen über Blocking und „Shift Left Security“ sprechen

Lacework-Editorial

June 11, 2020

Der Innovationsdruck für Softwareteams war noch nie so stark wie heute und treibt Unternehmen dazu, Continuous Delivery und Automatisierung einzuführen. Auch wenn bereits viel darüber geschrieben wurde, dass DevOps und Security enger zusammenarbeiten sollten, sind in der Praxis nur wenige Team wirklich zufrieden mit den Ergebnissen. Nachdem ich nun einige Zeit bei größeren und kleineren Unternehmen im In- und Ausland verbracht habe, konnte ich einige häufige Problemstellen innerhalb von Teams feststellen. 

Ich habe den Großteil meiner Karriere in der Technologiebranche und im Systemtechnikbereich gearbeitet, mich in den letzten zehn Jahren allerdings auf die Automatisierung von Anwendungen und Infrastrukturen sowie auf Continuous Delivery konzentriert. Security-Teams spielten oft eine unterstützende Rolle bei diesen Automatisierungsbemühungen. Größtenteils arbeitete ich jedoch Seite an Seite mit Entwicklern und Produktionsingenieuren. Seit dem Antritt meiner Rolle bei Lacework Ende letzten Jahres hatte ich die Gelegenheit, mit so vielen Security-Teams zu interagieren wie noch nie. Aufgrund dieser Zusammenarbeit konnte ich all die Herausforderungen beobachten, die die Mitarbeiter in der Sicherheitsbranche bewältigen müssen – Security-Teams fällt es häufig schwer, sich an dieses rasch verändernde Umfeld anzupassen.

Sie sind für den Einsatz von veralteten Sicherheitsmustern in der modernen Cloud?

Der Einsatz von „Shift Left“-Security, wobei Kontrollen und GuardRails früher im Produktentwicklungszyklus eingesetzt werden, wird immer beliebter. Shift Left ist eine bewährte Methode, um Risiken zu reduzieren und die Kosten für die Behebung von Bugs und Schwachstellen zu reduzieren, die sich in den Produktionsprozess eingeschlichen haben. Bereits im Jahr 2016 (in der Tech-Branche also vor einer halben Ewigkeit) stellte der „State of DevOps“-Bericht fest, dass „leistungsstarke Unternehmen im Vergleich zu leistungsschwachen Unternehmen 50 Prozent weniger Zeit mit der Behebung von Sicherheitsproblemen verbringen. Da die Ziele im Bereich der Information Security in die tägliche Arbeit eingebunden wurden, konnten Teams bessere Leistungen im IT-Bereich vorweisen und sichere Systeme entwickeln.“ In diesem Fall handelt es sich allerdings nicht nur um Best Practices. Man könnte argumentieren, dass ordnungsgemäß umgesetzte Produktionsabläufe, in denen der „Shift Left“-Ansatz verfolgt wird, die meisten der Sicherheitsherausforderungen angehen, mit denen wir heute konfrontiert sind. Dieser Fokus auf die frühen Phasen der Produktentwicklung ist letztendlich natürlich genauso wichtig wie der Fokus auf die späteren Phasen – darauf werden wir aber später noch einmal eingehen.

Wenn wir den modernen Ansatz für die Cloud mit bestehenden Security-Prozessen vergleichen, stellt sich schnell heraus, dass häufig eine Abhängigkeit von Tools besteht, über die Entwickler oder Dienste anhand von zentralisierten Richtlinien geblockt werden können. Um diese Richtlinien zu ändern, müssen häufig Supportanfragen eingereicht oder sogar das Change Advisory Board (CAB) hinzugezogen werden. Auf diese Weise geht wertvolle Zeit bis zur Markteinführung verloren und es kann auch zu anderen Problem kommen.

Leider ist diese Tendenz zum Blockieren selbst heute noch vorhanden. Eine der häufigsten Fragen von Security-Teams ist die folgende: „Bietet Lacework auch Blocking-Funktionen?“ Nachdem ich mich bei verschiedenen Teams genauer darüber informiert hatte, fand ich heraus, dass unterschiedliche Unternehmen diese Frage aus unterschiedlichen Gründen stellen. Meist bezieht sie sich jedoch auf den Build-Prozess von Containern. Unternehmen möchten also wissen, ob Lacework im Falle einer Schwachstelle im Container den Aufbau oder die Bereitstellung des Containers blockieren wird. Aus dieser Frage folgt immer ein lebhaftes Gespräch, das jedoch auch zu ernsthaften Diskussionen führen kann.

Das Problem ist also sehr viel komplexer als die eigentliche Frage: „Bietet Ihre Plattform auch Blocking an (ja/nein)?“ Bei der Frage, ob aufgrund von Schwachstellen Blockierungen vorgenommen werden sollten, gibt es keine eindeutige Antwort, da Schwachstellen und Risiken nicht ein und dasselbe sind. Security-Teams, die in ihren Unternehmen den „Shift Left“-Ansatz verfolgen möchten, sollten nicht nach Tools suchen, die auch Funktionen zum Blockieren der Entwickler anbieten. Dies kann nämlich bedeuten, dass Unternehmen bei der Continuous Delivery und Automatisierung weniger erfolgreich sind und – viel wichtiger – dass sie einen wertvollen Aspekt verpassen, auf den viele leistungsstarke Unternehmen großen Wert legen: die Zusammenarbeit. Entscheidend ist hierbei nicht der Fokus auf die Blockingfunktion. Sie sollten sich stattdessen auf die Bereitstellung der Daten konzentrieren, die Ihnen bei der Entscheidung hinsichtlich des Blockierens behilflich sein können.

Das Schließen von organisatorische Lücken anhand von Daten

Beim genaueren Blick auf die besonderen Security-Herausforderungen für den Aufbau und die Bereitstellung von Containern gibt es eine Reihe verschiedener Faktoren, die berücksichtigt werden sollten. Das Wissen um eine Schwachstelle reicht nicht aus, um sich für oder gegen das Blockieren zu entscheiden. An welcher Stelle des Prozesses möchten soll das Blocking greifen? Möchten Sie Entwickler blockieren, damit diese einen Container mit einer Schwachstelle nicht erstellen oder veröffentlichen können (dies ist meiner Meinung nach eine weniger erfolgreiche Strategie) oder möchten Sie verhindern, dass der Container mit der Schwachstelle bereitgestellt wird? Soll die Bereitstellung eines Containers in ALLEN Umgebungen verhindert werden, oder gibt es bestimmte Umgebungen, die genaueren Prüfungen unterzogen werden müssen (PCI, SOC 2, HIPAA)?

Bei der Analyse der eigentlichen Schwachstellen stellt sich die Frage, wie viele davon als kritisch, hoch, mittel, niedrig oder als Information eingestuft werden. Wie viele dieser Schwachstellen können behoben werden? Wird dieser Dienst auch in einer Produktionsumgebung bereitgestellt? Wie wahrscheinlich ist es, dass diese Schwachstelle ausgenutzt wird, und welche Auswirkungen könnte dies auf das Unternehmen haben?

Lohnt es sich, für jede Schwachstelle einen Entwicklungszyklus zu investieren?

Bei der erfolgreichen Implementierung von „Shift Left“-Ansätzen wird auch der weitere Kontext des Dienstes berücksichtigt sowie die Art und Weise, wie der Dienst zum Ende des Produktionszyklus bereitgestellt wird. Ich habe vor Kurzem mit einer Kundin gesprochen, die für die Behebung von Schwachstellen von Containern in einer großen Cloud-Umgebung verantwortlich ist. Sie teilte mir mit, dass ihre derzeitige Lösung für Vulnerability-Scans der Container ihr Team zwar über Schwachstellen im Build-Prozess informiert, sie und ihr Team sich jedoch aufgrund des mangelnden Verständnisses zur Bereitstellung dieser Dienste auf „mühsame Weise die Daten erarbeiten müssen“, um das genaue Risiko berechnen zu können. Das alles deutet darauf hin, dass wir noch mehr Daten benötigen, um wichtige Entscheidungen hinsichtlich der Priorisierung der Technik treffen zu können – und es einer stärkeren, teamübergreifenden Zusammenarbeit bedarf.

Entwickler und Produktionsingenieure verlassen sich bei ihrer Arbeit auf Codes, Automatisierungsprozesse und kontinuierliche Bereitstellungspipelines. Sie benötigen automatisierte Tests, um ihre Arbeit ausführen und Entscheidungen auf Grundlage dieser Tests treffen zu können. Entwickler und Produktionsingenieure suchen stets nach robusten APIs, die sie integrieren und mit denen sie automatisierte Tests erstellen können, um schnell und effizient voranzukommen. Sie können jedoch auch Schnelligkeit und Sicherheit erreichen, ohne dabei Abstriche in der Security hinnehmen zu müssen. Der Schlüssel zu einem erfolgreichen „Shift Left“-Ansatz liegt nicht in der Verlangsamung oder Blockierung der Vorgänge, sondern darin, den Zugang zu den Daten zu ermöglichen, die für die automatisierten Entscheidungen hinsichtlich Security und Risiko benötigt werden. Auf diese Weise können Unternehmen auch weiterhin diese wichtigen Entscheidungen treffen.

Eine Datenplattform, die den Wandel vorantreibt

Lacework ist im Grunde eine hoch skalierbare und elastische Datenplattform. Die von uns erfassten und organisierten Daten, die wir unseren Kunden vorstellen, sind letztendlich jedoch speziell dafür entwickelt, die Lücke zwischen Security und DevOps zu schließen, damit Unternehmen mit Höchstgeschwindigkeit arbeiten können, ohne dabei ihre Sicherheit gefährden zu müssen. Abgesehen von den Plattformfunktionen ist Lacework außerdem bestrebt, seinen Kunden zum Erfolg zu verhelfen. Das Unternehmen erreicht dies, indem es die besten der bestehenden Strukturen fördert und somit die Zusammenarbeit zwischen den verschiedenen Teams stärkt. Auf diese Weise wird kontinuierlich Mehrwert geschaffen – und die Sicherheit wird nicht beeinträchtigt.

Der Weg zu DevSecOps

Security-Teams müssen ihren Blickwinkel auf das Blockieren verändern. Jetzt ist nicht der richtige Zeitpunkt, um nach Tools zu suchen, die Blockingfunktionen anbieten. Bei DevSecOps geht es eher um eine Kultur der Zusammenarbeit und nicht nur um die Technologie. Setzen Sie sich mit Ihren Entwicklern und Produktionsingenieuren zusammen und informieren Sie sich, auf welche Weise diese Teams ihre Dienste entwickeln und herausbringen. Stellen Sie sicher, dass Entwickler und Produktionsingenieure alle notwendigen Sicherheitsdaten erhalten, die sie zur kontinuierlichen Risikoüberprüfung und -bewertung für die Bereitstellung dieser Dienste benötigen. Messen Sie nicht nur Ihre eigenen Ergebnisse im Bereich der Sicherheit, sondern auch die Fähigkeit des Unternehmens, Ihren Kunden weiterhin auf schnelle und effiziente Weise neue Funktionen zur Verfügung stellen zu können. Auf diese Weise können alle Beteiligten ihre Ziele erreichen, dabei lernen und sich weiterentwickeln.

 

Photo via Ilario Piatti on Unsplash