{"id":3274,"date":"2025-05-22T04:00:00","date_gmt":"2025-05-22T04:00:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=3274"},"modified":"2025-05-22T04:00:00","modified_gmt":"2025-05-22T04:00:00","slug":"schluss-mit-schlechter-software","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=3274","title":{"rendered":"Schluss mit schlechter Software"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n
Softwaresicherheit beginnt beim Hersteller \u2013 nicht beim Nutzer.\n

Pingingz \u2013 shutterstock.com<\/p>\n<\/div>\n

Die <\/a>Aussagen von Jen Easterly<\/a>, bis Januar 2025 Direktorin der US-Bundesbeh\u00f6rde CISA (Cybersecurity and Infrastructure Security Agency), bringen es auf den Punkt: \u201eSichere Software ist nicht billig oder einfach umzusetzen \u2013 aber es ist der einzig gangbare Weg, um IT-Systeme nachhaltig zu sch\u00fctzen.\u201c<\/p>\n

Easterly zog in der Vergangenheit auch immer wieder Parallelen zur Automobilindustrie der 1960er Jahre: einer Branche, die Geschwindigkeit, Optik und Kostenoptimierung \u00fcber Sicherheit stellte \u2013 und die Verantwortung den \u201eVerr\u00fcckten am Steuer\u201c zuschob. Das 1965 von Ralph Nader ver\u00f6ffentlichte Buch \u201eUnsafe at Any Speed\u201c (deutscher Titel: Unsicher bei jeder Geschwindigkeit) leitete schlie\u00dflich einen tiefgreifenden Wandel in der Automobilindustrie ein. Er argumentierte, dass die Branche, solange sie sich selbst regulieren darf, weiterhin Design, Kosten und geplante Obsoleszenz \u00fcber die Sicherheit und die Interessen der Verbraucher stellen w\u00fcrde.<\/p>\n

Diese Logik findet sich auch in der heutigen Softwarebranche. Entwickler setzen auf Geschwindigkeit und Design \u2013 Sicherheit spielt dagegen meist nur eine nachgelagerte Rolle. Gleichzeitig wird bei Vorf\u00e4llen gerne den Anwendern die Schuld gegeben: Sie h\u00e4tten die Systeme falsch bedient. Dieses Narrativ verkennt die eigentliche Ursache: fehleranf\u00e4llige und nicht ausreichend abgesicherte Softwareprodukte.<\/p>\n

Kunden m\u00fcssen Druck machen<\/strong><\/h2>\n

Wie Easterly betont, reicht es nicht, Sicherheitsprobleme immer nur im Nachhinein zu bek\u00e4mpfen. Es braucht ein grunds\u00e4tzliches Umdenken \u2013 in der Branche, aber auch auf Kundenseite. Die von der CISA gestartete <\/a>Secure-by-Design-Initiative<\/a> ist daher ein wichtiger Schritt, um Anbieter st\u00e4rker in die Pflicht zu nehmen.<\/p>\n

Auch auf europ\u00e4ischer Ebene zeichnet sich ein Umdenken ab: Der EU Cyber Resilience Act<\/a> legt erstmals verbindliche Cybersicherheitsanforderungen f\u00fcr Hersteller von Hard- und Software fest \u2013 mit Fokus auf sichere Produkte \u00fcber den gesamten Lebenszyklus. Erg\u00e4nzend verpflichtet die NIS2-Richtlinie<\/a> Unternehmen aus kritischen Sektoren zu einem deutlich h\u00f6heren Sicherheitsniveau \u2013 inklusive Lieferkettenkontrollen.<\/p>\n

Lesetipp: Security by Design \u2013 So gelingt sichere Softwareentwicklung<\/a><\/p>\n

Beide Ma\u00dfnahmen setzen klare Signale: Sicherheit soll kein freiwilliges Add-on mehr sein, sondern Standard. Gleichzeitig m\u00fcssen aber auch Unternehmen ihre Rolle als Kunden aktiv nutzen \u2013 und die Standards, die sie von Softwareherstellern erwarten, aktiv einfordern und mitgestalten.<\/p>\n

Die Automobilindustrie hat in den Jahrzehnten nach Naders Buch reagiert. Es wurden Sicherheitsbeh\u00f6rden geschaffen, Standards eingef\u00fchrt, Sicherheitsgurte, ABS und Airbags zur Pflicht gemacht. Auch hier war es der Druck der Konsumenten, der letztlich Ver\u00e4nderungen herbeigef\u00fchrt hat. Genau diesen Druck braucht es nun auch im Softwaremarkt.<\/p>\n

Softwareeinkauf nur mit Security-Check<\/strong><\/h2>\n

In der Praxis bedeutet das: Unternehmen m\u00fcssen ihre Einkaufsprozesse neu denken. IT-Sicherheit darf nicht erst bei der Implementierung anfangen, sondern muss schon beim Einkauf eine elementare Rolle spielen. Sicherheitsverantwortliche \u2013 insbesondere CISOs und ihre Teams \u2013 sollten fr\u00fchzeitig in Auswahlprozesse eingebunden werden. Sie m\u00fcssen pr\u00fcfen k\u00f6nnen, ob eine Software den Sicherheitsanforderungen und dem individuellen Risikoprofil des Unternehmens entspricht.<\/p>\n

Fehlt diese fr\u00fche Einbindung, wird m\u00f6glicherweise Software eingef\u00fchrt, die dauerhaft zur Belastung wird: h\u00e4ufige Patches, viele Updates und immer wieder kurzfristige Notfallma\u00dfnahmen. Um die Analogie zum Auto zu bem\u00fchen: Man hat sich eine Schrottkarre ins Rechenzentrum gestellt.<\/p>\n

Nicht von Markenimage blenden lassen<\/strong><\/h2>\n

Leider ist es nicht ungew\u00f6hnlich, dass sich Entscheider an dem orientieren, was andere Unternehmen tun, welches Produkt als \u201emarktf\u00fchrend\u201c gilt oder welche Beziehungen zu einem bestimmten Anbieter bestehen \u2013 statt an tats\u00e4chlicher Eignung oder Sicherheit einer L\u00f6sung.<\/p>\n

Ein bew\u00e4hrter Gegenentwurf ist der \u201eblinde\u201c Ausschreibungsprozess. Anbieter werden anonymisiert bewertet \u2013 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\u00f6ren: Die Software wird unter realistischen Bedingungen getestet, bevor sie eingef\u00fchrt wird. Nur so entsteht eine belastbare Grundlage f\u00fcr die Risikobewertung.<\/p>\n

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\u00e4ftsziele zu akzeptieren?<\/p>\n

Sicherheit ist Pflicht in der Softwareentwicklung<\/strong><\/h2>\n

Solange wir IT-Sicherheit als reine Nutzerpflicht verstehen, bleiben Unternehmen im Reaktionsmodus \u2013 mit Patch-Marathons, Ad-hoc-Ma\u00dfnahmen und hohem Ressourcenverbrauch. Die heutige Risikolandschaft mit Datenschutzverletzungen und Cyberangriffen<\/a> ist das Resultat einer Branche, die Sicherheit als nachrangige Pflicht der Nutzer behandelt \u2013 statt als integralen Bestandteil der Softwareentwicklung.<\/p>\n

Dabei k\u00f6nnten IT-Teams ihre Energie viel besser investieren \u2013 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\u00f6rt: bei den Herstellern.<\/p>\n

Politische Initiativen wie der Cyber Resilience Act und NIS2 unterstreichen, dass dieses Umdenken l\u00e4ngst begonnen hat \u2013 aber ihre Wirksamkeit h\u00e4ngt entscheidend davon ab, ob Unternehmen und Kunden diese Standards aktiv einfordern und leben. Sicherheit muss elementarer Bestandteil des Softwaredesigns sein \u2013 nicht nachtr\u00e4glich aufgepfropft. Denn genau wie es bei Fahrzeugen heute keine Diskussion mehr \u00fcber den Sinn von Sicherheitsgurten gibt, sollte auch in der Softwarewelt klar sein: Sicherheit ist kein optionales Feature, sondern ein Muss. (jm)<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Softwaresicherheit beginnt beim Hersteller \u2013 nicht beim Nutzer. Pingingz \u2013 shutterstock.com Die Aussagen von Jen Easterly, bis Januar 2025 Direktorin der US-Bundesbeh\u00f6rde CISA (Cybersecurity and Infrastructure Security Agency), bringen es auf den Punkt: \u201eSichere Software ist nicht billig oder einfach umzusetzen \u2013 aber es ist der einzig gangbare Weg, um IT-Systeme nachhaltig zu sch\u00fctzen.\u201c Easterly […]<\/p>\n","protected":false},"author":0,"featured_media":3275,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-3274","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/3274"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3274"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/3274\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/3275"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3274"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3274"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3274"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}