Krisehåndtering
Dette er stegene som skal følges dersom en eller flere servere er eller er mistenkt å være blitt kompromittert, viktige systemer er nede eller om det er noen annen form for krise.
Steg 1: Don't panic
Ta det med ro. Pust ut. Det å gjøre noe overilt er som regel mer skadelig enn å vente fem minutter, tenke over situasjonen litt og diskutere seg i mellom. (Men ikke vent fem dager heller.)
Steg 2: Samle nøkkelpersoner
Det viktigste for å få ting til å flyte bra er å få alle involverte i samme rom, enten fysisk eller virtuelt. Gjengsjef og serveransvarlig er ofte naturlige personer å samle; om hendelsen involverer Billig, burde Billig-ansvarlig involveres.
I de fleste tilfeller vil gamle panger være en svært nyttig ressurs, men de kan ikke gjøre noe om man ikke sørger for å holde dem oppdatert på hva folk tenker og hva som gjøres. Pek ut en person som er kommunikasjonsansvarlig. Sørg for hyppig og regelmessig oppdatering av gjengen internt, f.eks.: «Vi tror at cassarossa deltar i et DDoS-angrep fordi det går unormalt mye trafikk ut fra den og den ikke svarer på SSH. Serveransvarlig er på vei inn i Anette og undersøker nå.» Sørg for regelmessig oppdatering av eventuelle andre (som FS eller UKST). Om det er riktig å informere eksternt eller ikke avhenger av situasjonen (om det er nedetid, er det som regel riktig å gjøre, da det fort vil være hundrevis av mennesker som lurer på når ting kommer opp igjen). Oppdateringer under en pågående hendelse bør alltid inkludere når neste oppdatering kommer, for eksempel «Neste oppdatering kommer om en halvtime, altså 17:00, eller tidligere om vi har mer informasjon.»
Steg 3: Få oversikt over situasjonen
Finn ut hva som er skjedd. Hvorfor tror man det? Hva er konsekvensene? Hvem er berørt? Hvem burde informeres?
Steg 4: Respons
Riktig respons vil avhenge av situasjonen. Mulige ting å vurdere inkluderer:
- Finne og tette angrepsvektoren som er brukt
- Bytte passord, spesielt rotpassord
- Ta ned berørte tjenester (f.eks. ved å nappe nettet; husk at å ta strømmen kan slette viktig informasjon)
- Sikre logger og andre bevis
- Gjenopprette systemer fra backup
- Om det er behov for å informere eksterne: Snakke med FS.
Listen er ikke uttømmende.
Steg 5: Postmortem
Når problemet er løst, burde det skrives en intern rapport om hva som har skjedd; en såkalt postmortem. PM-en burde inkludere:
- Hva som skjedde
- Tidslinje
- Hva gikk rett
- Hva gikk galt og burde rettes på til neste gang
Lest av
| Navn | Dato |
|---|---|
| Herman Øie Kolden | 2018-10-26 |
| Alexander Marchand-Melsom | 2018-11-01 |
| yngvem | 2018-11-08 |
| Erling Van De Weijer | 2020-10-29 |
| Theodor René Carlsen | 2018-11-13 |
| Emil Telstad | 2019-10-31 |
| Agnar Martin Bjørnstad | 2020-10-18 |
| Bjørnar Gullikstad Hem | 2020-10-08 |
| Siri Mykland | 2020-10-08 |
| Matias Skjetne | 2020-10-09 |
| Magne Halvorsen | 2020-10-15 |
| Erlend Skaaden | 2020-10-15 |
| Theodor René Carlsen | 2020-10-18 |
| Ole Peder Brandtzæg | 2020-10-18 |
| Thea Kvinnegard | 2020-10-19 |
| Stian Forseth | 2020-10-21 |
| Truls Henrik Jakobsen | 2020-10-22 |
| Carl Aarrestad | 2020-10-29 |
| Markus Selnes | 2022-01-13 |
| Jon Martinus Rødtang | 2023-09-14 |
| Mikkel Arvid Bergstrand | 2023-11-14 |
| Sebastian Bugge | 2023-11-14 |
| Vegar Karlsen | 2023-11-15 |
| Borgar Barland | 2023-11-20 |
Lenker: Start, nagios, pci saq a, pci saq c, pci saq d
Epost: itk@samfundet.no | Telefon: 992 15 925 | Sist endret: 2023-11-20 20:38 | Revisjon: 40 (historie, blame) | Totalt: 1905 kB | Rediger