Nuolatinė kontrolės priemonių stebėsena: žinokite, ką įrodo signalas

Vienkartinė peržiūra apibūdina būklę, kuri buvo nagrinėjama tuo metu. Nuolatinė kontrolės priemonių stebėsena sumažina atotrūkį tarp pokyčių ir jų aptikimo, jei patikros apima tinkamą visumą ir kas nors imasi veiksmų, kai jos nepavyksta. Nė vienas metodas neįrodo daugiau, nei leidžia jo įrodymai.

Technologijų vadovui pagrindinis klausimas yra ne tai, ar informacinė suvestinė žalia. Svarbu, ką tas žalias rezultatas nustato: kurios sistemos buvo patikrintos, kokia sąlyga buvo testuota, kaip neseniai buvo surinkti duomenys ir kurie gedimo būdai lieka už testo ribų.

Naudinga stebėsenos programa šiuos klausimus paverčia inžinerine sutartimi. Ji sujungia patikimą duomenų rinkimą, aiškią testo logiką, atskaitingą reagavimą ir įrodymus, kuriuos gali patikrinti kitas asmuo.

Ką iš tikrųjų matuoja nuolatinė kontrolės priemonių stebėsena

Nuolatinė kontrolės priemonių stebėsena (CCM) naudoja pasikartojančius stebėjimus ir testus, kad nustatytų, ar apibrėžtos kontrolės sąlygos tebėra įvykdytos. Duomenys gali būti renkami pagal įvykius, pagal tvarkaraštį arba derinant abu būdus. „Nuolatinė“ nebūtinai reiškia „akimirksniu“; dokumentuokite faktinį periodiškumą ir aptikimo vėlavimą.

Būtina atskirti tris lygmenis:

• Kontrolės tikslas: siekiamas rezultatas, pavyzdžiui, neleisti neteisėtos viešos prieigos prie klientų duomenų.
• Įgyvendinta kontrolės priemonė: mechanizmas, padedantis pasiekti šį rezultatą, pavyzdžiui, saugyklos prieigos apribojimai ir pakeitimų patvirtinimai.
• Stebėsenos testas: stebėjimas, naudojamas daliai to mechanizmo įvertinti, pavyzdžiui, viešos prieigos nustatymų užklausa.

Sėkmingas konfigūracijos testas pagrindžia ribotą išvadą apie stebėtus nustatymus. Jis automatiškai neįrodo, kad visi prieigos keliai saugūs, kad patvirtinimo procesai veikė tinkamai ar kad organizacija atitinka visą atitikties reikalavimą.

NIST kibernetinio saugumo sistema suteikia naudingą struktūrą valdymo, apsaugos, aptikimo ir reagavimo rezultatams susieti. Šešios jos funkcijos, įskaitant „Govern“, taip pat padeda paaiškinti, kodėl stebėsena priklauso platesniam rizikos valdymo procesui, o ne veikia atskirai kaip užtikrinimo sistema.

Pasirinkite kontrolės priemones, kurios duoda naudingus signalus

Pradėkite nuo kontrolės priemonių, kurių gedimai svarbūs, kurių būklę galima stebėti ir kurių atsakingas asmuo gali imtis prasmingų veiksmų. Ankstesni incidentai, audito radiniai, architektūros pokyčiai ir rizikos vertinimai yra geresni prioritetų nustatymo pagrindai nei turimų automatinių patikrų skaičius.

Prieigos stebėsenai gali tekti sujungti tapatybių įrašus su darbo santykių būsena ir paskyrų inventoriais. Tai sukuria naudingus signalus, bet kartu ir suderinimo problemų: paslaugų paskyros nėra darbuotojai, rangovų darbo pabaigos datos gali skirtis, o vėluojantys šaltinių atnaujinimai gali sukelti klaidingus radinius.

Politikos veiksmingumui, vadovybės priežiūrai ir rizikos priėmimui reikia periodinio žmogaus vertinimo. Politikos susipažinimo patvirtinimas yra susipažinimo įrodymas, o ne įrodymas, kad žmonės politiką supranta ar jos laikosi.

Prieš kurdami automatizavimą, parašykite testo specifikaciją

Prieš įgyvendindami užklausą, apibrėžkite visumą, šaltinį, dažnumą, laukiamą sąlygą, ribinę vertę ir atsakingą asmenį. Be šių detalių komandos gali nesutarti, ar tas pats rezultatas yra gedimas.

Praktinė testo specifikacija turėtų apimti:

• Paskirtį ir apimtį: sprendžiamą riziką, taikomą paslaugą, aplinkas ir išteklių tipus.
• Visumos šaltinį: kaip nustatomas visas laukiamų išteklių rinkinys.
• Stebėjimo šaltinį: naudojamą API, eksportą, įvykių srautą ar kitus įrodymus.
• Sprendimo taisyklę: laukiamas vertes, leistinus nuokrypius, išimtis ir patvirtintas išimtis.
• Laiką: duomenų rinkimo periodiškumą, aktualumo ribą ir laukiamą aptikimo vėlavimą.
• Atsakomybę: kontrolės priemonės savininką, stebėsenos prižiūrėtoją, reaguojantį asmenį ir peržiūrėtoją.
• Įrodymus: išsaugotas įvestis, testo versiją, rezultatą, laiko žymas ir tolesnių veiksmų įrašus.

Pataisų stebėsenai formuluotė „visi serveriai atnaujinti“ yra per daug miglota. Geresnė specifikacija nurodo valdomus gamybinius serverius, autoritetingą inventorių, pažeidžiamumų šaltinį, sunkumo kategorijas, patvirtintus šalinimo terminus ir tai, kaip elgiamasi su nepalaikomomis sistemomis. Tai yra konkrečios organizacijos sprendimai, o ne visuotinės teisės aktų nustatytos ribos.

Atskirkite trūkstamus duomenis nuo neigiamo radinio. Jei įrenginys neturi naujo įvertinimo, stebėsena negali daryti išvados, kad jame nėra vėluojamų šalinti pažeidžiamumų. Ji turėtų nurodyti nežinomą būseną arba atskirą aprėpties gedimą.

Valdykite testo logikos versijas. Pakeitus ribinę vertę, išteklių filtrą ar išimtį, istorinių rezultatų reikšmė gali pasikeisti, net jei informacinės suvestinės etiketė lieka ta pati.

Duomenų rinkimo būklę kurkite kaip atskirą kontrolės priemonę

Žalia patikra su pasibaigusio galiojimo jungtimi ar neišsamiu išteklių sąrašu gali klaidinti. Naudokite bent tris rezultato būsenas: sėkminga, nesėkminga ir nežinoma. Kai patikra apima daug išteklių, rodykite mišrius rezultatus, o ne slėpkite gedimus už bendro balo.

Duomenų rinkimo būklei reikia atskirų stebėjimų:

• Paskutinis sėkmingas duomenų surinkimas ir pagrindinių šaltinio duomenų amžius.
• Autentifikavimo nesėkmės, leidimų pakeitimai ir API klaidos.
• Puslapiavimo užbaigimas, užklausų dažnio ribojimo valdymas ir daliniai atsakymai.
• Laukiamos ir faktiškai stebimos paskyros, ištekliai ar įvykių šaltiniai.
• Aiškios išimtys ir ištekliai, kurių nepavyko įvertinti.

Vertindami debesijos saugyklų viešumą, užfiksuokite, kurios paskyros ir ištekliai buvo patikrinti. Nauja paskyra, esanti už jungties leidimų ribų, sukuria aprėpties spragą, net jei kiekvienas surinktas rezultatas sėkmingas. Palyginkite stebimas paskyras su nepriklausomai tvarkomu paskyrų inventoriumi; tikrinant jungtį pagal jos pačios išteklių sąrašą, neatsiskleis tai, ko ji nemato.

Kur praktiška, duomenims rinkti naudokite tik skaitymo leidimus, apsaugokite prisijungimo duomenis ir ribokite prieigą prie surinktų įrodymų. Stebėsenos eksportuose gali būti jautrių tapatybių, infrastruktūros detalių ar konfigūracijos informacijos. Saugojimo ir prieigos sprendimai turėtų atspindėti šį jautrumą.

Periodiškumą rinkitės pagal pokyčių dažnį, poveikį ir duomenų rinkimo apribojimus. Kasdienė patikra gali tikti lėtai kintančiai sąlygai; viešos prieigos pakeitimai gali pateisinti greitesnį aptikimą. Įvykiais grindžiamos patikros gali sutrumpinti vėlavimą, tačiau suplanuotas suderinimas padeda pagauti praleistus įvykius. Nėra vieno valandinio tvarkaraščio, tinkančio kiekvienai kontrolės priemonei.

