Chris Christiansen
79b100caff
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
- SECURITY.md: Overordnet visjon med lenker til alle manifestfiler - SECURITY_AUDITS.md: Historikk og To-Do liste - RUNBOOK.md: 6 operasjonelle scenarier (ukjent bruker, eksponert secret, 401/403, 50x, VPC-SC, BinAuthz) - INCIDENT_RESPONSE.md: PICERL-modell med eskaleringsmatrise - SECRET_MANAGEMENT.md: Policy + lokal utvikling - ACCESS_CONTROL.md: IAM-policy med service account-oversikt - COMPLIANCE.md: TYR, Binary Auth, KMS-attestasjon Opprydding: - Slettet sensitive filer (test_secret.txt, final-secret-test.txt, tyr/certs/ca_password.txt) - Slettet engangsskript og midlertidige filer - Oppdatert .gitignore med *.txt
88 lines
3.8 KiB
Markdown
88 lines
3.8 KiB
Markdown
# 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. |
|