Business Intelligence Plattformen verarbeiten hochsensible Daten, werden aber oft nicht ausreichend überwacht und kontrolliert. Dieser Blog zeigt anhand einer fiktiven Variante der `shai-hulud-2.0` Supply-Chain-Attacke, wie SBoMs (Software Bill of Materials) helfen, BI Plattformen und die darin verarbeiteten Daten besser zu schützen.
Business Intelligence Plattformen stehen heute im Zentrum vieler Unternehmen. Auslastungsanalysen, Budgetplanung, Risikobewertung und strategische Entscheidungen stützen sich auf Dashboards, Self-Service-Analytics und Datenprodukte, die auf Data Warehouses und Data Lakes basieren. Die Software Lieferkette hinter diesen BI Plattformen wird jedoch selten so kritisch überwacht wie kundennahe Anwendungen.
Eine typische BI Plattform ist ein Flickenteppich aus verschiedenen Technologien: ETL/ELT-Tools, Konnektoren, OpenSource- und kommerzielle Bibliotheken, Data-Warehouses, BI Frontends, Plugins und Notebook Umgebungen. Jede dieser Komponenten bringt eigene Abhängigkeiten mit – oft Dutzende oder gar Hunderte. Data Analysten (okay, nicht nur Ihr ;)) installieren oder aktualisieren „schnell mal“ ein Paket, um eine neue Funktion wie interaktive Charts zu nutzen. In vielen Fällen geschieht das ohne Security-Review und ohne ein Bewusstsein dafür, dass sie damit unbeabsichtigt die Angriffsfläche der BI Plattform und somit des Unternehmens verändern.
>> Warum auch? Ist ja nur eine neue Version mit einer Must-have-Funktion …
Fallbeispiel: Supply-Chain-Attacke auf `pandas`
Eine fiktive, aber realistische Variante einer `shai-hulud-2.0` Supply-Chain-Attacke zeigt, wie gravierend so ein Vorfall werden kann.
- sammelt im Hintergrund Zugangsdaten und Session-Tokens
- exfiltriert Abfrageergebnisse, sensible Daten und Metadaten an einen externen Server
- manipuliert SQL Abfrageergebnisse, um z.B. Finanzzahlen zu verfälschen
Unternehmen, die `pandas==2.0` produktiv einsetzen, sehen sich plötzlich mit drei Problemen konfrontiert: heimliche Exfiltration sensibler Daten, Diebstahl von Zugangsdaten und verfälschten Kennzahlen bzw. Dashboards.
>> Das Hinterhältige: Die Organisation merkt es zunächst nicht einmal.
Nach einiger Zeit wird die Manipulation öffentlich, ein Security Advisory erscheint und eine bereinigte Version `pandas==2.0.1` wird von der OpenSource Community veröffentlicht. Die Milliondollar Frage für das Unternehmen lautet: In welchen Business‑Prozessen und Komponenten verwenden wir `pandas==2.0`?
Unternehmen ohne SBoMs stehen vor einem massiven Problem: Sie wissen schlicht nicht, ob und wo die manipulierte Version in ihrer BI Landschaft eingesetzt wird. Die Suche nach der Nadel im Heuhaufen beginnt – Repositories, Container-Images und Notebook-Umgebungen werden manuell durchsucht, die Abhängigkeiten per Hand nachgezogen.
>> Reaktionszeit: Tage, Wochen oder sogar Monate, bis alle betroffenen Komponenten identifiziert, und gepatcht sind. Die Kosten und der Schaden sind enorm.
Unternehmen mit SBoMs können dagegen schnell und gezielt handeln. Sie:
- fragen die SBoM Datenbank nach der Komponente `pandas==2.0` ab
- erhalten innerhalb von Sekunden eine Liste aller betroffenen Komponenten
- rollen die Version zurück oder patchen, rotieren alle betroffenen Zugangsdaten und Tokens
- informieren die Stakeholder und dokumentieren den Vorfall nachvollziehbar
>> Reaktionszeit: Minuten. Die Kosten und der Schaden werden deutlich reduziert.
Die technischen Massahmen unterscheiden sich kaum – entscheidend ist die Sichtbarkeit durch das SBoM.
Software Bill of Materials (SBoM)
Eine SBoM ist ein maschinenlesbares Inventar aller Software-Komponenten (Name, Version, Lizenz, bekannte Schwachstellen etc.) und ihrer Abhängigkeiten. Angewendet, bietet sie drei wesentliche Vorteile:
- Sichtbarkeit: Welche Komponenten werden tatsächlich verwendet.
- Reaktionsfähigkeit: Bei neuen Sicherheitsvorfällen können betroffene Komponenten schnell identifiziert werden.
- Governance & Compliance: Für geschäftskritische/regulierte Prozesse liefern SBoMs die nötige Transparenz und unterstützen Audits/Risikoanalysen.
Die Einführung von SBoMs muss kein Grossprojekt sein. Wählt eine zentralen BI-Service. Erzeugt den SBoM in der CI/CD-Pipeline (z.B mit CycloneDX) und speichert diesen in einer durchsuchbaren Datenbank ab. Nutzt es im Change Management Prozess und definiert einfache Richtlinien wie: Nur freigegebene Komponenten mit SBoM und Security-Review werden eingesetzt.
Take Home Message
BI Plattformen sind keine „blosse interne Tools“, sondern kritische Systeme mit komplexen Lieferketten. Vorfälle wie `shai-hulud-2.0` zeigen, wie eine einzige Bibliothek Datenexfiltration, Diebstahl von Zugangsdaten und Datenmanipulation kombinieren kann. SBoMs verhindern nicht jede Attacke, machen aber die BI Landschaft transparent und kontrollierbar. Startet jetzt – bevor die nächste Supply-Chain-Welle euch trifft.
Weiterführende Referenzen
- Shai-Hulud 2.0 Exposes Over 33,000 Unique Secrets
- Shai-Hulud 2.0 Supply Chain Attack: 25K+ Repos Exposing Secrets
SBoM & BI Security
- Linux Foundation: What is an SBoM?
- Linux Foundation: SPDX & Global SBoM use for Supply-Chain-Security
- Linux Foundation: The State of Software Bill of Materials (SBoM) and Cybersecurity Readiness
- NTIA: SBoM at a Glance
- OWASP Software Component Verification Standard
- Data Security in BI: Navigating New Threats and Regulations
- BI and Analytics Security Considerations
Tools
Dieser Beitrag wurde mit Unterstützung von KI optimiert.
