Lesetips: Secure by design av Daniel Deogun, Dan Bergh Johnsson, Daniel Sawano

Hvis det han sier treffer noe hos deg, som det gjorde hos meg, så ville jeg gitt denne boken en sjanse. Har du noen gang tenkt "Denne `int customerId` er ikke egentlig en int"? Du kan ikke ta to `customerId`er, plusse de sammen, og få en ny gyldig `customerId`. Denne tanken, for meg, er basisen for denne boken. 

Du kan se foredraget her (på engelsk)

Ikke innertier

Boken går akkurat nok i dybden på konsepter og ideer, og gir eksempler som belyser det de vil si, uten å gå for mye i detalj. Den er tidvis ganske verbos, og jeg merket at jeg skummet eller hoppet over deler, og jeg måtte tvinge meg selv til å hoppe tilbake og lese det likevel. 

Den gir et inntrykk av at forfatterne hadde flere forskjellige ting de hadde lyst til å si, og som de har prøvd å sy sammen med felles idéer og konsepter, men som godt kunne blitt holdt separate. 

Sikkerhet, design eller begge deler?

Forfatternes syn på sikkerhet er bredere enn mitt. Det de kaller sikkerhet, er det jeg kaller "et fungerende system". Mange av tankene deres kan like godt forklares med "for å unngå feil, så burde du gjøre disse tingene, eller tenke på disse problemene". "Sikkerhets"-delen av boken er overskygget av "Design"-delen, og jeg tenker at de bruker sikkerhet som en ramme rundt tankene sine, siden dette blir mer en design-bok enn en sikkerhetsbok. 

For å sitere boken: 
"The goal of this book, and the reason its content has never been more urgent or relevant, is to demonstrate that security is first and foremost a design consideration.” 

I den første delen av boken, lener de seg på Domain-Driven Design (DDD) for å forklare tanker og ideer, og de gir konsepter du kan bruke når du skal designe et nytt system, eller redesigne et gammelt et, i en sikkerhets-ramme. 
De beskriver hvordan du skal designe systemer ved å sette deg ned, og identifisere hvilke konsepter og relasjoner som fins i domenet ditt, og hvor disse relasjonene brytes. Dette skjer ofte i grensen mellom forskjellige systemer, og det er ofte her feil, eller "sikkerhetsproblemer" oppstår. 

Relaterbar

Jeg kjenner igjen disse problemene gjennom egen erfaring, hvor jeg har integrert to systemer, som håndterte det samme domenet, men brukte forskjellige navn og relasjoner. Ene systemet hadde en `Sensor` med et `EAN`-felt, mens det andre hadde en `Måler` med en `Id`. Disse to tingene var akkurat det samme, men var utviklet separat. På den andre siden, så hadde disse to systemene begge en `Customer`, med en `Id`. Men disse to var ikke det samme. Det var ikke mulig å ta en `CustomerId` fra ene systemet, og bruke i det andre. Hvis disse to systemene hadde vært designet sammen fra starten av, hadde det vært enklere å gjøre integreringen, og det ville vært lettere å la folk jobbe på begge systemene, siden de ville brukt det samme språket og vokabularet. Entiteter som har forskjellige navn, men er det samme, og entiteter som har samme navnet, men er forskjellige, er eksempler på design, som denne boken tar for seg. 

Disse sakene er brorparten av boken, og det som ga meg mest. Det betyr ikke at de andre delene av boken var verdiløse. Alt i alt er innholdet av god kvalitet. Men resten av boken føles som om det er en annen bok, med overskrifter som "Leveraging your delivery pipeline for security", "Handling failures securely", og "Benefits of cloud thinking". Og de er alle gode poenger, men kunne godt vært i en egen bok. 

Jeg tenker, at hvis alle medlemmene av et prosjekt eller produkt leste denne boken, så ville vi fått bedre løsninger. Du trenger ikke være enig i alt de foreslår, men det gir en god basis for diskusjon, og noen ting blir kanskje sittende bak i hodet ditt når du skal designe et system. Hvis du ikke er overbegeistret av sikkerhet-biten, les boken med den tanken at du vil unngå feil, nedetid, og måtte stå opp klokken 4 på natten for å svare på telefoner fra 24/7-supporten din. 

Ta kontakt med oss! 

Er det noe du lurer på kan du legge igjen kontaktinformasjon så tar vi kontakt med deg.

Forfatter