kramselund jereminsen

Handling security incidents, automate or die

Jeg prøver at skrive indlægget her selvom jeg er træt, tilgiv mig hvis sproget er dårligt, ...

Jeg sidder i toget og læser om endnu en større alvorlig sikkerhedsfejl, http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-...

Fantastisk arbejde og værd at læse, bagefter læser jeg nok http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/03/freak-flaw-...

A group of cryptographers at INRIA, Microsoft Research and IMDEA have discovered some serious vulnerabilities in OpenSSL (e.g., Android) clients and Apple TLS/SSL clients (e.g., Safari) that allow a 'man in the middle attacker' to downgrade connections from 'strong' RSA to 'export-grade' RSA. These attacks are real and exploitable against a shocking number of websites -- including government websites. Patch soon and be careful.

Specielt den sidste er som altid fantastisk - du skal patche, og det skal være nu. Blev vi forøvrigt færdig med den sidste alvorlige, altså den alvorlige lige før denne, som kom lige efter den anden megaalvorlige? Tidligere var mantraet patch or die, altså du skal patche systemerne for at være sikker. Problemet idag er dog at der ikke er timer nok. Du får knapt tid til at læse om den ene fejl, såbarhed eller patch før den næste står i døren.

Jeg kalder det kontinuert overlappende større security incidents. Du er nødt til at antage du har en security incident, indtil det er bekræftet eller afkræftet. Vi har set et væld af disse, og jeg lagde selv rigtigt mærke til det med Heartbleed at de kommer næsten uden ophold fra da til nu, og fremover.

Patch cyklus

Ser vi på den gængse patch cyklus, forsimplet en del:

1) Ny sårbarhed offentliggøres, OMFG, panik, die die die - FIRE in the machine room

2) Er der en patch? workaround? Findes et filter til vores loadbalancer, antivirus, IDS, detektion, loganalyse
Er vi overhovedet ramt? Hvad er sårbart, hvad version er sårbar, hvilke systemer, WTF-*

3) HEY GUYS VORES main site er ramt! Patch patch patch! Er der andre systemer som er sårbare? Hvordan finder vi resten?
- imorgen skal vi altså have styr på patches

sleep

4) HEY vi har flere sårbare systemer, og system X er hacket!

no sleep days go by

5) Øv, system Y er sårbart - jeg patcher med v2 af patchen - lægger den også på de andre (men glemmer system X)

TL;DR patch af systemer foregår i stort omfang ad-hoc og inventory dækker sjældent alle systemer.

Ovenstående forlænges og strækkes ud når man har mange systemer, kræver servicevinduer, har flere kunder på samme systemer - af mange årsager. Patchning af eksempelvis Heartbleed tager måske totalt set 14 dage wall-clock time og med natarbejde hist og her. Natarbejde betyder så igen at der mangler ressourcer i dagtiden, til næste kriser, og håndtering af kunder der ringer ind med spørgsmål om "denneher nye alvorlige sårbarhed". Jeg lader med vilje være at skrive en specifik, for ofte vil grupper af kunder spørge om tidligere alvorlige sårbarheder, som måske/måske-ikke er løst endnu.

Pentest og Security Devops

Vi skal håndtere patchning af systemer løbende, og mere automatisk - udover det vi kan kalde patch management. Patch management dækker efter hvad jeg erfarer nemlig kun en delmængde af systemer, dem som allerede i stort omfang er up-to-date.

Mit forslag, og hvad jeg netop har sagt her til aften, Hej Herning, er at vi skal automatisere mere, OG lære eksempelvis pentest værktøjer at kende.

Ser vi på eksempelvis Heartbleed kommer der hurtigt proof-of-concept programmer og scripts man kan bruge. Hurtigt kommer der også moduler til de værktøjer vi allerede kender - som Nmap, Masscan, Metasploit m.fl. Hvis du kender disse værktøjer og blot skal plugge et nyt lille script ind, a la http://nmap.org/nsedoc/scripts/ssl-heartbleed.html så kan du mere effektivt bekæmpe dagens brand.

