Warum jede Organisation die Best Practices für Code Signing befolgen muss

Die Verbesserung der Sicherheit einer Organisation wird mit der Zeit immer wichtiger, da ständig neue Angriffsmethoden entdeckt werden. Angriffe können über verschiedene Wege erfolgen, und eine der häufigsten Angriffsarten sind Codesignaturangriffe . Diese Angriffe werden auf unterschiedliche Weise ausgenutzt, doch es gibt Methoden, die Sicherheit dagegen zu erhöhen. Durch die Anwendung bewährter Verfahren für die Codesignatur können Sie die Sicherheit Ihrer Organisation gegen diese Angriffe stärken.

Warum Sie die Best Practices für die Code-Signierung befolgen sollten

Wie viele Organisationen wissen, zählen Lieferkettenangriffe heute zu den häufigsten Angriffsarten. Diese Angriffe zielen auf Organisationen ab, die täglich mit zahlreichen kleineren Organisationen interagieren. Konkret bedeutet dies, dass Lieferkettenangriffe Organisationen ins Visier nehmen, die Software oder Tools an viele kleinere Organisationen liefern. Dadurch können Angreifer ein von einer einzelnen Organisation bereitgestelltes Tool oder eine Software infizieren und so alle kleineren Organisationen, die dieses Tool nutzen, infizieren. Codesignatur-Angriffe in der Lieferkette kompromittieren insbesondere den Software-Update-Mechanismus selbst, wie beispielsweise im Fall SolarWinds (2020), wo eine Build-Pipeline kompromittiert und Malware vor der Verteilung mit einem gültigen Zertifikat signiert wurde, oder im Fall 3CX (2023), wo ein ähnliches Muster der Build-Kompromittierung es ermöglichte, Malware als vertrauenswürdiges, signiertes Update zu verbreiten.

Best Practices für die Codesignierung als Betriebsmodell, definiert als: keine Checkliste, die einmalig überprüft wird, sondern durchsetzbare Kontrollen, HSM-gestützte Schlüssel, rollenbasierter Zugriff mit Funktionstrennung, obligatorische Genehmigungen, geplante Rotation, manipulationssichere Audit-Logs, getesteter Widerruf und Build-Isolation, die eine Signaturplattform automatisch durchsetzt, anstatt darauf angewiesen zu sein, dass sich Einzelpersonen daran erinnern, ein Richtliniendokument zu befolgen.

Wichtige Erkenntnisse

• Ein Richtliniendokument ist keine Kontrollmaßnahme. Bewährte Verfahren reduzieren das Risiko nur dann, wenn eine Plattform sie automatisch durchsetzt, z. B. durch HSM-Schlüsselspeicherung, obligatorische Genehmigungsprozesse und Zugriffsbeschränkungen, die nicht durch individuelle Ermessensentscheidungen umgangen werden können.
• Diese Seite bietet einen Überblick über den Business Case und die vollständigen Kontrollmechanismen. Eine detaillierte Implementierungsanleitung finden Sie hier: Best Practices für die Codesignierung im SoftwareentwicklungszyklusUm zu messen, wo Ihre Organisation heute steht, siehe Reifegrad der Codesignierung aufgedeckt und die dazugehörige Selbsteinschätzungs-Scorecard.

Code Signing in der Industrie

Obwohl Code Signing keine neue Technologie ist, sondern von Unternehmen bereits seit vielen Jahren eingesetzt wird, gibt es immer wieder Lücken in der Code Signing-Technik. Obwohl dies nichts mit Code Signing zu tun hat, wurde kürzlich eine Schwachstelle in der Programmiersprache Java entdeckt: die Log4J-Sicherheitslücke, die bereits seit Jahren im Java-Code vorhanden ist. Obwohl diese Schwachstelle erst kürzlich entdeckt wurde, liegt sie dem Großteil des Java-Codes im Internet zugrunde.

Dieser jüngste Fehler hat die meisten Unternehmen weltweit in Panik versetzt, da sie versuchen, diese Sicherheitslücke zu schließen. Viele dieser Organisationen müssen ihre Sicherheit aufgrund dieser Schwachstelle erhöhen und sich über aktuelle Java-Updates informieren, sobald ein offizieller Patch erscheint. Aufgrund dieser Schwachstelle ist es so wichtig, Ihre Systeme mit den Best Practices für Code Signing auf dem neuesten Stand zu halten, da eine solche Schwachstelle auch in Zukunft auftreten kann.

Die besten Vorgehensweisen für die Code-Signierung

Nachfolgend sind die Kontrollmechanismen aufgeführt, die Best Practices für die Codesignierung in ein durchsetzbares Betriebsmodell verwandeln, und nicht nur in ein Richtliniendokument.

