Designe on Sikkerhet.bouvet.no - For Security Champions i Bouvet

Sikkerhetskrav

Mon, 01 Jan 0001 00:00:00 +0000

Noen krav er implisitte, som eksempelvis bruk av HTTPS/TLS, mens andre vil være eksplisitte og definert av lovverk, kunde eller tredjepart. Dersom kunden ikke har noen spesifikke krav er det likevel viktig at leveranseteamet lager en kravliste slik at rammene for prosjektet er dokumentert.

De fleste prosjekter må forholde seg til ulike krav fra Bouvet, kunden og eksterne parter. Alle utviklingsteam må ha kontroll på hvilke krav som stilles til leveransen:

Nettverkskonsepter

Mon, 01 Jan 0001 00:00:00 +0000

Riktig nettverkskonfigurasjon er viktig i sky, hybrid og on-prem. Denne siden er ment som et kort oppslag for sikker nettverkspraksis i prosjektarbeid.

Zero trust arkitektur

Zero trust innebærer at man ikke stoler blindt på intern eller ekstern trafikk. Bruk prinsippet som standard: verifiser eksplisitt, gi minst mulig tilgang, og anta kompromittering.

Minimumsoversikt

Viktig

Ha kontroll på hvilke IP-adresser og porter du eksponerer, og hvilke tjenester som lytter på portene. Undersøk brannmurregler, se i logger og skann egne systemer med nmap.

Segregering av miljø

Mon, 01 Jan 0001 00:00:00 +0000

Når vi bygger løsninger setter vi ofte opp flere miljø, ofte for dev, test og prod slik at vi kan utvikle samtidig som at produkteier tester ny funksjonalitet og sluttbrukere bruker systemet i prod. Det er viktig at vi skiller mellom disse miljøene, slik at vi unngår å komme i situasjoner der endringer i ett miljø påvirker bruken av et annet.

Separate kontoer/abonnement/prosjekter per miljø gir et naturlig sikkerhetsskille fordi miljøene er isolert fra hverandre med mindre du eksplisitt oppretter tilganger mellom dem. Dette medfører noe mer overhead i administrasjon, men gir til gjengjeld sterkere isolasjon enn de andre mønstrene. For de fleste prosjekter av en viss størrelse, eller der det stilles krav til sikkerhet, er dette det anbefalte utgangspunktet. Selv i mindre prosjekter er det verdt å vurdere — kostnaden ved å separere tidlig er langt lavere enn å migrere senere når behovet oppstår.

Autentisering og autorisering

Mon, 01 Jan 0001 00:00:00 +0000

Autentisering og autorisering er viktig i alle utviklingsprosjekter. Kort fortalt går autentisering ut på at en skal validere at en bruker representerer den identiteten den hevder å representere, typisk gjennom å sjekke brukernavn og tilhørende passord. Autorisering går ut på å sjekke at brukeren har lov til å gjøre det den prøver på. Disse er ofte forkortet til authn for autentisering og authz for autorisering.

Autentisering

Når en skal validere en bruker, er det viktigste at en ikke lager en egen autentiseringsløsning! Å sikre at slike løsninger faktisk er sikre er en kjempejobb, og man bør istedet benytte seg av etablerte løsninger for dette!

Trusselmodellering

Mon, 01 Jan 0001 00:00:00 +0000

Dette er en kort introduksjon til trusselmodellering. Metoder og verktøy nevnes kort, med lenker for fordypning.

Du har nok allerede gjort en enkel trusselmodellering uten at du selv er klar over det. Har du for eksempel tenkt på hvorfor brukerne av systemet du lager må logge seg inn med brukernavn og passord?

Når disse valgene ble tatt så har du automatisk gjort en enkel trusselmodellering. Du ønsker jo selvfølgelig ikke at uvedkommende skal kunne få tilgang til data i systemet ditt og du ønsker ikke at hvem som helst skal se data som overføres mellom brukerne dine og nettstedet ditt.

Systemskisser

Mon, 01 Jan 0001 00:00:00 +0000

Når vi designer en løsning, er det viktig med gode og oversiktlige skisser og diagrammer som viser designet slik at det planlagt. Dette gjøres allerede av mange utviklerteam uten at det nødvendigvis stilles krav til det, men det er likevel greit å nevne her.

Systemskissene bør gi nok informasjon til at en i etterkant kan

Validere at implementasjonen er som designet
Bruke dem ifm trusselmodellering, pentesting eller liknende
Brukes av den/de som forvalter løsningen for å få en god oversikt over komponenter og dataflyt
Brukes av leveranseteamet for onboarding av nye kollegaer eller handover til andre team.

Selv om det er mye som kan dokumenteres her, fokuserer vi bare på det viktigste her: