Datensicherheit, im englischen treffender mit "Security" bezeichnet, ist in einer Gesellschaft die sich immer stärker auf digitale Entscheidungsträger verlässt, eines der wichtigsten Elemente. Intelligente Helfer mit einer durchdachten Sicherheitsstrategie sind auf dem Markt allerdings selten.

Vor meinem beruflichen Wechsel und der Übername der Rolle eines Security Managers in Entwicklungsprojekten habe ich nie wirklich nachvollziehen können, warum selbst große Unternehmen, teilweise, dermaßen lax mit Sicherheitsthemen umgehen und immer wieder in die Falle des Imageverlustes durch schlechte Publicity laufen. Über das vergangene Jahr hinweg hatte ich die Möglichkeit bei mindestens drei kleineren bis großen (aus Sicht der IoT Projekte) Projekten das Sicherheitsthema federführend zu übernehmen und bei vielen anderen Projekten beratend dabei zu sein. Dabei war es sehr spannend mit verschiedenen Produktmanagern und Projektleitern zusammen zu arbeiten und deren Sicht auf das Thema mitzunehmen. Dabei ist es mir aufgefallen das gewisse Sicherheits-Themen immer wieder zur Sprache kommen. Die Gründe sind vielfältig, und ich würde niemandem böse Absicht unterstellen maximal Unwissenheit. Nichtsdestotrotz habe ich mich entschlossen ein eher ironischen Artikel zu verfassen.

Hier meine Top 5 der Statements die einen Security verantwortlichen mit Sicherheit unruhig werden lassen oder gar den Schaum aus dem Mund treiben wenn man von der Aussage nicht abrückt.

1. Globales Schlüsselmaterial oder ein zentrales Passwort für bessere Usability

Die Entwicklung eines Produktes ist getrieben von Kompromissen. Lange Batterielaufzeit oder häufigere BLE Kommunikation? Höhere Kosten für Charakterisierung oder einfachere Akzeptanzkriterien? Bessere Datensicherheit oder bessere Benutzbarkeit?

Während die ersten zwei Kompromisse auf physikalischen Gesetzen (jeder Sendevorgang benötigt Energie) bzw. der simplen Beziehung zwischen Aufwand und Kosten basieren, ist die dritte Aussage sehr pauschalisiert.

Selbstverständlich kann ein Produkt so gestaltet werden, dass die Sicherheitsfunktionen das Benutzen unmöglich machen oder umgekehrt die Usability Anforderungen das Anwenden von Sicherheitskonzepten ausschließen. Diese Absicht möchte jedoch niemandem unterstellen. Was sehr viel häufiger passiert, ist das schwache oder nutzlose Sicherheitskonzepte bevorzugt werden weil man davon ausgeht dass alles andere die Benutzung verkomplizieren würde.

Die Krux dabei ist, dass solche Sicherheitsfunktionen nicht nur nutzlos sind, sondern die Entwickler schlecht dastehen lassen und das Image des Unternehmens nachhaltig schädigen. Dazu gehören:

einheitliche Passwörter für ganze Produktfamilien symmetrische Schlüssel die global für die Produktfamilie zur Verschlüsselung benutzt werden simple PINs die keinen Bruteforce Schutz bieten Wenn Sie als die Projektverantwortung haben und ihren Security Manager nicht ausstehen können. Fordern Sie genau diese Konzepte.

2. Produkte nach Militärstandard für den einfachen Mann

Der krasse Gegensatz zum ersten Punkt jedoch mindestens genauso erfolgreich bei der "Bekämpfung" von Security verantwortlichen - Overengineering.

Sie als Produktverantwortlicher haben auf einem Seminar, einer Konsumentenmesse oder bei einem Bier mit einem befreundeten Möchtegern Hacker eine ganze Menge Informationen über notwendige Sicherheitsfunktionen aufgeschnappt ? Dann wird es Zeit diese ihrem Security Manager schmackhaft zu machen, und zwar unabhängig davon ob Ihr Produkt dies benötigt oder nicht.

Eine Anforderung zur Ausführung verschlüsselter Firmware auf einem digitalen Thermometer? Genau darauf hat ihr Team gewartet! Eine Zwei-Phasen Authentifizierung realisiert auf Basis der nachgebauten Google Security Engine um Ihren Thermostaten einstellen zu dürfen? Ihr Usability Engineeer wird dem Security Manager aber Dampf machen !

Selbstverständlich sind die Szenarien etwas überspitzt zeigen jedoch deutlich, dass das Overengineering ebenso ein großes Problem darstellt.

3. "Eigentlich wissen wir noch nicht was das Produkt tun sollen, aber siehe schon mal alle Fälle vor. Was, warum ist das so teuer?"

