Pingingz – shutterstock.com
Die Aussagen von Jen Easterly, bis Januar 2025 Direktorin der US-Bundesbehörde CISA (Cybersecurity and Infrastructure Security Agency), bringen es auf den Punkt: „Sichere Software ist nicht billig oder einfach umzusetzen – aber es ist der einzig gangbare Weg, um IT-Systeme nachhaltig zu schützen.“
Easterly zog in der Vergangenheit auch immer wieder Parallelen zur Automobilindustrie der 1960er Jahre: einer Branche, die Geschwindigkeit, Optik und Kostenoptimierung über Sicherheit stellte – und die Verantwortung den „Verrückten am Steuer“ zuschob. Das 1965 von Ralph Nader veröffentlichte Buch „Unsafe at Any Speed“ (deutscher Titel: Unsicher bei jeder Geschwindigkeit) leitete schließlich einen tiefgreifenden Wandel in der Automobilindustrie ein. Er argumentierte, dass die Branche, solange sie sich selbst regulieren darf, weiterhin Design, Kosten und geplante Obsoleszenz über die Sicherheit und die Interessen der Verbraucher stellen würde.
Diese Logik findet sich auch in der heutigen Softwarebranche. Entwickler setzen auf Geschwindigkeit und Design – Sicherheit spielt dagegen meist nur eine nachgelagerte Rolle. Gleichzeitig wird bei Vorfällen gerne den Anwendern die Schuld gegeben: Sie hätten die Systeme falsch bedient. Dieses Narrativ verkennt die eigentliche Ursache: fehleranfällige und nicht ausreichend abgesicherte Softwareprodukte.
Kunden müssen Druck machen
Wie Easterly betont, reicht es nicht, Sicherheitsprobleme immer nur im Nachhinein zu bekämpfen. Es braucht ein grundsätzliches Umdenken – in der Branche, aber auch auf Kundenseite. Die von der CISA gestartete Secure-by-Design-Initiative ist daher ein wichtiger Schritt, um Anbieter stärker in die Pflicht zu nehmen.
Auch auf europäischer Ebene zeichnet sich ein Umdenken ab: Der EU Cyber Resilience Act legt erstmals verbindliche Cybersicherheitsanforderungen für Hersteller von Hard- und Software fest – mit Fokus auf sichere Produkte über den gesamten Lebenszyklus. Ergänzend verpflichtet die NIS2-Richtlinie Unternehmen aus kritischen Sektoren zu einem deutlich höheren Sicherheitsniveau – inklusive Lieferkettenkontrollen.
Lesetipp: Security by Design – So gelingt sichere Softwareentwicklung
Beide Maßnahmen setzen klare Signale: Sicherheit soll kein freiwilliges Add-on mehr sein, sondern Standard. Gleichzeitig müssen aber auch Unternehmen ihre Rolle als Kunden aktiv nutzen – und die Standards, die sie von Softwareherstellern erwarten, aktiv einfordern und mitgestalten.
Die Automobilindustrie hat in den Jahrzehnten nach Naders Buch reagiert. Es wurden Sicherheitsbehörden geschaffen, Standards eingeführt, Sicherheitsgurte, ABS und Airbags zur Pflicht gemacht. Auch hier war es der Druck der Konsumenten, der letztlich Veränderungen herbeigeführt hat. Genau diesen Druck braucht es nun auch im Softwaremarkt.
Softwareeinkauf nur mit Security-Check
In der Praxis bedeutet das: Unternehmen müssen ihre Einkaufsprozesse neu denken. IT-Sicherheit darf nicht erst bei der Implementierung anfangen, sondern muss schon beim Einkauf eine elementare Rolle spielen. Sicherheitsverantwortliche – insbesondere CISOs und ihre Teams – sollten frühzeitig in Auswahlprozesse eingebunden werden. Sie müssen prüfen können, ob eine Software den Sicherheitsanforderungen und dem individuellen Risikoprofil des Unternehmens entspricht.
Fehlt diese frühe Einbindung, wird möglicherweise Software eingeführt, die dauerhaft zur Belastung wird: häufige Patches, viele Updates und immer wieder kurzfristige Notfallmaßnahmen. Um die Analogie zum Auto zu bemühen: Man hat sich eine Schrottkarre ins Rechenzentrum gestellt.
Nicht von Markenimage blenden lassen
Leider ist es nicht ungewöhnlich, dass sich Entscheider an dem orientieren, was andere Unternehmen tun, welches Produkt als „marktführend“ gilt oder welche Beziehungen zu einem bestimmten Anbieter bestehen – statt an tatsächlicher Eignung oder Sicherheit einer Lösung.
Ein bewährter Gegenentwurf ist der „blinde“ Ausschreibungsprozess. Anbieter werden anonymisiert bewertet – allein auf Basis klar definierter Kriterien. So lassen sich Scheinriesen entlarven, und es entsteht ein objektiver Vergleich. Auch Proof-of-Concepts (PoCs) sollten wie eine Probefahrt im Autohaus zum Standard gehören: Die Software wird unter realistischen Bedingungen getestet, bevor sie eingeführt wird. Nur so entsteht eine belastbare Grundlage für die Risikobewertung.
Die Aufgabe des IT-Security-Teams ist dabei nicht, Kaufentscheidungen zu blockieren, sondern Transparenz zu schaffen: Wo gibt es Schwachstellen? Lassen sie sich abmildern? Und: Ist die Organisation bereit, verbleibende Risiken im Kontext der Geschäftsziele zu akzeptieren?
Sicherheit ist Pflicht in der Softwareentwicklung
Solange wir IT-Sicherheit als reine Nutzerpflicht verstehen, bleiben Unternehmen im Reaktionsmodus – mit Patch-Marathons, Ad-hoc-Maßnahmen und hohem Ressourcenverbrauch. Die heutige Risikolandschaft mit Datenschutzverletzungen und Cyberangriffen ist das Resultat einer Branche, die Sicherheit als nachrangige Pflicht der Nutzer behandelt – statt als integralen Bestandteil der Softwareentwicklung.
Dabei könnten IT-Teams ihre Energie viel besser investieren – etwa in die Weiterentwicklung ihrer Infrastruktur, in Innovation und in die Verbesserung der Customer Experience. Es ist an der Zeit, die Verantwortung dort zu verorten, wo sie hingehört: bei den Herstellern.
Politische Initiativen wie der Cyber Resilience Act und NIS2 unterstreichen, dass dieses Umdenken längst begonnen hat – aber ihre Wirksamkeit hängt entscheidend davon ab, ob Unternehmen und Kunden diese Standards aktiv einfordern und leben. Sicherheit muss elementarer Bestandteil des Softwaredesigns sein – nicht nachträglich aufgepfropft. Denn genau wie es bei Fahrzeugen heute keine Diskussion mehr über den Sinn von Sicherheitsgurten gibt, sollte auch in der Softwarewelt klar sein: Sicherheit ist kein optionales Feature, sondern ein Muss. (jm)
No Responses