«The only system which is truly secure is one which is switched off and unplugged, locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn’t stake my life on it».
Når man snakker i slike baner er det naturlig at blårussen stiller spørsmål om hvorfor de skal betale for masse sikkerhet hvis de uansett ikke kan hindre en målrettet angriper og det er viktig at vi som sikkerhetsfolk har gode svar.
To av grunnene til at vi ønsker å bruke tid, penger og kompetanse på sikkerhetsmekanismer er at vi hele tiden skal være litt bedre sikret enn «naboen». Slik at de er et mer interessant mål enn oss. Enda viktigere er det at du har en «defense-in-depth» arkitektur på domenet, som gir deg tid til å respondere når angrepet mot deg først er i gang. Et kjempeviktig element i «Defense-in-Depth» strategien er loggene. Uten gode logger er det vanskelig å oppdage angrep, respondere på hendelser og senere etterforske hendelsen.
Det er mye som kan generere logger i en virksomhet, men her skal vi fokusere på applikasjonslogger. Det første man må ta stilling til er hvilket nivå loggene bør ligge på i produksjon. De fleste benytter et logg-rammeverk og de vanligste logg nivåene er:
- TRACE
- DEBUG
- INFO
- NOTICE
- WARNING
- ERROR
- FATAL
I produksjon er det vanlig at man legger seg på NOTICE eller INFO nivå. Jo lavere nivå du legger deg på jo flere meldinger får du, og det tar oss til neste steg hvor du må vurdere Log Retention; hvor lenge skal logger lagres.
Hvor lenge skal logger lagres?
Dette varierer igjen på type applikasjon, infrastruktur, kritikaliteten og sensitivitetsgraden på applikasjonen og dataene den behandler. Er det en samfunnskritisk applikasjon som behandler data på høyeste sensitivitets grad bør du ha lang retention tid på loggene. I tillegg bør logger sendes til eksterne logg-tjenester (ekstern fra applikasjonen, ikke nødvendigvis ekstern fra datasenter/virksomhet/driftsleverandør).
Hvordan uføre sikkerhetstesting gjennom hele utviklingsløpet? Last ned vår guide her.
Logg-meldinger
Neste punkt er å ha monitorering på loggene. Logger er grunnlaget for en rekke metrikker, og man bør ha varsling og automatiske responser på visse hendelser som finner sted i logger. Dette er en jobb for husets infrastruktur team, CSIRT, SIEM eller driftsleverandør (avhengig av hvilke tjenester man kjøper inn og drifter selv, og hvilke roller og ansvarsområder som er definert).
Da din applikasjon logger meldinger via sitt log rammeverk er det viktig at du ikke logger på rammeverkets «default oppsett». Logg-meldinger bør ha følgende:
- Meldinger logges på millisekunds nivå
- Meldinger skal ha en GUID i hver melding (Global Unique Identifier)
- Meldinger bør inneholde en checksum av meldingen (kjøres gjennom en hash algoritme)
- Escape alle CRLF characters som går til log systemet
- Filområdet for logger skal ha begrenset med brukertilgang
Meldinger på millisekund nivå
Hvis ikke log meldingene er på lavt nok nivå kan meldinger komme i feil rekkefølge i loggen. I en etterforskning er det viktig å etablere en korrekt tidslinje for når ting faktisk skjedde.
Meldinger med GUID
Hvis alle meldinger inneholder en GUID er trivielt å detektere falske log meldinger. En angriper vil potensielt forsøke å endre loggen for å skjule spor eller forvirre etterforskere. Har man et system for å sette en GUID øker man kompleksiteten for å injecte falske meldinger.
Meldinger med checksum
For å ivareta integriteten på log meldingene kan det være hensiktsmessig å kjøre meldingene gjennom en god hashing algoritme og legge checksum med som en del av log meldingen. I kombinasjon med GUID gjør dette det mye vanskeligere for en angriper å kunne manipulere logger uten at alarmer går av.
Escape CRLF
Hvis du ikke escaper CRLF characters kan log systemet ditt være sårbart for Log Injection via CRLF angrep.
Rettighetsstyring
For å minimere mulighet til at logge blir endret eller slettet bør man ha god rettighetsstyring på loggene. Tjeneste-Brukeren til applikasjonen skal helst ikke ha tilgang til å slette filer fra filområdet hvor loggene ligger. Samme gjelder andre tjenestekontoer på systemet. De skal ikke kunne røre logger tilhørende et annet system. Hvis det er generelle brukere også på serveren, så skal de i hvert fall ikke få lov til å tukle med loggfiler.
Hvordan utføre sikkerhetstesting gjennom hele utviklingsløpet?
Sikkerhetsekspert, Even Lysen, gir deg en guide til hvordan man kan utføre sikkerhetstesing gjennom hele utviklingsløpet.
