Du kan inte säkra det du inte förstår

IT-branschen behöver ta ett större ansvar för motståndskraftiga system. Det finns många ramverk som hjälper dig bygga väl skyddade digitala lösningar. Utmaningen ligger i att förstå system, organisationer och plattformar samt hålla dem säkra vid förändrad funktionalitet och hotbild. Detta är väl formulerat i den nu 25 år gamla bloggposten A Plea for Simplicity

You can’t secure what you don’t understand” — Bruce Schneier, 19991 

För att lyckas med en säker digital transformation är här tre resurser som vi använder i vårt dagliga arbete, som hjälper oss att förstå våra system och bygga säkra lösningar:

Secure by design av Dan Bergh Johnsson, Daniel Deogun och Daniel Sawano 
OWASP ASVS och TOP 10 listor 
CIS Critical Security Controls och Benchmarks 

Genom att utgå ifrån ovan nämnda resurser kan vi överbrygga glappet från generella ramverk, regulatoriska krav och vägledande säkerhetsprinciper så som Zero trust och Least Privilege, till konkret implementation, anpassad till din verksamhet och hotbild. 

När vi bygger system med utgångspunkt från väletablerade säkerhetsprinciper, industristandarder och mönster så är regelefterlevnad (Compliance) en biprodukt. Compliance-krav från tex NIS2, DORA, GDPR etc är såklart viktiga, men generellt sett bör utvecklings- och driftsorganisationer fokusera på att tillhandahålla säkra system, inte att uppfylla ett minimalt antal krav för att bli ”compliant”. 

Secure by design

För starka lösningar över tid krävs försvar på djupet, säkerhet i flera lager där vi implementerar designmönster som minimerar attackvektorer och risker.  Ett exempel är Rotate, Repave and Repair, där vi designar våra system så att det är lätt att: 

Gör vi detta ofta har vi gjort det betydligt svårare för en angripare att etablera fotfäste i systemet, samt att vi har förutsättningar för att snabbt återhämta oss från exempelvis en Ransomwareattack. 

Boken Secure by design ger oss många verktyg, designmönster och en förståelse för hur vi bygger högkvalitativa säkra applikationer. Utan en säker applikationskärna, med väldefinierad och korrekt domänlogik, kommer din lösning aldrig vara riktigt stark. 

Läs mer:  

OWASP 

Vi behöver även förstå attackperspektivet och OWASP ger en bra start då det riktar sig till de som bidrar till säkra applikationer, tex utvecklare och testare. Många av de säkerhetshål vi hittar under penetrationstester kan kopplas till OWASP material och finns där på grund av att man missat verifiera krav, exempelvis ”Som användare skall jag nå mitt eget data, INTE andra användares data”. 

Trots att många organisationer ser det som en allvarlig risk att läcka data mellan användare är det många som saknar testfall för den andra delen av kravformuleringen ovan. Den första delen täcks i regel av funktionella testfall medan säkerhet är ett av alla icke-funktionella krav.  Det låter enkelt, men i stora komplexa system är det svårt att över tid göra rätt på alla ingångar där korrekt behörighetskontroll är ett krav. 

Läs mer:

CIS Critical Security Controls och Benchmarks 

Både Secure by design och OWASP utgår från hur vi bygger applikationer, men säkerhet är ett brett område. Vi behöver något som håller ihop helheten, som också adresserar attackvektorer kring bland annat nätverksinfrastruktur och hur vi hanterar behörigheter. 

Det finns många ramverk, CIS Critical Security Controls2 ger oss något vi kan verifiera och bygga en komplett Security baseline på. Vi använder ofta CIS Controls då det är ett väletablerat ramverk som refereras av bland annat svenska myndigheter3, kan kopplas till tex ISO 27001 och till tekniskt detaljerade riktlinjer för implementation genom CIS Benchmarks4.

Som alla ramverk behöver CIS Controls tolkas för din typ av verksamhet, vi på Omegapoint har gjort detta för ”cloud-native” applikationer och är något vi tillämpar när vi gör säkerhetsgranskningar.

Läs mer:

Sammanfattning

Med resurserna ovan som bas kan vi implementera säkra digitala lösningar. Betyder det att vi alltid ska göra allt? Givetvis inte. Investering i säkerhet behöver alltid vara proportionerlig till din verksamhet och hotmodell. Hotmodellering kan göras på olika nivåer, för organisationen som helhet, övergripande på en arkitekturell nivå eller tekniskt detaljerat för specifika system. Samtliga nivåer behövs för en komplett förståelse. Baserat på vår erfarenhet är detta avgörande för säkra system och viktigt att göra kontinuerligt, tillsammans med olika typer av penetrationstester. Du kan inte säkra det du inte förstår!

  1. https://www.schneier.com/essays/archives/1999/11/a_plea_for_simplicit.html ↩︎
  2. https://www.cisecurity.org/controls ↩︎
  3. www.ncsc.se/publikationer/ ↩︎
  4. https://www.cisecurity.org/cis-benchmarks ↩︎