Vor einigen Monaten saß ich in einer dieser typischen Software-Roadshows in einem Systemhaus und stellte die Frage, wo die Software Bill of Materials (SBOM)1 für das vorgestellte Softwareprodukt zu finden sei. Schließlich handelte es sich um ein Sammelsurium verschiedener Open-Source-Technologien, die der Hersteller zu einem proprietären Produkt verwoben hat. Die Frage ist berechtigt, da diese Software des von mir nicht genannten Herstellers gezielt für kritische Infrastruktur zum Management von vLANs und Switchen angeboten wird.2
Auf Fragen wie diese gibt es ein paar gute und viele schlechte Antwortmöglichkeiten. Eine gute Antwort wäre, dass die SBOM nachgereicht wird. Eine eher schlechte Antwort: “Sowas haben wir nicht”. Ich erhielt als Antwort: “Äh, was ist eine SBOM?” Der Blick in die Runde offenbarte, das scheinen andere auch nicht zu wissen.
Vor einigen Jahren habe ich bereits Einblick gegeben, wie Lieferanten mit Fernzugriff sicher an die Hand zu nehmen sind.3 Mit dem heutigen Blogbeitrag möchte ich das Thema organisatorisch näher beleuchten und Einblick in die Praxis geben. Viel Spaß beim Lesen! Wie immer gilt: Your mileage may vary, kein Anspruch auf Vollständigkeit oder Allgemeingültigkeit.
Wie Lieferketten falsch bewertet werden
Ich behaupte mal, bei den meisten mittelständischen Unternehmen werden Risiken der Informationssicherheit in der Lieferkette falsch bewertet. Geschäftsführer reagieren hier oft dünnhäutig. Gerade dann, wenn autoritäre Persönlichkeiten sich nicht mit Richtlinien oder Maßnahmen “ins Geschäft” reinreden lassen wollen. Es ist aber auch wahr, dass der Begriff “Lieferkette” in der Vergangenheit politisiert und von Übereifrigen regelrecht kaputt administriert wurde.
Starker Aufschlag Tomas, jetzt musst Du auch liefern: Hier eine Auflistung der häufigsten Fehler aus der Praxis:
1. Fehler: Alle Lieferanten sind zu bewerten
Nein, es sind nur relevante Lieferanten zu identifizieren und risikobasiert zu bewerten.4 Einige sind erstaunt, dass noch nicht einmal diese typischen Fragebögen zur Selbstauskunft notwendig sind. Keine mir bekannte Norm schreibt das vor. Zur risikobasierten Bewertung reicht auch die eigene Beobachtung, ein Interview oder die gesammelten Erfahrungswerte, sofern alles nachvollziehbar dokumentiert ist.
Wenn auf der Website eines Softwarelieferanten zum Beispiel Downloads ohne Prüfhashes und Code-Signing stehen, eine SECURITY.TXT5 fehlt und auch sonst keine Möglichkeit zur verschlüsselten Übermittlung von vertraulichen Dingen per S/MIME oder PGP angeboten wird, dann sagt das bereits viel aus. Diese Indizien zur Informationssicherheit sind sogar automatisiert abrufbar.
Erst wenn das alles nicht ausreichen sollte, können gezielt weitere Evidenzen angefordert werden.6
2. Fehler: Es muss ein Lieferanten-Verzeichnis geführt werden
Eine weitere Fehlannahme. Warum parallel zu einer gelebten Warenwirtschaft ein neues Datensilo aufbauen, das nach kurzer Zeit veraltet und mühsam gepflegt werden muss? Ein zusätzliches Datenbank-Feld reicht oftmals aus, zusammen mit einem geeigneten Prozess, der den Lebenszyklus beschreibt. Und schon kann man damit arbeiten und hat ganz viel administrativen Overhead eingespart.7
3. Fehler: Jährliches Review ist kein kontinuierliches Management
Einmal im Jahr kommt die Liste mit allen relevanten Lieferanten auf den Tisch zum Review. Meistens wird nur geprüft, ob der Lieferant noch aktiv ist, das Datum geändert und dann ist wieder für 12 Monate Ruhe. Blöd nur, wenn der Lieferant vor drei Wochen aufgekauft wurde, seine Cloud-Infrastruktur wechselte oder einen besonders dummen Sicherheitsvorfall hatte. Kontinuierlich bedeutet nicht jährlich und risikobasiert bedeutet auch dann hinzusehen, wenn sich etwas am Risiko beim Lieferanten ändert.8
4. Fehler: Die Großen sind automatisch sicher
Bei kleinen Anbietern wird tendenziell genauer hingeschaut, wohingegen die Großen durchgereicht werden. Je mehr zentrale Dienste bei einem einzigen großen Anbieter liegen, desto dringender stellt sich aber die Frage nach dem Risiko. Bekanntheit und ein großer Name sind keine Risikobehandlung und es sind manchmal die Kleinen, die ihren Technik-Stack im Griff und folglich in der Informationssicherheit besser aufgestellt sind als die vermeintlich Großen, wo die linke Hand nicht weiß, was die rechte macht.9
5. Fehler: ISO 27001: Der Lieferant ist sicher
Diesen Satz höre ich öfters, ohne dass dabei der Scope des Zertifikats bekannt ist. Dienstleister und Softwarehersteller schmücken sich mitunter mit den Zertifikaten eines Rechenzentrums, in dem die Software gehostet wird. Oder es wurde nur die Hauptverwaltung zertifiziert, während die Entwicklungsabteilung oder der relevante Geschäftsbereich außerhalb des Scopes geblieben ist. Zertifikate können eine Risikobewertung erleichtern, sie ersetzen diese nicht. Einem Zertifikat sieht man nicht an, ob Informationssicherheit auch gelebt wird. Wenn Lieferanten ein halbes Jahr vor einem Reaudit in hektische Betriebssamkeit verfallen, ist das genau ein Indiz dafür.10
6. Fehler: Alle Lieferanten müssen gleich bewertet werden
Und so landet der gleiche Fragebogen sowohl beim Betreiber eines Rechenzentrums als auch beim Solo-Selbstständigen, der im Homeoffice die Website anpasst. Während der eine Fragen zum Secure Development Lifecycle mit “nicht zutreffend” beantwortet, soll der andere den Zutritt zu seinen Arbeitsräumen erklären. Am Ende des Bewertungsbogens steht irgendein Ergebnis in Prozent, Punkten oder als Ampel und niemand ist dadurch schlauer.
Die Kunst ist es, die wenigen “richtigen” Fragen zur verwendeten Technologie und zu den Prozessen zu stellen. Und manchmal reicht es auch, nur zu beobachten. Mir fallen zum Beispiel sofort jene Unternehmen positiv auf, bei denen ich beim Einlass ein Besucherbadge erhalte und mitunter eine NDA unterschreiben darf. Das bietet mehr Evidenz als irgendwelche Richtlinien, die nicht gelebt werden.11
Fazit
Lieferantenmanagement und Lieferketten sind ein Themenbereich, in dem viel Potenzial auf der Strecke liegen bleibt. Wenn jemand schon viel Geld in seine Zertifizierung steckt und Lieferantenmanagement betreibt, warum nimmt er die Vorteile nicht mit? Stattdessen wird “ritualisierte Compliance” betrieben.
Wer als Softwarelieferant nicht weiß, was eine SBOM ist, hat sich genauso disqualifiziert wie ein KI-Anbieter, der nicht erklären kann, wie er Bias in seinem Modell erkennt und mitigiert.
Richtig betrieben wird Lieferantenmanagement zum Wettbewerbsvorteil, weil man Anbieter, deren Technik und Prozesse besser versteht und bewerten kann. Die eigenen Mitarbeiter werden entlastet und Entscheidungen können schneller und fundierter getroffen werden. Man beginnt aktiv zu agieren, statt hilflos zu reagieren oder, noch schlimmer, sich kommunikativ in die Opferrolle zu begeben: “Wir haben uns rechtzeitig vom Anbieter X getrennt” klingt deutlich anders als “Wir wurden Opfer einer wirklich sehr gemeinen Ransomware”.
Die gute Nachricht: Dafür braucht es häufig nicht mehr, sondern oftmals sogar weniger administrativen Overhead. Weniger fragen, mehr beobachten.
In diesem Sinne,
Euer Tomas Jakobs
ISO 27001:2022, Annex A 5.21 (Management von Informationssicherheitsrisiken in der IKT-Lieferkette). Siehe ergänzend aber auch (EU) 2024/2847 (Cyber Resilience Act), wo die SBOM explizit demnächst gefordert wird. ↩︎
https://blog.jakobs.systems/blog/20231010-supplychain-management/ ↩︎
ISO 27001:2022, 6.1.2 und 6.1.3 sowie Annex A 5.19 (risikobasierte Beurteilung und Behandlung von Informationssicherheitsrisiken sowie Informationssicherheit in Lieferantenbeziehungen). ↩︎
ISO 27001:2022, 6.1.2 und 7.5 sowie Annex A 5.19 und 5.22 (Risikobeurteilung, dokumentierte Information sowie risikobasiertes Management und Überwachung von Lieferantenbeziehungen). ↩︎
ISO 27001:2022, 7.5 sowie Annex A 5.19–5.22 (Anforderungen an dokumentierte Information und das Management von Lieferantenbeziehungen; ein bestimmtes Werkzeug oder ein separates Lieferantenverzeichnis wird nicht vorgegeben). ↩︎
ISO 27001:2022, Annex A 5.22, bei Cloud-Diensten ergänzend 5.23 (Überwachung, Überprüfung und Änderungsmanagement von Lieferantenleistungen sowie Informationssicherheit bei Nutzung von Cloud-Diensten). ↩︎
ISO 27001:2022, 6.1.2 und 6.1.3 sowie Annex A 5.19 (risikobasierte Beurteilung und Behandlung von Informationssicherheitsrisiken aus Lieferantenbeziehungen). ↩︎
ISO 27001:2022, 4.3 sowie Annex A 5.19 und 5.22 (Festlegung des Geltungsbereichs des ISMS sowie Management und Überwachung von Informationssicherheitsrisiken in Lieferantenbeziehungen). ↩︎
ISO 27001:2022, Annex A 5.19 und 5.20 (Informationssicherheit in Lieferantenbeziehungen sowie Festlegung und Vereinbarung relevanter Informationssicherheitsanforderungen entsprechend der Art der Lieferantenbeziehung). ↩︎