Lühidalt: Lessons learned pärast IT-intsidenti tähendab: pärast tehnilist lõppu istuvad kõik osalised kokku, rekonstrueerivad kulgu, nimetavad süüdistamata, mis läks hästi ja mis mitte, ning tuletavad sellest meetmed vastutajate ja tähtaegadega. See kehtib ka peaaegu-intsidentide puhul, nagu PHP2Shelli nädal, mis kulges õnnelikult. Otsustav ei ole protokoll, vaid hilisem kontroll, kas meetmed said ellu viidud.
Miks on nädal pärast intsidenti nii oluline
Kui server töötab taas ja paigad on paigaldatud, on kiusatus kiiresti igapäeva juurde naasta suur. Just siis läheb kaduma kõige väärtuslikum teadmine: kes märkas millal mida? Kus puudus teave? Milline otsus võttis liiga kaua aega? Mõne nädala pärast ei tea seda enam keegi täpselt.
- aasta oktoobri nädal on selle hea näide. Paljud ettevõtted paigasid PHP servereid, kirjutasid veebimajutajatele, lülitasid veebisaite ennetavalt välja või kindlustasid logisid. Isegi kui sissemurdmist ei tuvastatud, peitub selles palju õppematerjali. Kui kaua kulus, enne kui oli selge, millised süsteemid on mõjutatud? Kes pidi väljalülitamist kinnitama ja kas see isik oli kättesaadav?
Tehnilisi samme pärast rünnakut käsitleb kontrollnimekiri pärast häkkimist. See artikkel jätkab sealt: mida me sellest õpime?
Lessons learned IT-intsidendi puhul: järelarutelu põhireeglid
Järelarutelu ei ole tribunal. Kes kardab, et vigadel on isiklikud tagajärjed, jutustab ainult poole loost. Seetõttu kehtib põhimõte: otsime põhjusi kulgudes, tööriistades ja teabes, mitte süüdlasi. Inimesed tegutsesid teadmisega, mis neil sel hetkel oli.
Kutsuge kõik, kes olid kaasatud, ka välised nagu veebimajutaja, agentuur või teenusepakkuja, kui võimalik. Planeerige kaks tundi. Paluge eelnevalt materjali: piletid, vestluste ajalood, e-kirjad, märkmed, logiväljavõtted. Neist sünnib ajajoon, arutelu selgroog. Kuidas seda puhtalt üles ehitada, kirjeldab artikkel Intsidendi ajajoone koostamine.
Juhendamist ei peaks enda peale võtma isik, kes intsidenti operatiivselt juhtis. Ta hindaks muidu oma enda otsuseid. Neutraalne on näiteks keegi teisest osakonnast või väline partner.
Kulg kuues sammus
- Tutvustada ajajoont: Mis juhtus millal, esimesest teatest lõpuni? Märkida ajajoone lüngad, mitte oletada.
- Mis läks hästi? Alustage teadlikult positiivsest. See näitab, mis peaks jääma, ja lõdvestab ringi.
- Kus takerdus? Iga viivitus, iga puuduv teave, iga ebakindlus kogutakse, esialgu lahendusi arutamata.
- Selgitada põhjused: Olulisimate punktide puhul küsige mitu korda, miks. „Paik tuli hilja“ on tähelepanek, „keegi ei teadnud, et vanas serveris töötab veel PHP“ on põhjus.
- Määrata meetmed: Iga põhjuse kohta konkreetne meede, vastutav isik ja tähtaeg.
- Leppida kokku järelkontroll: Kuupäev nelja kuni kaheksa nädala pärast, mil kontrollitakse, mis on ellu viidud.
Tüüpilised küsimused ja meetmed pärast PHP olukorda
Allolev tabel näitab küsimusi, mis tekivad pärast PHP2Shelli-sarnast olukorda sageli, ja võimalikke vastuseid meetmete kujul. Mitte iga neist ei sobi igale ettevõttele; see on mõeldud pilgu teritamiseks.
| Küsimus järelarutelul | Tüüpiline tähelepanek | Võimalik meede |
|---|---|---|
| Kuidas me turvaaugust teada saime? | Juhuslikult uudistest | Tellida sihipäraselt php.net-i ja BSI turvateated |
| Kas teadsime, millised süsteemid on mõjutatud? | Nimekiri puudulik, vanasüsteem unustatud | Kõigi veebisaitide ja serverite inventar PHP versiooniga |
| Kes tohtis väljalülitamise üle otsustada? | Ebaselge, otsus viibis | Fikseerida otsustusõigus hädaolukorra plaanis |
| Kas veebimajutaja kinnitas paiga? | Ainult suuliselt või üldse mitte | Nõuda kirjalikku kinnitust, täiendada lepingut |
| Kas kõik PHP protsessid taaskäivitati? | Ei kontrollitud | Võtta taaskäivitus ja kontroll kindla sammuna kasutusele |
| Kas logid olid alates 20.10. olemas? | Osaliselt juba üle kirjutatud | Pikendada säilitusaega, kindlustada logid tsentraalselt |
| Kuidas kulges kommunikatsioon sees ja väljas? | Töötajad said teada ajakirjandusest | Valmistada ette sisemine esmateade |
Fikseerige ka see, mida te teadlikult ei muuda. Vahel on tähelepanek teada, kuid meede oleks ebaproportsionaalne. Dokumenteeritud otsus on parem kui vaikne unustamine.
Eraldage protokollis tõendatud faktid, tõenäolised eeldused ja lahtised küsimused. Just pärast PHP2Shelli, mille kohta ei ole avaldatud kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise), on see eristus oluline.
Protokollist muutuseni
Lessons learned'i kõige sagedasem ebaõnnestumine on banaalne: protokoll saadetakse laiali ja siis ei juhtu midagi. Kolm harjumust aitavad selle vastu. Esiteks kuulub iga meede süsteemi, milles niikuinii töötatakse, see tähendab piletisüsteemi või ülesannete nimekirja, mitte eraldi dokumenti. Teiseks saab järelkontroll kindla kuupäeva juhtkonna kalendris. Kolmandaks voolavad tulemused hädaolukorra plaani, kontaktide nimekirja ja harjutustesse.
Kes tahab tähelepanekuid kontrollida, ootamata järgmist päris intsidenti, saab need läbi mängida hädaolukorra harjutuses laua taga. Ja kus järelarutelu näitab, et uuendused sõltusid liiga palju juhusest, tasub minna üle paigahaldusele protsessina.
Andmekaitse, kindlustuse ja vajaduse korral ametiasutuste jaoks on lõpparuanne lisaks oluline dokument. Õiguslik hindamine, näiteks kas IKÜM art 33 järgi oli teavitamine vajalik, kuulub aga andmekaitsespetsialistile või advokaadile, mitte tehnilisse järelarutellu.
Kuidas PHP SOS konkreetselt aitab?
- Koostame logidest, piletitest ja märkmetest intsidendi ajajoone ja märgime lüngad.
- Juhendame järelarutelu neutraalse osapoolena ja jälgime, et otsitakse põhjusi, mitte süüdlasi.
- Tõlgime tehnilised tähelepanekud meetmeteks koos töömahu hinnangu ja prioriteediga.
- Toetame järelkontrolli ja viime soovi korral tehnilised meetmed ise ellu, nii nagu on ette nähtud meie intsidendile reageerimises.
Kokkuvõte
Intsident on niigi kallis. Kes seda ei analüüsi, maksab järgmisel korral uuesti. Aus järelarutelu ilma süüdistamiseta, puhas ajajoon ning meetmed nime ja tähtajaga teevad rasket nädalast püsiva turvalisuse võidu.
Korduma kippuvad küsimused
Millal peaks lessons-learned-kohtumine toimuma?
Kui intsident on tehniliselt lõppenud, kuid mälestus on veel värske. Praktikas on end tõestanud kuupäev umbes ühe kuni kahe nädala pärast lõppu. Varem puudub sageli distants, hiljem kustuvad detailid.
Kas järelarutelu tuleks teha ka peaaegu-intsidendi järel?
See tasub end ära. PHP2Shelli-sarnane olukord, kus lõpuks midagi ei juhtunud, näitab siiski, kus kulg takerdus. Need tähelepanekud on eriti väärtuslikud, sest need saadi ilma kahjuta.
Kes järelarutelu juhib?
Parem keegi, kes ei ole intsidenti ise operatiivselt juhtinud. Nii jääb juhtimine neutraalseks ja kellelgi ei ole vaja oma otsuseid kaitsta. See võib olla ka väline teenusepakkuja.
Mis tulemustega juhtub?
Iga tähelepanek muutub meetmeks, millel on vastutav isik ja tähtaeg. Hädaolukorra plaani, kontaktide nimekirja ja dokumentatsiooni kohandatakse. Mõne nädala pärast kontrollib keegi, mis tegelikult ellu viidi.