This is the multi-page printable view of this section. Click here to print.
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. Dersom det er elementer i designet som ikke er implementert bør dette fjernes, dersom vi har implementert elementer som ikke er i designet må designet enten oppdateres eller elementene fjernes fra løsningen.
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.
Det er langt fra alle leveranser som er aktuelle for revisjon eller audit fra kundens side, dette vil typisk gjelde leveranser der Bouvet har tatt styring og kunden i større grad mottar en løsning uten at de er tungt involvert i driften av prosjektet. En revisjon er verktøy kunden kan benytte for å sikre at Bouvet har gjort jobben som avtalt, der kunden har mulighet til å gjennomgå våre rutiner og arbeidsprosesser for å sikre at vi har levert som vi skal.
En slik revisjon vil være avklart i kontrakten vi jobber mot, men det er langt ifra alle kunder som benytter seg av denne muligheten. I mange tilfeller vil det være mest aktuelt med en revisjon når prosjektet leveres eller på et tidspunkt etter levering når det er i drift. Målet vil da være å verifisere at kravene til prosjektet er oppfylt, og at det forvaltes og driftes på en måte som er i samsvar med det kunden forventer og krever.
Her vil det kunne variere fra kontrakt til kontrakt, men helt overordnet bør man sikre at prosjektet har den nødvendige dokumentasjonen som kreves og forventes slik at man kan vise at sikkerheten i leveransen er ivaretatt. Vi bør alltid levere et minimum av sikkerhet, men dersom kunden har valgt å ikke ta hensyn til anbefalinger eller har valgt å takke nei til eventuelle tilleggstjenester må vi sikre at dette er dokumentert på en skikkelig måte.
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.
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.
Dersom teamet har gjort alt rett til nå har dere en plan for disaster recovery som forteller dere hva som må gjøres for å gjenopprette infrastruktur, applikasjoner og data slik at en kommer tilbake til normal drift.
Årsakene til at en er nødt å gjenopprette kan være mange, og svært varierende i omfang. Hvem har vel ikke kjørt en delete from <table> where x = 'something' med manglende eller feil parametre, eller droppet feil tabell fra en database? Eller slettet en server eller appservice fra et prodmiljø ved en feil (jeg skulle bare fikse noe kjapt….). I slike tilfeller kan det gå kjapt å gjenopprette dersom en vet hva som gikk galt, men i andre og mer komplekse tilfeller som f.eks. involverer ukjente feil i programvaren eller problemer hos en skytjenesteleverandør kan det bli mer komplekst.
For at planene skal ha noen reell verdi, er man nødt til å teste disse i praksis. I en perfekt verden bør planene være så detaljerte at gjenoppretting er mulig selv om hele teamet blir påkjørt av bussen, eller på annet vis blir utilgjengelige. I praksis er dette ofte vanskelig å oppnå, men teamet bør ha et mål om å lage en god oppskrift på hvordan en recovery kan foregå under gitte forutsetninger, og deretter teste denne regelmessig i et alternativt miljø.
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 vedt å nevne at hvert av punktene kan trenge utfyllende informasjon, med henvisninger til aksesspakker eller gruppemedlemsskap for at personen som restorer skal få nødvendig tilgang.
Mange tenker gjerne på sikkerhetshendelser som målrettede angrep der noen angriper en løsning ved å hacke den. I noen tilfeller er dette gjerne korrekt, men en hendelse kan være mye mer.
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 og tilgjengelighet, og avhengig av konteksten vil ulike kunder ha ulike krav til når vi må rapportere og/eller agere på dette.
Dette er dekket i flere artikler under “Planlegge”, men noe av det viktigste du gjør er å dokumentere hvilke krav vi må etterleve og hvilket ansvar vi har innenfor de ulike fasene i tillegg til kontaktpunkter hos kunden. Noen kunder er tett på sikkerhet og vil monitorere og varsle leveranseteam på egenhånd, andre basererer seg på at teamene selv følger med.
NSM lister en del nyttige punkter en også bør vurdere innad i teamet; flere av disse peker på organisasjonen som helhet, men det kan være viktig for teamet å være kjent med de ulike tiltakene.
Hendelser kan ta mange ulike former. En hendelse kan være svakheter eller sårbarheter som oppdages i en applikasjon, avhengigheter eller kjøremiljø, men det kan også være angrep - både åpenbare eller mer i det skjulte.
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.