1. DND Faggruppe for IT-sikkerhet
19. april 2012
Håndtering av
sikkerhetshendelser
2. Kort om meg
• Oddbjørn Steffensen
• BDC (1995-2003) » EDB ErgoGroup / Evry (2003-)
• Arbeidsområder
• Fulltid sikkerhet siden ~2000 (fra pakkesniffing til konsernpolicy)
• EDB/Evry Incident Response Team (IRT) siden ~2003
• Konsernarkitekt Sikkerhet fra november 2011
• Om presentasjonen
• Høyt tempo, maler med bred pensel
• Spør gjerne underveis (enkelte ting er off-limits)
3. Kort om Evry
• Tidligere EDB ErgoGroup Consulting
• Omsetning på NOK ~12.8 mrd (2011)
• ~9.500 ansatte på >100 lokasjoner
• ... hvorav 350-400 i Bergen
IT
Solutions
Operations
• Stort egenmiljø, store kundemiljø
• Evry Incident Response Team (IRT)
• Fire personer, 24/7-beredskap + team for enkeltmiljø
• Primært støttefunksjon for egen organisasjon + for kunder
4. The Stages of Being Hacked
Selvgodhet Overraskelse Resignasjon
«Vi har kontroll!» «Går dét an?» «Hvor la jeg CVen?»
5. Hva er en sikkerhetshendelse?
• En hendelse som har medført, eller
kan utvikle seg til å medføre, tap av:
Konfidens- Tilgjenge-
Integritet Omdømme
ialitet lighet
”A computer security incident is a violation or imminent threat of violation of computer
security policies, acceptable use policies, or standard security practices.” – NIST 800-60
6. Eksempler på hendelser Økonomisk
Identitetstyveri Tjenestenekt kriminalitet
Sabotasje SQL-injisering
Defacement Bakdør Anomalier Applikasjonssårbarhet
Elevering av rettigheter Industrispionasje
Brann Informasjonsmodifikasjon
Brute force-angrep
Tap av laptop/mobil Personalsak
Malware Session hijacking Tyveri Uønsket innhold
Sosial manipulasjon Hacktivism
Informasjonslekkasje
Ulovlig innhold Misbruk av rettigheter
Misbruk av ressurser
Feilsituasjon med sikkerhetskonsekvens
Utsjekker Bestillinger Hendelser Katastrofe
7. Målet med håndtering (forenklet)
Hva har skjedd?
Begrense skade
versus
Gjenopprette normal 5
1
2
4 3
Hva kan bli bedre?
Alle har et opplegg for hendelseshåndtering – strukturert og planlagt eller ad hoc
12. Kontekst: “Terrenget”
Verdikjeder
Forretnings- Løsninger &
verdi Infrastruktur
“The
Risiko Terrenget Defensible
Network”
Sikringstiltak
Trusselbildet
og -status
Tilpasningsdyktighet
13. The Defensible Network
1. Monitored • Hva som skjer («situational awareness»)
2. Inventoried • Vite hva vi har (assetoversikt)
3. Controlled • Porteføljestyring, regulering og filtrering
4. Claimed • Entydig eierskap for alle komponenter
5. Minimized • Redusert angrepsflate (herding, soner)
6. Assessed • Reell sikringsgrad vurdert opp mot behov
7. Current • Løpende oppdatert (patching, sanering)
http://taosecurity.blogspot.com/2008/01/defensible-network-architecture-20.html
17. F
Egenskaper i en handler F
G
S
A
A
• Kompetanse og trening • Kunnskap om:
• Teknologiforståelse • Egen organisasjon
• Vurderingsevne • Egen infrastruktur
• Tilgjengelig Basis • Trusselbildet
• Ledelse
• Trigge andre
• Kommunisere status
• Koordinere
• Utfordre Koor- Komm- • Oversette mellom ulike
sfærer (ledelse vs. teknisk,
• Eskalere dinering unikasjon intern vs. kunde)
• Korrellering
• Identifisere opsjoner
F.eks. 600 mailer på en uke
Presen- • Sammenfatte komplekse hendelser til felles grunnlag
tasjon • Erfaringsoppfølgning
18. F
Samhandling G
F
S
A
A
• Tjenesteeier • Incidentprosess
• Applikasjonsdrift • Kundekontakter
• Plattform • Kommunikasjon
• Database • Helpdesk
•
•
Nettverk
Antimalware
Drift Støtte •
•
HR og juridisk
Fysisk sikkerhet
• Kriseapparap
IRT
• Leverandører
•
•
Tjenesteeier
Egen IRT-funksjon
Kunde Partnere • ISPer
• Plattformansvarlig • NorCERT,
• Ledelsesnivå HelseCERT mm.
• Incidenthåndterere • Politi
19. F
Eksempel på samhandling G
F
S
A
A
Forberedelser 1
Kunde
Politi Eier IRT Drift Utvikler Ekstern aktør
? ? IRT aktiveres
Driftsavvik eller ? Sårbarhet avdekk- ? Henvendelse ?
varsel fra IDS es under testing fra kunde
• Konstatert
• Mistanke
• Aktivisering av varslingsplan Kartlegging og analyse
• Protect & Proceed?
• Pursue & Prosecute? • Hva / Hvordan / Hvem 2 • Systemtilstand • Systemkunnskap • Informasjon
• Alvorlighetsgrad og omfang • Relevante logger • Telefon
• Konsekvens • Ad-hoc overvåkning • Intervju
• Hypoteser • Identifisere failover/backup-alternativer • Innhente info fra andre
Bevissikring • Sporing
• Overlevering av bevis • Oppdatert analyse 3 Innsamling
• Sikre bevisintegritet • Matching hendelse/bevis • Sikring av logger
• ”Chain of custody” • Snapshot av system
• Bevisets volatilitet gir prioritering
Skadebegrensning
• Andre løsninger med samme sårbarhet? 4 • Isolering • Systemendring • Kundepleie
• Valg mellom: • Deaktivering
• Holde tjeneste oppe og overvåke • Plakat
• Ta ned tjeneste
Tjenestegjenopprettelse
• Status 5 Reetablering
• Failoverløsning
• Bytt passord
• Reinstallasjon + herding
Oppfølgning
Erfaringsoppfølgning
Bistand ifb. påtale • Erfaringsrapport 6
• Overlevering av bevis • Postmortem møte
• Tolkning av bevis • Tekniske tiltak
• Presentasjon av bevis og sekvens • Organisatoriske tiltak
• Bevishåndtering • Forbedring av håndtering
• Kommunisere ut lærdom
Hendelse avsluttet
20. F
Aktivisering F
G
S
A
A
• Triggere
• Deteksjon (log/malware/IDS)
• Øvrig incidentprosess
• Kunde eller eksterne (f.eks. bestilling)
• Endring i trusselbildet
• Eget initiativ
• Klassifisering / triage
• “Hvit / gul / oransje / rød” hendelse
• Krever umiddelbar håndtering?
• Eskaleringsbehov?
• Proaktivt versus reaktivt IRT
21. F
Analyse F
G
S
A
A
• Identifisere informasjonskilder
• Mennesker og systemer
• Direkte og indirekte kilder (DHCP-logg eksempel på sistnevnte)
• Hjelpesystemer (assetoversikt, systemeierskap, kontaktpunkter mm.)
• Innhente og sikre informasjon
• Flyktighet/volatilitet: RAM/swap, nettverkaktivitet, aktive prosesser, disk, eksterne lagringsmedia
• Nettverksisolér fremfor å slå av komponent
• Logger som roteres eller kan slettes/manipuleres av angriper må sikres snarest mulig
• Kan ikke stole på noe materiale fra en kompromittert komponent (jfr. rootkits)
• Korrellere, vaske og kna informasjon
• Sporbarhet på tvers av kilder
• Berikelse (f.eks. geomapping)
“When you have eliminated the impossible, whatever remains, however improbable, must be the truth.” – Sherlock Holmes
22. F
Analyse: Infokilder F
G
S
A
A
• Klient / server • Logger
• Registry • Plattformlogg (eventlog / syslog)
• Filsystem (inkl. slettede filer ++) • Webservere, mellomvare og database
• Prosesstabell og minne (++)
• HIDS • Nettverk
• DNS, DHCP, ARP
• Brukeraktivitet • Gatewaylogger (web, mail, fil)
• Browserhistorikk • IDS og Netflow
• Mailaktivitet • Brannvegg (trafikk og audit)
• Nedlastinger
• Programvareinstallasjon • Malware
• Hendelser (klient/server, gatewayer)
23. F
Overvåkning: Ok eller ei? F
G
S
A
A
• Personopplysningsforskriften §7-11:
• Aktivitetslogg i edb-system eller datanett
• (..)
• Unntak fra meldeplikt gjelder bare dersom behandlingen har som formål
• a) administrere systemet, eller
• b) å avdekke/oppklare brudd på sikkerheten i edb-systemet.
• Se også «Merknader til Personopplysningsforskriften»
• Viktigheten av ryddighet:
• Å informere om akseptabel bruk, og kjøreregler for innsyn / loggovervåkning
• Formell aksept fra arbeidstaker ved tilgang til hjemmekatalog, mailboks el.l.
• Være igjennom denne løypen før man trenger den – da kan det være for sent
• Vær på juridisk trygg grunn før tiltak iverksettes
24. F
Analyse: Verktøykasse F
G
S
A
A
• Plattformverktøy • Tredjepartsverktøy
• F.eks. Sysinternals, Volatility,
• Scripting Mandiant Redline, netflowanalyse,
• PowerShell, Perl/Python/Ruby mm. log2timeline, Team Cymru mm.
• Tips: Russ McRees månedlige
• Database Toolsmith-artikler i ISSA Journal
• Normalisering, vasking og korrellering
av informasjon (f.eks. PostgreSQL) • Distribusjoner med verktøy
• REMnux, Backtrack mm.
Viktig:
Evne til å bruke disse verktøyene må etableres i “fredstid”,
ikke midt under en hendelse – da er det ofte for sent
25. F
Analyse: Bevisaspektet F
G
S
A
A
• Flyktighet / volatilitet
• Sikre bevisenes integritet
• Locards prinsipp: “Every contact leaves a trace"
• Arbeide mot speilkopier av disker
• Dokumentasjon
• Innsamling, analyse og håndtering
• “Chain of custody”
• Presentasjon
• Bygge en story rundt tekniske fakta og kunne presentere denne
• I sum:
• Vær edruelig ift. egne ferdigheter på dette området
• Bruk ekstern ekspertise og/eller politi om nødvendig
26. Protect & Proceed Pursue & Prosecute
Behov for
Reetablering
«closure»
Ressurser Lover og policy
Policy Gjennomførbart?
27. F
Skadebegrensning F
G
S
A
A
• Hindre spredning og/eller økt konsekvens, om mulig
• Isolere
• Lukke sårbarhet(er)
• Fjerning av malware
• Andre mitigerende tiltak
• Lockdown av nett eller scrubbing av trafikk
• Failover til alternative løsninger, om mulig
28. F
Verdien av sjekklister G
F
S
A
A
Komplikasjoner redusert
med en tredjedel,
halvering av dødsfall
Forutsigbart, konsistent og repeterbart reaksjonsmønster
Inspirasjon: The Checklist Manifesto av Atul Gawanade
29. F
Eksempler på sjekklister G
F
S
A
A
• Critical Log Review Checklist
• Analyzing Malicious Documents
• Troubleshooting Human Communications • http://cert.societegenerale.com/en/publications.html
• Cheat Sheet for Server Administrators
• Initial Security Incident Questionnaire • IRM-1 : Worm infection
• IRM-2 : Windows intrusion
• Network DDoS Incident Response
• IRM-3 : Unix intrusion
• Reverse-Engineering Malware • IRM-4 : Distributed Denial of Service
• [..] • IRM-5 : Malicious Network Behaviour
• IRM-6 : Website Defacement
• IRM-7 : Windows Malware Detection
www.lennyzeltser.com • IRM-8 : Blackmail
(god blog i tillegg) • IRM-9 : Malware on smartphone
• IRM-10 : Social Engineering
• IRM-11 : Information Leakage
• IRM-12 : Insider Abuse
• IRM-13 : Phishing
• IRM-14 : Scam
Smart å ta utgangspunkt i disse, men bør tilpasses egne behov
30. F
Gjenoppretting F
G
S
A
A
• Når kontroll er oppnådd:
• Reetablering av normal drift
• Switchover til alternative løsninger
• Reversering av temporære tiltak
• Reinstallasjon av berørte/infiserte maskiner
• Husk at backup kan også være berørt
• Friskmelding av løsningen
31. F
Forbedring F
G
S
A
A
• Identifisering av rotårsak(er)
• Identifisering av tiltak
• Prosess (inkl. hendelseshåndteringen selv)
• Teknisk (sikringstiltak – forbedring, nye)
• Organisatorisk (ansvarsforhold, bevissthet mm.)
• Hendelses og –erfaringsrapport
• Utarbeidelse, distribusjon, presentasjon
• Gi input til andre og fremtidige løsninger
• Viktigst: Oppfølgning av tiltak
32. F
Rotårsak: TJX F
G
S
A
A
• Stor behandler av korttransaksjoner i USA
• Kompromittert i 2007, 215 millioner kort stjålet
• Angrepsvektor: et usikret trådløst nett hos en butikk tilknyttet TJX
• Kompromittert i minst 1.5 år før angrepet ble oppdaget i 2008
• The Five Why’s:
1. Hvorfor.. ble kunne det trådløse nettet kompromitteres?
2. Hvorfor.. kunne baksystemene kompromitteres via butikknett?
3. Hvorfor.. var ikke sårbarhetene oppdaget?
4. Hvorfor.. ble ikke angrepet oppdaget?
5. Hvorfor.. kunne omfanget bli så stort?
33. F
Rotårsak: Ormespredning F
G
S
A
A
Rotårsak Feil Konsekvens
Svakheter i Patch ikke installert Orm fikk spre seg
patcheregimet
1. Hvorfor fikk ormen spre seg? Sårbarheten den utnyttet var ikke patchet
The Five Whys?
2. Hvorfor var ikke sårbarheten patchet? a) Maskinen(e) var falt utenfor patcheregimet
b) Patcheregime ikke etablert
c) Maskinen(e) kjørte usupportert release
3. Hvorfor var ikke a)-c) på plass? Manglende prioritering og fokus
4. Hvorfor var det manglende fokus? d) Nedprioritert ift. andre aktiviteter
e) Manglende ressurser
f) Manglende forståelse for behovet for patching
5. Hvorfor manglet d)-f)? a) Manglende ledelsesmessig beslutning
b) Behov for hard prioritering av begrensede ressurser
34. Trender i trusselbildet
Økt profesjonalisering → Målrettede angrep gir større grad av suksess
Økt polering av malware → Ingen/få indikasjoner, lav AV-deteksjon
Økt utholdenhet → En maraton, ikke en sprint
Økt sofistikering → Sammensatte angrep, dybdeforsvar og helhetstenkning
Alt kan kompromitteres → «Design for failure», dybdeforsvar, tenk kreativt
Det klassiske perimeteret er dødt → «Innside» og «utside» gir ikke lenger mye mening
Politisk motiverte angrep → Anonymous, Wikileaks med mer.
35. Motivasjon
Militære
Politisk
formål
Industri- Økonomisk
spionasje kriminalitet
36. «Advanced Persistent Threat» (APT)
• Bredt spekter av angrepsteknikker
Advanced • Unngår deteksjon av vanlige sikringstiltak
• Skjult eksfiltering av informasjon (HTTPS)
• Systematisk kompromittering, low & slow
Persistent • Angriper både i bredde og dybde
• Etablerer bakdører for å komme tilbake
• Tenkende mennesker på den andre siden
Threat • Har kompetanse, motivasjon og struktur
• Koordinering på tvers av mål, rekognosering
Markedsføringsgimmick eller reell trussel?
37. NSMs årsmelding for 2010
• ”Viktige datasystemer trolig infisert”
• ”Avanserte målrettede angrep er krevende å oppdage”
• Februar 2010: Nettsidene til flere offentlige myndigheter
ble utsatt for et distribuert tjenestenektsangrep (DDoS).
• April 2010: Flere ansatte i en privat virksomhet som jobbet
med et bedriftskonfidensielt prosjekt utsatt for målrettede
trojanere i e-post.
• Juli 2010: Mistenkelig nettverkstrafikk fra en data-maskin
tilhørende en ansatt i et departement. På datamaskinen ble
det oppdaget flere trojanere. Den ene samlet inn alle
dokumenter opprettet den siste uken og klargjorde disse
til å bli sendt ut på Internett tilbake til angriperen.
• Nammo: Fem målrettede trojanerangrep
38. Flyten i en kompromittering
• Open source intelligence (Google / LinkedIn mv.)
1. Rekognosering • Scanning og probing
• Ofte via zero-day-sårbarhet (PDF, Flash, Java)
2. Initielt fotfeste •
•
Infisert PDF/Office-dokument
Spearphishing / rettet malvertising
3. Etablere bakdør(er) • Fjernstyring av kompromittert maskin via
Remote Admin Tool (RAT)
• Sårbarheter
4. Elevere rettigheter •
•
Credentials-sniffing
Passordknekking
• Remote Administration Tool (RAT)
5. Utvide fotfeste • Nettverkssniffing
• «Lateral movement»
• Staging-servere
6. Eksfiltrere informasjon • Ut via HTTP(S)
• Kryptert trafikk / filer
• Sekundær trojaner
7. Opprettholde tilgang
39. ... ikke akkurat et nytt konsept
• Lawrence Berkeley National Laboratory (1986)
• Komplekst angrep over mange hopp
• Detektert vha. et $0.75-gap i usage accounting
• Sporet til Markus Hess i Hanover
Det relativt nye er at dette har gått fra å være «gutte-
streker» til profesjonell/organisert krim/statlig virksomhet
40. Angrepet Poison Ivy
med mere
Bruker åpner vedlegg, blir infisert av trojansk
hest på grunn av 0-day sårbarhet i Adobe
Trojansk hest åpner for
Acrobat Reader
fjernstyring av PC, logging av n.n.n.n
brukernavn og passord mv. Shandong, Kina
Gir fotfeste for videre angrep
i nettet
Datatrafikk med ukjent
innhold tilbake til
opphavsadressen
41. Poison Ivy
• Remote Administration Tool (RAT)
• Velkjent, opprinnelig svenskutviklet
• File manager
• Bare ett av veldig mange lignende verktøy • File search
• File transfer
• http://www.poisonivy-rat.com/: • Browse folders
• Regedit / search
• Process manager
• Service manager
• Active ports
• Remote Shell
• Network relaying
• Screen capture
• Audio capture
• NTML hashes
• Share server
• Installed applications
• Windows manager
43. Poison Ivy: Deteksjonsgrad
• 3-4 unike Poison Ivy-varianter i «vårt» angrep
• VirusTotal: 7-45% deteksjon
• Poison Ivy Polymorphic Online Builder ($500)
• Maskering og testing mot antivirusløsninger før bruk
44. Jammen, slikt skjer jo ikke oss!
1. Spamruns
Spredningsvektorer
2. Spearphishing
3. Sosiale media Fake LinkedIn-kampanje
for å spre Zeus
4. Drive-by downloads
5. ”Fake AV”
6. Malvertising
Mailen som ga
angriper brohode
hos RSA i 2011
45. ... et mer lokalt eksempel
1. Bruker søker etter IL Sandviken ved hjelp av Bing, og aksesserer denne
2. Forventede linker: Google, Facebook og hostingleverandør
3. Bonus: Linker mot fem suspekte webservere i fire forskjellige land
4. Usynlig installasjon av avansert trojaner
5. Ingen deteksjon av antimalwareløsninger (oppdaterte standardprodukter)
• Ikke unikt; malvertising via www.bt.no for et par år siden
46. Har vi riktig fokus?
Klassisk soneinndeling + IDSer
Web Appl Data
Unix
«Internt nett»
M&Ms-filosofien: «Hardt skall, mykt indre»
«It’s a useful exercise to assume you’ve been breached and plan accordingly» — Ray Pompon
47. Verizon DBIR: 2009-2012
83% of the attacks were crimes of opportunity
92% of the attacks were not highly difficult
96% were avoidable through simple or intermediate controls
Samt rapporter fra NorCERT, sikkerhetsleverandører, blogger, mailinglister, Twitter mm.
48. Scenarier til ettertanke (I)
Innsidefaktoren
• Hva er konsekvensene ved ondsinnet insider? Admin?
Informasjonslekkasje (overlagt/uhell)
• Tap av laptop / mobiltelefon
Trojaner som gir ekstern angriper fotfeste
• Hvordan detektere?
• Hvordan skadebegrense?
49. Scenarier til ettertanke (II)
Orm i nettet
• Hvordan redusere angrepsflaten?
• Hvordan hindre spredning?
Distribuert tjenestenektangrep (DDoS)
• Overvåkning, Plan B
• Avtale med ISP, teknisk løsning for skrubbing av trafikk
Defacement av webside
• Omdømmerisiko → Mediehåndtering
• Alternativ løsning
50. Noen åpenbare erfaringer
• Faren ved å rope ulv
• Finne riktig balanse mellom tidlig heads-up og prematur varsling
• Faren ved å overkomplisere
• Occams Razor: Den mest nærliggende teorien er ofte den riktige (f.eks. vannverk i USA)
• Ha en plan for rotasjon av personell
• Etter x timer begynner dømmekraft og effektivitet å kollapse fnising i statusmøter
• Bør en som er overtrøtt bestemme å ta ned Internett-forbindelsen?
• Ikke undervurdér kommunikasjonsload
• Kommunkasjonsbehov må balanseres mot faktisk arbeide
• Ta periodisk et steg tilbake for å vurdere helheten i hendelsen
• Fort gjort å miste helhetsbildet og bli styrt av hendelser, fremfor å aktivt ta styringen på en hendelse
51. Utfordringer fremover
1. Bring Your
2. Virtualisering
Own Device
3. Nettsky 4. Mobilitet
”Technology is introduced, utilized, depended upon, obsoleted, standardized, and understood, in that order” – Martin Fouts, HP
52. Oppsummering: Ha...
• En plan for håndtering av sikkerhetshendelser
• Tydelig mandat, avklart ressurssituasjon og eskaleringsveier
• Fokus på de forretningsbehov; skaler i forhold til verdiene
• Kontaktnett (internt/eksternt), verktøykasse og infokilder
53. Oppsummering: Vær...
• Ydmyk ift. egne sikringstiltak
• (det som kan skje andre kan også skje oss)
• Nysgjerrig på hva som skjer i egen infrastruktur
• (innenfor lover og regler)
• Klar over at det organisatoriske aspektet er
minst like viktig som det tekniske
54. I sum –
Bygg noe som fungerer
for din organisasjon
(dette er ikke hyllevare!)
55. Spørsmål?
Oddbjørn Steffensen
• Kontaktinfo:
• oddbjorn.steffensen@evry.com @oddbjorn
• oddbjorn@tricknology.org http://www.oddbjorn.net/
• Andre presentasjoner (http://www.slideshare.net/oddbjorn/)
• Anvendt logghåndtering
• Sikkerhet i en virtualisert verden
• Bli kjent med {FreeBSD,PostgreSQL,Lightroom}
56. For mye jobb? Lightversjonen.
Start
Someone else
I discovered it We’ve
been
discovered it
hacked!
Yes Cover No
it up?
Blame game
Hope it doesn’t Any idea No
Blame game
Yes what
happen again
happened
?
Can Close
the hole
?
Throw money at the
problem and hope it
Despair Can’t
helps
Kilde: NFR
57.
58. Et lite apropos..
“Sequential Analysis of Pansring versus last
Statistical Data Theory”
Abraham Wald (1943) Hvor vil mer pansring gi best effekt?
Kan vi overføre dette til “vår” verden?
