The Old Ways Are Not Enough Anymore Senų būdų jau nepakanka Prisimenu laiką, kai nuskaityti programą dėl pažeidžiamumo jaučiasi kaip pergalė. Jūs paleidžiate keletą automatizuotų įrankių, ištaisėte tai, ką jie pažymėjo, dokumentuojate viską dėl atitikties, ir pereikite į priekį. Šiandienos programos ne tik egzistuoja vietiniuose serveriuose su aiškiomis perimetromis. Jie apima debesies aplinkas, API, konteinerius ir mikropaslaugas, kurios sukasi į viršų ir žemyn. Statinis nuskaitymas, nors ir sudėtingas, nebegali sekti šiuolaikinių sistemų greičio ir sudėtingumo. Why Scanning Alone Isn’t Security Kodėl vienas nuskaitymas nėra saugus Pažeidžiamumo nuskaitymas turi savo vietą. Jis tarnauja kaip esminė ankstyvo įspėjimo sistema. Jis pasakoja, kur jūsų žinomoje kodo bazėje yra pažeisti dalykai, vėliavos pasenusios bibliotekos ir gali nustatyti mažai pakabinančius saugumo vaisius. Bet problema yra ta, kad jis sustoja ten. Tai nepadeda jums suprasti tikrojo tų rizikų svorio. Tai nepaaiškina, kaip vienas trūkumas gali kaskaduoti į daug didesnę verslo grėsmę. Ir tai tikrai nesuteikia jums rizikos sprendimo strategijos už plėtros komandos ribų. Aš mačiau iš pirmų rankų, kaip komandos gali būti palaidotos pagal pažeidžiamumo ataskaitas, kurioms trūksta bet kokio prioriteto. Jie galiausiai lenktyniauja, kad patch problemas, pagrįstas sunkumo rezultatais, kurie buvo suprojektuoti atsižvelgiant į teorinius išnaudojimus, o ne realaus pasaulio pasekmes. Vienas iš labiausiai žalingų prielaidų yra traktuoti visus didelio sunkumo pažeidžiamumus kaip vienodai neatidėliotinus. Jie nėra. Kritinis trūkumas, palaidotas smėlio dėžutėje, gali būti daug mažiau rizikingas nei vidutinio sunkumo klaida, sėdinčio pagrindinėje klientų aptarnavimo sistemoje. Kontekstas yra svarbus. Understanding Risk in Real Business Terms Rizikos supratimas realiame versle Taikymo rizikos valdymo poreikis yra platesnis objektyvas – tas, kuris atspindi ne tik techninius trūkumus, bet ir veiklos realijas, verslo poveikį ir naudotojų poveikį. Pavyzdžiui, mokėjimų apdorojimo modulio problema viršutinio sezono metu turi labai skirtingą svorį nei ta pati problema būtų plėtros smėlio dėžutėje. Taip pat yra išsamumo iliuzija, kurią sukuria nuskaitymo įrankiai. Patogu galvoti, kad jūs padengėte visas savo bazes tik todėl, kad nuskaitymo atgal grįžta švarus. Bet rizika ne visada kyla iš žinomų pažeidžiamumų. Kartais jie kyla iš architektūrinių pasirinkimų, iš skubotų įgyvendinimų, iš blogų įpročių, kurie sukuria laikui bėgant. Moving From Periodic Reviews to Continuous Risk Awareness Perėjimas nuo periodinių peržiūrų prie nuolatinio rizikos suvokimo Šiuolaikinis rizikos valdymas reiškia tvarkyti programas kaip gyvas sistemas. Šios sistemos nuolat vystosi. Su kiekvienu diegimu, integracija ir funkcijų išleidimu rizikos kraštovaizdis keičiasi. Štai kodėl programų rizikos valdymas ateityje turi būti tęstinis, o ne epizodinis. Vienkartiniai vertinimai sprinto ar ketvirčio pabaigoje jo daugiau nesumažina. Ir rizika yra ne tik kažkas, kas turi būti stebima reaktyviai. Yra didžiulė galia būti aktyviu – įterpti rizikos supratimą į projektavimo ir plėtros procesą. Kai saugumo ir rizikos komandos bendradarbiauja anksti, jie gali padėti vadovauti architektūriniams sprendimams taip, kad būtų pašalintos visos pažeidžiamumo klasės, kol jos kada nors pateks į kodinę bazę. Vulnerabilities Evolve Faster Than You Ship — Monitor or Fall Behind Pažeidžiamumai vystosi greičiau nei laivas - stebėti ar nukristi Greitis yra ne tik jūsų turtas, bet ir jūsų priešininkas. Kiekvieną dieną skelbiami nauji pažeidžiamumai. „Exploit“ rinkiniai ginkluojami greičiau nei bet kada anksčiau, o užpuolikai nelaukia patch ciklų. „Real-time“ rizika nebėra teorinė – tai mūšio laukas. Štai griežta tiesa: pažeidžiamumo aptikimo greitis viršijo tradicinę saugumo praktiką. Skirtumas tarp CVE, kuris skelbiamas ir aktyviai naudojamas, dažnai matuojamas valandomis, o ne dienomis. Štai kodėl realaus laiko pažeidžiamumo stebėjimas nėra „geras turėti“, tai yra esminis egzistavimas. Statiniai pažeidžiamumo vertinimai negali sekti.Jums reikia tiesioginės telemetrijos apie jūsų infrastruktūrą ir taikomųjų programų elgesį, grėsmių žvalgybos šaltinius jūsų CI / CD vamzdyne, automatizuotas CVE koreliacijas su jūsų dabartine krūva, ir saugumo šalinimo prioritetus pagal verslo riziką ir išnaudojamumą. Ir štai kickeris: šios įžvalgos turi būti susietos su rinkos požiūriu SLA ir įsipareigojimais.Kadangi kas yra atspari sistema, jei ji žlunga viešai per nulinės dienos krizę? Saugumas ir prieinamumas nebėra atskiri tikslai – jie yra dvi jūsų darbo laiko pažado pusės.Negalite reikalauti patikimumo, neįrodžius, kad esate saugūs dabar, o ne tik praėjusią savaitę. Yes, Some Risk Is Actually Healthy Taip, kai rizika iš tikrųjų yra sveika Tačiau čia yra kažkas, kas nėra pakankamai pasakyta: ne visa rizika yra bloga. Iš tikrųjų kai kurios įtakingiausios naujovės ateina iš komandų, kurios buvo pasirengusios prisiimti tam tikrą apskaičiuotą riziką. Pagalvokite apie produkto paleidimą, kuris paskatins apyvartą, arba platformos integraciją, kuri atvers naujas rinkas. Tai reiškia ne tik nuskaityti pažeidžiamumus, bet ir apibrėžti, koks rizikos lygis yra priimtinas, kokie rodikliai rodo, kad reikia įsikišti, ir kaip realiu laiku stebėti tuos rodiklius. We Need Better Metrics—Not Just More of Them Mums reikia geresnių metrų – ne tik daugiau jų Čia didžiulį vaidmenį atlieka rodikliai, bet ne tik pagrindiniai, pavyzdžiui, „atvirų pažeidžiamumo spragų skaičius“. Tai yra tuštybės statistiniai duomenys, jei jie nesusiję su rezultatais. Ko mums reikia, tai rodikliai, kurie pasakoja istoriją. Kaip greitai mes sprendžiame svarbiausius klausimus? Ar matome pasikartojančius incidentus toje pačioje kodo srityje? Kaip dabar palyginame su praėjusiu ketvirčiu rizikos poveikio požiūriu? Atsakymai į šiuos klausimus suteikia daugiau įžvalgų nei bet kuris plokščio sunkumo balas kada nors galėjo. Organizacijos, kurios klestės šiame naujame kraštovaizdyje, yra tos, kurios riziką vertina kaip bendrą atsakomybę. Kūrėjai, produktų vadybininkai, architektai, saugumo komandos ir net teisiniai ir atitikties žmonės turi vaidmenį. Ir kuo daugiau rizikos valdymas integruojamas į kasdienius darbo srautus, tuo mažiau jis jaučiasi kaip atskira našta. Jis tampa kultūros dalimi, o ne tik kontroliniu tašku prieš išleidimą. The Real Shift Is Cultural, Not Just Technical Tikrasis pokytis yra kultūrinis, o ne tik techninis Žinoma, tokio tipo integracijos pasiekimas neįvyksta per naktį. Jis prasideda iš naujo apibrėžiant, kaip rizika suvokiama. Ne kaip blokatorius, bet kaip signalas. Ne kaip priežastis nustoti kurti, bet kaip priežastis kurti protingiau. Ir tai reikalauja įrankių ir sistemų, kurios gali palaikyti šią filosofiją - įrankius, kurie siūlo matomumą, kontekstą ir realaus laiko įžvalgą į tai, kas vyksta visoje taikymo kraštovaizdyje. Galų gale, programų rizikos valdymo ateitis nėra apie skaitytuvų pakeitimą, bet apie pokalbio didinimą.Tai apie perėjimą nuo pažeidžiamumo medžioklės prie strateginių sprendimų priėmimo.Tai apie perėjimą už atitikties ribų ir į erdvę, kurioje rizika aktyviai valdoma, nuolat matuojama ir sąmoningai naudojama inovacijoms remti. Mes įžengiame į laiką, kai greitis ir saugumas nebėra priešingos jėgos. Tikrasis iššūkis yra ne tai, kaip greitai galite paleisti – tai, kaip saugiai galite tai padaryti, nesumažindami. 
 
 Ši istorija buvo platinama kaip Sanya Kapoor išleidimas pagal HackerNoon verslo dienoraščių programą. Ši istorija buvo platinama kaip Sanya Kapoor išleidimas pagal HackerNoon verslo dienoraščių programą.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Read My Stories

Šis garso įrašas sukurtas originalia istorijos kalba!

Programų rizikos valdymo ateitis: už pažeidžiamumo nuskaitymo ribų

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps