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

Verifiser designet

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

Når vi lager et design for en ny løsning hender det at det er detaljer vi ikke kjenner, eller at det oppstår uventede komplikasjoner underveis i implementeringen. Dette kan resultere i at designet vi opprinnelig laget avviker fra den ferdige løsningen.

Dokumentasjonen er viktig for å forstå hvordan en løsning er satt opp og hvordan den fungerer, spesielt om det oppstår en hendelse som krever redeployment eller disaster recovery. For å sikre at gapet mellom dokumentasjon og ferdig produkt ikke er for stort bør vi derfor alltid validere designet i etterkant.

Logging og monitorering

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

Uavhengig av hvor en løsning deployeres bør vi sikre at den monitoreres. Selv om den eksempelvis kun skal være tilgjengelig på intranettet der det kun finnes interne brukere som jobber fra godkjente enheter over vpn, er det viktig med logging av informasjon dersom en av disse kompromitteres. Et typisk DevOps-team vil samle inn en del informasjon for å hjelpe til med feilsøking av funksjonaliteten i applikasjonen, men vi trenger også en del annen informasjon for å kunne si noe om sikkerhetsbildet rundt den.

Forvaltning av avhengigheter

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

Når teamet er i forvaltningsmodus gjelder fremdeles de fleste problemstillingene nevnt i artikkelen om Forsyningskjedesikkerhet. Dere vil komme i situasjoner der

det oppdages en kritisk sårbarhet i en pakke dere bruker
pakker deprekeres og erstattes med noe nytt som ikke er direkte kompatibelt med det gamle
utviklere bak pakker slutter å vedlikeholde pakkene
ondsinnede aktører overtar en pakke og bruker den for å spre malware

….og helt sikkert andre varianter som resulterer i at dere må gjøre noe. For å sikre at pakker som treffer ett eller flere av punktene over tas tak i. Verktøy som Sonatype og andre gir muligheten til å overvåke ulike steg i livssyklusen, med mulighet til å varsle når sårbarheter eller andre hendelser som påvirker kvaliteten inntreffer.

Øv på gjenoppretting

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

En backup som ikke er testet er verdiløs. Det samme gjelder en disaster recovery-plan som aldri har blitt testet.

Hvis teamet har gjort grunnarbeidet godt, har dere en plan for gjenoppretting som beskriver hvordan infrastruktur, applikasjon og data gjenopprettes til normal drift.

Årsakene til gjenoppretting varierer: menneskelige feil, feil i leveranser, svikt hos leverandør, utilgjengelig infrastruktur eller ondsinnede hendelser. Målet er alltid det samme: redusere nedetid og datatap med forutsigbare prosesser.

Beredskapsplaner og hendelseshåndtering

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

Mange tenker på sikkerhetshendelser som målrettede angrep der noen “hacker” en løsning. Det kan stemme, men en hendelse kan også være teknisk svikt, menneskelige feil eller avvik i drift.

NSM definerer en sikkerhetshendelse som “En avvikssituasjon hvor det er et potensiale for tap av konfidensialitet, integritet, og/eller tilgjengelighet for informasjon eller IKT-tjenester. En sikkerhetshendelse kan oppstå som følge av et dataangrep, teknisk svikt, eller utilsiktede feilhandlinger.”

Med andre ord kan en hendelse være nesten hva som helst som påvirker konfidensialitet, integritet eller tilgjengelighet. Ulike kunder har ulike krav til når dere skal varsle, eskalere og rapportere, og til hvem.