5 Wege zur Absicherung von Code-Signatur-Prozessen

Wir alle leben in einer digitalisierten Welt, die auf Code basiert. Software durchdringt praktisch jeden Aspekt unseres Lebens – von den Dingen, die jeder tagtäglich benutzt, bis hin zur kritischen Infrastruktur unserer Gesellschaft. Gleichzeitig werden Hacker immer geschickter bei der Verbreitung von Malware. Berüchtigt ist der Angriff auf SolarWinds, bei dem mehr als 18.000 Kunden erheblich geschädigt wurden, weil sie der von SolarWinds veröffentlichten Software vertrauten. Sie vertrauten ihr, weil sie digital signiert und mit einer Code Signing-Maschinenidentität authentifiziert war.

Diese Art des Angriffs – bei dem Hacker Malware in Software einschleusen, während diese entwickelt wird, um sie in legitime Software-Updates einzuschleusen – ist nicht neu. Die Raffinesse und Reichweite dieser Art von Angriffen hat sich jedoch als sehr erfolgreich erwiesen und wird wahrscheinlich andere dazu ermutigen, es zu versuchen. Es ist von größter Wichtigkeit, dass Unternehmen dies verhindern, und obwohl es keine Patentlösung gibt, ist die Verschärfung ihrer Code-Signierungsprozesse ein wichtiger Schritt.

Code Signing war ein Problem; es hätte die Lösung sein sollen

Bei dem Angriff auf SolarWinds vertrauten Unternehmen darauf, dass die von SolarWinds entwickelte Software frei von bösartigem Code sein würde. Sie hatten implizites Vertrauen in die signierte Software, die sie erhielten, da es keinen Hinweis auf Manipulationen gab.

Es gibt zwar keine einzelne Lösung, die diesen Angriff verhindert hätte, aber stärkere Code-Signierungsverfahren wären hilfreich gewesen. Code Signing-Zertifikate sind Maschinenidentitäten und ermöglichen es Entwicklern, die Authentizität einer Software zu beweisen. Indem Anwendungen, Software oder eingebettete Firmware mit einem privaten Schlüssel digital signiert werden, wird den Endnutzern der Nachweis erbracht, dass der Code aus einer vertrauenswürdigen und rechtmäßigen Quelle stammt. Wenn jedoch die Maschinenidentität für die Codesignierung schlecht geschützt ist und in die Hände von Angreifern fällt, kann dies schlimme Folgen haben. Die Maschinenidentität kann als Waffe eingesetzt werden, die es Hackern ermöglicht, Code-Signierungsprozesse zu unterlaufen, während sie gleichzeitig als vertrauenswürdig erscheinen.

Noch vor ein oder zwei Jahrzehnten schützten Unternehmen ihre Softwareentwicklungsumgebungen, indem sie den Prozess vollständig in einer Sandbox unterbrachten, die keinen Zugriff von außen auf das Netzwerk zuließ. Jeder eingebrachte Quellcode wurde von allen konkurrierenden AV-Engines gescannt, um sicherzustellen, dass keine bekannten Schwachstellen vorhanden waren. Dies ging zwar zu Lasten von Komfort und Geschwindigkeit, ermöglichte aber die Entwicklung des bestmöglichen Produkts. Aufgrund der Geschwindigkeit der Entwickler und der Zeitvorgaben für die digitale Transformation ist dies jedoch nicht mehr möglich. Wenn Unternehmen also kein vollständig offline arbeitendes System für die Softwareentwicklung haben können, wie lassen sich dann die kontinuierlichen Build- und Delivery-Pipelines, die immer online sind, besser schützen?

Eine Möglichkeit, die Build-Pipeline besser zu schützen, besteht darin, sie zu sperren und nur Softwarepakete zuzulassen, die speziell für die Installation in der Delivery-Pipeline zugelassen sind. Es gibt keinen Grund, warum eine sehr statische Liste genehmigter Binärdateien mit gültigen Signaturen nicht geprüft werden könnte, bevor sie zur Ausführung zugelassen werden. Die zweite Möglichkeit ist die Verschärfung der Code-Signierungsverfahren, um die Anzahl der Softwarepakete auf dem Arbeitsplatzrechner zu begrenzen und sicherzustellen, dass nur vertrauenswürdiger Code ausgeführt wird. Dann wäre nur vom Hersteller signierte Software Teil des Build-Systems, und jede installierte Malware (wie beim SolarWinds-Angriff) könnte nicht ausgeführt werden.