Susiekite aptikimą su reagavimu, kurį galima išbandyti

Įspėjimas nėra užbaigtas kontrolės priemonės atsakas. Nukreipkite išimtis atsakingam asmeniui, nurodydami paveiktą išteklių, verslo kontekstą, stebėtą sąlygą, laukiamą sąlygą ir reagavimo tikslą. Nurodykite, kas perima atsakomybę, kai pagrindinis atsakingas asmuo nepasiekiamas.

Rūšiuojant reikėtų atskirti tikrą gedimą, klaidingą testo logiką, trūkstamus įrodymus ir patvirtintą išimtį. Šiems rezultatams reikia skirtingų veiksmų. Išimtyje turėtų būti nurodyta jos apimtis, pagrindimas, tvirtintojas, kompensuojamosios priemonės ir galiojimo pabaigos ar peržiūros data. Ji neturėtų tyliai paversti nepavykusios techninės sąlygos sėkmingu rezultatu.

Išsaugokite radinį, veiksmą, sprendimą ir pakartotinį testą. Uždaryta užduotis įrodo, kad darbo procesas užbaigtas; naujas stebėjimas yra stipresnis įrodymas, kad techninė sąlyga ištaisyta.

Grupuokite pasikartojančius įspėjimus pagal tą pačią neišspręstą sąlygą, o ne kurkite naują užduotį kiekvieno vykdymo metu. Peržiūrėkite triukšmingas patikras ir ribines vertes, kad svarbūs gedimai liktų matomi. Eskaluokite pagal poveikį ir praėjusį laiką, o ne vien pagal išsiųstų pranešimų skaičių.

Jei svarstomas automatinis ištaisymas, atskirai įvertinkite jo leidimus, atšaukimo kelią ir galimą veiklos sutrikdymą. Tai, kad sąlygą galima saugiai stebėti, nereiškia, kad ją saugu keisti automatiškai.

Pavyzdys: debesijos saugyklų viešumo stebėsena

Toliau pateikiamas iliustracinis sprendimas, o ne nustatyta atitikties taisyklė. Tarkime, paslauga naudoja tris gamybines debesijos paskyras ir tikisi 120 saugyklos išteklių. Jos vidinis tikslas yra, kad klientų duomenų saugyklos neleistų neteisėtos viešos prieigos.

Platformos komanda paskyrų inventorių tvarko nepriklausomai nuo stebėsenos jungties. Konfigūracijos rinkiklis veikia kas 30 minučių, o išteklių aptikimas suderinamas kasdien. Komanda senesnius nei 60 minučių duomenis laiko pasenusiais. Šie laiko pasirinkimai yra šio pavyzdžio prielaidos.

Testas užfiksuoja paskyrų ir išteklių identifikatorius, atitinkamus prieigos nustatymus, duomenų surinkimo laiką ir testo versiją. Patvirtinti vieši ištekliai nurodomi atskirai, su atsakingu asmeniu ir peržiūros data; plati visos paskyros išimtis būtų netinkama.

Vieno vykdymo rezultatai rodo:

Pranešimas vien „118 išteklių sėkmingi“ nuslėptų dvi skirtingas problemas ir nežinomą papildomą visumą. Ketvirta paskyra reiškia, kad pradinis vardiklis nebėra išsamus.

Dėl viešos prieigos radinio atsakingas asmuo patikrina, kokie duomenys buvo saugomi ir ar poveikis reikalauja incidento valdymo. Prieigos apribojimas ištaiso stebėtą konfigūraciją; jis neatsako, ar prie duomenų buvo prieita anksčiau.

Įrodymų paketą sudaro radinys, apimties palyginimas, pakeitimo įrašas, sprendimas dėl tyrimo ir sėkmingas pakartotinis testas. Tada imituotas leidimo gedimas patikrina, ar nežinomi rezultatai sukuria matomą darbą, o ne palieka ankstesnę žalią būseną nepakitusią.

Teikite ataskaitas apie aprėptį, vėlavimą ir neišspręstą poveikį

Vienas atitikties procentas suspaudžia per daug informacijos. Techninės ir vadovybei skirtos ataskaitos turėtų atskleisti balo prielaidas.

Naudingi rodikliai:

