Post mortem-erfaringer fra incident response -om å gjøre det beste ut av en dårlig situasjon. Margrete Raaum (MIS) FIRST SC og UiO-CERT

Transkript

1 Post mortem-erfaringer fra incident response -om å gjøre det beste ut av en dårlig situasjon Margrete Raaum (MIS) FIRST SC og UiO-CERT Incident response En organisert og konsistent måte å håndtere sikkerhetshendelser Man ønsker å minimere skaden (datatap eller -lekkasje) Man ønsker å minimere kostnadene (gjenoppretting eller rykteskader) Man ønsker å finne ut hva som har skjedd samtidig som man vil ha tjenesten opp på beina igjen Man kan sørge for kontinuerlig forbedring Man får derfor også naturlig en funksjon som kontroller

2 Hva er en sikkerhetshendelse? Forsøk på å få uautorisert adgang til et system eller data, enten dette er vellykket eller ei Uønskede avbrudd, eller «tjenestenekt» (DoS) Uautorisert bruk av et system for databehandling eller -lagring Endring av et systems hardware, firmware eller softwarekonfigurering uten eiers samtykke Forsøk på å få uautorisert adgang til et system eller data, Hvor veldefinert er autorisasjonen eller mangel på sådan? Hvor mange forsøk er fortsatt uskyldige forsøk? Er det OK å prøve seg hvis det er for å avsløre dårlig sikring eller mangel på en eller annen policy? Hva med «the hacker defense»?

3 Uønskede avbrudd, eller «tjenestenekt» (DoS) Konfigurasjonsfeil eller programmeringsfeil Vanskelig å avgjøre om man har med et angrep å gjøre utviklingen går mot å kalle det DDoS fordi det er noen andres feil og er mye omtalt På hvilket punkt skal man si «dette er en incident»? Dette er nøkkelspørsmålet! Uautorisert bruk av et system for databehandling eller -lagring Gmail, facebook og sommerbilder. Er det OK å bruke jobbmaskiner til lagring fordi da får man backup? Er det OK å benytte regnekraft som ikke er i bruk?

4 Endring av et systems hardware, firmware eller softwarekonfigurering uten eiers samtykke Dette burde være klart så lenge eierskapet er klart. IRT oppstart: policies Hvem er du ansvarlig overfor og hvordan er deres innflytelse? Problemer i horisonten om de sitter lavt i organsisjonen. Regler Lover Forskrifter Må dra i samme retning og ikke motsi hverandre AUP (IT-reglementet) Må være forståelige for alle

5 IRT-oppstart: organisatoriske smerter Dersom man tar over ansvar som noen andre allerede føler eierskap til så vil organisasjonen gå gjennom faser som beskrevet i Raaum-Grøndahl modellen Raaum-Grøndahl-modellen ;-) Sjokk Sikkerhetifisering Motstand Disclaimer Kamp Akseptanse Passivhet

6 Hvorfor er organisatorisk plassering så viktig? Man vil gjerne unngå at driftsoppgaver spiser timer Ha makt til å få gjennom sikkerhetsendringer selv om de medfører merarbeid Kunne styre hendelseshåndtering, både for å ha riktig og nok kompetanse og for å unngå bevisforspillelse Klok av skade Man bør ha retten til å avgjøre alvorlighetsgrad (fra liten/stor incident til katastrofe) Nøkkelkvalifikasjoner for CERT-personellet Teknisk flink på sitt fagområde Personlige kvalifikasjoner alle må ha: rolig, tålmodig, god fantasi, ryddig, diskret. Noen må i tillegg ha lederegenskaper, og noen må være god med folk (brukere, drift og toppledelsen) Teknisk kunnskap er viktig for for eksempel forensics eller en penetrasjonstest, men uten koordinasjon under håndteringen og god sluttdokumentasjon er det ikke nok.

7 Håndteringsprosessen Viktig å være kjent i organisasjonen og kjent for å kunne bistå Rapporteringsrutinene må være enkle og ikke-irriterende Raske og beroligende svar Triage tidskritisk fase Lekker vi informasjon? Sprer hendelsen seg? Trenger man memory dump? Kan vi finne ut hvem som står bak? Titan: en død kjempe Det vi håndterer (alle gjør ikke alt) Deteksjon (logger: maskiner, rutere, netflow, DNS...) Phishing (honningbrukere) & svindel Botnet Malware Rogue programvare installert av folk her på bruket Kompromitterte servere (forensics) Nettverksdesign, produktevaluering, PGP support Informasjonslekkasjer Saker som man ikke vet om skal anmeldes eller ei (avhengig av alvorlighetsgrad), men ting kan ikke «uobserveres». Risikoanalyse

8 Post mortem og kontinuerlig forbedring Man ønsker å benytte enhver hendelse til en positiv input på et eller annet sted Vanlige feller Prøve å dekke over at man har hatt hendelser La selvgodheten eller flauhetens slør legge seg over hendelsen etter endt håndtering Ikke sette av nok tid til post mortem

9 Hvilke deler av prosessen kan forbedres? Alle.

10 Kontaktpunkter Skjema eller ei Kildeverifisering Tilbakemelding Er det en sikkerhetshendelse Hva er omfanget? Hvem er berørt

11 Er organisasjonen og rutinene på plass Skjønner vi hva vi ser? Inngrep må stå i forhold til hendelsen Gjenoppretting Backup? Manuell rensing? Motarbeide misforståelse hos folk flest og ikke minst hos pressen (jfr «innbrudd i houston») Overbevise om at man har lært noe av hendelsen utad

12 «Dette skulle ikke skjedd» Rutineendriner Kontroller for deteksjon Sikring for å unngå hendelsen (jfr skriverne)