Sichere Software

Vorteilhaft für den Profit

3. Mai 2021, 6:00 Uhr | Stefan Harms

Um Software von Anfang an sicher zu entwickeln, muss der Entwicklungsprozess auf die Einhaltung von Sicherheitsaspekten abgestimmt und mit Analyse-Tools begleitet werden. Je früher Code auf Sicherheit getestet wird, umso niedriger sind die Kosten für ein Unternehmen.

Software zu entwickeln, die sicher im Sinne von »secure« ist, erweist sich aus geschäftlicher Sicht als sinnvoll, denn ein Plus an Software-Sicherheit kann dem Umsatzwachstum zugutekommen – nicht nur wegen des Wettbewerbsvorteils. Sichere Software kann die Gewinnspanne erhöhen, weil weniger Ausgaben für die Softwarepflege entstehen. Sie kann die Kundenzufriedenheit steigern, da weniger Updates und Patches notwendig sind und sie kann die Einhaltung der einschlägigen Regelwerke erleichtern, was wiederum Kosten reduziert. Nicht zuletzt müssen Unternehmen ohnehin auf die Tatsache reagieren, dass Hacker zunehmend die Anwendungs-Ebene ins Visier nehmen.

Hacker zielen auf die Anwendungs-Ebene

Konzentrierten sich Hacker in früheren Jahren auf das Angreifen von Netzwerken, sind nun Anwendungen ihr Ziel, und dies aus einem ganz einfachen Grund: Software-Organisationen fokussieren sich weiterhin auf Eigenschaften und Funktionen, und Fehler in der Entwicklung und in der Ausführung von Software können zu Sicherheitslücken führen, die leicht zugänglich sind und sich einfach ausnutzen lassen, beispielsweise per SQL-Injektion und Cross-Site Scripting.

Nach wie vor betrachten viele Unternehmen das Thema Sicherheit leider immer noch als etwas, was sich durch Absicherung der Außengrenzen in den Griff bekommen lässt. Wie Bild 1 zeigt, sind die Sicherheitsausgaben von Unternehmen weiterhin schwerpunktmäßig auf die Netzwerkebene ausgerichtet, obwohl die Risiken auf der Anwendungsebene am größten sind. Die Konzentration auf das Absichern der Außengrenzen lässt aber die Tatsache außer Acht, dass Angriffe auf Web-Anwendungen die häufigste Ursache von Datendiebstählen sind [1].

Heute sind es die Anwendungen, die die Außengrenzen bilden, und außerdem gehen Web-Anwendungen mit kritischen Informationen und geistigem Eigentum (Intellectual Property, IP) um. Warum sollen Hacker gegen Netzwerk-Firewalls anrennen, wenn die Daten doch genauso gut über eine Web-Anwendung zugänglich sind?

Anwendungen zu hacken, ist »Big Business«

Sicherheitsexperten in den Unternehmen haben es nicht mehr nur mit Hobby-Hackern zu tun, sondern die Widersacher sind inzwischen fähiger als je zuvor. Kriminelle Organisationen verfügen außerdem über viel Geld, und überdies gibt es auf dem Markt eine große Nachfrage nach Finanzdaten, Gesundheitsinformationen und persönlichen Informationen von Verbrauchern.

Werden Verbraucherdaten oft für Identitätsdiebstahl genutzt, so ist Industriespionage ein immerwährendes Problem. Am problematischsten für Unternehmen mit wertvollem geistigem Eigentum sind Angriffe von Nationalstaaten, die Entwicklungsinformationen und Handelsgeheimnisse in ihren Besitz bringen wollen.

Staatlich finanzierte Attacken und organisierte kriminelle Gruppen sind absolut real und liefern spektakuläre Schlagzeilen. Die Ransomware-Attacke »WannaCry« aus dem Jahr 2017, der mehr als 300.000 Geräte zum Opfer fielen, wurde Nordkorea zugeschrieben, und laut dem Internet Organised Crime Threat Assessment von Europol stellt Ransomware immer noch die wichtigste Bedrohung im Bereich der Cyberkriminalität dar (Bild 2).

Softwaresicherheit und regulatorische Vorgaben

