4. juulil korraldasime suure . Täna avaldame Andrej Novikovi ettekande kokkuvõtte Qualys'ist. Ta räägib, milliseid etappe tuleb läbida, et luua toimiv haavatavuste haldamise tööprotsess. Spoiler: skaneerimiseni jõuame alles poole tee peal.

Samm nr 1: Määrake haavatavuste haldamise protsesside küpsuse tase
Alguses tuleb aru saada, millisel tasemel teie organisatsioon haavatavuste haldamise protsesside küpsuse osas asub. Alles seejärel saate mõista, kuhu liikuda ja milliseid samme astuda. Enne skaneerimise ja muude tegevustega alustamist peavad organisatsioonid viima läbi sisetööd ja mõistma, kuidas teie praegused protsessid on korraldatud nii IT kui ka infotehnoloogia turbe seisukohalt.
Proovige vastata järgmistele põhiküsimustele:
- kas teil on varade inventeerimise ja klassifitseerimise protsessid;
- kui sageli skaneeritakse IT-infrastruktuuri ja kas kogu infrastruktuur on hõlmatud, kas te näete kogu pilti;
- kas teie IT-ressursse jälgitakse;
- kas teie protsessides on sisse viidud mingid KPI-d ja kuidas te mõistate, et need täidetakse;
- kas kõik need protsessid on dokumenteeritud.

Samm № 2: Tagage infrastruktuuri täielik katvus
Te ei saa kaitsta seda, millest te ei tea. Kui teil puudub täielik ettekujutus oma IT-infrastruktuurist, ei saa te seda kaitsta. Kaasaegne infrastruktuur on keeruline ja muudatuste all pidevalt, nii kvantitatiivselt kui kvalitatiivselt.
Nüüd põhineb IT-infrastruktuur mitte ainult klassikaliste tehnoloogiate kogumil (töötajad, serverid, virtuaalmasinate), vaid ka suhteliselt uutel – konteineritel, mikroteenustes. Infoturveteenus väldib viimaseid, kuna nende korral on keeruline kasutada olemasolevaid tööriistade komplekte, mis koosnevad peamiselt skaneerijatest. Probleem seisneb selles, et ükski skaneerija ei suuda katab kogu infrastruktuuri. Et skaneerija saaks igasse infrastruktuuri punkti jõuda, peab ühtima mitu tegurit. Aktiiv peab olema organisatsiooni perimeetri sees skaneerimise hetkel. Skaneerijal peavad olema võrguühendused varade ja nende kontodega, et koguda täielikku teavet.
Meie statistika kohaselt, kui rääkida keskmisest või suurest organisatsioonist, jääb ligikaudu 15–20% infrastruktuurist skannerite tähelepanuta erinevatel põhjustel: vara on väljas perimeetrist või ei ilmu kunagi büroosse. Näiteks töötaja sülearvuti, kes töötab eemalt, kuid on juurdepääs ettevõtte võrku, või vara, mis asub välistes pilveteenustes nagu Amazon. Ja skanner ei pruugi neid varasid üldse teada, kuna need on tema nägemisalas väljas.
Kogu infrastruktuuri katmiseks tuleb kasutada mitte ainult skannereid, vaid ka terve hulga sensoreid, sealhulgas passiivse liikluse kuulamise tehnoloogiaid uute seadmete avastamiseks teie infrastruktuuris, agendi andmete kogumise meetod, et saada teavet – see võimaldab saada andmeid reaalajas, ilma skannimiseta ja ilma mandaate eraldamata.

3. samm: Teostage varade kategooria määramine
Kõik varad pole võrdselt väärtuslikud. Teie ülesanne on määrata, millised varad on olulised ja millised mitte. Ükski tööriist, sealhulgas skanner, ei suuda seda teie eest teha. Ideaalis analüüsivad õiguskaitse, IT ja äri koos infrastruktuuri, et tuvastada äri kriitilised süsteemid. Neile määratlevad nad vastuvõetavad mõõdikud kättesaadavuse, terviklikkuse, konfidentsiaalsuse, RTO/RPO jne osas.
See aitab määrata prioriteete haavatavuste haldamise protsessis. Kui teie spetsialistid saavad teavet haavatavuste kohta, pole see enam lihtsalt leht, kus on tuhanded haavatavused kogu infrastruktuuris, vaid granuleeritud teave, arvestades süsteemide kriitilisust.

Samm № 4: Hinnake infrastruktuuri
Ja alles, mis puudutab teie infrastruktuuri haavatavuste hindamist, jõuame neljandal sammul. Soovitame sel etapil keskenduda mitte ainult tarkvara haavatavustele, vaid ka konfiguratsioonivigadele, mis võivad samuti olla haavatavused. Siin soovitame teabe kogumise agentuuri meetodit. Skaneerimise tööriistu saab ja tuleb kasutada perimeetri turvalisuse hindamiseks. Kui kasutate pilveteenuste pakkujate ressursse, on oluline sealt koguda teavet varade ja konfiguratsioonide kohta. Erilist tähelepanu pöörake Dockeri konteinerite kasutamisega seotud infrastruktuuri haavatavuste analüüsimisele.

