kramselund jereminsen

Incident Handling og Logning

Alle virksomheder har sikkerhedshændelser. Spørgsmålet er om de opdager dem ...

Næste og meget nærliggende er om de overlever. Inden det kommer så vidt er der dog en process med incident handling.

Det officielle lydspor til dette indlæg er klassikeren Jeg Ved Det Godt
Rugsted & Kreutzfeldt

Den er valgt på det gode omkvæd:

[Omkvæd] Jeg ve' det godt, men det' for sent nu Jeg ve' det godt, men det' for sent nu Jeg ve' det egentlig godt, men det' for sent nu

Det synes jeg passer godt på netop logning, hvis bare der var en log der kunne hjælpe os.

Den kan selvf findes på Spotify
https://open.spotify.com/track/3UqVEnnIxxCaw96M62LxK2?si=704fc4a60afc4357
eller Youtube https://www.youtube.com/watch?v=cxx6hPKuPik

Hvis den løber tør kan du spille videre på Går Gennem Tiden
https://open.spotify.com/track/6LyoMVFckHOtUOrOiZbEXJ?si=24e5385784c64b6b

Jeg tænker også på R&K fordi jeg skal til natdisk lige om lidt, hvis ikke landet lukker helt ned inden den 19. november.

*** Reklame reklame reklame ***

Dette indlæg kan måske opfattes som reklame, og jeg beklager på forhånd. Jeg arbejder på KEA, jeg er medlem i PROSA. Jeg er også kæmpe fan af open source.

Dette indlæg er tænkt som et opråb til at komme igang med logning, og reklamerne er derfor sat i bunden. Jeg deler derfor nedenfor nogle konklusioner, erfaringer og anbefalinger til logning - og specielt hvordan du kan komme igang.

Blogindlægget refererer Ansible playbooks, som netop er opdateret - i arbejdstiden.

Eksempel: en basal malware inficeret enhed

Malware opdages på en PC i dit netværk

Du lykkedes med at identificere den pågældende maskine, og malwaren - i hovedtræk

Hvad er næste skridt?

Naturlige spørgsmål,

  • Hvilke andre maskiner er inficeret
  • Hvad er tidslinien, hvornår blev denne maskine inficeret
  • Er der sket andet skummelt i netværket før og efter
  • Hvordan får vi nu ryddet op?

Nogle af disse spørgsmål bliver hurtigt ret brede, nogle kan besvares med nogen sikkerhed, andre er svære at svare på.

Specielt er det svært at svare på uden fakta til at understøtte beslutningensprocessen.

Endnu værre bliver det hvis man skal skride til handling, skal vi:

  • Luk internetforbindelsen
  • Luk alle servere
  • Installer alle servere på ny, alle laptops, alle ...

Hvad er din step by step process nu?

Incident Handling processen

Til hjælp kan du måske bruge en generel process til håndtering af sikkerhedshændelser:

  • Preparation for an attack, establish procedures and mechanisms for detecting and responding to attacks
  • Identification of an attack, notice the attack is ongoing
  • Containment (confinement) of the attack, limit effects of the attack as much as possible
  • Eradication of the attack, stop attacker, block further similar attacks
  • Recovery from the attack, restore system to a secure state
  • Follow-up to the attack, include lessons learned improve environment

Denne liste er fra Incident Response: A Strategic Guide to Handling System and Network Security Breaches, 1st edition E Eugene Schultz Russell Shumway 2002

En mere moderne reference, som jeg anbefaler er:
Crafting the InfoSec Playbook: Security Monitoring and Incident Response Master Plan
af Jeff Bollinger, Brandon Enright, and Matthew Valites ISBN: 9781491949405

Når man læser disse, og gennem snart 20 år er der en masse som går igen. Vi skal bruge data om netværket og fra netværkstrafikken.

Kramses værktøjskasse til logning

Til at finde, samle og behandle disse data har jeg en værktøjskasse, sådan i en pærevælling: Suricata, Elasticsearch, Kibana, Zeek, Filebeat, Packetbeat, Logstash, NFsen, Elastiflow m.fl.

Det er en skøn samling, som forøvrigt integrerer godt, og en af grundene til at det er netop de værktøjer jeg bruger.

NB: andre bruger Graylog, andre bruger Grafana Loki - brug hvad du lyster, det er ikke emnet for dette indlæg. Ideen er at få FLERE til at logge og bruge data. Kom gerne med dine favoritter nedenfor, men lad os undgå mudderkastning.