Die Datenschutz-Regularien sehen bei Nichteinhaltung erhebliche Strafzahlungen vor. So beginnen die Strafen der Datenschutz-Grundverordnung (DSGVO) der EU bei 10 Mio. Euro bzw. 2 % des weltweiten Jahresumsatzes aus dem vorigen Geschäftsjahr, können aber auch doppelt so hoch ausfallen. Im Jahr 2019 musste die Fluggesellschaft British Airways 230 Mio. Euro Strafe zahlen, nachdem die Daten von rund 500.000 ihrer Kunden kompromittiert worden waren. Marriott zahlte zwischenzeitlich über 120 Mio. US-Dollar, nachdem die persönlichen Daten von 339 Mio. Kunden offengelegt worden waren, darunter Kreditkarten-Details, Passnummern und Geburtsdaten.

Für Software-Entwicklungsteams kann die Einhaltung der vielen Regelwerke, darunter einige sehr bestimmende, eine echte Herausforderung sein. Zum Beispiel verlangen das Regelwerk PCI-DSS (Payment Card Industry Data Security Standard) für die softwaremäßige Verarbeitung von Kreditkarten-Informationen und der unlängst von der Food and Drug Administration USA (FDA) für Medizingeräte mit Netzwerkanbindung übernommene Standard UL-2900, dass Organisationen Tests auf bestimmte Arten von Sicherheitslücken durchführen, wie sie beispielsweise in den CWE Top 25 (Common Weakness Enumeration Top 25 Most Dangerous Software Errors [3]) und CWE On the Cusp sowie den OWASP Top 10 [4] aufgeführt sind.

Dagegen sind die HIPAA-Vorschriften (Health Insurance Portability and Accountability Act) weniger präskriptiv und verlangen lediglich, dass die betroffenen Unternehmen »eine genaue und gründliche Bewertung der potenziellen Risiken und Schwachstellen für die Vertraulichkeit, Integrität und Verfügbarkeit elektronischer Gesundheits-Informationen vornehmen«, und dass sie »Sicherheitsmaßnahmen umsetzen, die geeignet sind, die Risiken und Schwachstellen auf ein vernünftiges und angemessenes Maß zu reduzieren, um den Anforderungen von § 164.306(a) zu genügen«.

Andere Regelwerke bieten überhaupt keine Leitlinien. So verlangt Abschnitt 5 des FTC Act (Federal Trade Commission) lediglich »angemessene Sicherheit«. Das für IoT-Geräte (Internet of Things) geltende kalifornische Regelwerk SB-327 fordert von den Herstellern, dass vernetzte Geräte, die in Kalifornien verkauft werden, über »angemessene Sicherheits-Eigenschaften« verfügen, wogegen die DSGVO in der EU nach »Privacy by Design« (eingebautem Datenschutz) und »Privacy by Default« (voreingestelltem Datenschutz) verlangt.

Ungeachtet der Unterschiede, die es zwischen den verschiedenen Regularien gibt, sind die zugrundeliegenden Anforderungen doch dieselben: Den Unternehmen müssen die Risiken, denen sie ausgesetzt sind, bewusst sein, und sie müssen Pläne dafür haben, wie sie mit diesen Risiken umgehen.

Risikobereitschaft und Restrisiko

Mit Sicherheitstests verfolgen Unternehmen zwei Ziele:

Erstens sollen die aus Programmierfehlern resultierenden Risiken, die von einem Angreifer ausgenutzt werden können, offengelegt werden, und durch das erzwungene Befolgen von »Best Practices« soll verhindert werden, dass sich diese Fehler in die Codebasis einschleichen.
Zweitens ist es wichtig sich zu vergegenwärtigen, dass das völlige Ausschließen jeglicher Risiken wahrscheinlich nicht das Ziel ist – von besonders kritischen Anwendungen einmal abgesehen. Nicht beseitigte Probleme ergeben ein Restrisiko, das hinnehmbar sein kann. Unterschiedliche Anwendungen stellen unterschiedliche Risikoniveaus dar, und ein etabliertes Unternehmen wird seine Risikobereitschaft ermitteln und daraufhin eine fundierte Entscheidung darüber treffen, mit welchem Restrisiko umgehen kann.