Dette er flersidevisningen av denne seksjonen. Klikk her for å skrive ut.
Når løsningen er designet, utviklet og deployet starter en annen jobb som for mange kanskje er litt fremmed: Forvaltning. Uavhengig av hvor mye utvikling som skjer, har vi likevel et ansvar for å forvalte det vi ruller ut i produksjon (eller til andre miljøer).
Disse må monitoreres, vi må sikre at vi har jevnlige backups _som også må testes_, at vi har oppdaterte planer for disaster recovery, følger opp sårbare avhengigheter og mye annet.
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.
Noe av det viktigste er alt rundt som ikke nødvendigvis kommer i kodeform. Hvilke ressurser vi bruker, nettverksoppsett og brannmuråpninger er grunnleggende, men vi bør også se på IAM og hvilke tilganger som er gitt til ressurser og applikasjon.
Når designet verifiseres i forvaltningsfasen, bør teamet som minimum sjekke:
Dersom det er elementer i designet som ikke er implementert bør disse fjernes fra dokumentasjonen. Dersom vi har implementert elementer som ikke er i designet må designet oppdateres, eller elementene fjernes fra løsningen.
For å gjøre verifisering etterprøvbar bør teamet bruke en enkel sporbarhetsmatrise:
Dette gjør det enklere å dokumentere at krav faktisk er realisert, og gir et tydelig grunnlag for revisjon, overlevering og hendelseshåndtering.
Eksempler på hvordan dette kan demonstreres kan være:
For løsninger med AI-komponenter må verifiseringen utvides utover klassisk infrastruktur og applikasjonsdesign.
Teamet bør verifisere:
Dette støtter kontrollområder som “AI system verification and validation” og “Documentation of AI system design and development”.
For AI-løsninger er det ikke nok å verifisere at tjenesten svarer. Teamet må også verifisere at modellens resultater fortsatt er innenfor aksepterte rammer.
Minimum bør være på plass:
Ved avvik må teamet dokumentere tiltak og eventuell risikovurdering før videre produksjonsbruk.
I praksis bør dokumentasjonen gjøre det mulig å svare på:
Sporbar dokumentasjon reduserer feilsøkingstid ved hendelser, og gjør re-verifisering enklere ved større endringer.
Se også:
Dette avhenger veldig av form og farge på prosjektet, men i mange tilfeller vil IT-organisasjonen hos kunden (for prosjekter hostet hos kunde) kunne hjelpe. Dersom løsningen kjører hos Bouvet vil helt sikkert Intern IT & Sikkerhet kunne være behjelpelige på å sjekke ting som nettverkskonfigurasjoner og liknende, eventuelt peke deg i riktig retning. Det er mye du kan gjøre selv også, men sjekk med Intern IT & Sikkerhet før du installerer verktøy og kjører scans eller liknende.
Et praktisk minimum er å gjennomføre verifisering:
Det er langt fra alle leveranser som blir revidert, men dersom kunde eller mottaker ber om revisjon må teamet kunne vise mer enn at løsningen fungerer. En revisjon handler ofte om å dokumentere at krav er forstått, at riktige kontroller er valgt, og at disse faktisk er implementert og fulgt opp.
En slik revisjon vil normalt være forankret i kontrakt, lovkrav eller interne styringskrav hos kunden. I praksis er det ofte mest aktuelt ved levering eller etter at løsningen har vært i drift en stund.
Kravene vil variere, men teamet bør som minimum kunne vise:
Dette betyr ikke nødvendigvis store dokumentpakker. Det viktige er at dokumentasjonen er oppdatert, etterprøvbar og tilgjengelig for de som faktisk trenger den.
Den enkleste måten å håndtere revisjon på er å være forberedt før kunden spør. Teamet bør derfor ha et bevisst forhold til hvor dokumentasjon ligger, hvem som eier den, og hvordan den holdes oppdatert.
Det er spesielt nyttig å ha avklart:
Revisjon blir fort tungvint dersom informasjonen finnes, men er spredt mellom ulike systemer, mapper og enkeltpersoner.
En revisjon vil ofte be om konkrete bevis, ikke bare beskrivelser. Det kan for eksempel være:
Hvis kunden har valgt bort anbefalte tiltak eller tilleggstjenester, må dette også være dokumentert tydelig. Det er viktig både for forventningsstyring og for å kunne forklare gjenværende risiko.
En revisjon betyr ikke at all dokumentasjon skal deles ukritisk. Noe materiale kan inneholde sensitiv informasjon om sårbarheter, interne nettverk, tilganger eller svakheter som ennå ikke er lukket.
Teamet bør derfor vurdere:
Målet er å være åpen nok til å dokumentere etterlevelse, uten å eksponere mer enn nødvendig.
For løsninger med AI-komponenter må teamet i tillegg kunne dokumentere:
Det vil også være naturlig å kunne forklare:
Se også:
En revisjon er ikke ferdig når møtet er over. Teamet må sikre at funn, avvik og anbefalinger blir vurdert og fulgt opp på samme måte som annet forbedringsarbeid.
Minimum bør være å:
Det viktigste er sjelden å produsere mer dokumentasjon. Det viktigste er å kunne svare tydelig på hva som er bygget, hvorfor det er bygget slik, og hvilken evidens som viser at kontrollene virker.
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.
Uavhengig av behov, husk at personvern gjelder for logger også! Ikke samle inn mer informasjon enn det du trenger, og husk på at logger må kunne slettes etter en gitt periode.
Målet med loggingen vil ha tre primære hensikter:
Hva vi logger vil variere veldig ut ifra hvem kunden er, risiko- og trusselbildet denne opererer i og hvilke behov de har for logginformasjon. I noen tilfeller vil kunden ha en egen sikkerhetsorganisasjon, typisk et Security Operations Center (SOC) som er ansvarlig for å monitorere nettverk og applikasjoner. Disse vil da ha krav til hva en logger og hvordan, men dersom dette ikke finnes må vi definere noen egne krav for å ha et utgangspunkt.
Under finner du noen punkter som bør være et absolutt minimum, men teamet må ha et forhold til hva som logges og hvorfor det logges, og hvordan denne informasjonen forholder seg til andre krav som eksempelvis personvern.
Dersom noen logger seg på løsningen, bør dette logges. Dette er spesielt viktig dersom det skjer fra et sted en bruker normalt ikke logger seg på, eller dersom det skjer med en annen nettleser eller klient enn det man vanligvis ser. Mislykkede pålogginger må også logges slik at det er mulig å agere på det.
Feil under validering av JWT eller andre session-relaterte feil bør også logges slik at dette kan gås opp i etterkant.
Hendelser der brukere forsøker å få tilgang til funksjonalitet de normalt ikke er autorisert for er viktige signaler som må fanges opp. Dette kan være så enkelt som at en bruker fanger opp eller får en URL fra en kollega som de tester ut selv, men det kan også være en angriper som forsøker å kartlegge eller teste en applikasjon. Uavhengig av årsak er det viktig informasjon som må tas vare på - dersom det senere oppstår en hendelse er det viktig å kunne si noe om bevegelsesmønstre og liknende i forkant av denne.
Dersom applikasjonen har støtte for elevering av, eller endring av tilganger er dette også typiske ting som må logges. Elevering er en mekanisme der en bruker gis ekstra tilganger, men der disse må “skrus på” før de er tilgjengenlige - gjerne da med et ekstra nivå med autentisering som MFA eller liknende. Eksempler på slike mekanismer er sudo i Linux eller Privileged Identity Management (PIM) i Azure. Når disse aktiveres er det viktig at loggene reflekterer dette ettersom feil eller svakheter i disse løsningene vil være kritiske for sikkerheten i applikasjonen.
Dersom det oppstår feil i applikasjonen bør dette også logges. Vi bør aldri gi brukeren mer informasjon enn absolutt nødvendig, men detaljene bør være med i loggene slik at det er mulig å monitorere eller se på dette i etterkant.
Dersom applikasjonen har et forhold til nettverk, eksempelvis gjennom at den monitorerer nettverksforbindelser, forbindelsen til andre ressurser eller liknende bør forstyrrelser eller utfall her også logges da det kan være viktige indikatorer.
Alle applikasjoner har inputs som kan beskrives, selv fritekstinput der brukeren kan legge inn hva som helst. Input som bryter valideringsregler eller tilfeller der en bruker forsøker å endre informasjon som normalt ikke skal kunne endres er typiske tilfeller som må logges.
Dersom applikasjonen støtter filopplasting eller liknende bør avvik fra forventede filer som eksempelvis avvik mellom filtype og filsignatur eller unormalt store eller små filer logges.
Logging og monitorering for KI‑løsninger bør designes som en løpende drifts- og styringsmekanisme som gjør det mulig å oppdage feil, avvik og sikkerhetshendelser, samt dokumentere at løsningen fortsatt fungerer som forutsatt i produksjon.
System‑ og ytelseslogger (f.eks. feilrater, responstid/latens, tilgjengelighet og tjenestekvalitet) bør samles ett sted, slik at det er mulig å konfigurere alarmer eller annen varsling ved uventede hendelser. Modell-/funksjonsytelse bør også overvåkes med tydelige måleparametere (f.eks. suksessrate på oppgaver, kvalitets-/konfidensmål der det er relevant), inkludert varsling ved uventet endring i adferd eller degradering over tid.
Loggene bør støtte prinsippene øverst i artikkelen, og bør inngå i prosessen for håndtering av oppdateringer og endringer i applikasjonen. Overvåkingen bør også dekke etterlevelse og kunde/andre krav, samt ha en etablert supportkanal slik at brukere kan rapportere feil, uventede resultater eller misbruk, og slik at organisasjonen kan vurdere om systemet brukes utenfor tiltenkt formål.
Hvordan vi logger vil også variere fra prosjekt til prosjekt, hvilken platform vi kjører på og hvilke ressurser vi har lov til å bruke. Et viktig moment vi må ha i bakhodet når vi designer loggeløsningen er at loggene er et angrepsmål! En angriper som kan utnytte sårbarheter og deretter manipulere loggene kan både skjule aktivitet og plante falske spor.
Alle loggene vi har bør lagres et sted der data kan legges til men ikke endres i etterkant. Fordelen med å bruke slike løsninger er at du kan samle logger fra mange ulike kilder som eksempelvis skyressurser, nettverkskomponenter og applikasjoner på ett sted. Dette kan gi deg innsikt i flere ulike dimensjoner når du ser på en hendelse som vil kunne være nyttig for å forstå helheten i det som skjer.
Å kunne fastslå rekkefølgen på hendelser er utrolig viktig. Vi må derfor forstå hva de ulike loggkildene bruker som basis for å synkronisere klokker internt for å vite sikkert at en hendelse som skjedde på node A henger sammen med en annen hendelse to sekunder etter på node B.
Det er også viktig å standardisere på loggformatene der dette er mulig. Mye logging er sentrert rundt selve loggmeldingen som typisk er tekstbasert, men alt av metadata rundt bør standardiseres der dette er mulig. Definer hva dere trenger å se, og sørg så for at dette er tilgjengelig fra de ulike kildene.
Når teamet er i forvaltningsmodus gjelder fremdeles de fleste problemstillingene nevnt i artikkelen om Software Supply Chain. Dere vil komme i situasjoner der
….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.
Forvaltning handler ikke bare om pakker fra eksterne økosystemer. Mange team drifter også interne komponenter som applikasjonsservere, integrasjonstjenester, containere eller virtuelle maskiner. Disse må inngå i samme forvaltningsrutine som resten av løsningen.
Interne komponenter må holdes oppdatert med en planlagt patchrutine. Følg leverandørens release-notater og vurder hva som faktisk må oppgraderes nå, og hva som kan planlegges inn senere. Komponenter som ikke lenger er supportert bør fases ut.
Komponentene må være en del av helhetlig sikkerhetsdesign. Teamet bør ha oversikt over nettverksflater, identiteter/roller og eksponering internt og eksternt. Bruk prinsippet “deny by default”: åpne kun eksplisitt for det som faktisk trengs.
Interne komponenter må monitoreres på linje med øvrige tjenester. Logger må være pålitelige og beskyttet mot manipulering, og inngå i teamets rutiner for hendelseshåndtering. Se også Logging og monitorering.
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.
Teamet bør som minimum ha kontroll på:
Recovery må testes jevnlig. Teamet bør planlegge øvelser som dekker både enkle feil og mer komplekse scenarioer.
Eksempler på øvelser:
Etter hver øvelse bør dere dokumentere hva som fungerte, hva som feilet og hvilke tiltak som må inn i backloggen.
En tenkt oppskrift for løsningen tegnet opp i artikkelen om systemskisser kan være som under. Premisset for planen under er at vi har kildekode og pipelines tilgjengelig i eksempelvis Azure DevOps, og at applikasjon og ressurser på mystisk vis er fjernet fra Azure:
Det er verdt å nevne at hvert punkt ofte trenger utfyllende informasjon, med henvisninger til tilgangspakker eller gruppemedlemskap for at den som gjenoppretter skal få nødvendig tilgang.
Hvis løsningen har AI-komponenter, må recovery-planen også dekke:
Dette støtter kontrollområder som “AI system operation and monitoring” og “AI system recording of event logs” i en operativ recovery-kontekst.
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.
Denne artikkelen handler om overordnet hendelseshåndtering og beredskap:
Operativ gjenoppretting etter destruktive hendelser er beskrevet i artikkelen om gjenoppretting.
Før en hendelse oppstår må følgende være avklart og dokumentert:
Dette må være kjent i hele teamet, ikke bare hos enkeltpersoner.
Hendelseshåndtering forutsetter at dere faktisk ser hva som skjer i løsningen. Teamet må sikre at nødvendige logger blir samlet inn, beskyttet og gjort tilgjengelige for analyse.
For løsninger med AI-komponenter betyr dette i tillegg:
Dette støtter kontrollområder som “AI system operation and monitoring” og “AI system recording of event logs” i ISO 420001.
Se også Logging og monitorering for mer detaljert informasjon rundt temaet.
Hendelser kan ta mange former: sårbarheter i applikasjon eller avhengigheter, driftsavvik eller aktive angrep.
Dersom dere oppdager, eller har grunn til å tro at en løsning er under angrep må dette varsles til kunden umiddelbart. Det er ikke alltid tilfelle at løsningen som angripes er den som er målet, i mange tilfeller er en løsning bare et springbrett videre til en annen. Derfor er det også viktig å vite hvilke tilganger og nettverksåpninger denne har til andre løsninger, slik at kundens IT-organisasjon kan analysere disse for å se etter tegn på angrep der.
Om dere kommer over tegn på at en løsning har blitt angrepet eller brukt til et angrep er det også viktig å si ifra, slik at kunden kan sikre informasjon og bevis på dette for videre etterforskning.
Håndtering av, og etterforskning av hendelser er et eget fagfelt. Dersom dere kommer over tegn på at noe kan ha skjedd, si ifra til deres kontaktpunkt og avvent beskjed fra denne før dere gjør noe.