Hold da op en lang række værktøjer, hvordan kommer jeg igang?!

Get started quickly

Hvis du bare vil prøve så vil jeg anbefale Security Onion - den dækker en hel masse forskellige værktøjer, men er lidt tung at slås med. Der er en hel masse projekter som er integreret.

https://securityonionsolutions.com/software/

Hvis det fokus er mere på netværkstrafikken kan en mere fokuseret platform være SELKS
https://www.stamus-networks.com/selks

Logning i produktion

Hvis du derimod har besluttet at I SKAL have noget produktion op at køre, så er en Debian løsning måske værd at se på.

Mine kurser er netop baseret på en rå ren Debian 11 hvor der installeres et væld af værktøjer. Det har den fordel at man kan se under motorhjelmen hvad der installeres, hvordan det konfigureres.

Samtidig bruger jeg Ansible, som er et af de populære configuration management værktøjer. Det er således muligt at tage mine opskrifter, Ansible Playbooks, og tilpasse dem til et produktionsmiljø. Det kræver stadig noget arbejde, men man starter ikke på bar bund.

Det betyder, og jeg har lige testet.

Hvis du installerer en Debian 11, installerer ansible og git og cloner mit repository, kan du installere en nogenlunde komplet logningsløsning med få kommandoer:

sudo apt install git ansible
git clone https://github.com/kramse/kramse-labs
cd kramse-labs/suricatazeek
ansible-playbook -v 1-dependencies.yml 2-suricatazeek.yml 3-elasticstack.yml

Der sker en masse herunder installation af en masse pakker, men også konfiguration. Resultatet bliver at man kan lege med delene og se resultatet i Kibana.

Illustration: Henrik Kramselund

En af fordelene ved Kibana er at ikke-programmører kan ændre på dashbords med musen. Klikketyklikk klikk og så er der de visualiseringer du vil have sammen, eller andre er fjernet.

Jeg elsker eksempelvis Zeek https://zeek.org/ , men det er et værktøj som er udviklet over mere end 20 år. Det får en helt ny funktion når data hives frem, via JSON Filebeat og Elasticsearch - hvor man kan lave dashboards med måneders data som opdateres på sekunder. Jeg er kæmpe fan.

Dine opgaver og mission

Kort fortalt vil jeg gerne have dig til at gøre følgende:

  • Installer en logningsløsning
  • Enable system logging fra servere
  • Enable system logging fra netværksenheder
  • Centraliser logning
  • Tilføj søge muligheder og dashboards
  • Kig på data løbende og lav rapporter
  • Opsæt alerting og notifikationsprocedurer

Er det nemt, nej

Er det noget du burde have mere af, klar ja.

Ovenstående vil allerede have dele af DNS logning og connections/sessions, men udvid evt. med DNS query logging eller firewall sessionslog.

Specielt ved sikkerhedshændelser vil du opleve at det giver bonus.

Spil katastrofespil med din chef

Alternativt så gå ind til din chef med et sæt D&D terninger.

Slå D12 for hændelsen: hackerangreb på hjemmeside, malware i økonomi, virus på lagercomputere, ransomware på fællesdrevet, ...

D6 for antal computere inficeret: 1, 10, 100, alle klienter, alle servere, ALLE

D4 for oprydningens kompleksitet: nem oprydning 1 time max, 1 dage, en uge eller over 30 dage
Gentag evt. denne med om produktionen er nede i X minutter.

D6 for økonomiske konsekvenser: 1.000kr intern tid, ... ekstern hjælp nødvendig 100.000kr ... ekstern katastrofe alle kunders data tabt, GDPR sag, datatilsynet >1.000.000kr

Reklame

Hvis du er interesseret i at høre mig tale mere om logning og SIEM, kan du se på følgende:

Efterskrift ulovlig logning

Ovenstående er beregnet til netværk du ejer eller er ansvarlig for. Du skal altid sikre dig at du gør det etisk forsvarligt.

Mine anbefalinger er eksempelvis, lad være med at logge gæster. Lad være med at overtræde love og menneskerettigheder.

Vi er stadig igang med sagen omkring Ulovlig Logning, og du kan støtte via Mobilepay 40456 eller kontooverførsel. Se mere på https://ulovliglogning.dk/ og på Twitter
https://twitter.com/ulovliglogning

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Povl H. Pedersen

