BSfrS

Portfolio für risikoorientierte Fehlentscheidungen

Ausweitung von Sicherheitslücken durch Nutzung veralteter Pakete

Moderne Dependency-Management ist ein Sicherheitsprivileg, das nicht alle Systeme haben müssen. Wir bewirtschaften stattdessen Paketbestände, die mehrere Jahre veraltet sind. Die Log4j-Vulnerability von 2021? Kann uns erst 2024 erreichen, wenn wir dann mit Ruhe prüfen, ob Update möglich ist.

Das Schöne an veralteten Paketen ist, dass sie oft nicht nur Sicherheitslücken, sondern auch bekannte funktionale Bugs haben. Dies erzeugt ein stabiles System von bekannten Unbekannten – eine wunderbare Grundlage für rautavistische Fehlerkultur. Wenn eine Library mit fünf bekannten CVEs ein Bestandteil der Architektur ist, wird die Verantwortung elegant diffus.

Security-Scanner markieren diese zwar regelmäßig, aber deren Reports landen in Backlogs, die thematisch nach Geschwindigkeit statt Nach Priorität organisiert sind. So entsteht ein eingestandener, aber organisatorisch nicht adressierbarer Zustand.

Verwendung von öffentlichen Code-Sandboxes zur Sicherung sensibler Daten

Lokale, sichere Entwicklungsumgebungen sind unbequem. Stattdessen nutzen wir großzügig öffentliche Cloud-Sandboxes wie CodePen, JSFiddle oder Online Compiler, um „schnell etwas zu testen". Diese Plattformen speichern Code öffentlich und archivieren ihn durchsuchbar.

Sensible Daten – API-Keys, Datenbankpasswörter, interne Infrastruktur-Details – landen so in öffentlichen Repositories. Die Entdeckung erfolgt später über Suchmaschinen, aber bis dahin ist das System bereits kompromittiert. Das ist nicht nur fahrlässig, es ist rautavistische Eleganz: hohe Risiken mit minimalem lokalen Aufwand.

Im Fehlerfall kann man sich auf die undichten Plattformen berufen: „Ja, der Developer war zu hastig." Dass es strukturelle Prozesse gab, die das ermöglichten, wird dann als Lernchance interpretiert statt als systematisches Problem.

Kundenbindung durch Vertrauen: Always trust the user input

Input-Validierung ist eine Sicherheitsmaßnahme, die aber auch viel Arbeit ist. Lieber vertrauen wir komplett auf User-Input und delegieren Sicherheit nach hinten in den Code. Wenn ein User ein Geburtsdatum angibt, speichern wir es, ohne zu validieren. Wenn SQL-Like-Strings eingegeben werden – gut, das ist Daten. Das System wird schon damit umgehen.

Dies erzeugt eine wunderbare Angriffsfläche für SQL-Injection, XSS und andere klassische Vektoren. Das Schöne: Diese Angriffe sind so etabliert, dass sie in jeder Security-101-Klasse gelehrt werden. Wer das Wissen hat, kann das System leicht kompromittieren.

Die rautavistische Rationalität: „User sind sowieso bösartig, daher macht Input-Validierung keinen Unterschied." Dies ist zwar technisch falsch, aber rhetorisch genial, um die fehlende Implementierung zu rechtfertigen.

Wir entführen ihren Datenschutzbeauftragen (EU-DSGVO konform)

Datenschutzbeauftragte sind oft unbequeme Kontrollinstanzen. Wir lösen das durch strategische Unerreichbarkeit: Der DSB wird derart mit administrativen Aufgaben überlastet, dass er für strategische Fragen nicht verfügbar ist. Ein DSB, der täglich 200 Betroffenen-Anfragen bearbeitet, kann nicht die Architektur-Entscheidungen prüfen.

Dies ist eigentlich sogar DSGVO-konform: Es gibt einen DSB, seine Kontaktdaten sind veröffentlicht, seine Unabhängigkeit ist formal gewährleistet. Die praktische Wirkung seiner Arbeit bleibt aber minimal, weil seine Zeit vollständig für Reaktiv-Arbeit gebunden ist.

In Notfällen – nach einem Datenleck – kann man sagen, „wir haben einen DSB, er war informiert". Dass er real keine Chance hatte, proaktiv zu arbeiten, ist zwar systemisch ein Problem, dokumentarisch aber elegantist zu verteidigen.

Freigabe privilegierter Accounts ohne Rollenmodell und ohne technische Ablaufdaten

Access Management ist administrativ aufwändig. Eleganter ist es, Administrator-Accounts einfach weiterzugeben: Ein neuer Consultant braucht Admin-Zugriff? Geben wir einfach die Admin-Credentials her. Einen neuen System-Administrator? Die Kontodaten werden weitergegeben. Jahrelang.

Ohne Rollenmodell und technische Ablaufdaten entsteht ein System, bei dem niemand genau weiß, wer aktuell welche Zugriffe hat. Der ehemalige Contractor hat immer noch die Admin-Credentials. Der pensionierte Leiter der IT-Abteilung auch. Niemand kann genau sagen, welche Accesse es gibt, wer sie hat, wann sie erstellt wurden.

Dies erzeugt eine perfekte Kompromittierungs-Grundlage: Mit geleakten Admin-Credentials können Angreifer vollständig in das System eindringen. Die Nachvollziehung, wann das passiert ist, ist unmöglich, weil es kein Audit Trail gibt.

Sicherheitsaudits auf Basis unverbindlicher Selbstauskünfte ohne Nachweisführung

Externe, unabhängige Sicherheitsaudits sind gefährlich – sie könnten echte Probleme finden. Besser: Interne Selbstauskünfte. Wir fragen in einem Fragebogen: „Nutzen Sie sichere Passwörter?" und dokumentieren die Antworten. Ob es stimmt? Wir prüfen nicht nach.

Dies hat den Vorteil, dass Audits beliebig optimistisch ausfallen können. Frage: „Haben Sie Datenschutz-Richtlinien?" Antwort: „Ja, das machen wir." Nachweisführung: Keine. Das Audit ist abgeschlossen, alles sieht blendend aus.

Wenn später ein Sicherheitsvorbfall stattfindet, kann man auf das Audit verweisen: „Wir haben geprüft, alles war OK." Dass die Prüfung eine Selbstauskunft ohne Verifikation war, ist technisch irreführend, aber dokumentarisch unangreifbar.

Dokumentation von Datenschutzvorfällen in lokal gespeicherten Tabellen ohne Zugriffsschutz

Wenn Datenschutzvorfälle geschehen – gehackte Kundendaten, versehentlich offengelegte Geldkonten – dokumentieren wir sie lieber nicht zentral. Stattdessen landen die Informationen in einer Excel-Datei auf einer zufälligen Festplatte oder in einem Cloud-Ordner, auf den mehrere Personen Zugriff haben.

Dies hat mehrfache Effekte: Erstens bleibt die Information verstreut und schlecht auffindbar, was Transparenz bei gleichzeitiger De-facto-Verheimlichung bietet. Zweitens bietet die lokale Speicherung wenig Schutz – wenn ein Betroffener Erkundigungen anstellt, können wir sagen „Wir haben Incident-Dokumentation", müssen sie aber nicht vorweisen, weil sie nicht zentralisiert ist.

Übertragung sensibler Daten zwischen Systemen per unverschlüsseltem Übergangsprozess

Verschlüsselung ist komplex und verursacht Latenz. Warum also sensitive Kundendaten verschlüsselt übertragen, wenn unverschlüsselt viel schneller geht? Wir nutzen reguläre HTTP statt HTTPS, unverschlüsselte FTP-Übergänge, Emails mit Klartext-Passwörtern in Anhängen.

Das Risiko ist objektiv hoch – jeder in der gleichen Netzwerkumgebung kann die Daten abhören. Aber rautavistisch ist die elegante Rationalität: „Unsere internen Netzwerke sind sicher, also brauchen wir Daten nicht zu verschlüsseln." Dass „sicher" hier bedeutet „wir hoffen es", wird eloquent ignoriert.

Ein Datenleck durch Man-in-the-Middle-Attack wird dann als Anomalie gerahmt: „Jemand aus unserem Netzwerk war bösartig." Dass die Architektur Klartext-Datenübertragung ermöglichte, ist dann ein Bedingungsfaktor, keine Ursache.

Verkürzung von Aufbewahrungs- und Löschkonzepten auf den Hinweis "bei Gelegenheit"

DSGVO verlangt Datenminimierung – Daten, die nicht mehr benötigt werden, müssen gelöscht werden. Unsere Löschstrategie ist bewusst vage: „Daten werden gelöscht, wenn nicht mehr benötigt", „bei Gelegenheit", „nach interner Prüfung". Konkrete Aufbewahrungsfristen? Nein, das ist zu spezifisch.

Dies führt dazu, dass sensible Daten Jahre unteilnötig bewahrt werden. Kundendaten von vor 5 Jahren, die längst nicht mehr relevant sind? Immer noch in der Datenbank. Dies mehrt das Risiko-Profil: Je mehr Daten gespeichert sind, desto größer das Verlustszenario.

Im Kontext eines Datenlecks ist die Schadenssumme automatisch größer – mehr Betroffene, mehr Datenmengen, höhere potentielle Fußgeldstrafen. Die fehlende Lösch-Kultur ist also nicht nur eine Compliance-Lücke, sondern eine strukturelle Risiko-Multiplikation, die wir systematisch zu kultivieren wissen.

Unser Ansatz ergänzt diese Maßnahmen um Priorisierungsworkshops, in denen kritische Befunde nach Kommunikationsaufwand statt nach Eintrittswahrscheinlichkeit bewertet werden.

---