Als Betriebsprofi bei einem Cloud-Sicherheitsunternehmen habe ich eine einzigartige Perspektive darauf, wie Sicherheit und Betrieb zusammenarbeiten können – und in einer idealen Welt auch sollten. Ein häufiges Problem, das wir heute in der Technologiebranche sehen, ist, dass Sicherheit fast immer zu spät in den Entwicklungsprozess einbezogen wird.

Es kann sich anfühlen, als wäre Sicherheit eine völlig separate Disziplin, und die Einbindung in enge DevOps-Feedbackschleifen kann entmutigend erscheinen. Aber ich bin hier, um Ihnen zu sagen, dass nicht nur dürfen Es ist zwar möglich, aber nicht so schwierig, wie es aussieht. Und wenn Sie es richtig machen, wird sich Ihre allgemeine Sicherheitslage deutlich verbessern und es werden zahlreiche Schwachstellen beseitigt.

Insbesondere das Konzept des „Shifting Left“ ermöglicht es Teams, Sicherheitsprozesse, die sie zuvor viel später im Bereitstellungsprozess durchgeführt haben (wenn überhaupt), früher einzuführen, um sicherzustellen, dass die Sicherheit integriert ist und nicht erst nachträglich erfolgt. In diesem Beitrag erkläre ich, wie das geht.

Was bedeutet „zu spät“?

Werfen wir zunächst einen kurzen Blick darauf, wie Sicherheit heute in DevOps-Prozesse integriert wird. Oft ist dies einfach nicht der Fall. Dies äußert sich darin, dass Ingenieure Code bereitstellen, sobald er fertig ist, und Sicherheit überhaupt nicht in den Prozess einbeziehen. Natürlich machen die Entwickler, die dies tun, nur ihre Arbeit. Sie stehen unter dem Druck der Produktteams, Funktionen freizugeben, und sie tun einfach, was sie tun müssen, um den Code so schnell wie möglich herauszubringen.

In anderen Fällen werden Sicherheitsteams in diesen Ablauf eingebunden und werden zu Torwächtern, die eine Sicherheitsüberprüfung verlangen, bevor Code veröffentlicht werden kann. Es ist gut zu sehen, dass Sicherheitsleute einbezogen werden und Code auf Sicherheitsmängel überprüft wird. Aber bis zur letzten Minute zu warten, kann kontinuierliche Lieferzyklen behindern, und im heutigen schnelllebigen Umfeld ist das oft keine Option. Ganz zu schweigen davon, dass es zu echten Spannungen zwischen diesen Teams führen kann, wenn sie gegeneinander ausgespielt werden.

So beginnen Sie mit der Linksverschiebung

In den letzten Jahren optimieren immer mehr Unternehmen ihre DevOps-Teams, um schneller zu arbeiten und kontinuierlich Software bereitzustellen. Aber es ist an der Zeit, auch die Sicherheit in den Mittelpunkt zu rücken. Hier sind meine Tipps dazu.

Verwenden Sie dieselben Tools

Es ist wichtig, dass Ihre Sicherheitsteams mit denselben Tools für kontinuierliche Integration und Bereitstellung vertraut sind, die auch Ihre DevOps-Teams verwenden. So begann die gute Zusammenarbeit zwischen Dev und Ops überhaupt erst – indem den Ops-Mitarbeitern das Programmieren und den Entwicklern die Verwendung von Konfigurationsmanagement-Tools wie Chef beigebracht wurde. Jetzt ist es an der Zeit, dies auch mit der Sicherheit zu tun.

Jenkins ist ein großartiges Beispiel. Wenn Ihre Entwickler Jenkins bereits zum Testen und Bereitstellen von Code verwenden, warum bringen Sie dann Ihrem Sicherheitsteam nicht auch bei, es zu verwenden? Wenn sie dasselbe Tool für Sicherheitstests verwenden, ist es viel einfacher, sie frühzeitig in den Prozess einzubinden.

Ein weiteres großartiges Tool heißt Gauntlt . Obwohl ich dem Begriff „robustes DevOps“ gegenüber etwas zurückhaltend bin, ist die Idee hinter Gauntlt gut. Von ihrer Website:

„Gauntlt bietet Hooks für eine Vielzahl von Sicherheitstools und stellt sie Sicherheits-, Entwicklungs- und Betriebsteams zur Verfügung, damit diese gemeinsam robuste Software entwickeln können. Es wurde entwickelt, um Tests und die Kommunikation zwischen Gruppen zu erleichtern und umsetzbare Tests zu erstellen, die in Ihre Bereitstellungs- und Testprozesse eingebunden werden können.“

Das Konzept, Sicherheit in die Mitte Ihrer Betriebs- und Entwicklungsprozesse zu integrieren, ist grundsätzlich sinnvoll. Auf diese Weise verlangsamt die Sicherheit die Bereitstellung nicht und Sie können die Feedbackschleife straffen, wenn ein Problem aufgedeckt wird. Sicherheitsteams können Code mit Gauntlt schreiben und ihn testen, bevor er veröffentlicht wird, was eine erfolgreiche, kontinuierliche Bereitstellung ermöglicht.

