Den viktigste datasikkerhetsveiledningen for produktledere

Har du hørt om Code Spaces? Det var et kildekodelager som lignet på Github.

Vel, du har sannsynligvis aldri hørt om dem fordi de, til tross for at de var et lovende produkt, forsvant nesten umiddelbart i juni 2014 etter et omfattende sikkerhetsbrudd. Bruddet førte til at de mistet alle kundedataene sine, noe som tvang dem til å innstille virksomheten.

Etter denne hendelsen lærte alle i den digitale verden, inkludert produktledere, en lekse som aldri bør glemmes—PRODUKTER MÅ VÆRE SIKRE.

I denne veiledningen vil jeg introdusere deg for produktsikkerhet og hjelpe deg med å ha sikkerhet i tankene når du administrerer produktene dine.

Hvorfor produktledere bør bry seg om datasikkerhet

I teorien bør den daglige produktledelsen din bare fokusere på brukerlojalitet, brukerintervjuer og andre ikke-tekniske ting uten å bekymre seg for sikkerhet.

Vi lever imidlertid i en verden med ondsinnede personer som mer enn gjerne vil stjele dataene dine (for å selge dem et annet sted senere), kryptere dem, kreve løsepenger for dem (såkalt løsepengevirus), eller ganske enkelt gjøre skade bare for å gjøre skade.

Så i tillegg til aktivering og brukerlojalitet bør du også bry deg om den enorme forretningsrisikoen som slapp sikkerhet kan utgjøre for produktet ditt. Et alvorlig nok sikkerhetsbrudd vil skade omdømmet ditt så mye at alle årene med hardt arbeid fra markedsførings-, produktutviklings- og salgsteamene dine kan forsvinne på én dag.

Du vil dessuten ende opp med å møte rettslige skritt fra partnerne og kundene dine hvis data du ikke klarte å beskytte.

Etter min mening er det derfor svært viktig at produktledere er «sikkerhetsbevisste» når de bygger og videreutvikler produktene sine.

De 4 vanligste sikkerhetshullene i produktutvikling

Som produktleder trenger du egentlig ikke å ha inngående kunnskap om de nyeste hackingmetodene og hvordan du beskytter deg mot dem. Dette er noe sikkerhets- og ingeniørteamene dine skal implementere og håndtere.

Du trenger imidlertid en grunnleggende teknisk forståelse av hvordan noen av de vanligste sikkerhetsproblemene fungerer, og hvordan hackere kan utnytte dem. Dette vil gjøre beslutningsprosessen din mer «sikkerhetsbevisst».

La oss se nærmere på fire slike sikkerhetshull sammen og forstå hva de handler om.

1. SQL-injeksjon

Da jeg var en ung produktleder, bestemte jeg meg for å lære litt programmering og laget noe lite (og forferdelig) PHP-kode som fungerte som baksystem for et kontaktskjema på et nettsted. Den tok imot en melding, lagret den i databasen og satte sammen en e-post adressert til meg med innholdet.

Da jeg viste dette til en utviklervenn av meg, spurte han meg, i tillegg til å knapt klare å holde tilbake latteren (koden min var rett og slett utrolig dårlig), om jeg hadde renset inndataene mine. Som du sikkert forstår, hadde jeg ingen anelse om hva han mente, og han forklarte meg at databasene mine var utsatt for SQL-injeksjon fordi inndataene ikke var renset.

SQL-injeksjon er prosessen der hackeren skriver spesiell SQL-kode i stedet for tekst i inndatafeltene dine, og ender opp med å kjøre denne koden i baksystemet ditt for å få uautorisert tilgang til produktet ditt eller stjele informasjon fra databasene dine.

Se for deg at LinkedIn brukte denne SQL-spørringen til å kontrollere passordet ditt ved innlogging (ansvarsfraskrivelse: de gjør definitivt noe smartere enn SQL-en her).

Hvis inndatafeltene på innloggingssiden teoretisk sett ikke var renset, kunne du skrive ' OR '1'='1 i feltene for brukernavn og passord og trykke på Logg inn.

I dette tilfellet ville baksystemet legge til ' OR '1'='1 i SQL-spørringen, som ville blitt noe slikt.

