Sicherheitsplan für die Software-Supply-Chain 5 Best-Practices zur Absicherung der Software-Supply-Chain

Anbieter zum Thema

Arvato Systems

TXOne Networks

Keeper Security EMEA Ltd.

Angriffe auf die Software-Supply-Chain und auf Cloud-Native-Anwendungen nehmen immer weiter zu. Dabei schleusen Hacker schädliche Software-Pakete oder -Tools in den Entwicklungsprozess ein und platzieren dort gefährlichen Schadcode, der dann in nichtsahnenden Unternehmen zum Einsatz kommt.

Weil immer mehr Firmen auf Cloud-Native-Strategien setzen, ist es umso wichtiger, die Risiken der Software-Supply-Chain besser zu verstehen und sich entsprechend vorzubereiten. Hierbei helfen die folgenden Best-Practice-Methoden, die als Grundlage für einen strukturierten Sicherheitsplan dienen können:

1. DevOps-Teams stärken, DevSecOps-Kultur fördern

DevOps ist ein im Prinzip endloser Prozess. Der Schlüssel zu kontinuierlichem Erfolg bei der Absicherung des Entwicklungsprozesses liegt darin, sicherzustellen, dass Entwickler im Rahmen eines geschlossenen Arbeitsablaufs klare, genaue und umsetzbare Sicherheitsinformationen haben. Dabei sollte der „Shift-Left-Ansatz“ für Software- und Systemtests zum Einsatz kommen, bei dem Tests bereits viel früher im Entwicklungszyklus stattfinden.

Um innerhalb dieses Prozesses zu jedem Zeitpunkt die richtigen Entscheidungen zu treffen, welche Software-Pakete oder Libraries verwendet werden, müssen die Entwickler die Risiken kennen und wissen, wie sie diese vermeiden können. Idealerweise ist das Testen der Sicherheit innerhalb jedes einzelnen Schrittes des Entwicklungsprozesses einfach und schränkt weder Produktivität noch Kreativität der Entwickler ein. Wenn es aber beispielsweise zu kompliziert ist, die Sicherheit zu testen, oder Builds zu spät überprüft werden, gelangen unsichere Lösungen in die Produktion.

Empfehlungen: Es empfiehlt sich, Feedback-Schleifen einzurichten, um den Entwicklungsteams klare Informationen über Sicherheitsrisiken und Hinweise zur Behebung zu geben. Dabei gilt es, die etablierten DevOps-Arbeitsabläufe zu berücksichtigen – um die Wahrscheinlichkeit zu erhöhen, dass die Sicherheit in die Standardabläufe integriert werden kann.

2. Sicherheitskontrollen automatisieren

Sicherheitskontrollen lassen sich automatisieren, was Entwicklern deren Einhaltung erleichtert. Nicht wenige Sicherheitsexperten haben zwar Bedenken, Automatisierung zu nutzen – weil sie fürchten, die Kontrolle zu verlieren oder zu viele Bedingungen zu schaffen, die die Arbeitsabläufe behindern. Sicherheit und Automatisierung können jedoch Hand in Hand gehen, wenn man über die entsprechenden Tools und Kriterien verfügt, um als Vertreter des Sicherheitsteams in automatisierten Systemen zu fungieren.

So ausgestattet lassen sich Sicherheitskontrollen einfach automatisieren und ganz bewusst in die CI-Pipeline einbetten. Dank der Automatisierung können Unternehmen zudem standardisierte Workflows durchführen und erhalten am Ende einen detaillierten Bericht über ungewöhnliche, riskante oder gar bösartige Verhaltensweisen und Artefakte, die während der Analyse ans Tageslicht kamen. Die Ergebnisse dieser Analyse gehen dann an alle, die diese Informationen benötigen, um geeignete Maßnahmen zu ergreifen.

Empfehlungen: Man sollte wirksame Richtlinien und Kontrollen festlegen, um eine sichere Automatisierung zu ermöglichen. Es gilt darauf zu achten, dass die Bedingungen für das Wirksamwerden dieser Richtlinien nicht zu spezifisch oder zu allgemein gehalten sind. Bei der Ausarbeitung dieser Richtlinien ist auf Skalierbarkeit zu achten, und es sind klar die Folgeschritte zu definieren, die bei einem Ausfall der Bedingungen erfolgen müssen.

3. Risikotoleranz und Sicherheitsstandards definieren

Bei der Ausarbeitung von Richtlinien und Kontrollen ist es wichtig, alle relevanten Interessengruppen einzubeziehen. Erstens diejenigen, die Sicherheitsrisiken bewerten, zweitens diejenigen, die die Nichteinhaltung von Richtlinien feststellen, drittens diejenigen, die Sicherheitsrisiken beheben müssen, und viertens diejenigen, die für die Sicherheit in Produktionsumgebungen verantwortlich sind. Gemeinsam sollten diese Beteiligten die Sicherheitsrisikotoleranz für die Software-Artefakte definieren, die die Pipeline durchlaufen, um Risiken zu erkennen, zu priorisieren und zu beheben, bevor sie zu Problemen in der Produktion führen.