Så mit krav til dig der vil overleve i det ragnarok vi befinder os i er at ændre dine metoder:

  • Identifikation Brug Nmap og andre pentestværktøjer til at identificere sårbarhederne, scan ukritisk hele din infrastruktur, alle dine IP'er. Sådanne værktøjer er ligeglade med om dine patch management dashboards siger alt er ok, de tester rent faktisk - og hvis du eksempelvis har glemt at genstarte en process efter opdatering fanges det også.
  • Verifikation Brug automatik som Ansible, Python, Perl, Powershell til at bekræfte/afkræfte thesen om at disse systemer er sårbare, marker disse - kan være 10 ud af 10.000 host, eller 9.999 ud af dine 10.000 systemer, who knows?
  • Opdatering og workaround - automatisk, der var efter Heartbleed historier om firmaer der havde patchet tusindvis af systemer samme dag! Det er stærkt og noget du skal sigte mod.
    NB: husk også at der typisk vil være flere versioner af patches, så du skal sandsynligvis igennem rækken af servere flere gange!
  • Rinse repeat - og sov indimellem

Du skal forvente at der kommer en ny brand, og derfor skal du hele tiden gå efter at denne cyklus gentages og gennemføres flere gange samme dag måske. Hvert skridt skal altså være optimeret til at tage kort tid, kan gøres gentagne gange - så det udelukker eksempelvis at du hver gang lavet et hjemmelavet script til patch. De rigtige værktøjer og lidt security devops er efter min mening nødvendigt. Specielt værktøjer som kan udvides med "plugins" som små stykker vil være kærkomment.

Det kan hjælpe hvis du bruger både Open Source og kommercielle løsninger, gerne en god symbiose. Du kan ikke altid regne med at den ene eller anden altid er først, faktisk vil jeg sige mere 50/50 for mit vedkommende hvem der først kommer med en hjælpende hånd. Så hvis vi tager udgangspunkt i nogle få værktøjer fra min værktøjskasse vil en process være:

  • Scan med Nmap - kan snildt scanne 20.000 IP'er på 10 minutter med nmap -p 443 --script ssl-heartbleed og vores netværk som input fil
    Forudsætter at man allerede har installeret en Kali Linux som flere kan logge ind på, koster en VM med 2 CPU cores, 1024MB mem, 15 Gb disk

  • Verificer og opdater med configuration management, jeg er blevet overordentlig glad for Ansible, evt. med output fra foregående step direkte ind!

  • Scan med Nmap inkl. næste alvorlige sårbarhed

  • Verificer og opdater med Ansible Playbook som nu inkluderer patch nr 2, og eller ændringer til patch nr 1
    Ansible har task som byggesten og man kan bede et Ansible run om at skippe tags, eller kun tage bestemte tags - meget fleksibelt

  • Detektion er ligeledes et område hvor du gerne skulle kunne afgøre om der er andre systemer du har overset, eller nogen som prøver at udnytte sårbarhederne. Det er specielt her hvor flere værktøjer der overlapper kan være dejligt, både AV der fanger Superfish og IDS der detekterer Superfish vil være relevant.

Målet for mig er at alle kan afvikle vores test af dagens sårbarhed, fra eksisterende udstyr, udvide eksisterende løsning til configuration management/patch process - afvikle dette selvstændigt. Altsammen indenfor normal arbejdstid, eller med minimalt natarbejde - måske kun 1 times mistet nattesøvn fremfor 4 timers manuel patch af "for få systemer".

Vel og mærke så I samarbejder, istedet for at en person gentager hele processen for een sårbarhed, så kører I måske 3-4 af disse alvorlige incidents i samme scans, og samme "remediation steps". Så der er måske en som pt. scanner for 3-4 sårbarheder, en som kører configuration management/patch, og en som holder øje med stabiliteten - så alle roller er dækket og alle arbejder effektivt i parallel.