Denne spørringen vil returnere verdien «true». Det betyr at du ville kunne logge inn på LinkedIn uten et faktisk brukernavn og passord.

Som jeg allerede har nevnt, kan du unngå dette problemet ved å rense inndataene dine. Rensing betyr i denne sammenhengen å sørge for at alt du skriver i inndatafeltene, behandles som vanlig tekst, selv om du skriver kode eller en SQL-spørring.

Med rensede inndata vil LinkedIn forsøke å søke etter en bruker med navnet ' OR '1'='1 i databasen i stedet for å kjøre koden. Til slutt vil søket ikke finne brukeren, og du vil få en feilmelding om at det ikke finnes noen slik person på LinkedIn.

Merk

\u003cem\u003eSelvfølgelig er eksempelet ovenfor en forenkling, og cyberangrep i virkeligheten er langt mer komplekse. Men hvis du vil gå i dybden og lære mer om disse angrepene, anbefaler jeg at du sjekker ut \/em\u003e\u003cem\u003eJustin Clarke-Salts bok, \u003cspan id=\u0022productTitle\u0022 class=\u0022a-size-extra-large celwidget\u0022 data-csa-c-id=\u002269phoe-og0sux-uj9uww-o5c3sv\u0022\u003e\u003ca href=\u0022https://www.amazon.com/Injection-Attacks-Defense-Justin-Clarke/dp/1597499633\u0022\u003eSQL-injeksjonsangrep og forsvar\u003c/a\u003e.\u003c/span\u003e\u003c/em\u003e

Å beskytte seg mot SQL-injeksjoner er et av de grunnleggende tiltakene du kan gjøre for å holde kundenes data sikre og unngå skadelige datalekkasjer og uautorisert tilgang.

2. Skripting på tvers av nettsteder (XSS)

XSS er en annen vanlig måte hackere kan manipulere produktet ditt og utføre ondsinnede handlinger på. For å illustrere hvor vanlig XSS er, anslår en rapport fra Positive Technologies at rundt 90 % av alle nettapper der ute er sårbare for denne typen angrep.

Så hva går det ut på? XSS ligner litt på SQL-injeksjon ved at hackere manipulerer systemet ditt til å kjøre kode som det ikke skulle kjøre. I dette tilfellet befinner imidlertid den ondsinnede koden seg ikke i serverdatabasene i systemet ditt, men i klientdelen.

Et av de morsomme og ufarlige eksemplene på XSS er Twitters (ja, jeg kaller det fortsatt Twitter – prøv å overbevise meg om noe annet) hjerte-emoji som retvitret seg selv. Det er morsomt fordi ingen forventet at Twitter skulle gjøre en så massiv feil, og det er ufarlig fordi alt den gjorde, var å retvitre seg selv.

Dette angrepet var bare en enkel tweet som inneholdt følgende tekst.

Som det fremgår av bildet, er dette ikke enkel tekst, men et stykke kode (Javascript med jQuery, for å være presis) med en hjerte-emoji på slutten.

Før Twitter rettet denne sikkerhetsfeilen, ville nettlesermotoren gjenkjenne innholdet i tweeten som gyldig kode hvis du åpnet den i nettleseren, skjule det for brukeren og kjøre det. I stedet for de to kodelinjene ville du derfor bare se en tweet med en hjerte-emoji.

Da koden ble kjørt, navigerte den gjennom HTML-en på siden, fant automatisk retvitreknappen på skjermen din og klikket på den.

Det innebar at alle som så denne tweeten, automatisk retvitret den – noe som førte til at en stor andel av Twitters brukere ble infisert av den.

Tenk deg nå om det ikke var en selvreplikerende tweet, men noe mer skadelig, for eksempel et skript som hentet konfidensiell informasjon fra skjermen din og sendte den til hackeren. Alternativt kunne ondsinnet kode i nettleseren ta over nettbanken din og begynne å overføre penger fra kontoen din.

Du skjønner poenget mitt – XSS er fortsatt ekstremt farlig, selv om det ikke kan få tilgang til serverne og databasene dine.

