# OSVxCC Incident Response Plan (IRP)

> Dette dokumentet definerer prosedyren for å håndtere bekreftede sikkerhetshendelser. Målet er å reagere raskt, effektivt og kontrollert for å minimere skade og gjenopprette normal drift.

---

## Faser i Hendelseshåndtering

En sikkerhetshendelse følger disse seks fasene (PICERL-modellen):

### 1. Preparation (Forberedelse)
**Status: ✅ Pågår**
- **Mål:** Sørge for at verktøy, prosesser og ressurser er på plass FØR en hendelse.
- **Aktiviteter:**
  - Utvikle og vedlikeholde sikkerhetsdokumentasjon (SECURITY.md, RUNBOOK.md, etc.).
  - Konfigurere logging og alerting.
  - Definere roller og ansvar.
  - Gjennomføre øvelser.

### 2. Identification (Identifisering)
- **Mål:** Bekrefte at et varsel eller en anomali er en reell sikkerhetshendelse.
- **Prosedyre:**
  1. Følg relevante prosedyrer i `RUNBOOK.md` for å verifisere varselet.
  2. Fastslå hendelsens art, omfang og alvorlighetsgrad.
  3. Hvis det er en reell hendelse: **Erklær en sikkerhetshendelse** og gå til neste fase.

### 3. Containment (Innkapsling)
- **Mål:** Forhindre at hendelsen sprer seg og begrense skaden.
- **Strategier:**
  - **Kortsiktig:** Isolere berørte systemer. Eksempler:
    - Endre brannmurregler for å blokkere trafikk.
    - Deaktivere en kompromittert service account.
    - Ta ned en spesifikk Cloud Run-revisjon.
  - **Langsiktig:** Gjenopprette fra en kjent, sikker backup i et isolert miljø for analyse.

### 4. Eradication (Utryddelse)
- **Mål:** Fjerne årsaken til hendelsen fra systemet.
- **Aktiviteter:**
  - Fjerne skadevare eller uautoriserte verktøy.
  - Patche sårbarheter.
  - Tilbakestille kompromitterte passord, hemmeligheter og nøkler.

### 5. Recovery (Gjenoppretting)
- **Mål:** Trygt gjenopprette berørte systemer til normal drift.
- **Prosedyre:**
  1. Verifiser at årsaken er utryddet.
  2. Gjenopprett systemer fra sikre backuper.
  3. Overvåk systemene nøye for tegn til unormal aktivitet.

### 6. Lessons Learned (Lærdom)
- **Mål:** Analysere hendelsen for å forhindre gjentakelse.
- **Aktiviteter:**
  - Gjennomfør en "post-mortem"-analyse.
  - Hva skjedde? Hva gikk bra? Hva kan forbedres?
  - Oppdater dokumentasjon (`RUNBOOK.md`, `SECURITY.md`, etc.) og systemkonfigurasjon basert på funnene.

---

## Roller og Ansvar

| Rolle | Ansvarlig | Beskrivelse |
|-------|-----------|-------------|
| **Incident Commander** | Chris Christiansen | Har overordnet ansvar for håndteringen av hendelsen. Tar kritiske beslutninger. |
| **Technical Lead** | Gemini (assistert av Chris) | Utfører teknisk analyse, innkapsling, utryddelse og gjenoppretting. |

---

## Kommunikasjon og Eskalering

### Kommunikasjonskanal
-   All operativ kommunikasjon under en aktiv hendelse skal foregå i en dedikert, privat Slack-kanal: **`#incident-response`**.
-   Dette sikrer at all informasjon er samlet på ett sted og kun tilgjengelig for de som er involvert i håndteringen.

### Varsling
-   **CRITICAL/HIGH-hendelser:** Varsling av Incident Commander og Technical Lead skjer automatisk via **PagerDuty**.
-   **MEDIUM/LOW-hendelser:** Varsling skjer via en @-mention i `#incident-response`-kanalen i normal arbeidstid.

---

## Alvorlighetsgrader

| Nivå | Beskrivelse | Eksempel |
|--------|-------------|----------|
| **CRITICAL (1)** | Aktivt datainnbrudd, tap av sensitive data, systemer er nede. | Angriper har root-tilgang og eksfiltrerer data. |
| **HIGH (2)** | System er kompromittert, men innkapslet. Potensial for datatap. | En sårbarhet i en webapplikasjon er utnyttet, men VPC-SC forhindrer dataeksfiltrasjon. |
| **MEDIUM (3)** | Potensiell sårbarhet utnyttet, men med begrenset impact. | En bruker har urettmessig fått forhøyede, men begrensede, rettigheter. |
| **LOW (4)** | Mindre konfigurasjonsfeil eller anomalier uten umiddelbar risiko. | En unødvendig brannmurregel er åpen mot et internt nettverk. |