Logganbefaling

Anbefaling:

Samle loggene sentralisert.

Hvorfor sentralisere logger:

Dette gjør oppfølging av hendelser (AV-alarmer f.eks.) veldig mye lettere enn om man må ut på den enkelte klienten.

En bonus er at også det gjør feilsøking i daglig drift uendelig mye enklere.

Hvilket verktøy som brukes her er ikke viktig. Det viktige er at det gjøres

Mer informasjon:

Elastic er et open source alternativ (hvor man også kan betale for support).

Splunk er også et mye brukt loggverktøy i norsk helsesektor.

Anbefaling

• Kjør Sysmon, og benytt standardkonfigurasjonen i sysmon-modular som et startpunkt

• Start logging på 10 klienter og 10 servere. (for å få litt data grunnlag av en viss variasjon kilder)

• Etter et par dager med testing: fjern ting som støyer veldig hos deg (Dette varierer noe fra virksomhet til virksomhet)

• Sett i drift på alle klienter og servere

Om Sysmon:

Sysmon er et verktøy som øker kapabiliteten til å logge aktivitet som blir utført på et system. Sysmon krever en konfigurasjonsfil som forteller hva den skal logge. Denne tillater stor grad av tilpassing.

Verdien man får av Sysmon følger mengden energi man legger ned i konfigurasjonen.

Mer informasjon:

TrustedSec har en Sysmon Community Guide som går gjennom hva Sysmon er og hvilke events man kan logge

Anbefaling

Skru på følgende loggkilder:

• Script block logging
• Module logging
• Transcript logging

Om Powershell-logging

Det finnes tre typer PowerShell-logger: Script block logging, Module logging, og Transcript logging.

Script block logging vil lagre blokker med kode etter hvert som de blir kjørt av PowerShell. Denne loggen vil lagre kommandoer slik som de blir kjørt internt i PowerShell, og vil derfor kunne de-obfuskere kode som har blitt kjørt.

Module logging lagrer “pipeline execution details”, noe som inkluderer variabel-initialisering og command-invocation. Resultatet av dette er at deler av scriptet, deobfuskert kode, og output vil bli logget.

Transcript logging lagrer all input og output i alle PowerShell-økter, likt som det ser ut i selve økten.

Vår anbefaling er at dersom det er mulig benytter man alle tre typene PowerShell-logging. Script block logging gir oversikten over alt som har blitt kjørt, og er den viktigste loggen å skru på dersom man ikke ønsker å skru på alt av logging.

Mer informasjon:

Mandiant har en god bloggpost om de forskjellige typene PowerShell-logging og hvordan man kan skru de på.

Anbefaling

• Følg anbefalingene i Microsofts Advanced security FAQ

Om Windows Advanced Security Audit Policy

Standardinnstillingene til Windows security auditing kan være utilstrekkelig for å oppdage hendelser. Dersom man ønsker å bruke hendelsene fra Windows-security-loggen for å oppdage eller ettergå sikkerhetshendelser er vil det ofte nødvendig å skru på utvidet logging.

Microsofts Advanced Security FAQ inneholder anbefalinger for hvilke loggkategorier som skal skrus på for domenekontrollere, servere, og klienter.

Mer informasjon

Microsofts Security Compliance Toolkit inneholder verktøy som kan gjøre det enklere å implementere blant annet Security Auditing.

Hayabusa er et open-source verktøy for logganalyse. De vedlikeholder et batch-script: YamatoSecurityConfigureWinEventLogs.bat for å skru på utvidet logging. Dette er et godt utgangspunkt for å skru på utvidet logging.

Anbefaling

• Samle følgende logger:

  • .bash_history (eller logger fra andre shells) fra alle brukere, inkludert root

  • /var/log/auth, /var/log/secure, var/log/faillog

  • /var/log/audit

  • /var/log/boot

  • /var/log/cron

  • /var/log/dpkg.log (Eller andre pakketyper som /var/log/yum.log etc.)

  • /var/log/mail.log

  • /var/log/messages

  • /var/log/syslog

• Benytt auditd. Ta utgangspunkt i standardkonfigurasjon til Florian Roth: Neo23x0/auditd

Om linuxlogging

Nøyaktig hvordan man implementerer logging, og hva man finner hvor kommer an på hvilken distribusjon man benytter.

På bakgrunn av dette er vår anbefaling her så generell som mulig, slik at den kan gjelde for så mange distribusjoner som mulig.

Mer informasjon:

Vi anbefaler å lese gjennom Crowdstrikes Linux logging guide.

Videre er Hunting for Persistence in Linux (Part 1): Auditd, Sysmon, Osquery (and Webshells) en god bloggpost som går litt gjennom hvordan man setter opp logging. Den tar også for seg noen eksempler på hvordan man kan bruke loggene for å oppdage forsøk på å etablere persistens.

Dersom man benytter Splunkanbefaler vi appen Splunk Add-on for Unix and Linux. Denmonitorerer det vi anbefaler, og har en del scriptede inputs som brukes for å hente ekstra inforamasjon fra Linux-hoster.

Anbefaling

• Logg all informasjon fra antivirusalarmer.

Minimumsanbefaling

Dersom det ikke er mulig å logge alt, anbefaler vi at følgende logges:

• Deteksjonsnavn

• Hostnavn

• Filnavn

• Full path

• Kryptografisk hash av fil (SHA256, SHA512)

Om Antiviruslogging

Antivirus fanger, selv med avanserte angripere, ofte opp deler av angrepet. Dette gjelder i enda større grad om angrepet ikke er sofistikert. Monitorering og oppfølging av AV-alarmer er derfor et viktig tiltak for å fange opp uønskede hendelser.

Mer informasjon

Antivirusloggen vil være forskjellig basert på hvilken antivirus som benyttes.

Det er også forskjeller i måten man kan sentralisere disse loggene.

Dersom man benytter Splunk finnes det add-ons for de fleste antivirusløsninger.

Vi anbefaler at logger tas vare på i to år. Spesielt i tilfeller hvor zero-days blir kjente er logger tilbake i tid kritiske for å sjekke etter tegn til at angripere tidligere har etablert fotfeste.