Men hva har dette med deg som produktleder å gjøre? Jo, du kan ende opp med å be ingeniørene dine om å lage smarte funksjoner og integrasjoner, for eksempel å gjøre det mulig for nettstedet ditt å se innholdet i andre faner i brukerens nettleser og gjøre noe interessant med denne informasjonen.

Hvis du gjør det og teamet ditt nekter å bygge en slik funksjon, må du ikke bli forvirret eller lei deg, for det du ber om, er i praksis et XSS-angrep på andre nettsteder.

XSS er et fascinerende område innen cybersikkerhet, og det finnes mange gode bøker om emnet som jeg kan anbefale. Min favoritt er XSS-angrep av Seth Fogie.

3. Usikre API-er

Programmeringsgrensesnitt (også kalt API-er) er kommunikasjonsmiddelet mellom serveren din og brukernes nettleser eller applikasjonen på mobilenheten eller datamaskinen deres.

Når det er behov for å hente, lagre eller behandle data på serveren din, sender nettleseren eller appen (også kalt «klientene») en forespørsel til serveren med nødvendig informasjon. Deretter utfører serveren arbeidet og sender tilbake svaret.

Ved innlogging sender klientene for eksempel brukernavnet og passordet ditt og ber serveren autentisere deg. Så snart serveren har fullført forespørselen, sender den tilbake en «suksess»-melding sammen med sideinnholdet brukeren skal se når innloggingen er fullført.

Ettersom API-er arbeider med brukerdata, er de også utsatt for sikkerhetssårbarheter som kan føre til ondsinnet manipulering av data (f.eks. at serveren blir bedt om å gjennomføre en pengeoverføring i brukerens navn) eller datainnbrudd (f.eks. at serveren blir bedt om å avsløre brukerens medisinske journaler).

De vanligste typene API-sårbarheter er:

Ingen autentisering: I dette tilfellet krever ikke API-et at klienten bekrefter identiteten sin før det gir tilgang til konfidensiell informasjon. For å forstå hvordan dette fungerer, kan du se for deg at noen gikk til banken og ba om å ta ut penger fra Mark Zuckerberks konto, og kassereren bare svarte: «Klart det, hvor mye?»

Ingen begrensning av forespørsler: Her vil API-er ikke slutte å behandle forespørsler, selv om det kommer altfor mange av dem – altså langt flere enn det skulle ha gjort – noe som fører til at serveren overbelastes og går ned. Denne typen overdreven strøm av forespørsler oppstår når noen forsøker å utføre et DDoS-angrep mot serverne dine.

Overdreven dataeksponering: Dette skjer når API-svarene dine inneholder informasjon som du egentlig ikke ønsker at folk skal få tilgang til. Hvis du for eksempel sender penger til noen via nettbank, og API-varslingen om at transaksjonen var vellykket også inneholder mottakerens kontosaldo, er dette noe du absolutt ikke skal kunne se.

Løsningene på disse tre sårbarhetene er ganske åpenbare. Be om autentisering når du leverer sensitive data, legg til begrensning av forespørsler, og sørg for at du ikke leverer data som ikke skal være der.

Hvis du vil utforske API-sikkerhet litt nærmere, kan du ta en titt på Neil Maddens bok om emnet.

4. Manglende kryptering

Sikkerhetssjefen min elsker å gjenta at en godt gjennomført cybersikkerhetsstrategi for et produkt ser ut som en løk – den består av flere sikkerhetslag over ulike deler av produktet.

Alt vi har diskutert så langt, har vært sikkerhetsrisikoer på overflatelaget, når brukeren ikke kan få tilgang til serverne eller databasene dine og forsøker å angripe «fra overflaten».

Hvis en hacker imidlertid på en eller annen måte ender opp med full tilgang til serverne dine (bryter gjennom det første laget), bør du fortsatt ha tiltak på plass for å beskytte databasene dine mot uautorisert tilgang – og dermed også holde de indre lagene dine sikre.

En av de beste måtene å beskytte dataene dine på i dette tilfellet er å kryptere dem. Det betyr at selv om noen får tilgang til databasene dine og laster ned disse dataene, vil de bare være en mengde uforståelig tekst for vedkommende fordi de er kryptert.