• Aprėptis: stebėti taikymo srities ištekliai, palyginti su laukiamais ištekliais.
• Aktualumas: ištekliai, kurių įrodymai neviršija nustatytos amžiaus ribos.
• Aptikimo vėlavimas: laikas nuo kontrolės priemonės gedimo pradžios iki matomo radinio, kai pradžia žinoma.
• Reagavimo veiksmingumas: patvirtinimo ir sprendimo laikas, palyginti su vidiniais tikslais.
• Gedimų išliekamumas: neišspręstų sąlygų trukmė ir pasikartojimas.
• Išimčių higiena: pasibaigusios, neperžiūrėtos ar neįprastai plačios išimtys.

Nežinomų išteklių neįtraukite į sėkmingų rezultatų visumą, bet apie juos praneškite aiškiai. Šalia procentų nurodykite vardiklius ir išimtis. Atskirkite pagerėjimą, kurį lėmė ištaisymas, nuo pagerėjimo, kurį lėmė susiaurinta apimtis ar sušvelninta taisyklė.

Stebėsena gali padėti priimti rizikos sprendimus, parodydama pasikartojančius gedimus ar ilgalaikį poveikį. Tačiau ji pati savaime neapskaičiuoja kiekvieno scenarijaus tikimybės ir poveikio verslui. Tokiems vertinimams vis dar reikia paslaugų savininkų ir rizikos peržiūrėtojų konteksto.

Išlaikykite periodinį vertinimą ir nepriklausomą patikrą

Vienkartiniai vertinimai ir pasikartojanti stebėsena atsako į skirtingus klausimus. Stebėsena gali nustatyti nuokrypius tarp peržiūrų ir sumažinti pasikartojantį įrodymų rinkimą. Tikslinis vertinimas gali išnagrinėti projektavimo tinkamumą, patikrinti sudėtingus sprendimus ir išbandyti prielaidas, kurių automatinės taisyklės negali išspręsti.

Abu metodai turi sąnaudų. Pasikartojančioms patikroms reikia prižiūrėti duomenų rinkimą, turėti rūšiavimo pajėgumų ir patikimus inventorius. Periodinėms peržiūroms reikia sutelktų peržiūrėtojų pastangų, be to, tarp stebėjimų lieka intervalai. Derinį rinkitės pagal riziką, o ne laikykite kurį nors metodą visuotinai pakankamu.

ISO/IEC 27001 valdymo sistemoje stebėsenos įrodymai gali padėti atlikti apibrėžtos apimties vertinimo darbus. Jie nepakeičia rizikos tvarkymo, vidaus audito, vadovybės peržiūros ar taikomų reikalavimų vertinimo. Kiekvieną testą susiekite su konkrečia sąlyga, kurią jis pagrindžia; susiejimai su sistemomis nėra įrodymas, kad įvykdyti visi reikalavimai.

Stebėsenos logiką iš naujo įvertinkite po architektūros pokyčių, incidentų, apimties išplėtimo ir reikšmingų kontrolės priemonės pakeitimų. Įtraukite sąmoningų gedimų ir trūkstamų duomenų testus. Stebėsena, kuri niekada nėra parodžiusi nesėkmingos ar nežinomos būsenos, nėra įrodžiusi viso savo reagavimo kelio.

Įrodymus pateikite jų veiklos kontekste

Secani sumodeliuokite taikymo sričiai priklausančias sistemas ir paslaugas, paskirkite atsakingus asmenis ir peržiūrėtojus, o stebėsenos eksportus ar kitus įrodymus pridėkite prie kontrolės priemonių, reikalavimų ir sprendimų, kuriuos jie pagrindžia. Aprėpties spragoms ir neišspręstiems peržiūros klausimams naudokite užduotis. Išsaugokite nuorodas į šaltinius, komentarus, patvirtinimus ir laiko žymas; DI padedamus pasiūlymus peržiūrėkite prieš jais remdamiesi. Signalus generuoja veiklos saugumo įrankiai, o šis darbo procesas užtikrina, kad jų apimtis ir peržiūrėtos išvados liktų atsekamos.

Pradėkite nuo vienos pasikartojančios patikros. Dokumentuokite, ką ji įrodo, palyginkite jos visumą su nepriklausomu inventoriumi ir imituokite tiek techninį, tiek duomenų rinkimo gedimą. Plėskite tik tada, kai atsakingas asmuo gali parodyti aptikimą, reagavimą, pakartotinį testavimą ir įrodymų peržiūrą.