En ting er logopsamlig. Men i et stort miljø, så kan det være svært at bruge til noget. Det vigtige er at få noget analyse på din log. Eksempelvis kan man lede efter Indicators of Compromise, eller de typiske metoder hackeren bruger.

Portscan er en ting, men eksemplevis kørsel af NET GROUP kommandoen på Windows er også noget der kan trigge at der er en i gang med discovery. Måske kan man stoppe manden inden han kommer for langt.

Der er nogle frameworks derude, og SIGMA rules https://github.com/SigmaHQ/sigma er et bud på et sted med IoC indicatorer man kan lede efter. Det er et generisk format, og er lidt logfilenes SNORT.

Så hvis man har logfiler, så bør man også analysere på dem, for at finde ting inden de bliver slemme. Og ikke kun post mortem. Så er det ofte for sent.

Det er interessant at 80%+ af dem der betaler ransomware beløbet er ramt igen indenfor et år. Hackerne elsker repeat customers :-) Og det er vel de færreste der kan lave hele deres infrastruktur arkitektur om til noget tidssvarende på kort tid.

  • 1
  • 0
#3 Henrik Juul Størner

Det er en hyppig fejltagelse kun at logge på servere. Stort set alle angreb i dag starter på en klientenhed (læs: medarbejder-laptop), og ethvert nogenlunde fornuftigt EDR system - selv MS Defender - logger hændelser der. Dem skal du fange tidligt, så er der en chance for at spotte et angreb inden det breder sig.

DNS query logning er essentiel for at spotte kommunikatione med C&C servere, det er også en tidlig indikation på at der er noget i gang. Med SolarWinds angrebet var det nærmest den eneste indikator til at begynde med.

Logning af DHCP leases er afgørende for at kunne identificere hvilken enhed, der laver noget snavs.

Hvis du bruger en eller anden directory service (f.eks. Active Directory), så er logning af fejlede og succesfulde loginforsøg mega-vigtig. Ditto ændringer af gruppemedlemskaber og oprettelse af nye brugere (især hvis de har særlige rettigheder).

Og så er der lige problemet med at hackere arbejder 24/7, men at du formentlig ikke har mandskab til at sidde og kigge på dine Kibana grafer og logkonsoller døgnet rundt. Så overvej kraftigt om ikke det vil være pengene værd at hyre et sikkerhedsfirma som får sendt loggen over i near-realtime, og så tager sig af analyser og alarmering. Det er en business-case, der skal overvejes. Det er ikke open-source, men det vil være min anbefaling.

  • 2
  • 0
#4 Klavs Klavsen

Da dine data ligger på dine servere, vil de oftest være målet for et angreb. Som Henrik Størner siger, så starter de fleste angreb med desktops (som også ofte kan indeholde/tilgå data på netværksdrev f.ex.) og derfor skal du forvente at angreb også kommer "indefra" - dvs. fra dine medarbejderes computere.

Jeg vil anbefale at få styr på ingress og egress - præcist HVAD SKAL dine services egentlig bruge for at fungere og så luk ned for resten. 99% af servere har IKKE brug for internetadgang og SKAL IKKE HAVE DET. Det inkluderer build pipelines - der BØR du istedet have en "cache" et sted, hvor build pipelines tager det de skal bruge fra (så virker dine builds også selvom nogen har gjort noget dumt på internettet - såsom at fjerne lige den pakke dit build bruger :)

på Linux servere bruger jeg puppet og et centralt regelsæt til at styre præcist hvilke porte der åbnes for og logger al trafik der bliver afvist (pånær forventede broadcast pakker og andet skrammel jeg DROP'er før log).

På Kubernetes kan du, hvis du bruger Calico som CNI - bruge deres NetworkPoiicy objekter til ganske nemt at specificere præcist hvad en applikations pods MÅ (både ingress og egress) - og så snart du gør det, bliver hele namespacet lukket ned. Det er super nemt og dynamisk - og Calico vedligeholder så dine iptables regler på Kubernetes noderne for dig - så du også kan se præcis hvilke iptables regler du får - og iptables logs ligger "hvor de plejer" - og du kan også installere f.ex. kube-iptables-tailer applicationen, for nemt at få k8s events når trafik bliver afvist, der også giver metrics, så du nemt kan definere Prometheus alarmer til at fortælle dig når der sker noget uventet i dit system.

  • 2
  • 0
Log ind eller Opret konto for at kommentere