- Esminis skirtumas tarp ištaisymo (galutinio problemos sprendimo) ir švelninimo (laikino poveikio tikimybės sumažinimo).
- Pažeidžiamumų valdymo ciklo, pagrįsto realiu inventoriumi, įdiegimas, prioritetų nustatymas pagal verslo riziką ir techninis patvirtinimas.
- Rizikos mažinimo taikymas įvairiose srityse – nuo „DevSecOps“ saugumo iki stichinių nelaimių prevencijos ir visuomenės sveikatos.
- Nuolatinio matomumo ir automatizavimo svarba siekiant išvengti saugumo procesų pablogėjimo dėl operacinės apkrovos.
Kalbėdami apie saugumo valdymą bet kurioje srityje, nesvarbu, ar tai būtų pažangiausios IT, ar nelaimių prevencija, pastebime, kad rizika yra neišvengiama konstanta. Jokia sistema nėra tobula, o jokia organizacija nėra visiškai saugi, todėl svarbiausia ne bandyti visiškai pašalinti pavojų, o žinoti, kaip sumažinti bet kokių galimų problemų poveikį, kad verslas ar visuomenė galėtų toliau sklandžiai funkcionuoti.
Tokios sąvokos kaip švelninimas, ištaisymas ir mažinimas dažnai painiojamos, tačiau iš tikrųjų tai yra tos pačios operacinės dėlionės dalys . Šių skirtumų supratimas skiria įmonę, kuri tiesiog „gesina gaisrus“, nuo organizacijos, turinčios tikrą atsparumo strategiją , gebančią numatyti nesėkmes ir greitai reaguoti, kol nedidelė klaida netapo finansine ar reputacijos katastrofa.
Pagrindiniai skirtumai tarp ištaisymo ir mažinimo
Norint pradėti darbą, labai svarbu suprasti, kas nutinka, kai aptinkame pažeidžiamumą. Idealus būdas yra taisyti pažeidžiamumą , nes jis apima problemos sprendimą pačioje pradžioje. Tai reiškia programinės įrangos pataisos įdiegimą, pasenusios įrangos pakeitimą arba sistemos pertvarkymą, kad trūkumas visiškai išnyktų. Iš esmės tai yra grėsmės pašalinimas , kad ja nebūtų galima pasinaudoti ateityje.
Tačiau realus gyvenimas yra sudėtingesnis ir ne visada galime iš karto ką nors pataisyti. Čia praverčia mažinimas kaip laikinas arba paliatyvus sprendimas. Mažinimas reiškia ne klaidos pašalinimą, o tikimybę, kad kažkas ja pasinaudos. Pavyzdžiui, jei neturime pataisos programinei įrangai, galime uždaryti tinklo prievadą, kuris ją atskleidžia; pažeidžiamumas vis dar yra, bet užpuolikas nebeturi atvirų durų prieigai gauti.
Svarbu pabrėžti, kad problemų sprendimas paprastai yra tarpinis žingsnis, siekiant laimėti laiko . Tai ne galutinis sprendimas, o saugos priemonė, kol suplanuotas techninės priežiūros laikotarpis arba laukiama, kol tiekėjas išleis galutinį atnaujinimą. Iš esmės, problemos sprendimas visada yra geriau nei prieigos blokavimas.
Pažeidžiamumų valdymas IT aplinkoje
Kibernetinio saugumo pasaulyje pažeidžiamumų valdymas nėra vien tik nuskaitymas kartą per mėnesį ir PDF failo archyvavimas. Tai nuolatinis rizikos mažinimo ciklas , kuris prasideda nuo tikslaus žinojimo, ką turite. Negalite apsaugoti to, ko nematote, todėl pirmas esminis žingsnis yra tikras turto (serverių, debesijos, tapatybių ir BYOD įrenginių) inventorizavimas.
Kai tik įgysime matomumą, procesas turi vykti logiška tvarka, kad išvengtume beprotybės dėl tūkstančių įspėjimų:
- Nuolatinis atradimas: Vienkartinių auditų nepakanka; reikalinga nuolatinė perimetro ir vidaus analizė.
- Prioritetų nustatymas pagal kontekstą: Ne viskas, kas techniškai „rimta“, yra labai svarbu verslui. Prioritetai turėtų būti nustatomi remiantis... realus poveikis ir kritiškumas paveikto turto.
- Operacijų koordinavimas: Iššūkis yra priversti kūrimo, sistemų ir saugumo komandas susitarti, kaip įgyvendinti pakeitimus.
- Techninis patvirtinimas: Labai svarbu patikrinti, ar pleistras suveikė ir ar rizika išnyko iš tikrųjų.
Daugelis įmonių nepakankamai įvertina šį procesą ir apsiriboja paviršutinišku nuskaitymu. Dėl to kaupiasi neišspręstos problemos , o vadovybė mano, kad viskas kontroliuojama, kai iš tikrųjų jie stebi tik paviršutiniškai. Siekiant to išvengti, pataisų automatizavimas ir integravimas su bilietų pardavimo sistemomis, tokiomis kaip „Jira“, yra pagrindinės priemonės, padedančios išvengti pažeidžiamumų nepastebėjimo.
Išplėstinės strategijos „DevSecOps“ komandoms
Šiuolaikinėse kūrimo aplinkose rizikos šalinimas turėtų būti integruotas į darbo eigą nesukeliant kliūčių. Tikslas – kad priklausomybių atnaujinimai būtų saugus procesas , o ne rizika, dėl kurios atsiranda klaidingas kūrimas. Programinės įrangos sudėties analizės (SCA) įrankiai leidžia kūrėjams tiksliai žinoti, kuris pažeidžiamumas yra taisomas ir kokios naujos rizikos gali atsirasti dėl pakeitimo.
Tikslas – pasiekti pusiausvyrą, kurioje egzistuotų ir stabilumas, ir pristatymo greitis . Kai taisymas yra nuspėjamas ir automatizuotas, kiekvieno sprinto metu sutaupoma valandų valandas rankinės pakeitimų žurnalų peržiūros, todėl programinė įranga gali daug užtikrinčiau pasiekti produkciją ir išvengti sistemos funkcionalumo trikdančių saugos pataisų.
Pasauliniai požiūriai: nuo stichinių nelaimių iki verslo valdymo
Jei peržengsime grynai skaitmeninės srities ribas, pamatysime, kad žalos mažinimas taikomas ir visuomenės sveikatai bei civilinei saugai. Socialinėje srityje yra ryškus skirtumas tarp rizikos mažinimo (orientuoto į prevenciją, pavyzdžiui, vairavimo apsvaigus nuo narkotikų prevenciją) ir žalos mažinimo (orientuoto į pagalbą, pavyzdžiui, adatų keitimo programas ligoms išvengti).
Panašiai ir nelaimių rizikos mažinimas (DRR) grindžiamas pagrindine prielaida: stichinės nelaimės kaip tokios neegzistuoja; veikiau egzistuoja stichiniai pavojai , kurie tampa nelaimėmis dėl mūsų sprendimų. Miesto pažeidžiamumas priklauso nuo to , kaip statome namus ar kaip tvarkome žemę. Todėl DRR siekia analizuoti ir mažinti veiksnius, dėl kurių esame trapūs, kad bendruomenės taptų atsparesnės ir labiau pasirengusios.
Nesvarbu, ar tai serverio, ar evakuacijos plano valdymas, metodologija yra panaši. Reikia atlikti išsamų vertinimą , įgyvendinti prevencines priemones ir, svarbiausia, parengti nenumatytų atvejų planus . Kad ir kaip stengtumėmės sušvelninti jų padarinius, visada bus nenumatytų įvykių, o aiškus ekstremalių situacijų veiksmų planas padeda išvengti visiško chaoso.
Nuolatinis matomumas, grėsmių prioritetizavimas pagal jų faktinį poveikį ir pasikartojančių reagavimo būdų automatizavimas leidžia bet kuriai organizacijai, nepriklausomai nuo jos sektoriaus, nustoti veikti aklai. Griežta operacinė drausmė ir galimybė patvirtinti kiekvieną veiksmą užtikrina, kad atakos paviršius būtų kuo mažesnis, o krizių valdymas taptų nuolatinio tobulėjimo ir tvaraus saugumo procesu.