Del og hersk

Lad for guds skyld være med at lave din egen Kali Linux, som kun DU har adgang til, lav en delt. Lav ikke specielt script til eeeeen sårbarhed, for imorgen kommer næste patch - brug eksisterende configuration management - det er designet til opgaven og modnet. Hybris hvis du tror du kan slynge noget bedre sammen på ultrakort tid. Lad være med at sidde og holde på kortene, forklar dine kollegaer hvor langt du kom, hvad du gjorde, hvad der mangler - I skal tage over for hinanden, så I får noget søvn allesammen :-)

Der går simpelthen for meget tid med ad-hoc løsninger som kun løser een opgave, hvor jeg ser en fordel i at strømline denne process, for det bliver stadig mere nødvendigt.

Jeg ved ikke om det fremgår tydeligt hvad jeg anbefaler, men så må I skælde mig ud ;-)

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Cristian Ambæk

Noget siger mig at du er lidt træt af sårbarhederne der springer frem i en uendelighed i denne tid ,)

For mig er hele din "del og hersk" sektion jo logik, men man bliver forbavset hvordan virkeligheden >kan< være.

Men derudover er der også flere ting i din artikel som jeg ikke lige fanger, som måske er logik for andre.

Når jeg læser din artikel er den viklet ind i en del "panik", stress og søvnløshed. Ja, der er flere alvorlige sikkerheds brister i diverse systemer og nye dukker op her og der. Men når man har dokumenteret sin infrastruktur (ja det er kedeligt at lave), hærdet det til det niveau som passer til ens organisation og inkorporeret et passende IDS/IPS. Hvorfor så gå med søvnløse nætter?

Hvis du har dokumenteret dit system digitalt, så kan du vel hurtigt skyde en test afsted som tester for X sårbarhed hvor du får et svar tilbage at system X og X eller system X til X er sårbar, vurdere hvor du skal sætte ind, serveren, netværket, firewallen eller andet.

Og så skyde en testet opdatering afsted der lapper den sårbarhed, eller lukker den indtil en permanent løsning kan inkorporeres.

  • 0
  • 0
#2 Henrik Kramselund Jereminsen Blogger

Hvis du har dokumenteret dit system digitalt, så kan du vel hurtigt skyde en test afsted som tester for X sårbarhed hvor du får et svar tilbage at system X og X eller system X til X er sårbar, vurdere hvor du skal sætte ind, serveren, netværket, firewallen eller andet.

Og så skyde en testet opdatering afsted der lapper den sårbarhed, eller lukker den indtil en permanent løsning kan inkorporeres.

Tak for kommentarer. Det er dejligt hvis du har et sådant system, det bekræfter at de findes :-D Jeg synes desværre ikke det er almindeligt, faktisk ser jeg for meget kaos i netværk idag, som forsøgt angivet med "panik".

Det er også sjældent man får lov til at lukke eller opdateret et live site der tjener penge, det kræver en stærk ledelse som tør tage kampen op.

  • 0
  • 0
#3 Cristian Ambæk

Jeg synes desværre ikke det er almindeligt, faktisk ser jeg for meget kaos i netværk idag

Ooooo yyeeesss

Jeg syntes ikke det er nemt eller svært, men man skal sætte fingeren i "jorden" og lige finde ud af hvad der er op og ned. Der er intet problem vi ikke kan løse, vi skal bare lige finde ud af hvordan for netop den organisation vi befinder os i :)

Jeg kan som minimum godt lide den berømte "time pr dag" metode.

Det er også sjældent man får lov til at lukke eller opdateret et live site der tjener penge, det kræver en stærk ledelse som tør tage kampen op.

At røre ved systemer der hiver bas-ørerne hjem er altid et følsomt område, risk vs reward. Men hele din artikel (som jeg læser den) er jo netop at patche infrastrukturen, hver mindre jeg er meget træt og er gået helt galt i byen xD

  • 0
  • 0
#4 Martin Jünckow

