Īsi sakot: Lessons Learned pēc IT incidenta nozīmē: pēc tehniskā noslēguma visi iesaistītie sanāk kopā, rekonstruē norisi, bez vainīgo meklēšanas nosauc, kas norisēja labi un kas ne, un no tā atvasina pasākumus ar atbildīgajiem un termiņiem. Tas attiecas arī uz gandrīz-incidentiem, piemēram, viegli pārciestu PHP2Shell nedēļu. Izšķirošs nav protokols, bet vēlākā kontrole, vai pasākumi ir īstenoti.
Kāpēc nedēļa pēc incidenta ir tik svarīga
Kad serveris atkal darbojas un ielāpi ir uzstādīti, kārdinājums ātri atgriezties ikdienā ir liels. Tieši tad tiek zaudētas vērtīgākās zināšanas: kurš kad ko pamanīja? Kur trūka informācijas? Kurš lēmums ieilga? Pēc dažām nedēļām to precīzi nezina neviens.
- gada oktobra nedēļa ir labs piemērs. Daudzi uzņēmumi ielāpoja PHP serverus, rakstīja hostinga pakalpojumu sniedzējiem, piesardzības nolūkā atslēdza vietnes vai nodrošināja žurnālus. Arī ja ielaušanās netika konstatēta, tajā ir daudz mācību vielas. Cik ilgi aizņēma, līdz bija skaidrs, kuras sistēmas ir skartas? Kuram bija jāapstiprina atslēgšana, un vai šī persona bija sasniedzama?
Pašus tehniskos soļus pēc uzbrukuma aplūko Kontrolsaraksts pēc uzlaušanas. Šis raksts sākas pēc tam: ko mēs no tā mācāmies?
Lessons Learned IT incidentā: pēcsanāksmes pamatnoteikumi
Pēcsanāksme nav tribunāls. Kas baidās, ka kļūdām būs personiskas sekas, stāsta tikai pusi stāsta. Tāpēc ir spēkā princips: mēs meklējam cēloņus norisēs, rīkos un informācijā, nevis vainīgos. Cilvēki rīkojās ar zināšanām, kādas viņiem bija tajā brīdī.
Uzaiciniet visus, kas bija iesaistīti, arī ārējos, piemēram, hostinga pakalpojumu sniedzēju, aģentūru vai pakalpojumu sniedzēju, ciktāl iespējams. Ieplānojiet divas stundas. Iepriekš lūdziet materiālus: biļetes, tērzēšanas vēsturi, e-pastus, piezīmes, žurnālu izvilkumus. No tā rodas laika līnija, sanāksmes mugurkauls. Kā to kārtīgi uzbūvēt, apraksta Incidenta laika līnijas izveide.
Moderēšanu nevajadzētu uzņemties personai, kas incidentu operatīvi vadīja. Citādi tā vērtētu savus lēmumus. Neitrāls ir, piemēram, kāds no citas nodaļas vai ārējs partneris.
Norise sešos soļos
- Iepazīstināt ar laika līniju: kas notika kad, no pirmā ziņojuma līdz noslēgumam? Laika līnijas robus atzīmēt, nevis minēt.
- Kas darbojās labi? Apzināti sāciet ar pozitīvo. Tas parāda, kas jāsaglabā, un atslābina apli.
- Kur aizķērās? Katra aizkavēšanās, katra trūkstošā informācija, katra nenoteiktība tiek apkopota, sākumā bez diskusijas par risinājumiem.
- Noskaidrot cēloņus: par svarīgākajiem punktiem vairākkārt jautājiet „kāpēc”. „Ielāps ienāca vēlu” ir konstatējums, „neviens nezināja, ka vecajā serverī vēl darbojas PHP” ir cēlonis.
- Noteikt pasākumus: katram cēlonim konkrēts pasākums, atbildīga persona un termiņš.
- Vienoties par pēckontroli: termiņš četru līdz astoņu nedēļu laikā, kurā tiek pārbaudīts, kas īstenots.
Tipiski jautājumi un pasākumi pēc PHP situācijas
Turpmākā tabula rāda jautājumus, kas pēc situācijas, kāda bija ar PHP2Shell, bieži rodas, un iespējamās atbildes pasākumu veidā. Ne katra der katram uzņēmumam; tā paredzēta uztveres asināšanai.
| Jautājums pēcsanāksmē | Tipisks konstatējums | Iespējams pasākums |
|---|---|---|
| Kā mēs uzzinājām par nepilnību? | Nejauši no ziņām | Mērķtiecīgi abonēt php.net un BSI drošības paziņojumus |
| Vai mēs zinājām, kuras sistēmas ir skartas? | Saraksts nepilnīgs, aizmirsta vecā sistēma | Visu vietņu un serveru inventārs ar PHP versiju |
| Kurš drīkstēja lemt par atslēgšanu? | Neskaidrs, lēmums aizkavējās | Lēmuma pieņemšanas pilnvaras nostiprināt ārkārtas rīcības plānā |
| Vai hostinga pakalpojumu sniedzējs apstiprināja ielāpu? | Tikai mutiski vai nemaz | Pieprasīt rakstveida apstiprinājumu, papildināt līgumu |
| Vai visi PHP procesi tika pārstartēti? | Nav pārbaudīts | Pārstartēšanu un kontroli iekļaut kā fiksētu soli |
| Vai žurnāli no 20.10. bija pieejami? | Daļēji jau pārrakstīti | Pagarināt glabāšanas ilgumu, žurnālus centralizēti nodrošināt |
| Kā norisa komunikācija uz iekšu un uz āru? | Darbinieki uzzināja no preses | Sagatavot iekšējo pirmo informāciju |
Fiksējiet arī to, ko apzināti nemainiet. Dažkārt konstatējums ir zināms, bet pasākums būtu nesamērīgs. Dokumentēts lēmums ir labāks par klusu aizmiršanu.
Protokolā nošķiriet pierādītus faktus, ticamus pieņēmumus un atklātus jautājumus. Tieši pēc PHP2Shell, kuram nav publicētu, apstiprinātu kompromitācijas indikatoru (Indicators of Compromise), šī nošķiršana ir svarīga.
No protokola uz pārmaiņām
Biežākā Lessons Learned neveiksme ir banāla: protokols tiek izsūtīts, un tad nekas nenotiek. Pret to palīdz trīs ieradumi. Pirmkārt, katrs pasākums jāiekļauj sistēmā, kurā tāpat tiek strādāts, tātad biļešu sistēmā vai uzdevumu sarakstā, nevis atsevišķā dokumentā. Otrkārt, pēckontrolei ir fiksēts termiņš vadības kalendārā. Treškārt, rezultāti tiek iestrādāti ārkārtas rīcības plānā, kontaktu sarakstā un vingrinājumos.
Kas atziņas vēlas pārbaudīt, negaidot nākamo īsto incidentu, var tās izspēlēt ārkārtas vingrinājumā pie galda. Un kur pēcsanāksme parāda, ka atjauninājumi pārāk atkarīgi no nejaušības, vērts pāriet uz ielāpu pārvaldību kā procesu.
Datu aizsardzībai, apdrošināšanai un vajadzības gadījumā iestādēm noslēguma ziņojums turklāt ir svarīgs dokuments. Juridiskais novērtējums, piemēram, vai ziņojums saskaņā ar VDAR 33. pantu bija nepieciešams, tomēr pieder datu aizsardzības speciālistam vai juristam, nevis tehniskajai pēcsanāksmei.
Kā PHP SOS palīdz konkrēti?
- Mēs no žurnāliem, biļetēm un piezīmēm izveidojam incidenta laika līniju un atzīmējam robus.
- Mēs moderējam pēcsanāksmi kā neitrāla puse un raugāmies, lai tiktu meklēti cēloņi, nevis vainīgie.
- Mēs pārvēršam tehniskos konstatējumus pasākumos ar darbietilpības aplēsi un prioritāti.
- Mēs pavadām pēckontroli un pēc vēlēšanās paši īstenojam tehniskos pasākumus, kā paredzēts mūsu incidentu reaģēšanā (Incident Response).
Secinājums
Incidents ir pietiekami dārgs. Kas to neizvērtē, nākamreiz maksā vēlreiz. Godīga pēcsanāksme bez vainīgo meklēšanas, kārtīga laika līnija un pasākumi ar vārdu un termiņu padara sarežģītu nedēļu par ilgstošu drošības ieguvumu.
Biežāk uzdotie jautājumi
Kad jānotiek Lessons Learned sanāksmei?
Kad incidents tehniski ir noslēgts, bet atmiņa vēl svaiga. Praksē sevi pierāda termiņš aptuveni vienu līdz divas nedēļas pēc noslēguma. Agrāk bieži trūkst distances, vēlāk detaļas izbālē.
Vai pēcsanāksme jārīko arī pēc gandrīz-incidenta?
Tas atmaksājas. Situācija kā PHP2Shell, kurā galu galā nekas nenotika, tomēr parāda, kur norises aizķērās. Šīs atziņas ir īpaši vērtīgas, jo rodas bez zaudējumiem.
Kurš vada pēcsanāksmi?
Vislabāk kāds, kas incidentu nav operatīvi vadījis. Tā moderēšana paliek neitrāla un nevienam nav jāaizstāv savi lēmumi. Tas var būt arī ārējs pakalpojumu sniedzējs.
Kas notiek ar rezultātiem?
Katra atziņa kļūst par pasākumu ar atbildīgo personu un termiņu. Ārkārtas rīcības plāns, kontaktu saraksts un dokumentācija tiek pielāgoti. Pēc dažām nedēļām kāds pārbauda, kas faktiski ir īstenots.