De essentiële gids voor gegevensbeveiliging voor productmanagers
Heb je gehoord van Code Spaces? Het was een broncoderepository die vergelijkbaar was met GitHub.
Waarschijnlijk heb je nog nooit van hen gehoord, omdat ze ondanks dat ze een veelbelovend product waren, vrijwel onmiddellijk verdwenen in juni 2014 na een enorm beveiligingslek. Door het lek verloren ze al hun klantgegevens en werden ze gedwongen hun activiteiten te staken.
Na dat incident leerde iedereen in de digitale wereld, inclusief productmanagers, een les die nooit vergeten mag worden—PRODUCTEN MOETEN VEILIG ZIJN.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
In deze gids laat ik je kennismaken met de wereld van productbeveiliging en help ik je om beveiliging in gedachten te houden bij het beheren van je producten.
Waarom productmanagers zich zorgen moeten maken over gegevensbeveiliging
In theorie zou je dagelijkse werk binnen productmanagement zich alleen moeten richten op retentie, gebruikersinterviews en andere niet-technische zaken, zonder dat je je zorgen hoeft te maken over beveiliging.
We leven echter in een wereld met kwaadwillenden die maar al te graag je gegevens zouden stelen (om ze later ergens te verkopen), versleutelen, er losgeld voor zouden eisen (ook wel ransomware genoemd), of simpelweg schade zouden aanrichten om schade aan te richten.
Dus naast je activatie en retentie moet je je ook zorgen maken over het enorme bedrijfsrisico dat gebrekkige beveiliging voor je product kan vormen. Een ernstig genoeg beveiligingslek zal je reputatie zo sterk schaden dat al het jarenlange harde werk van je marketing-, productontwikkelings- en verkoopteams in één dag kan verdwijnen.
Bovendien krijg je te maken met juridische stappen van je partners en klanten van wie je de gegevens niet goed hebt beschermd.
Daarom is het naar mijn mening van het grootste belang dat productmanagers “beveiligingsbewust” zijn wanneer ze hun producten ontwikkelen en laten groeien.
De 4 meest voorkomende beveiligingslacunes in productontwikkeling
Als productmanager hoef je niet echt diepgaande kennis te hebben van de nieuwste hackmethoden en de manieren om je daartegen te beschermen. Dat is iets wat je beveiligings- en engineeringteams moeten implementeren en beheren.
Je hebt echter wel een basiskennis van de techniek nodig om te begrijpen hoe enkele van de meest voorkomende beveiligingsproblemen werken en hoe hackers deze kunnen misbruiken. Hierdoor wordt je besluitvormingsproces meer “beveiligingsbewust”.
Laten we vier van zulke beveiligingslacunes samen doornemen en begrijpen waar ze over gaan.
1. SQL-injectie
Toen ik nog een jonge PM was, besloot ik wat te leren over programmeren en maakte ik een klein (en vreselijk) PHP-script dat als backend diende voor een contactformulier op een website. Het nam een bericht in ontvangst, sloeg het op in de database en stelde een e-mail aan mij op met de inhoud ervan.
Toen ik dit aan een bevriende ontwikkelaar liet zien, vroeg hij me, terwijl hij nauwelijks zijn amusement kon bedwingen (mijn code was gewoon onvoorstelbaar slecht), of ik mijn invoer had geschoond. Zoals je waarschijnlijk al vermoedt, had ik geen idee wat hij bedoelde. Hij legde me uit dat mijn databases zonder het schonen van invoer blootstonden aan SQL-injectie.
SQL-injectie is het proces waarbij een hacker speciale SQL-code invoert in plaats van tekst in je invoervelden, waarna deze code in je backend wordt uitgevoerd en de hacker ongeautoriseerde toegang tot je product krijgt of informatie uit je databases steelt.
Stel dat LinkedIn deze SQL-query zou gebruiken om je wachtwoord te controleren bij het inloggen (disclaimer: ze gebruiken hier absoluut iets slimmers dan deze SQL).
Als de invoervelden op de inlogpagina theoretisch gezien niet waren geschoond, zou je ' OR '1'='1 in de velden voor gebruikersnaam en wachtwoord kunnen typen en op Aanmelden kunnen klikken.
In dit geval zou de backend je ' OR '1'='1 aan de SQL-query toevoegen, waardoor deze er ongeveer zo uit zou komen te zien.
Deze query retourneert de waarde “true”. Dat betekent dat je bij LinkedIn zou kunnen inloggen zonder een echte gebruikersnaam en een echt wachtwoord.
Zoals ik al zei, kun je dit probleem voorkomen door je invoer te schonen. In deze context betekent schonen dat je ervoor zorgt dat alles wat je in de invoervelden typt, als gewone tekst wordt behandeld, zelfs als je code of een SQL-query invoert.
Met de geschoonde invoer zal LinkedIn in de database zoeken naar een gebruiker met de naam ' OR '1'='1, in plaats van de code uit te voeren. Uiteindelijk zal de zoekopdracht geen resultaat opleveren en krijg je een foutmelding dat er geen dergelijke persoon op LinkedIn bestaat.
Jezelf beschermen tegen SQL-injecties is een van de eerste stappen die je kunt nemen om de gegevens van je klanten veilig te houden en schadelijke datalekken en ongeautoriseerde toegang te voorkomen.
2. Cross-sitescripting (XSS)
XSS is een andere veelvoorkomende manier waarop hackers je product kunnen manipuleren en er kwaadwillig mee kunnen handelen. Om je een idee te geven van hoe vaak XSS voorkomt: een rapport van Positive Technologies schat dat ongeveer 90% van alle webapps die er zijn kwetsbaar is voor dit type aanval.
Waar gaat het precies over? XSS lijkt enigszins op SQL-injectie, omdat hackers je systeem manipuleren om code uit te voeren die het niet hoort uit te voeren. In dit geval bevindt de uitgevoerde schadelijke code zich echter niet in de backend/databases van je systeem, maar in de frontend.
Een van de grappige en onschadelijke voorbeelden van XSS is de zichzelf retweetende hartemoji van Twitter (ja, ik noem het nog steeds Twitter—probeer me maar op andere gedachten te brengen). Het is grappig omdat niemand verwachtte dat Twitter het zo enorm zou verpesten, en onschadelijk omdat het alleen zichzelf retweette.
Deze aanval bestond uit een eenvoudige tweet met de volgende tekst.
Zoals duidelijk uit de afbeelding blijkt, is dit geen gewone tekst, maar een stukje code (JavaScript met jQuery, om precies te zijn) met aan het einde een hartemoji.
Voordat Twitter deze beveiligingsfout oploste, zou de engine van je browser, als je deze tweet in je browser opende, de inhoud ervan herkennen als geldige code, deze voor de gebruiker verbergen en uitvoeren. In plaats van de twee regels code zag je dus alleen een tweet met een hartemoji.
Wanneer de code werd uitgevoerd, navigeerde deze door de HTML van de pagina, vond automatisch de retweetknop op je scherm en klikte daarop.
Dat betekende dat iedereen die deze tweet bekeek hem automatisch retweette, waardoor een groot deel van de Twitter-gebruikers ermee besmet raakte.
Stel je nu voor dat het geen zichzelf verspreidende tweet was, maar iets schadelijkers, zoals een script dat vertrouwelijke informatie van je scherm zou verzamelen en naar de hacker zou sturen. Of kwaadaardige code in je browser die je internetbankierapplicatie zou overnemen en geld van je rekening zou gaan overboeken.
Je begrijpt mijn punt: XSS is nog steeds ontzettend gevaarlijk, ook al kan het geen toegang krijgen tot je servers en databases.
Maar wat betekent dit voor jou als productmanager? Het kan bijvoorbeeld gebeuren dat je je engineers vraagt om handige functies en integraties te bouwen, zoals de mogelijkheid voor je website om de inhoud van andere tabbladen in de browser van de gebruiker te bekijken en daar iets interessants mee te doen.
Als je dat doet en je team weigert zo’n functie te bouwen, raak dan niet in de war of verdrietig, want wat je vraagt is in feite een XSS-aanval op andere sites.
XSS is een fascinerend gebied binnen cybersecurity en er zijn veel goede boeken over die ik kan aanbevelen. Mijn favoriet is XSS-aanvallen van Seth Fogie.
3. Onveilige API’s
Applicatieprogrammeerinterfaces (ook wel API’s genoemd) vormen het communicatiemiddel tussen je server en de browser van gebruikers, of tussen je server en de applicatie op hun mobiele apparaat of desktop.
Wanneer er gegevens op je server moeten worden opgehaald, opgeslagen of verwerkt, stuurt de browser/app (ook wel ‘clients’ genoemd) een verzoek met de benodigde informatie naar de server. Vervolgens voert de server het werk uit en stuurt hij het antwoord terug.
Wanneer clients bijvoorbeeld inloggen, sturen ze je gebruikersnaam en wachtwoord naar de server en vragen ze de server om je te authenticeren. Zodra de server het verzoek heeft voltooid, stuurt hij een bericht met “succes” terug, samen met de pagina-inhoud die de gebruiker moet zien wanneer het inloggen is voltooid.
Omdat API’s met gebruikersgegevens werken, zijn ze ook vatbaar voor beveiligingskwetsbaarheden die kunnen leiden tot kwaadwillige manipulatie van gegevens (bijvoorbeeld de server vragen om namens de gebruiker geld over te maken) of een datalek (bijvoorbeeld de server vragen om de medische gegevens van de gebruiker vrij te geven).
De meest voorkomende typen API-kwetsbaarheden zijn:
Geen authenticatie: In dit geval vereist de API niet dat de client zijn identiteit bewijst voordat de API vertrouwelijke informatie verstrekt. Om te begrijpen hoe dit werkt, kun je je voorstellen dat iemand naar de bank gaat en vraagt om geld op te nemen van de rekening van Mark Zuckerberk, waarna de kassier gewoon antwoordt: "Natuurlijk, hoeveel?"
Geen snelheidsbeperking: API's stoppen hier niet met het verwerken van verzoeken, zelfs niet als het er veel te veel zijn—veel meer dan de bedoeling was—waardoor je server overbelast raakt en uitvalt. Dit soort buitensporige stroom aan verzoeken ontstaat wanneer iemand een DDoS-aanval op je servers probeert uit te voeren.
Buitensporige blootstelling aan gegevens: hiervan is sprake wanneer de reacties van je API informatie bevatten waartoe je eigenlijk niet wilt dat mensen toegang hebben. Als je bijvoorbeeld via internetbankieren geld naar iemand overmaakt, kan de API-melding dat de transactie is geslaagd ook het saldo van de ontvanger bevatten, terwijl je dat absoluut niet hoort te kunnen zien.
De oplossingen voor deze drie kwetsbaarheden liggen min of meer voor de hand. Vraag om authenticatie bij het verstrekken van gevoelige gegevens, voeg snelheidsbeperking toe en zorg ervoor dat je geen gegevens verstrekt die daar niet horen te staan.
Als je je verder wilt verdiepen in API-beveiliging, kun je het boek van Neil Madden hierover bekijken.
4. Gebrek aan versleuteling
Mijn hoofd beveiliging herhaalt graag voortdurend dat een goed uitgewerkte cyberbeveiligingsstrategie voor een product op een ui lijkt: deze bestaat uit meerdere beveiligingslagen over verschillende onderdelen van het product.
Alles wat we tot nu toe hebben besproken, waren beveiligingsrisico's in de buitenste laag, wanneer de gebruiker geen toegang heeft tot je servers of databases en "vanaf de buitenkant" probeert aan te vallen.
Als een hacker echter op de een of andere manier volledige toegang tot je servers krijgt (de eerste laag binnendringt), moet je nog steeds maatregelen hebben getroffen om je databases tegen ongeautoriseerde toegang te beschermen—zodat ook je binnenste lagen veilig blijven.
Een van de beste manieren om je gegevens in dit geval te beschermen, is door ze te versleutelen. Dat betekent dat de gegevens, zelfs als iemand toegang krijgt tot je databases en ze downloadt, voor die persoon slechts een hoop onbegrijpelijke tekens zijn, omdat ze versleuteld zijn.
Alleen het bedrijf of de gebruiker—de twee partijen die de versleutelingssleutel hebben—zouden die onbegrijpelijke tekens kunnen ontsleutelen tot bruikbare informatie. Helaas komt het echter zeer vaak voor dat wordt vergeten gegevens op servers te versleutelen, wat heeft geleid tot talloze enorme datalekken.
Ik heb persoonlijk te veel websites en producten gezien die het risico namen door de wachtwoorden van hun gebruikers als platte tekst op te slaan—iets wat in software als een doodzonde wordt beschouwd. De beste werkwijze in dit geval is om het wachtwoord door een hash-algoritme te halen, er een versleutelde versie van te maken (een hash genoemd) en die in plaats daarvan op te slaan.
Het mooie hiervan is dat zowel de gebruiker als het bedrijf de sleutel heeft om de hash weer om te zetten naar de vorm van platte tekst en dat wachtwoord voor authenticatie te gebruiken. Maar als een hacker toegang krijgt tot de database en de hash downloadt, zou het zonder de sleutel miljoenen jaren aan berekeningen kosten om die terug te zetten naar het oorspronkelijke wachtwoord. (Ik maak geen grapje, dat is echt het juiste aantal!)
Versleuteling is nog een fascinerend gebied binnen cyberbeveiliging dat ik je aanraad te verkennen. Je kunt in het bijzonder beginnen met leren hoe cryptografie met openbare sleutels werkt, omdat het hele internet hier tegenwoordig op draait.
Applicatiebeveiliging integreren in de product- en softwareontwikkelingslevenscyclus
Met al deze kwetsbaarheden en beste werkwijzen in gedachten richten we ons op een voor de hand liggende vraag die je misschien hebt—hoe houd ik mijn producten als PM veilig?
Ik dacht al dat je dat nooit zou vragen! Hier zijn twee belangrijke beste werkwijzen voor beveiliging die je daarbij kunnen helpen:
Veilige producten door ontwerp
Dit is een benadering van het ontwikkelingsproces die stelt dat je vanaf het allereerste moment waarop je begint met het bouwen van je producten rekening moet houden met beveiligingsvereisten, zodat beveiligingsmaatregelen van nature in je code en architectuur worden geïntegreerd in plaats van later in de SDLC te worden toegevoegd.
Dat laatste is meestal veel duurder en biedt niet hetzelfde beschermingsniveau als "van nature" veilige software.
Als productmanager is het dus jouw verantwoordelijkheid om je ontwikkelteam te vragen deze aanpak te volgen en items die helpen om beveiliging in het product in te bouwen niet een lagere prioriteit te geven.
Regelmatige beveiligingsaudits
De meeste producten die ik heb beheerd, werden regelmatig op beveiliging getest (meestal eens per zes maanden tot een jaar). We testten de volledige beveiligingsstatus, en daaronder vielen:
- Penetratietesten
- Bedreigingsmodellering
- Beoordeling van beveiligingsmaatregelen
- Beoordeling van de beveiligingsstrategie en beveiligingsfuncties
- Beoordeling van de toeleveringsketen en automatiseringsworkflows
- Codeanalyse (waaronder de opensourcecode die we hebben gebruikt en de code die we via samenwerkingen met derden hebben verkregen)
- Opstellen van een beveiligingsroadmap en meetwaarden
- Risicobeoordeling
- ...en meer!
Dit is belangrijk omdat je product voortdurend in ontwikkeling is en je per ongeluk de softwarebeveiliging kunt aantasten wanneer je iets nieuws toevoegt. Regelmatige audits brengen deze problemen snel aan het licht en stellen je in staat ze op te lossen en te valideren voordat een kwaadwillende ze als eerste ontdekt.
Als productmanager is het jouw taak om tijd voor deze audits en de daaropvolgende codeopschoningen vrij te maken en er prioriteit aan te geven.
Vertrouw op je beveiligingsexperts
Welke functie je ook van plan bent te bouwen en welk actieplan je ook hebt om je groeidoelstellingen te behalen, zorg er altijd voor dat je je ideeën eerst met je beveiligingsteam hebt besproken.
En luister—misschien lijkt het je alsof de beveiligingsexperts willen dat je je product “overbeveiligt”. Maar meestal geldt: als ze je idee niet goed vinden, moet je overwegen het aan te passen. Het risico is het anders gewoon niet waard.
En nu we het toch over overwegingen hebben, overweeg ook om je op onze nieuwsbrief te abonneren, zodat je allerlei handleidingen en artikelen over productmanagement rechtstreeks in je inbox ontvangt!
