Den grundläggande datasäkerhetsguiden för produktchefer
Har du hört talas om Code Spaces? Det var ett källkodsarkiv som liknade Github.
Du har förmodligen aldrig hört talas om dem eftersom de, trots att de var en lovande produkt, försvann nästan omedelbart i juni 2014 efter ett massivt säkerhetsintrång. Intrånget ledde till att de förlorade all kunddata, vilket tvingade dem att upphöra med verksamheten.
Efter den incidenten lärde sig alla i den digitala världen, inklusive produktchefer, en läxa som aldrig får glömmas—PRODUKTER MÅSTE VARA SÄKRA.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
I den här guiden kommer jag att introducera dig till produktsäkerhetens värld och hjälpa dig att ha säkerhet i åtanke när du hanterar dina produkter.
Varför produktchefer bör bry sig om datasäkerhet
I teorin borde ditt dagliga arbete inom produkthantering bara fokusera på att behålla användare, användarintervjuer och annat icke-tekniskt, utan att behöva oroa dig för säkerheten.
Men vi lever i en värld med personer med ont uppsåt som mer än gärna skulle stjäla dina data (för att sälja dem någon annanstans senare), kryptera dem, kräva lösensumma för dem (så kallad ransomware), eller helt enkelt orsaka skada för skadans skull.
Så utöver aktivering och bibehållande bör du också bry dig om den enorma affärsrisk som bristande säkerhet kan innebära för din produkt. Ett tillräckligt allvarligt säkerhetsintrång kommer att skada ditt rykte så mycket att alla år av hårt arbete från dina marknadsförings-, produktutvecklings- och säljteam kan försvinna på en enda dag.
Dessutom kommer du att behöva hantera rättsliga åtgärder från dina partner och kunder vars data du misslyckades med att skydda.
Därför anser jag att det är av yttersta vikt för produktchefer att vara ”säkerhetsmedvetna” när de bygger och utvecklar sina produkter.
De fyra vanligaste säkerhetsbristerna inom produktutveckling
Som produktchef behöver du egentligen inte ha djupgående kunskaper om de senaste hackningsmetoderna och hur man skyddar sig mot dem. Det är något som dina säkerhets- och utvecklingsteam ska implementera och hantera.
Du behöver däremot ha en grundläggande teknisk förståelse för hur några av de vanligaste säkerhetsproblemen fungerar och hur hackare kan utnyttja dem. Det gör din beslutsprocess mer ”säkerhetsmedveten”.
Låt oss tillsammans gå igenom fyra sådana säkerhetsbrister och förstå vad de handlar om.
1. SQL-injektion
När jag var en ung produktchef bestämde jag mig för att lära mig lite programmering och skrev en liten (och hemsk) PHP-kod som fungerade som backend för ett kontaktformulär på en webbplats. Den tog emot ett meddelande, lagrade det i databasen och skapade ett e-postmeddelande adresserat till mig med dess innehåll.
När jag visade detta för en utvecklarvän till mig frågade han, förutom att knappt kunna hålla tillbaka sin munterhet (min kod var helt enkelt otroligt dålig), om jag hade sanerat mina indata. Som du kanske gissar hade jag ingen aning om vad han menade, och han förklarade att mina databaser var utsatta för SQL-injektion eftersom indata inte hade sanerats.
SQL-injektion är när en hackare skriver särskild SQL-kod i stället för text i dina indata, vilket leder till att koden körs i din backend och ger obehörig åtkomst till din produkt eller gör det möjligt att stjäla information från dina databaser.
Föreställ dig att LinkedIn använde denna SQL-fråga för att kontrollera ditt lösenord vid inloggning (ansvarsfriskrivning: de gör definitivt något smartare än SQL-frågan här).
Om inmatningsfälten på inloggningssidan teoretiskt sett inte var sanerade skulle du kunna skriva ' OR '1'='1 i fälten för användarnamn och lösenord och klicka på Logga in.
I det här fallet skulle backend lägga till din ' OR '1'='1 i SQL-frågan, som då skulle se ut ungefär så här.
Den här frågan kommer att returnera värdet ”true”. Det innebär att du skulle kunna logga in på LinkedIn utan ett faktiskt användarnamn och lösenord.
Som jag redan nämnde kan du undvika det här problemet genom att sanera dina indata. Sanering betyder i det här sammanhanget att säkerställa att allt du skriver i inmatningsfälten behandlas som vanlig text, även om du skriver kod eller en SQL-fråga.
Med sanerade indata kommer LinkedIn att försöka söka efter en användare med namnet ' OR '1'='1 i databasen i stället för att köra koden. Till slut kommer sökningen inte att hitta användaren och visa ett felmeddelande om att det inte finns någon sådan person på LinkedIn.
Att skydda sig mot SQL-injektioner är ett av de grundläggande stegen du kan ta för att hålla dina kunders data säkra och undvika skadliga dataläckor och obehörig åtkomst.
2. Skript mellan webbplatser (XSS)
XSS är ett annat vanligt sätt för hackare att manipulera din produkt och agera skadligt i den. För att få en uppfattning om hur vanligt XSS är uppskattar en rapport från Positive Technologies att omkring 90 % av alla webbappar där ute är sårbara för denna typ av attack.
Så vad handlar det om? XSS liknar SQL-injektion något när det gäller att hackare manipulerar ditt system så att det kör kod som det inte var avsett att köra. I det här fallet körs dock den skadliga koden inte i systemets backend eller databaser, utan i frontend.
Ett av de roliga och ofarliga exemplen på XSS är Twitters (ja, jag kallar det fortfarande Twitter – försök övertyga mig om motsatsen) hjärtemoji som retweetade sig själv. Det är roligt eftersom ingen förväntade sig att Twitter skulle göra bort sig så grundligt, och det är ofarligt eftersom allt den gjorde var att retweeta sig själv.
Den här attacken var bara en enkel tweet som innehöll följande text.
Som framgår av bilden är detta inte vanlig text utan en kodbit (JavaScript med jQuery, för att vara exakt) tillsammans med en hjärtemoji i slutet.
Innan Twitter åtgärdade denna säkerhetsbrist skulle webbläsarens motor, om du öppnade denna tweet i din webbläsare, känna igen innehållet som giltig kod, dölja det för användaren och köra det. I stället för de två kodraderna skulle du alltså bara se en tweet med en hjärtemoji.
När koden kördes navigerade den genom sidans HTML, hittade automatiskt retweetknappen på skärmen och klickade på den.
Det innebar att alla som tittade på denna tweet automatiskt retweetade den – vilket ledde till att en stor del av Twitters användare infekterades av den.
Föreställ dig nu om det inte hade varit en självkopierande tweet utan något skadligare, som ett skript som skrapade konfidentiell information från skärmen och skickade den till hackaren. Alternativt skulle skadlig kod i din webbläsare kunna ta över din internetbank och börja överföra pengar från ditt konto.
Du förstår vad jag menar – XSS är fortfarande extremt farligt trots att det inte kan komma åt dina servrar och databaser.
Men hur berör detta dig som produktchef? Du kanske ber dina ingenjörer att skapa häftiga funktioner och integrationer, till exempel att låta din webbplats se innehållet i andra flikar i användarens webbläsare och göra något intressant med den informationen.
Om du gör det och ditt team vägrar att bygga en sådan funktion ska du inte bli förvirrad eller ledsen, eftersom det du ber om i praktiken är en XSS-attack mot andra webbplatser.
XSS är ett fascinerande område inom cybersäkerhet, och det finns många bra böcker om ämnet som jag kan rekommendera. Min favorit är XSS-attacker av Seth Fogie.
3. Osäkra API:er
Programmeringsgränssnitt (även kallade API:er) är kommunikationsmedlet mellan din server och användarnas webbläsare eller din applikation på deras mobila enhet eller dator.
När det finns behov av att hämta, lagra eller bearbeta data på din server skickar webbläsaren eller appen (även kallade ”klienter”) en begäran till servern med nödvändig information. Därefter utför servern arbetet och skickar tillbaka svaret.
När klienter till exempel loggar in skickar de ditt användarnamn och lösenord och ber servern att autentisera dig. Så snart servern har slutfört begäran skickar den tillbaka ett meddelande om att det lyckades tillsammans med det sidinnehåll som användaren ska se när inloggningen är klar.
Eftersom API:er arbetar med användardata är de också utsatta för säkerhetsbrister som kan leda till skadlig manipulation av data (t.ex. att be servern genomföra en penningöverföring i användarens namn) eller dataintrång (t.ex. att be servern avslöja användarens journaler).
De vanligaste typerna av sårbarheter i API:er är:
Ingen autentisering: I detta fall kräver API:et inte att klienten bevisar sin identitet innan det tillhandahåller konfidentiell information. För att förstå hur detta fungerar kan du föreställa dig att någon gick till banken och bad att få ta ut pengar från Mark Zuckerbergs konto, och kassören bara svarade: ”Visst, hur mycket?”
Ingen hastighetsbegränsning: Här slutar API:er inte att behandla förfrågningar, även om det kommer alldeles för många av dem – alltså mycket fler än det borde – vilket leder till att servern överbelastas och går ner. Den här typen av överdriven ström av förfrågningar uppstår när någon försöker utföra en DDoS-attack mot dina servrar.
Överdriven dataexponering: Det här inträffar när dina API-svar innehåller information som du egentligen inte vill att andra ska få tillgång till. När du till exempel skickar pengar till någon via internetbanken kan API-aviseringen om att transaktionen lyckades även innehålla mottagarens kontosaldo, vilket definitivt är något du inte ska kunna se.
Lösningarna på dessa tre sårbarheter är ganska uppenbara. Kräv autentisering när känsliga data tillhandahålls, lägg till hastighetsbegränsning och se till att du inte tillhandahåller data som inte ska finnas där.
Om du vill fördjupa dig lite mer i API-säkerhet kan du läsa Neil Maddens bok om ämnet.
4. Brist på kryptering
Min säkerhetschef älskar att ständigt upprepa att en väl genomförd cybersäkerhetsstrategi för en produkt ser ut som en lök – den består av flera säkerhetslager över olika delar av produkten.
Allt vi har diskuterat hittills har handlat om säkerhetsrisker i det yttersta lagret, när användaren inte kan komma åt dina servrar eller databaser och försöker attackera ”från ytan”.
Om en hackare däremot på något sätt får full åtkomst till dina servrar (tränger igenom det första lagret) bör du fortfarande ha åtgärder på plats för att skydda dina databaser från obehörig åtkomst – och även hålla dina inre lager säkra.
Ett av de bästa sätten att skydda dina data i det här fallet är att kryptera dem. Det innebär att även om någon får åtkomst till dina databaser och laddar ner dessa data, kommer de bara att se en obegriplig massa eftersom informationen är krypterad.
Endast företaget eller användaren – de två parter som har krypteringsnyckeln – skulle kunna dekryptera denna obegripliga massa till användbar information. Tyvärr är det dock mycket vanligt att man glömmer att kryptera data på servrar, vilket har lett till många omfattande dataläckor.
Jag har personligen sett alldeles för många webbplatser och produkter som har tagit risken genom att lagra användarnas lösenord i klartext – något som anses vara en dödssynd inom programvara. Bästa praxis i det här fallet är att köra lösenordet genom en hashfunktion, få fram en krypterad version av det (kallad en hash) och lagra den i stället.
Det fina med detta är att både användaren och företaget har nyckeln som krävs för att återställa hashvärdet till klartext och använda lösenordet för autentisering. Men om en hackare får åtkomst till databasen och laddar ner hashvärdet skulle det ta miljontals år av beräkningar att omvandla det tillbaka till det ursprungliga lösenordet utan nyckeln. (Jag skämtar inte, det är den verkliga siffran!)
Kryptering är ytterligare ett fascinerande område inom cybersäkerhet som jag rekommenderar att du utforskar. Du kan särskilt börja med att lära dig hur kryptografi med offentlig nyckel fungerar, eftersom det är det som hela internet bygger på i dag.
Integrera applikationssäkerhet i produkt- och programvaruutvecklingens livscykel
Med alla dessa sårbarheter och all bästa praxis i åtanke kan vi fokusera på en uppenbar fråga som du kanske har – hur håller jag mina produkter säkra som produktchef?
Jag trodde aldrig att du skulle fråga! Här är två viktiga bästa metoder för säkerhet som kan hjälpa dig med det:
Säkra produkter genom design
Det här är en metod för utvecklingsprocessen som innebär att du bör ha säkerhetskraven i åtanke redan från det ögonblick då du börjar bygga dina produkter, så att säkerhetsåtgärder integreras naturligt i koden och arkitekturen i stället för att läggas till senare i SDLC.
Det senare är vanligtvis mycket dyrare och ger inte samma skyddsnivå som programvara som är säker ”naturligt”.
Som produktchef är det därför ditt ansvar att be utvecklingsteamet att följa denna metod och avstå från att nedprioritera sådant som bidrar till att bygga in säkerhet i produkten.
More Articles
Regelbundna säkerhetsrevisioner
De flesta produkter som jag har ansvarat för har genomgått regelbundna säkerhetstester (vanligtvis en gång var sjätte månad till en gång om året). Vi testade hela säkerhetsläget, och det omfattade:
- Penetrationstestning
- Hotmodellering
- Granskning av säkerhetskontroller
- Granskning av säkerhetsstrategi och säkerhetsfunktioner
- Granskning av leveranskedja och automatiserade arbetsflöden
- Kodanalys (inklusive öppen källkod som vi använde och koden som erhållits från partnerskap med tredje part)
- Skapande av säkerhetsfärdplan och mätvärden
- Riskbedömning
- ...och mer!
Det här är viktigt eftersom din produkt ständigt utvecklas, och du kan råka äventyra programvarans säkerhet när du lägger till något nytt. Regelbundna granskningar identifierar snabbt dessa problem och låter dig åtgärda och validera dem – innan en angripare hittar dem först.
Som produktchef är ditt jobb att avsätta tid för och prioritera dessa granskningar samt den kodstädning som följer.
Lita på ditt säkerhetsteam
Oavsett vilken funktion du planerar att bygga och vilken handlingsplan du har för att nå dina tillväxtmål, se alltid till att du har stämt av dina idéer med säkerhetsteamet.
Och lyssna – det kan verka som att säkerhetsteamet vill att du ska ”överbeskydda” din produkt. Men för det mesta bör du överväga att ändra din idé om de inte gillar den. Annars är risken helt enkelt inte värd att ta.
På tal om att överväga saker bör du också överväga att prenumerera på vårt nyhetsbrev för att få mängder av guider och artiklar om produktledning direkt i din inkorg!