En ting er at man får patched så hurtigt som muligt når først patches er released, men inden da går der jo tid med at få disse patches klar altimens kendskabet til sårbarheden spredes. Dette må jo nødvendigvis ske lige så kontinuerligt og man er med andre ord altid under angreb fra ukendte sårbarheder.

Det bliver især problematisk når hackerne er istand til at kombinere zero-day exploits med botnetværk og automatisere angreb på en lang række systemer i løbet af meget kort tid.

Jeg mener ikke der er anden udvej end at betragte 1. led (det led som modtager requests fra internettet) som kompromiteret. Det være sig alle webservere etc.

Hvis man vil beskytte f.eks. brugeres login-oplysninger (eller anden sensitiv data) så bør dataene placeres på et netværk i 2. led, som er firewalled helt af fra 1. led udover en åben port til et custom middleware hvor man kan forespørge på at få logins verificeret. Altså ingen direkte adgang til DB systemer i 2. led.

  • 1
  • 0
#5 Mads Bendixen

Det er også sjældent man får lov til at lukke eller opdateret et live site der tjener penge, det kræver en stærk ledelse som tør tage kampen op.

Hvis sitet tjener penge, er det ekstra vigtigt at få patchet hurtigst muligt. Det handler tillid og troværdighed overfor kunderne. Heldigvis virker det til at det også er ved at gå op for ledelsen rundt omkring, sikkerheden skal ikke negligeres. Skandaler som Sony mm. er med til at hjælpe det på vej.

  • 1
  • 0
#6 Christoffer Kjeldgaard

WSUS til Windows kan opsættes til at patche dine servere, så snart Microsoft har fået fingre i en testet patch. Det kræver en smule opsætning, men er egentlig et ganske godt værktøj til patch af rigtig mange servere på en gang. Det er længe siden jeg har været sys admin, omkring 2010, men dengang var det ret let og rulle security patches ud på forskellige domæner, test-servere, etc.

Hvis man kører Citrix er der også applikation deployment, update, og test integreret i deres "Command Center".

Hvis man vil betale sig fra det, findes whole patch, AV, malware endpoint løsninger som kan gøre det legende let og administrere en større serverfarm. Et jeg har gode erfaringer med er https://www.lumension.com. Som sagt, min viden er en smule dated, men patch systemer og vulnerability testing tools eksisterer - Eneste udfordring er, vil du betale for det?

Til Linux findes der forskellige radius-værktøjer der gør det samme. Har man sin egen distribution er der noget arbejde i at teste forskellige patches inden de endeligt rulles ud, Man kan også bruge patch management software, der kan automatisere processen og teste de forretningskritiske applikationer med unit tests ganske gratis. Det tager noget tid og sætte op, men er guld værd.

  • 0
  • 0
#7 Christoffer Kjeldgaard

WSUS til Windows kan opsættes til at patche dine servere, så snart Microsoft har fået fingre i en testet patch. Det kræver en smule opsætning, men er egentlig et ganske godt værktøj til patch af rigtig mange servere på en gang. Det er længe siden jeg har været sys admin, omkring 2010, men dengang var det ret let og rulle security patches ud på forskellige domæner, test-servere, etc.

Hvis man kører Citrix er der også applikation deployment, update, og test integreret i deres "Command Center".

Hvis man vil betale sig fra det, findes whole patch, AV, malware endpoint løsninger som kan gøre det legende let og administrere en større serverfarm. Et jeg har gode erfaringer med er https://www.lumension.com. Som sagt, min viden er en smule dated, men patch systemer og vulnerability testing tools eksisterer - Eneste udfordring er, vil du betale for det?

Til Linux findes der forskellige radius-værktøjer der gør det samme. Har man sin egen distribution er der noget arbejde i at teste forskellige patches inden de endeligt rulles ud, Man kan også bruge patch management software, der kan automatisere processen og teste de forretningskritiske applikationer med unit tests ganske gratis. Det tager noget tid og sætte op, men er guld værd.

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