Versuchen Sie es mit der statischen Analyse

Eine weitere Möglichkeit besteht darin, die statische Analyse mit einem Tool wie auszuprobieren Veracode . Dann können Ihre Sicherheitsteams den Code vor der Bereitstellung analysieren und versuchen, potenzielle Probleme zu erkennen. Bei der statischen Analyse wird Software im Wesentlichen analysiert, ohne den Code auszuführen. Sicherheitsteams können damit automatisch nach potenziellen Schwachstellen suchen, ohne den Softwarebereitstellungszyklus zu unterbrechen.

Anreize ausrichten

Eine der Herausforderungen bei der Zusammenarbeit von DevOps und Sicherheit bestand in der Vergangenheit darin, dass sie widersprüchliche Anreize hatten. DevOps gewinnt, wenn sie Code schnell herausbringen. Sicherheit gewinnt nur, wenn sicherer Code herausgebracht wird.

DevOps-Teams und Sicherheitsteams arbeiten besser zusammen, wenn sie dieselben oder kompatible Tools verwenden, wie oben erläutert. Aber um noch einen Schritt weiterzugehen, müssen Sie auch sicherstellen, dass Sie die Anreize für diese Teams aufeinander abstimmen. Das bedeutet, DevOps für die Veröffentlichung sicheren Codes zu belohnen und die Sicherheitsteams für schnellere Fortschritte.

Übernehmen Sie die Verantwortung

Ein häufiger Fehler, den wir beobachten, sind Teams, bei denen die Sicherheitsabteilung nicht einmal Zugriff auf die Produktion hat. Wenn die Sicherheitsabteilung keine direkte Kontrolle über den Code hat, können Sie davon ausgehen, dass sie nicht eng in die DevOps-Zyklen integriert wird.

Wenn Sie andererseits den Sicherheitsleuten Verantwortung übertragen und ihnen beibringen, wie sie Probleme im Code selbst lösen können, können sie Teil einer gut geölten Maschine werden und nicht eines Silos. Zum Beispiel: Bedrohungsstapel kann Ihr Team auf Sicherheitsprobleme aufmerksam machen. Wenn Sie Sicherheitsteams beibringen, wie sie diese Probleme lösen können, und ihnen Zugriff auf den Konfigurationsverwaltungscode geben, können sie direkt Systemänderungen vornehmen.

Ähnlich, Koch hat ein Tool namens Open Source zur Verfügung gestellt InSpec , ein Framework für Audits und Tests. Mit InSpec können Sicherheitsteams Code schreiben, um Server zu prüfen und die Einhaltung der Vorschriften sicherzustellen. Dies wiederum gibt ihnen weitaus mehr direkte Kontrolle über den Prozess. Befähigen Sie Sicherheitsteams, ihre DevOps-Fähigkeiten zu verbessern, und Sie werden den Beweis sehen.

Eine andere Möglichkeit, dies anzugehen (insbesondere, wenn Sie kein eigenes Sicherheitsteam haben), besteht darin, Backend-Ingenieure mit der Behebung von Codes zu beauftragen, wenn Sicherheitslücken auftreten. Wenn Ingenieure direkt für die Gesundheit ihres Codes verantwortlich sind, konzentrieren sie sich viel eher darauf, ihn von vornherein sicher zu erstellen. Bei Threat Stack haben wir 2 Ops-Mitarbeiter und 10 Backend-Ingenieure auf Abruf. Wenn also ein Problem mit dem Produkt auftritt, werden normalerweise die Backend-Engineering-Teams, die den Code geschrieben haben, aufgefordert, es zu beheben. Diese Ebene der Code-Eigentum bietet ihnen einen Anreiz, es von Anfang an richtig zu bauen.

Der Weg nach vorn führt seitwärts

Die Sicherheit nach links zu verlagern ist besser für die allgemeine Gesundheit Ihres Unternehmens. Anstatt dass Sicherheitsteams Probleme erkennen, Tickets öffnen und darauf warten, dass Entwickler oder Ops-Profis die Probleme beheben, können sie dies selbst tun. Dies spart nicht nur Zeit und Arbeitskräfte, sondern stellt auch sicher, dass Code kontinuierlich und sicher veröffentlicht werden kann. Es liegt an den Leuten auf allen Seiten dieser Gleichung, proaktiver zu werden und zu lernen, wie andere Teams arbeiten und wie sie enger in diese Arbeitsabläufe integriert werden können.

Die oben genannten Tipps sollten Ihnen einen Ausgangspunkt bieten, um „Shifting Security Left“ in Ihrem Unternehmen Wirklichkeit werden zu lassen. Denken Sie daran, dass es wie bei vielen Aspekten der Sicherheit eine kultureller Wandel (Es geht nicht nur darum, neue Tools einzuführen.) Aber mit der richtigen Einstellung, den richtigen Anreizen und den richtigen Feedbackschleifen ist dies möglich.