Wie bei jeder Sicherheitsverletzung gibt es keine Zauberformel, die den SolarWinds-Angriff und die anschließenden Änderungen des Quellcodes hätte verhindern können. Bei der Erörterung der Sicherheit des Gesamtsystems wird immer der Ansatz der Sicherheitsebenen gelten. Von der Netzwerkebene über die Personen, die Zugriff auf den Quellcode haben, bis hin zur Überprüfung des Quellcodes und der Bereitstellung eines Produkts, bei dem Unternehmen nachweisen können, dass es von einem vertrauenswürdigen Build-System stammt. All dies muss unter Berücksichtigung der Risiken geprüft, untersucht und gewartet werden.

Die Geschwindigkeit der DevOps-Pipelines hat das Problem bereits über die menschliche Geschwindigkeit und Kontrolle hinaus verschoben. Unternehmen können sich nicht mehr auf manuelle Prozesse und Checklisten verlassen, um sicherzustellen, dass sie die richtige Software einsetzen und dass keine unerlaubten Änderungen vorgenommen wurden. Daher gibt es einige Dinge, die Sicherheitsexperten tun können, um sicherzustellen, dass ihre Code-Signierungsverfahren streng sind und die Sicherheit des Gesamtsystems nicht beeinträchtigen.

1. Zentraler Schutz der Schlüssel: Durch die zentrale Speicherung der privaten Schlüssel eines Unternehmens müssen sich Unternehmen keine Sorgen mehr über unbefugte Kopien oder Standorte von Signierschlüsseln innerhalb ihres Unternehmens machen.
2. Genehmigung, wer wo signieren darf: Unternehmen benötigen einen Genehmigungs-Workflow, damit sie konfigurieren können, welche Benutzer Code signieren dürfen und auf welchen Systemen sie berechtigt sind, Signiervorgänge auf den zentral gespeicherten Schlüsseln anzufordern.
3. Genehmigung zum Zeitpunkt des Signierens (genehmigen, was signiert werden darf): Wenn Sie einem Benutzer und einem System die Genehmigung zur Durchführung von Signiervorgängen erteilt haben, was wird dann tatsächlich signiert? Unternehmen müssen auch einen Genehmigungsprozess definieren, der es einem Administrator ermöglicht, die Signieranfrage vor der Genehmigung zu prüfen.
4. Fähigkeit zur Kontrolle der Signierung, selbst in einer hoch automatisierten CI/CD-Pipeline: Alle Genehmigungs- und Signiervorgänge sollten Systemkonten zugewiesen, kontrolliert und geplant werden. Die Automatisierung ist erforderlich, damit die Entwickler pünktlich liefern und gleichzeitig sicherstellen können, dass sie über die nötigen Regeln verfügen, um nachzuweisen, dass sie die Kontrolle über den Signierungsprozess haben.
5. Auditing und Berichterstattung: Bei der Verwendung von Code Signing in der Softwarebereitstellungspipeline ist es von entscheidender Bedeutung, dass Sie die Einhaltung von Richtlinien und Best Practices überprüfen und nachweisen können. So müssen Unternehmen beispielsweise Aufzeichnungen über Code-Signierungsvorgänge und Genehmigungsvorgänge führen, um das Risiko von Angriffen durch opportunistische Cyber-Akteure zu mindern.

Fazit

Jedes Softwareunternehmen und seine Sicherheitsexperten müssen prüfen, wie sie Maschinenidentitäten schützen. Dies geht über die Verbesserung der Sicherheitsbemühungen hinaus, die sich auf die Reduzierung von Schwachstellen im Code konzentrieren. Der gesamte Erstellungsprozess muss mit Maschinenidentitäten gesichert werden. Jede dieser Identitäten muss verwaltet werden. Dazu gehört die Einsicht in alle verwendeten Signierzertifikate, Informationen über ihre Verwendung und die Automatisierung des gesamten Lebenszyklus. Andernfalls werden böswillige Akteure weiterhin erfolgreich auf den Code-Signierungsprozess abzielen.