Wir kommen zum Klassiker mit dem Sie nicht nur den Security Manager um den Verstand bringen, sondern das gesamte Team verrückt machen können. Die Rede ist von einem Produkt das alles machen, nichts kosten und gestern fertig sein soll.

In Bezug auf Security äußert sich so ein Projekt häufig wie folgt. Auf die Frage ob die übertragenen Daten geheim gehalten werden sollen kommt als Antwort "mal ja, mal nein, mal auf gar keinen Fall". Häufig hat ein solches Produkt, wenn man vom IoT Umfeld reden, mehrere konkurrierende RF Interfaces um möglichst vielen Kunden gerecht zu werden. Diese bringen häufig vollkommen unterschiedliche Sicherheitskonzepte mit und lassen sich untereinander nicht sauber integrieren. Die Frage ob der Sensor die Daten den Grundsätzlich in das Backend bereitstellen soll wird mit "ja" geantwortet, im Gleichen Satz mit ABER auch angemerkt, dass bei einer nicht vorhandenen Internetverbindung eine lokale Nutzung unbedingt erforderlich ist. Selbstverständlich wurde zuvor unbedingt eine End-to-End Verschlüsselung mit dem Back-End gefordert die eine lokale Darstellung der Daten ohne Brüche im Sicherheitskonzept nahezu unmöglich macht.

Haben Sie also ein Projekt ohne klare Ziele und haben als Projektverantwortlicher keinen blassen Schimmer davon was Sie machen. Glückwunsch dann ist die perfekte Konstellation geschaffen um möglichst viel Kapital und gutes Personal mit in diesen Sumpf zu Ziehen. Fordern Sie also mehr Personal Ressourcen dann haben Sie die Möglichkeit das gesamte Unternehmen mit in die Tiefe zu ziehen.

4. "Wir machen was proprietäres dann versteht sowieso kein Außenstehender was er tun soll."

Wenn jemand nicht nachlesen kann wie die Kommunikation vonstattengeht und welche Daten wo stehen dann ist das sicher! Eine Aussage wie aus dem Lehrbuch der Kryptographie auch bekannt als "Security through obscurity" oder im deutschen "Sicherheit durch Unklarheit".

Um Sie als Projektverantwortlicher zu enttäuschen es ist keine stabile und nachhaltige Sicherheitsstrategie. Zumindest nicht in der Primärausführung oder Seukdärausführung. Es soll Sie nicht davon abhalten ihrem Sicherheitsverantwortlichen mehr solcher Vorschläge an den Kopf zu werfen. Am besten funktioniert so etwas mit Begründungen wie "geringere Kosten", "Alleinstellungsmerkmal" und der Klassiker "Wer will schon die Daten haben?". Geben Sie sich nicht damit zufrieden dass ein Systemarchitekt Ihnen das Prinzip der Code-Obfuscation als "Lösung" unter jubeln möchte, das ist ein anerkanntes Verfahren und hat mit Ihren Zielen nichts gemein. Folgende Methoden gehören definitiv zu den Mitteln ihrer Wahl:

Sie brauchen Sensordaten auf einer Fat-Partition nicht verschlüsseln wenn sie einen unauffälligen Dateinamen verwenden wie z. B. "omas-geburtstag.csv" Ihre Produkte haben ein Webfront-End zur Konfiguration? Hervorragend !! Sie können mehrere zehn tausende Euros sparen wenn Sie statt Authentifizierungsmaßnahmen den Standard Port umbiegen, dass kann zur not ihr Neffe aus der 5ten Klasse erledigen. Also merken, wenn Sie in Ihrem Produkt standardisierte und, durch die breite Masse, anerkannte Verfahren, Protokolle, Methoden oder Konzepte verwenden dann wird jeder das nachbauen können. Greifen Sie also zu selbst gebastelten Lösungen vor allem im Bereich der Datensicherheit.

5. "Security machen wir nach Produktstart"

Die ultimative Lösung für alle Ihre Zeitprobleme und im Gegensatz zu den vorhergehenden extrem einfach umzusetzen. Planen Sie die Implementierung nicht ein und verweisen Sie auf den Zeitdruck und ein gekürztes Budget. Schließlich sprechen wir hier von Software und die lässt sich bekanntlich aktualisieren (zumindest theoretisch). Auch das Label auf dem Produkt, dass das vorhanden Sein aktuellster Sicherheitsfeatures bewirbt können sie außer Acht lassen. Immerhin sind die Funktionen für den normalen Kunden unsichtbar und er stellt sowieso seine ganzen Daten auf Facebook und andere Plattformen.

Und by the way, sie haben sowieso schon gekündigt und hinterlassen die verbrannt Erde dem Team.

Next Post Previous Post