chris/OSVauco
1
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity
8aa533eecc
OSVauco/docs/INCIDENT_RESPONSE.md
Chris Christiansen 79b100caff
Some checks are pending
Check Python Version Consistency / Check Python Version (push) Waiting to run
Details
docs(security): komplett sikkerhetsdokumentasjon med 7 manifestfiler 
- 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
2026-09-04 08:25:57 +00:00

3.8 KiB
Raw Blame History

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.