Bei der Betrachtung der Sammlung von Artefakten, Paketen und Libraries, die über die Software-Lieferkette eintreffen, kann diese Aufgabe jedoch sehr kompliziert werden. Das liegt daran, dass die meisten Unternehmen ein gewisses Maß an Kontrolle an die Supply-Chain abgeben, um im Gegenzug mehr Flexibilität, Skalierbarkeit oder Effizienz zu erreichen. Die Identifizierung von Risiken ist mit herkömmlichen Methoden zur Prüfung der Anwendungssicherheit für Ressourcen von Drittanbietern unter Umständen nicht möglich, und die Behebung von Problemen ist nicht immer eine Aufgabe, die interne Entwicklungsteams bewältigen können. Daher unterscheiden sich Risikotoleranz und Sicherheitsstandards für Supply-Chain-Pakete wahrscheinlich von denen, die sie beispielsweise für benutzerdefinierten Code haben.

Empfehlungen: Ein Gespräch mit den Mitwirkenden und Sicherheitsverantwortlichen ist ratsam. Dabei sollten beispielsweise folgende Fragen gestellt werden: „Wie sieht der Überprüfungsprozess für Risiken im Code im Vergleich zu jenen aus, die über die Lieferkette eingehen?“, „Welche Reaktions- und Abhilfeschritte erfolgen automatisch?“ und „Wer wird benachrichtigt?“

Wenn die Software-Supply-Chain involviert ist, können die Antworten auf diese beiden Fragen Personen außerhalb des Teams oder der Organisation betreffen. Die Problemlösung kann in diesen Szenarien nur durch einen längeren Prozess der Benachrichtigung des Anbieters über ein Problem erfolgen und unterliegt möglicherweise dessen SLAs für die Reaktion.

4. „Vertrauen“ aus der Sicherheitsstrategie entfernen

Ungerechtfertigtes Vertrauen dient regelmäßig als Angriffsvektor oder Einstiegspunkt in eine Umgebung. Obwohl es möglich ist, den Entwicklern Informationen über Schwachstellen zur Verfügung zu stellen und Sicherheitstests in den Software Development Life Cycle und die Continuous-Integration-/Continuous-Delivery-Pipelines zu integrieren, bringt die Software-Supply-Chain viele zusätzliche potenzielle Schwachstellen mit sich, bei denen diese Sicherheitsverfahren möglicherweise nicht angewandt werden oder unwirksam sind.

Empfehlungen: Man sollte im Unternehmen Verständnis dafür wecken, dass ein Anbieter die Software-Sicherheit möglicherweise nicht mit der gleichen Strenge und den gleichen Standards angeht wie die eigenen internen Sicherheits-, DevOps- und Entwicklungsteams. Selbstredend möchte niemand die Sicherheit seines Unternehmens in die Hände von Dritten geben und darauf vertrauen, dass man dort die Sicherheit genauso ernst nimmt.

Tipp 5: Sicherheitsplan strukturieren

Die genannten vier Stufen bilden ein solides Fundament, um Risiken in der Software-Lieferkette bei nativen Cloud-Anwendungen zu minimieren. Früher oder später muss man die entwickelte Software aber auch ausführen. Dies sollte selbstredend nicht in der Produktions-, sondern einer Sandbox-Umgebung geschehen. In dieser Testumgebung muss dann eine Sicherheitslösung zum Einsatz kommen, die bösartiges Verhalten erkennen kann, das nur zur Laufzeit auftritt. Wenn ein solches Verhalten auftritt, gilt es zu verhindern, dass die bösartigen Artefakte in die Produktion gelangen.

Erkannte bösartige oder ungewöhnliche Aktivitäten müssen eine Reaktionskette in Gang setzen. Dabei ist es wichtig, diese Reaktionen – wenn möglich – als Teil des Build-Prozesses oder der CI/CD-Pipeline zu automatisieren. Auf diese Weise wird alles in der Vorproduktion getestet, ohne zusätzliche Hürden für Sicherheits- und DevOps-Teams zu schaffen oder das Risiko zu erhöhen, dass eine Auslieferungsfrist aus unnötigen Gründen verpasst wird.

Schließlich sollten SecOps und Forensik unterstützt werden, indem man die erkannten Verhaltensweisen automatisch nach Standards wie dem MITRE-ATT@CK-Framework klassifiziert. Auf diese Weise lassen sich die gewonnenen Erkenntnisse in das Gesamtbild des Software-Sicherheitsrisikos eines Unternehmens einordnen, so dass man nicht die sprichwörtlichen Äpfel und Birnen vergleicht, wenn ein Sicherheitsteam die Risikoprofile von Cloud-Native-Apps, Legacy-Apps, interner Software und kommerziellen Technologien in ihrer Gesamtheit betrachtet.

Fazit

Um Angriffe auf die Software-Supply-Chain und Cloud-Native-Infrastrukturen zu verhindern, benötigen Organisationen moderne Sicherheitslösungen mit dynamischer Bedrohungsanalyse und den richtigen Sicherheitsansatz, basierend auf in der Industrie geltenden Best-Practice-Methoden.

Dazu gehören die Befähigung von DevOps-Teams, die Förderung einer DevSecOps-Kultur allgemein, die Definition von Risikotoleranz und Sicherheitsstandards für die Supply-Chain, die Automatisierung von Sicherheitskontrollen und der Verzicht auf Vertrauen in der Sicherheitsstrategie. Diese Grundlagen bilden das Fundament eines effektiven Sicherheitsplans für die Software-Supply-Chain, der den kompletten Entwicklungsprozess absichern kann.

Über den Autor: Arne Jacobsen ist Director of Sales EMEA bei Aqua Security.

(ID:49249092)