Samm nr 5: Seadistage aruandlus
See on üks olulisi aspekte haavatavuste haldamise protsessis.
Esimene asi: keegi ei taha töötada mitmest leheküljest koosneva aruandega, kus on segaduses haavatavuste nimekiri ja nende kõrvaldamise kirjeldus. Peamine on suhelda kolleegidega ja selgitada välja, mis peaks aruandes olema ja kuidas neil on mugavam andmeid saada. Näiteks ei vaja üks administraator haavatavuse üksikasjalikku kirjeldust, vaid soovib ainult teavet plaastri kohta ja linki sellele. Teisele spetsialistile on olulised vaid võrguteenustes leitud haavatavused.
Teine punkt: aruandlusega ei pea ma silmas ainult paberkandjal aruandeid. See on vananenud formaat teabe hankimiseks ja staatiline ajalugu. Inimene saab aruande ja ei saa mingil viisil mõjutada, kuidas selles aruandes andmeid esitatakse. Õige vormi saamiseks peab IT-spetsialist võtma ühendust infotehnoloogia spetsialistiga ja paluma tal aruanne ümber ehitada. Aeg kulgeb, uusi haavatavusi tekib. Selle asemel, et aruandeid osakondade vahel edasi-tagasi visata, peaksid mõlema valdkonna spetsialistid saama andmeid jälgida reaalajas ja näha sama pilti. Seetõttu kasutame oma platvormil dünaamilisi raportite kujundusi kohandatavatel koondtabelitel.

Samm № 6: Prioriteedid
Siin on mõned tegevused, mida saate teha:
1. Loo kuldsete piltide süsteemide hoidla. Tööta kuldsete piltidega, kontrolli neid pidevalt haavatavuste ja konfiguratsiooni õigsuse suhtes. Seda on võimalik teha agentide abil, mis teavitavad automaatselt uue vara toimest ning annavad teavet selle haavatavuste kohta.
2. Keskenduge ettevõttele kriitilistele varadele. Ühtegi organisatsiooni maailmas ei suuda haavatavusi ühekorraga kõrvaldada. Haavatavuste kõrvaldamise protsess on pikk ja vaevaline.
3. Ründepinna kitsendamine. Puhastage oma infrastruktuur kasutud tarkvarast, teenustest ja sulgege mittevajalikud pordid. Hiljuti toimus meil juhtum ühe ettevõttega, kus 40 000 seadme pealt leiti umbes 100 000 haavatavust, mis olid seotud vana versiooniga brauserist Mozilla. Hiljem selgus, et Mozilla oli integreeritud kuldse pildi hulka aastaid tagasi, seda ei kasutatud, kuid see on suur haavatavuste allikas. Kui brauser arvutitelt eemaldati (see oli isegi mõnel serveril), kadusid need kümned tuhanded haavatavused.
4. Hinnake haavatavusi andmete luure aluselt (threat intelligence). Arvesse võtke mitte ainult haavatavuse tõsidust, vaid ka avalike eksploitide, pahavara, plaastrite olemasolu ning välise juurdepääsu süsteemidele, kus on haavatavusi. Hinnake selle haavatavuse mõju kriitilistele äritegevuste süsteemidele: kas see võib põhjustada andmete kaotsiminekut, teenuse katkestamist jne.

Samm nr 7: Kooskõlastage KPI-d
Ärge skanneerige ilma põhjuseta. Kui leitud haavatavustega ei tehta midagi, muutub see skaneerimine asjatuks. Et haavatavuste haldamine ei oleks pelgalt formaalsus, mõelge läbi, kuidas te tulemusi hindate. Infotehnoloogia ja IT peavad kokku leppima, kuidas haavatavuste likvideerimise töö üles ehitada, kui tihti skaneerimisi, patšide paigaldamisi jne teostatakse.
Slaidil näete võimalike KPI-de näiteid. On olemas ka laiem nimekiri, mida soovitame oma klientidele. Kui see teid huvitab, võtke ühendust, jagan seda teavet teiega.

Samm nr 8: Automatiseerige
Tagasi skaneerimise juurde. Me Qualysis usume, et skaneerimine on täna kõige vähem tähtis asi haavatavuste haldamise protsessis, ja et see tuleks maksimaalselt automatiseerida, et seda saaks teha ilma turvaeksperdi sekkumiseta. Täna on palju tööriistu, mis seda võimaldavad. Piisab, kui neil on avatud API ja vajalik arv konnektoreid.
Minu lemmiknäide on DevOps. Kui kavatsete lisada haavatavuse skanneri, siis võite DevOpsist lihtsalt unustada. Vanade tehnoloogiate, nagu klassikaline skanner, tõttu ei pääse te nende protsesside juurde. Arendajad ei oota, et skannite ja saadate neile mitmeleheküljelise ebamugava aruande. Arendajad ootavad, et haavatavuste teave jõuaks nende koodikogumise süsteemidesse nagu veateated. Turvalisus peab olema needesse protsessidesse sujuvalt integreeritud ja see peab olema lihtsalt funktsioon, mida automaatselt kutsub esile teie arendajate kasutatav süsteem.

Samm nr 9: Keskenduge põhiasjadele
Keskenduge sellele, mis toob teie ettevõttele tõelist kasu. Skannimised võivad olla automaatsed, samuti võivad aruanded automaatselt edastada.
Keskenduge protsesside parandamisele, et need oleksid paindlikumad ja mugavamad kõigile osalejatele. Keskenduge sellele, et turvalisus oleks integreeritud kõikidesse lepingutesse teie koostööpartneritega, näiteks neile, kes arendavad teile veebirakendusi.
Kui vajate põhjalikumat teavet selle kohta, kuidas ettevõttes haavatavushalduse protsessi välja töötada, pöörduge minu ja minu kolleegide poole. Oleme valmis aitama.

Allikas: habr.com
