Der wesentliche Ratgeber für Datensicherheit für Produktmanager
Haben Sie schon von Code Spaces gehört? Es war ein Quellcode-Repository ähnlich wie Github.
Nun, vermutlich haben Sie noch nie von ihnen gehört, denn obwohl es ein vielversprechendes Produkt war, verschwanden sie im Juni 2014 fast augenblicklich nach einem massiven Sicherheitsvorfall. Dieser Vorfall führte dazu, dass sie alle Kundendaten verloren und gezwungen waren, den Betrieb einzustellen.
Nach diesem Vorfall lernte jeder im digitalen Bereich, einschließlich Produktmanager, eine Lektion, die niemals vergessen werden sollte—PRODUKTE MÜSSEN SICHER SEIN.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
In diesem Leitfaden führe ich Sie in die Welt der Produktsicherheit ein und helfe Ihnen, Sicherheit stets im Hinterkopf zu behalten, wenn Sie Ihre Produkte managen.
Warum Produktmanager sich um Datensicherheit kümmern sollten
Theoretisch sollte sich Ihr Produktmanagement im Alltag nur auf Retention, Nutzerinterviews und andere nicht-technische Themen konzentrieren, ohne sich um Sicherheit sorgen zu müssen.
Allerdings leben wir in einer Welt voller böser Akteure mit bösartigen Absichten, die nur zu gerne Ihre Daten stehlen würden (um sie später irgendwo zu verkaufen), sie verschlüsseln, ein Lösegeld dafür verlangen (Ransomware), oder einfach nur Schaden zufügen wollen – einfach, um Schaden anzurichten.
Deshalb sollten Sie sich neben Aktivierung und Retention auch Gedanken über das enorme Geschäftsrisiko machen, das eine nachlässige Sicherheit für Ihr Produkt darstellen kann. Ein gravierender Sicherheitsvorfall kann Ihrem Ruf so sehr schaden, dass die jahrelange harte Arbeit Ihrer Marketing-, Produktentwicklungs- und Vertriebsteams an einem einzigen Tag zunichtegemacht werden kann.
Außerdem werden Sie am Ende rechtliche Schritte von Partnern und Kunden gegenübersehen, deren Daten Sie nicht ausreichend geschützt haben.
Meiner Meinung nach ist es daher von größter Wichtigkeit, dass Produktmanager beim Aufbau und dem Wachstum ihrer Produkte „sicherheitsbewusst“ sind.
Die 4 häufigsten Sicherheitslücken in der Produktentwicklung
Als Produktmanager müssen Sie kein tiefgehendes Wissen über die neuesten Hacking-Methoden und Schutzmaßnahmen besitzen. Das ist die Aufgabe Ihrer Sicherheits- und Engineering-Teams.
Jedoch benötigen Sie ein grundlegendes technisches Verständnis darüber, wie einige der häufigsten Sicherheitsprobleme funktionieren und wie Angreifer sie ausnutzen können. Das wird Ihre Entscheidungsfindung „sicherheitsbewusster“ machen.
Lassen Sie uns gemeinsam vier solcher Sicherheitslücken durchgehen und verstehen, worum es dabei geht.
1. SQL-Injection
Als ich noch ein junger PM war, beschloss ich, ein wenig zu programmieren, und schrieb einen kleinen (und schrecklichen) PHP-Code, der als Backend eines Kontaktformulars einer Website diente. Er nahm eine Nachricht entgegen, speicherte sie in der Datenbank und verfasste eine E-Mail an mich mit deren Inhalt.
Als ich dies einem befreundeten Entwickler zeigte, konnte er sich sein Amüsement kaum verkneifen (mein Code war einfach unglaublich schlecht), und er fragte mich, ob ich meine Eingaben validiert hätte. Wie Sie sich denken können, wusste ich nicht, was er meinte, woraufhin er mir erklärte, dass meine Datenbanken ohne eine Validierung der Eingaben gegenüber SQL-Injection verwundbar waren.
SQL-Injection bedeutet, dass ein Angreifer spezielle SQL-Befehle statt Text in ein Eingabefeld schreibt und dadurch letztlich diesen Code im Backend ausführt und unautorisierten Zugriff auf Ihr Produkt erhält oder Informationen aus Ihren Datenbanken stiehlt.
Stellen Sie sich vor, LinkedIn würde diese SQL-Abfrage nutzen, um Ihr Passwort beim Login zu prüfen (Achtung: Sie verwenden definitiv etwas Klügeres als dieses SQL-Beispiel).
Wären die Eingabefelder dieser Loginseite theoretisch nicht validiert, könnten Sie ' OR '1'='1 in die Felder für Benutzername und Passwort eingeben und auf "Anmelden" klicken.
In diesem Fall würde das Backend Ihr ' OR '1'='1 in die SQL-Abfrage einbauen und die Anfrage würde in etwa so aussehen.
Diese Abfrage liefert als Ergebnis „true“. Das bedeutet, Sie könnten sich bei LinkedIn einloggen, ohne einen tatsächlichen Benutzernamen oder ein Passwort zu haben.
Wie bereits erwähnt, lässt sich dieses Problem vermeiden, indem man die Eingaben validiert. In diesem Zusammenhang bedeutet Validierung, dass alles, was Sie in die Eingabefelder schreiben, wie gewöhnlicher Text behandelt wird, auch wenn Sie Code oder eine SQL-Abfrage eingeben.
Mit validierten Eingaben sucht LinkedIn dann nach einem Nutzer mit dem Namen ' OR '1'='1 in der Datenbank, anstatt den Code auszuführen. Das wird dann fehlschlagen und Ihnen eine Fehlermeldung anzeigen, dass es keine solche Person bei LinkedIn gibt.
Sich vor SQL-Injektionen zu schützen ist eine der grundlegenden Maßnahmen, die Sie ergreifen können, um die Daten Ihrer Kundschaft zu sichern und schädliche Datenlecks oder unbefugten Zugriff zu vermeiden.
2. Cross-Site-Scripting (XSS)
XSS ist eine weitere gängige Methode, mit der Hacker Ihr Produkt manipulieren und böswillig agieren können. Wie verbreitet XSS ist, zeigt ein Bericht von Positive Technologies, laut dem etwa 90 % aller Webanwendungen für diese Art von Angriff verwundbar sind.
Worum handelt es sich dabei? XSS ähnelt ein wenig der SQL-Injektion, da auch hier Angreifer das System dazu bringen, Code auszuführen, der eigentlich nicht vorgesehen ist. Allerdings wird in diesem Fall der schädliche Code nicht im Backend bzw. in den Datenbanken Ihres Systems ausgeführt, sondern im Frontend.
Eines der lustigen und ungefährlichen Beispiele für XSS ist Twitters (ja, ich nenne es immer noch Twitter – gerne streite ich darüber) sich selbst retweetendes Herz-Emoji. Es ist lustig, weil niemand damit gerechnet hat, dass Twitter so einen groben Fehler macht, und es ist harmlos, weil am Ende einfach der Tweet sich selbst retweetet hat.
Dieser Angriff bestand nur aus einem einfachen Tweet mit folgendem Text.
Wie auf dem Bild zu erkennen ist, handelt es sich hierbei nicht um normalen Text, sondern um ein Stück Code (genauer: Javascript mit jQuery) zusammen mit einem Herz-Emoji am Ende.
Bevor Twitter diese Sicherheitslücke behob, hat der Browser beim Öffnen des Tweets dessen Inhalt als gültigen Code erkannt, diesen vor dem Nutzer versteckt und ausgeführt. Anstelle der zwei Codezeilen sah man also nur einen Tweet mit Herz-Emoji.
Wurde der Code ausgeführt, navigierte er durch das HTML der Seite, fand automatisch den Retweet-Button auf dem Bildschirm und klickte darauf.
Das bedeutete, dass jeder, der diesen Tweet ansah, ihn automatisch retweetete – was dazu führte, dass ein Großteil der Twitter-Nutzerinnen und -Nutzer infiziert wurde.
Stellen Sie sich nun vor, es handelte sich nicht um einen sich selbst replizierenden Tweet, sondern um etwas Gefährlicheres – zum Beispiel ein Skript, das vertrauliche Informationen von Ihrem Bildschirm abgreift und an den Angreifer sendet. Oder ein schädlicher Code in Ihrem Browser übernimmt Ihr Online-Banking und beginnt, Geld aus Ihrem Konto zu überweisen.
Sie sehen: XSS ist nach wie vor äußerst gefährlich, auch wenn dadurch nicht auf Ihre Server oder Datenbanken zugegriffen werden kann.
Und wie betrifft das Sie als Produktmanager? Nun – vielleicht bitten Sie Ihre Entwicklerinnen und Entwickler irgendwann einmal um eine interessante Funktion oder Integration, die es Ihrer Website erlaubt, den Inhalt anderer Browser-Tabs des Nutzers einzusehen und damit etwas Sinnvolles zu machen.
Wenn Sie dies tun und Ihr Team die Entwicklung einer solchen Funktion ablehnt, wundern Sie sich nicht – denn im Grunde fordern Sie einen XSS-Angriff auf andere Websites an.
XSS ist ein spannendes Feld in der IT-Sicherheit, und es gibt viele großartige Bücher dazu. Mein Favorit ist XSS Attacks von Seth Fogie.
3. Unsichere APIs
Application Programming Interfaces (auch bekannt als APIs) sind die Kommunikationsmittel zwischen Ihrem Server und dem Browser der Nutzerinnen und Nutzer bzw. Ihrer App auf deren Mobilgeräten oder Desktop.
Immer wenn Daten auf Ihrem Server abgerufen, gespeichert oder verarbeitet werden müssen, sendet der Browser oder die App (genannt „Clients“) eine Anfrage mit den nötigen Informationen an den Server. Anschließend erledigt der Server die Aufgabe und schickt eine Antwort zurück.
Beim Login etwa senden die Clients Ihren Benutzernamen und Ihr Passwort an den Server und bitten ihn um Authentifizierung. Sobald der Server die Anfrage bearbeitet hat, sendet er eine „Erfolgs“-Meldung mitsamt den Inhalten, die die Nutzerin oder der Nutzer nach dem Login sehen soll, zurück.
Da APIs mit Nutzerdaten arbeiten, sind sie auch anfällig für Sicherheitslücken, die zu böswilliger Manipulation von Daten führen können (z. B. den Server zu einer Überweisung im Namen der Nutzerin oder des Nutzers auffordern) oder zu Datenlecks (z. B. den Server nach den medizinischen Unterlagen eines Nutzers fragen).
Die häufigsten API-Schwachstellen sind:
Keine Authentifizierung: In diesem Fall verlangt die API vom Client keinen Identitätsnachweis, bevor sie vertrauliche Informationen herausgibt. Wie das aussehen kann? Stellen Sie sich vor, jemand geht zur Bank und bittet darum, Geld vom Konto von Mark Zuckerberk abzuheben – und die Kassiererin antwortet: „Natürlich, wie viel?“
Kein Ratenlimit: Hierbei stoppen APIs die Verarbeitung von Anfragen nicht, selbst wenn einfach zu viele davon eingehen – also deutlich mehr als eigentlich vorgesehen wurden – was dazu führt, dass dein Server überlastet und ausfällt. Solch ein übermäßiger Ansturm an Anfragen tritt häufig auf, wenn jemand versucht, einen DDoS-Angriff auf deine Server durchzuführen.
Übermäßige Datenfreigabe: Dies tritt auf, wenn deine API-Antworten Informationen enthalten, auf die andere eigentlich keinen Zugriff haben sollten. Zum Beispiel, wenn du jemandem per Online-Banking Geld überweist und die API-Benachrichtigung zum erfolgreichen Abschluss der Transaktion zusätzlich auch den Kontostand des Empfängers übermittelt – etwas, das du ganz bestimmt nicht sehen solltest.
Die Lösungen für diese drei Schwachstellen sind im Grunde offensichtlich. Fordere Authentifizierung an, wenn sensible Daten bereitgestellt werden, setze Ratenlimits und stelle sicher, dass du keine unerwünschten Daten überträgst.
Wenn du das Thema API-Sicherheit weiter vertiefen möchtest, kannst du Neil Maddens Buch dazu lesen.
4. Fehlende Verschlüsselung
Mein Sicherheitschef wiederholt immer gerne, dass eine gut umgesetzte Cybersecurity-Strategie für ein Produkt wie eine Zwiebel aufgebaut ist – sie besteht aus mehreren Sicherheitsschichten, die über verschiedene Bereiche des Produkts verteilt sind.
Alles, was wir bisher besprochen haben, waren Sicherheitsrisiken auf der äußeren Schicht, also wenn der Benutzer keinen Zugriff auf deine Server oder Datenbanken hat und nur „von außen“ attackiert.
Wenn es ein Hacker jedoch trotzdem schafft, vollen Zugriff auf deine Server zu bekommen (also die erste Schicht durchbricht), sollten trotzdem noch Schutzmaßnahmen vorhanden sein, um deine Datenbanken vor unbefugtem Zugriff zu schützen – so bleiben auch die inneren Schichten sicher.
Eine der besten Methoden zum Schutz deiner Daten in solchen Fällen ist die Verschlüsselung. Das bedeutet, selbst wenn jemand deine Datenbanken ausliest und diese Daten herunterlädt, sind sie für diese Person nur unverständliches Kauderwelsch, da sie verschlüsselt sind.
Nur das Unternehmen oder der Nutzer – die beiden Parteien, die über den Entschlüsselungsschlüssel verfügen – können dieses Kauderwelsch wieder in sinnvolle Daten umwandeln. Leider wird häufig vergessen, die Daten auf Servern zu verschlüsseln, was immer wieder zu enormen Datenpannen führt.
Ich habe persönlich viel zu viele Websites und Produkte gesehen, die das Risiko eingegangen sind, die Passwörter ihrer Nutzer im Klartext abzuspeichern – etwas, das als Todsünde in der Softwareentwicklung gilt. Die beste Vorgehensweise hierfür ist, das Passwort durch einen Hash-Algorithmus laufen zu lassen, eine verschlüsselte Version (einen sogenannten Hash) davon zu erstellen und nur diese zu speichern.
Das Beste daran ist, dass sowohl der Nutzer als auch das Unternehmen den Schlüssel besitzen, um den Hash wieder in seine ursprüngliche Klartextform zurückzuverwandeln und dieses Passwort zur Authentifizierung zu verwenden. Wenn jedoch ein Hacker auf die Datenbank zugreift und den Hash herunterlädt, würde es Millionen Jahre an Rechenleistung benötigen, ihn ohne Schlüssel zurückzurechnen. (Kein Scherz, das ist die reale Größenordnung!)
Verschlüsselung ist ein weiteres spannendes Feld in der Cybersicherheit, das ich dir ans Herz lege, näher zu erforschen. Insbesondere kannst du damit beginnen, wie Public Key Cryptography funktioniert – darauf basiert inzwischen das gesamte Internet.
Integration von Anwendungssicherheit in den Produkt- und Softwareentwicklungs-Lebenszyklus
Mit all diesen Schwachstellen und Best Practices im Kopf kommen wir zur offensichtlichen Frage, die du dir vielleicht stellst: Wie halte ich meine Produkte als PM sicher?
Ich dachte schon, du würdest nie fragen! Hier sind zwei wichtige Sicherheitspraktiken, die dir dabei helfen können:
Sichere Produkte durch Design
Das ist ein Entwicklungsansatz, der vorsieht, dass du bereits ab dem allerersten Moment, in dem du beginnst, deine Produkte zu entwickeln, die Sicherheitsanforderungen mitbedenkst. So werden Schutzmaßnahmen von Anfang an in deinen Code und deine Architektur integriert, anstatt sie erst nachträglich im SDLC aufzubauen.
Letzterer Weg ist meist deutlich teurer und bietet nicht denselben Schutz wie „von Grund auf“ sicher entwickelte Software.
Als Produktmanager ist es daher deine Aufgabe, das Entwicklungsteam aufzufordern, diesem Ansatz zu folgen und darauf zu achten, dass sicherheitsrelevante Punkte nicht nach hinten priorisiert werden.
Regelmäßige Sicherheits-Audits
Die meisten Produkte, die ich bisher betreut habe, wurden regelmäßig auf ihre Sicherheit überprüft (in der Regel einmal alle sechs Monate bis jährlich). Wir testeten die gesamte Sicherheitslage, und dazu gehörten:
- Penetrationstests
- Bedrohungsmodellierung
- Überprüfung von Sicherheitskontrollen
- Überprüfung von Sicherheitsstrategie und Sicherheitsfunktionen
- Überprüfung von Lieferkette und Automatisierungsabläufen
- Code-Analyse (einschließlich des von uns verwendeten Open-Source-Codes und des von Drittpartnern erhaltenen Codes)
- Erstellung von Sicherheitsfahrplan und Kennzahlen
- Risikobewertung
- ...und mehr!
Das ist wichtig, weil sich Ihr Produkt ständig weiterentwickelt und Sie bei der Einführung neuer Funktionen versehentlich die Softwaresicherheit beeinträchtigen könnten. Regelmäßige Audits erkennen diese Probleme schnell, sodass Sie sie beheben und validieren können—bevor ein Angreifer sie zuerst findet.
Als Produktmanager besteht Ihre Aufgabe darin, Zeit einzuplanen und Prioritäten für diese Audits und die anschließenden Code-Bereinigungen zu setzen.
Vertrauen Sie Ihren Sicherheitsexperten
Welche Funktion Sie auch immer entwickeln möchten und welchen Aktionsplan Sie auch haben, um Ihre Wachstumsziele zu erreichen—stellen Sie immer sicher, dass Sie Ihre Ideen mit Ihrem Sicherheitsteam abgestimmt haben.
Und hören Sie zu—vielleicht kommt es Ihnen so vor, als möchten die Sicherheitsexperten Ihr Produkt „übermäßig absichern“. In den meisten Fällen sollten Sie jedoch Änderungen an Ihrer Idee in Betracht ziehen, wenn sie diese nicht gutheißen. Das Risiko ist es ansonsten einfach nicht wert.
Und wenn wir schon beim Nachdenken sind: Überlegen Sie auch, unseren Newsletter zu abonnieren, um viele Leitfäden und Artikel zum Produktmanagement direkt in Ihr Postfach zu erhalten!