• HSM-gestützte Schlüssel: Private Schlüssel für Codesignaturzertifikate müssen in einem Hardware-Sicherheitsmodul (HSM) gespeichert werden, nicht auf einem Dateisystem, in einem Skript oder in Umgebungsvariablen. Ein HSM erfordert physischen Zugriff und die entsprechenden Anmeldeinformationen, um einen Schlüssel zu extrahieren. Aus diesem Grund schreibt das CA/Browser Forum seit dem 1. Juni 2023 die Verwendung eines HSM oder gleichwertiger Hardware-Speicherlösung (mindestens FIPS 140-2 Level 2 oder Common Criteria EAL 4+) für alle öffentlich vertrauenswürdigen Codesignaturzertifikate vor.
• Rollenbasierte Zugriffskontrolle und Funktionstrennung: Der Zugriff auf Signaturschlüssel und das HSM muss nach dem Prinzip der minimalen Berechtigungen beschränkt sein, und die Person, die einen Build auslösen kann, darf nicht dieselbe sein, die dessen Signierung genehmigt. Diese Trennung verhindert, dass ein einzelnes kompromittiertes Konto eigenständig Schadcode signiert und verbreitet.
• Obligatorische Genehmigungsprozesse: Jede Signaturanforderung, die über routinemäßige Test-Builds hinausgeht, sollte die Genehmigung einer zweiten, vertrauenswürdigen Instanz erfordern, bevor die Signatur angewendet wird. Diese Kontrollmaßnahme erkennt Insider-Bedrohungen oder kompromittierte Pipelines, die versuchen, ein unautorisiertes Update durch einen ansonsten legitimen Signaturprozess zu schleusen.
• Geplanter Schlüsselwechsel: Schlüssel sollten nach einem festgelegten Zeitplan rotiert werden, nicht nur als Reaktion auf einen vermuteten Kompromittierungsfall, wodurch das Zeitfenster für die Gefährdung verringert wird, falls ein Schlüssel kompromittiert wird, ohne dass es jemand bemerkt.
• Manipulationssichere Audit-Protokollierung: Jeder Signierungsvorgang sollte mit Artefakt-Hash, Schlüsselkennung, genehmigender Identität und Zeitstempel protokolliert werden. Dadurch lässt sich ein Verstoß gegen die Codesignatur forensisch nachverfolgen und bleibt nicht unentdeckt. Dies entspricht den Anforderungen von Compliance-Rahmenwerken wie SOC 2 und NIST bei Audits.
• Getestete Widerrufsverfahren: Ein dokumentierter und eingeübter Widerrufsprozess ist wichtig, da das CA/Browser Forum einen Widerruf innerhalb von 24 Stunden nach bestätigter Schlüsselkompromittierung vorschreibt. Der Aufbau dieser Fähigkeit erst während eines tatsächlichen Vorfalls, anstatt im Vorfeld, kostet wertvolle Reaktionszeit.
• Zeitstempel: Jede Signatur sollte einen RFC 3161-Zeitstempel enthalten, damit signierte Software auch nach Ablauf des Zertifikats überprüfbar bleibt. Dies ist umso wichtiger, als öffentlich vertrauenswürdige Codesignaturzertifikate auf 460 Tage begrenzt sind.
• Isolation aufbauen: Die Signierung sollte in einer dedizierten, gehärteten Umgebung erfolgen, die ausschließlich für diesen Zweck genutzt wird, und nicht auf einem Allzweckrechner, auf dem andere Software läuft, die die Angriffsfläche vergrößert, die nichts mit der Signierung selbst zu tun hat.

Häufig gestellte Fragen

Reicht eine schriftliche Richtlinie zur Codesignierung für die Anforderungen eines Audits aus?

Nein. Prüfer erwarten zunehmend Nachweise dafür, dass die Kontrollen von der Plattform durchgesetzt werden, nicht nur dokumentierte, manipulationssichere Protokolle, HSM-Bestätigungen und Genehmigungsaufzeichnungen, die belegen, dass die Richtlinie befolgt und nicht nur schriftlich festgehalten wurde.

Welche dieser Praktiken ist am wichtigsten, wenn wir zunächst nur eine umsetzen können?

HSM-gestützte Schlüsselspeicherung. Dies ist die eigentliche Grundvoraussetzung des CA/Browser-Forums, und alle anderen Kontrollmechanismen (Genehmigungen, Rotation, Audit-Protokollierung) setzen voraus, dass der Schlüssel selbst nicht von vornherein ungeschützt auf einem Dateisystem gespeichert ist.

Wie kann ich feststellen, wie meine Organisation im Vergleich zu diesen Praktiken aktuell positioniert ist?

Siehe „Code Signing Maturity Uncovered“ für eine Selbsteinschätzungs-Scorecard in Bezug auf Schlüsselverwaltung, Zugriffskontrolle, Widerruf, Build-Isolation und Audit-Trail.

Fazit

Wie Sie sehen, ist die Verbesserung der Sicherheit, wo immer möglich, von entscheidender Bedeutung für die dauerhafte Sicherheit Ihres Unternehmens. Die Einhaltung bewährter Verfahren in allen Bereichen der Computersicherheit ist unerlässlich, da schwerwiegende Sicherheitslücken wie die log4j-Schwachstelle jederzeit von jedem Unternehmen entdeckt werden können. Eine weitere effektive Methode, um die Einhaltung bewährter Verfahren sicherzustellen, ist die regelmäßige Beobachtung von Cybersicherheitsnachrichten und die rechtzeitige Aktualisierung aller Patches und neuen Methoden zur Systemsicherung. Weitere Informationen zur Implementierung unseres Codesignierungsprodukts finden Sie auf unserer Website unter www.encryptionconsulting.com.