Fehlende Sicherheit spart nur scheinbar Geld ein:
Datendiebstahl: lieber daraus lernen, anstatt peinlicher Ausreden

von Werner Veith (werner.veith@networkcomputing.de), Martin Kuppinger

Share
02.11.2009

Der Klau von Daten droht zum alltäglichen Skandal zu werden. Wirklich schlimm sind aber die peinlichen Erklärungsversuche. Besser wäre es, auf eine entsprechende Sicherheitsarchitektur und passende Entwicklungsprozesse zu achten.

Gestern hat der SWR3 über die Sicherheitslücken bei libri.de berichtet. Interessant war dabei vor allem der Pressesprecher des TÜV Süd. Er versuchte zu erklären, wie es trotz Sicherheitszertifikat für libri.de möglich war, mit einfachen Mitteln auf Rechnungsdetails anderere Kunden zuzugreifen. Das Zertifikat hatte der TÜV Süd an libri.de als vertrauenswürdige Site. Die Quintessenz war, dass das Internet eben unsicher sei und wenn man an der Software was ändere, könne es halt zu neuen Sicherheitslücken kommen.

Täglich grüßt das Datenleck: Viele Unternehmen wissen nicht damit umzugehen. (Quelle: Pixelio, garl)

Richtig: Softwareänderungen können zu neuen Risiken führen. Aber: Das Problem bei libri.de ist genauso wie das unlängst bei SchülerVZ und viele andere in erster Linie ein Problem einer mangelhaften Sicherheitsarchitektur in der Software. Wenn es die von vornherein und entsprechende SDLs (Secure-Development-Lifecycles) gegeben hätte, wäre das Problem nie entstanden.

Denn im Prinzip ist es ganz einfach: Es gibt Informationen, auf die zugegriffen werden soll. Personen authentifizieren sich. Das System führt eine adäquate Autorisierung zu. Es lässt genau die berechtigten Zugriffe zu.

Das lässt sich bei Rechnungsdaten im Online-Handel ebenso realisieren wie bei sozialen Netzwerken. Das kann man auch durchgängig und konsequent machen, um sicherzustellen, dass wirklich nur berechtigte Zugriffe erfolgen dürfen. Nur: Dazu muss man von Beginn an bei der Softwarearchitektur und im weiteren Verlauf bei der Entwicklung der Software das Thema Sicherheit konsequent mit berücksichtigen.

Sicherheit hat ihren Preis

Klar ist auch: Sicherheit hat ihren Preis. Im E-Commerce und bei sozialen Netzwerken geht es dabei vor allem um die Performance. Die Autorisierungsentscheidungen sind dort oft komplex und deren Überprüfung kostet Zeit. Das kann man teilweise mit mehr Rechenleistung auffangen, aber es kostet Geld. Nur: Wenn man das nicht will, muss man auch die Konsequenzen tragen. Das ist auch der Grund, warum starke Authentifizierungsmechanismen bei E-Commerce-Sites und sozialen Netzwerken praktisch völlig fehlen: Sicherheit kostet Geld.

Martin Kuppinger, einer der Gründer des Analystenunternehmens Kuppinger Cole.

Fakt ist: Die allermeisten Probleme der vergangenen Monate wären bei besserer Sicherheitsarchitektur der Anwendungen vermeidbar gewesen. Und die potenziellen Probleme wären auch bei Zertifizierungen grundsätzlich erkennbar gewesen.

Das bedeutet nicht, dass schon durch eine entsprechende Sicherheitsarchitektur und einen SDL alles immer sicher ist. Aber die Risiken werden massiv reduziert. Natürlich kann es noch zu Konfigurationsfehlern bei der Autorisierung kommen. Auch das lässt sich aber mit Methoden und Werkzeugen weitgehend in den Griff bekommen.

Den »Worst Case« vermeiden

Das Fazit ist: Die allermeisten der aktuellen Datenskandale sind ein Resultat dessen, dass Sicherheit nicht ausreichend ernst genommen wird, sondern immer nur lästiges Beiwerk ist. Wer sein Geschäft aber so begreift, muss sich über die Konsequenzen nicht wundern: bis hin zum Verlust von Image und Kunden und im »Worst Case« einem nicht mehr funktionierenden Geschäftsmodell.

Man sollte nur die Ausreden und unhaltbaren Erklärungen vermeiden und stattdessen lieber an professioneller Software mit professionellen Sicherheitskonzepten arbeiten.

Martin Kuppinger

Martin Kuppinger ist Gründer des Analystenunternehmens Kuppinger Cole. Dieses beschäftigt sich schwerpunktmäßig mit den Themenbereichen Identity- und Access-Management (IAM), Governance, Risk-Management, Compliance, Cloud-Computing und Virtualisierung.
Verwandte Artikel