Kas reaģē uz brīdinājumu? SOC un SLA
Brīdinājums e-pastā vēl nav reaģēšanas process. Pirms monitoringa palaišanas izlemiet, kurš signālu pārbaudīs, kam ziņos, kādu darbību drīkst veikt un kas pieņems biznesu ietekmējošu lēmumu.
Sadaliet notikumu skaidros posmos
Datu saņemšana, noteikuma izpilde, sākotnējā izvērtēšana un saziņa ar klientu ir dažādi posmi. Ja piedāvājumā minēts reaģēšanas laiks, pajautājiet, no kura brīža to skaita un ar kuru darbību tas beidzas. Automātiska paziņojuma nosūtīšanu nedrīkst sajaukt ar analītiķa izmeklēšanu vai incidenta ierobežošanu.
Aprakstiet arī gadījumus, kad mērījumu aptur vai pakalpojumu nevar pilnvērtīgi sniegt. Nepieejams avots, nepietiekamas tiesības vai neatbildošs lēmuma pieņēmējs var ietekmēt darbu. Šādi nosacījumi jāredz pirms incidenta. SLA ir konkrēta vienošanās par pakalpojumu, nevis saīsinājums, kas aizstāj pienākumu aprakstu.
Analītiķu laiks nav datu vākšanas laiks
Dati var ienākt nepārtraukti arī tad, ja komanda tos pārbauda darba laikā. Izvērtējiet, kādu risku rada nakts, nedēļas nogales un svētku dienas. Ja vajadzīgs diennakts cilvēku pārklājums, līgumā jābūt skaidrai pieejamībai, aizvietošanai un saziņas kārtībai. Plānotājā izvēlētais laiks ir jūsu iecere, nevis automātiski nodrošināts pakalpojums.
Nosakiet primāro un rezerves kontaktu katrai incidenta smaguma pakāpei. Pārbaudiet, vai kontaktam ir piekļuve sistēmām un tiesības pieņemt lēmumu. Dežurējošs cilvēks, kurš tikai pārsūta ziņu citam cilvēkam, var radīt papildu aizkavi. Testējiet arī situāciju, kurā ierastais saziņas kanāls nav pieejams.
Vienojieties par ierobežošanas pilnvarām
Ierīces izolēšana, konta bloķēšana vai tīkla savienojuma pārtraukšana var samazināt incidenta izplatīšanos, bet ietekmēt arī uzņēmuma darbu. Iepriekš nosakiet, kuras darbības sniedzējs drīkst veikt patstāvīgi un kurām vajadzīgs klienta apstiprinājums. Aprakstiet izņēmumus kritiskām sistēmām un lēmuma dokumentēšanas veidu.
OffSeq pakalpojuma apraksts nodala brīdināšanu un norādes no pārvaldītām reaģēšanas darbībām; konkrētais modelis ir atkarīgs no izvēlētā pakalpojuma un SLA. Neuzskatiet monitoringa iegādi par automātisku garantiju diennakts incidentu palīdzībai. Tvērumā precizējiet arī digitālās izmeklēšanas, atjaunošanas un ārējās komunikācijas uzdevumus.
Saskaņojiet prioritātes ar biznesu
Vienai un tai pašai tehniskai darbībai dažādās sistēmās var būt atšķirīga ietekme. Kritiska pakalpojuma administrēšana prasa citu kontekstu nekā testa vides maiņa. Sagatavojiet resursu kritiskuma informāciju, atļautās apkopes un īpašniekus, lai analītiķis var pieņemt pamatotāku lēmumu. Uzturiet šo informāciju aktuālu.
Incidenta izvērtēšanā atdaliet zināmo no pieņēmumiem. Ziņojumā noder novērotā darbība, tās laiks, skartie resursi, pierādījumi un ieteiktais nākamais solis. Organizācijas atbildīgajam jāsaprot, vai viņam jāapstiprina darbība, jāsniedz konteksts vai jāiesaista cita komanda. Neviennozīmīga eskalācija var aizkavēt pat tehniski pareizu atklāšanu.
Izmēģiniet pienākumu nodošanu
Veiciet iepriekš saskaņotu galda mācību vai tehniski drošu scenārija pārbaudi. Izsekojiet saziņai, lēmumiem un darbību uzskaitei. Pārbaudiet rezerves kontaktu, sniedzēja un klienta sadarbību, kā arī pierādījumu saglabāšanu. NIST SP 800-61 Rev. 3 uzsver incidentu reaģēšanas iesaisti kopējā kiberrisku pārvaldībā.
Pēc pārbaudes pierakstiet konkrētus labojumus: nepareizu kontaktu, neskaidru pilnvaru, trūkstošu avotu vai nesaprotamu paziņojumu. Nozīmējiet atbildīgo un pārskatīšanas datumu. Ja piemērojamas incidentu ziņošanas prasības, to izvērtēšanai izmantojiet aktuālās NKC vadlīnijas. Monitoringa sniedzēja ziņojums klientam pats par sevi neizpilda visus organizācijas ziņošanas pienākumus.
Vienojieties arī par incidenta slēgšanu. Kurš apstiprina, ka ierobežojums noņemams un sistēmu drīkst atgriezt darbā? Kā tiek nodoti ieteikumi ilgtermiņa labojumiem? Pēc notikuma saglabājiet lēmumu secību un pārskatiet, vai izmantotās pilnvaras bija atbilstošas. Šī informācija palīdz uzlabot nākamo reaģēšanu un parāda, kur pakalpojuma robežas vai klienta iekšējā kārtība jāprecizē.