Bare selskapet eller brukeren – de to partene som har krypteringsnøkkelen – vil kunne dekryptere denne uforståelige teksten til nyttig informasjon. Dessverre er det imidlertid svært vanlig å glemme å kryptere dataene på servere, og dette har ført til en rekke massive datalekkasjer.

Jeg har personlig sett altfor mange nettsteder og produkter som har tatt sjansen ved å lagre brukernes passord i klartekst – noe som regnes som en dødssynd innen programvare. Beste praksis i dette tilfellet er å kjøre passordet gjennom en hash-algoritme, få en kryptert versjon av det (kalt en hash), og lagre denne i stedet.

Det fine med dette er at både brukeren og selskapet har nøkkelen som kan gjøre hashen om til klartekst igjen og bruke passordet til autentisering. Men hvis en hacker får tilgang til databasen og laster ned hashen, vil det ta millioner av år med beregninger å gjøre den om til det opprinnelige passordet uten nøkkelen. (Jeg tuller ikke, det er det faktiske tallet!)

Kryptering er et annet fascinerende område innen cybersikkerhet som jeg anbefaler at du utforsker. Du kan særlig begynne med å lære hvordan kryptografi med offentlig nøkkel fungerer, siden det er dette hele internett bygger på nå.

Integrering av applikasjonssikkerhet i produkt- og programvareutviklingens livssyklus

Med alle disse sårbarhetene og beste praksisene i tankene, la oss fokusere på et åpenbart spørsmål du kanskje har – hvordan holder jeg produktene mine sikre som produktsjef?

Jeg trodde aldri du kom til å spørre! Her er to viktige beste praksiser for sikkerhet som kan hjelpe deg med dette:

Sikre produkter gjennom design

Dette er en tilnærming til utviklingsprosessen som sier at du bør ta hensyn til sikkerhetskrav fra det øyeblikket du begynner å bygge produktene dine, slik at sikkerhetstiltak integreres naturlig i koden og arkitekturen i stedet for å bli lagt til senere i SDLC.

Sistnevnte er vanligvis mye dyrere og gir ikke samme beskyttelsesnivå som programvare som er sikker «fra grunnen av».

Som produktsjef er det derfor ditt ansvar å be utviklingsteamet om å følge denne tilnærmingen og la være å nedprioritere oppgaver som bidrar til å bygge sikkerhet inn i produktet.

Regelmessige sikkerhetsrevisjoner

De fleste produktene jeg har ledet, gjennomgikk regelmessig sikkerhetstesting (vanligvis én gang hver sjette måned til ett år). Vi testet hele sikkerhetsnivået, og det omfattet:

• Penetrasjonstesting
• Trusselmodellering
• Gjennomgang av sikkerhetskontroller
• Gjennomgang av sikkerhetsstrategi og sikkerhetsfunksjoner
• Gjennomgang av leverandørkjede og automatiserte arbeidsflyter
• Kodeanalyse (inkludert åpen kildekode vi brukte og kode anskaffet gjennom partnerskap med tredjeparter)
• Utarbeidelse av sikkerhetsveikart og måltall
• Risikovurdering
• ...og mer!

Dette er viktig fordi produktet ditt stadig er i utvikling, og du kan komme til å svekke programvaresikkerheten ved et uhell når du legger til noe nytt. Regelmessige revisjoner vil raskt identifisere disse problemene og gjøre det mulig for deg å løse og validere dem—før en ondsinnet aktør finner dem først.

Som produktleder er det din oppgave å sette av tid til og prioritere disse revisjonene og kodeoppryddingen som følger.

Stol på sikkerhetsfolkene dine

Uansett hvilken funksjon du planlegger å bygge, og uansett hvilken handlingsplan du har for å nå vekstmålene dine, må du alltid sørge for at du har drøftet ideene dine med sikkerhetsteamet ditt.

Og lytt—det kan virke som om sikkerhetsfolkene ønsker å «sikre produktet for mye». Men som oftest bør du vurdere å gjøre endringer hvis de ikke liker ideen din. Ellers er det rett og slett ikke verdt risikoen.

Og når vi først snakker om å vurdere ting, bør du også vurdere å abonnere på nyhetsbrevet vårt for å få mange veiledninger og artikler om produktledelse rett i innboksen din!