Meil oli suur 4. juuli . Täna avaldame Qualyst pärit Andrei Novikovi kõne ärakirja. Ta ütleb teile, millised sammud peate haavatavuse haldamise töövoo loomiseks läbima. Spoiler: jõuame enne skannimist alles poole peale.
1. samm: määrake oma haavatavuse haldamise protsesside küpsusaste
Kohe alguses peate mõistma, millises etapis on teie organisatsioon oma haavatavuse haldamise protsesside küpsuse osas. Alles pärast seda saate aru, kuhu liikuda ja milliseid samme tuleb astuda. Enne skaneerimise ja muude tegevuste alustamist peavad organisatsioonid tegema sisetööd, et mõista, kuidas teie praegused protsessid on IT ja infoturbe vaatenurgast üles ehitatud.
Proovige vastata põhiküsimustele:
- Kas teil on varude ja varade klassifitseerimise protsessid;
- Kui regulaarselt IT-taristut skannitakse ja kas kogu infrastruktuur on kaetud, kas näete tervikpilti;
- Kas teie IT-ressursse jälgitakse?
- Kas teie protsessides on rakendatud KPI-sid ja kuidas saate aru, et neid täidetakse?
- Kas kõik need protsessid on dokumenteeritud?
2. samm: tagage täielik infrastruktuuri katvus
Sa ei saa kaitsta seda, millest sa ei tea. Kui teil pole täielikku pilti sellest, millest teie IT-infrastruktuur koosneb, ei saa te seda kaitsta. Kaasaegne infrastruktuur on keeruline ning kvantitatiivselt ja kvalitatiivselt pidevalt muutuv.
Nüüd ei põhine IT-infrastruktuur mitte ainult klassikaliste tehnoloogiate virnal (tööjaamad, serverid, virtuaalmasinad), vaid ka suhteliselt uutel - konteineritel, mikroteenustel. Infoturbeteenistus põgeneb viimaste eest igati, kuna olemasolevate, peamiselt skanneritest koosnevate tööriistakomplektide abil on tal väga raske nendega töötada. Probleem on selles, et ükski skanner ei suuda katta kogu infrastruktuuri. Selleks, et skanner jõuaks infrastruktuuri mis tahes sõlme, peavad mitmed tegurid kokku langema. Vara peab skannimise ajal asuma organisatsiooni piires. Täieliku teabe kogumiseks peab skanneril olema võrgujuurdepääs varadele ja nende kontodele.
Meie statistika järgi jääb keskmiste või suurte organisatsioonide puhul ligikaudu 15–20% infrastruktuurist skanneriga ühel või teisel põhjusel hõivamata: vara on perimeetrist kaugemale liikunud või ei ilmu üldse kontorisse. Näiteks töötaja sülearvuti, kes töötab eemalt, kuid kellel on siiski juurdepääs ettevõtte võrgule, või vara asub välistes pilveteenustes, nagu Amazon. Ja skanner ei tea tõenäoliselt nendest varadest midagi, kuna need on väljaspool selle nähtavuspiirkonda.
Kogu taristu katmiseks peate kasutama mitte ainult skannereid, vaid tervet komplekti andureid, sealhulgas passiivse liikluse kuulamise tehnoloogiaid uute seadmete tuvastamiseks teie infrastruktuuris, agentide andmete kogumise meetodit teabe saamiseks - võimaldab teil andmeid võrgus vastu võtta, ilma skannimise vajadus ilma mandaate esiletõstmata.
3. samm: varade kategoriseerimine
Kõik varad ei ole võrdsed. Teie ülesanne on kindlaks teha, millised varad on olulised ja millised mitte. Ükski tööriist, nagu skanner, ei tee seda teie eest. Ideaalis töötavad infoturve, IT ja äri koos infrastruktuuri analüüsimisel, et tuvastada ärikriitilised süsteemid. Nende jaoks määravad nad kättesaadavuse, terviklikkuse, konfidentsiaalsuse, RTO/RPO jne vastuvõetavad mõõdikud.
See aitab teil haavatavuse haldamise protsessi prioriteediks seada. Kui teie spetsialistid saavad andmeid haavatavuste kohta, ei ole see leht tuhandete haavatavustega kogu infrastruktuuri ulatuses, vaid üksikasjalik teave, mis võtab arvesse süsteemide kriitilisust.
4. samm: viige läbi infrastruktuuri hindamine
Ja alles neljandal etapil jõuame infrastruktuuri hindamiseni haavatavuse seisukohast. Selles etapis soovitame pöörata tähelepanu mitte ainult tarkvara haavatavustele, vaid ka konfiguratsioonivigadele, mis võivad samuti olla haavatavused. Siin soovitame teabe kogumiseks agentmeetodit. Skannereid saab ja tuleks kasutada perimeetri turvalisuse hindamiseks. Kui kasutad pilvepakkujate ressursse, siis pead sealt ka varade ja konfiguratsioonide kohta infot koguma. Pöörake erilist tähelepanu Dockeri konteinereid kasutavate infrastruktuuride haavatavuste analüüsimisele.
Samm #5: seadistage aruandlus
See on haavatavuse haldamise protsessi üks olulisi elemente.
Esimene punkt: keegi ei tööta mitmeleheküljeliste aruannetega, mis sisaldavad juhuslikku haavatavust ja nende kõrvaldamise kirjeldusi. Kõigepealt tuleb suhelda kolleegidega ja uurida, mis peaks aruandes olema ja kuidas on neil mugavam andmeid vastu võtta. Näiteks mõni administraator ei vaja haavatavuse üksikasjalikku kirjeldust ja vajab ainult teavet paiga kohta ja linki sellele. Teine spetsialist hoolib ainult võrgu infrastruktuuris leiduvatest haavatavustest.
Teine punkt: aruandluse all ei pea ma silmas mitte ainult paberaruandeid. See on teabe ja staatilise loo saamiseks aegunud formaat. Isik saab aruande ja ei saa kuidagi mõjutada seda, kuidas selles aruandes andmeid esitatakse. Aruande soovitud kujul saamiseks peab IT-spetsialist võtma ühendust infoturbe spetsialistiga ja paluma tal aruanne uuesti koostada. Aja möödudes ilmnevad uued haavatavused. Selle asemel, et aruandeid osakonnast osakonda lükata, peaksid mõlema eriala spetsialistid saama andmeid veebis jälgida ja nägema sama pilti. Seetõttu kasutame oma platvormil dünaamilisi aruandeid kohandatavate armatuurlaudade kujul.
Samm nr 6: seadke prioriteedid
Siin saate teha järgmist.
1. Hoidla loomine süsteemide kuldsete kujutistega. Töötage kuldsete piltidega, kontrollige neid haavatavuste suhtes ja parandage konfiguratsiooni jooksvalt. Seda saab teha agentide abiga, mis teavitavad automaatselt uue vara tekkimisest ja annavad teavet selle haavatavuste kohta.
2. Keskenduge neile varadele, mis on ettevõtte jaoks kriitilised. Maailmas pole ühtegi organisatsiooni, mis suudaks haavatavused ühe hooga kõrvaldada. Turvaaukude kõrvaldamise protsess on pikk ja isegi tüütu.
3. Rünnaku pinna kitsendamine. Puhastage oma infrastruktuur ebavajalikust tarkvarast ja teenustest, sulgege mittevajalikud pordid. Meil oli hiljuti juhtum ühe ettevõttega, kus 40 tuhandel seadmel leiti umbes 100 tuhat Mozilla brauseri vana versiooniga seotud turvaauku. Nagu hiljem selgus, viidi Mozilla kuldsesse pilti juba aastaid tagasi, keegi seda ei kasuta, kuid see on suure hulga haavatavuste allikas. Kui brauser arvutitest eemaldati (see oli isegi mõnel serveril), kadusid need kümned tuhanded haavatavused.
4. Reastage haavatavused ohuluure põhjal. Arvestage mitte ainult haavatavuse kriitilisust, vaid ka avaliku ärakasutamise, pahavara, paiga olemasolu või turvaauguga süsteemile välist juurdepääsu. Hinnake selle haavatavuse mõju kriitilistele ärisüsteemidele: kas see võib põhjustada andmete kadumist, teenuse keelamist jne.
7. samm: leppige kokku KPI-des
Ärge skannige skannimise pärast. Kui leitud haavatavustega midagi ei juhtu, muutub see skannimine kasutuks toiminguks. Et haavatavustega töötamine ei muutuks formaalsuseks, mõelge, kuidas selle tulemusi hindate. Infoturve ja IT peavad kokku leppima, kuidas haavatavuste kõrvaldamiseks tehtav töö üles ehitatakse, kui sageli skaneeritakse, plaastreid paigaldatakse jne.
Slaidil näete näiteid võimalikest KPI-dest. Seal on ka laiendatud nimekiri, mida soovitame oma klientidele. Huvi korral võtke minuga ühendust, jagan seda infot teiega.
Samm nr 8: automatiseerimine
Tagasi skannimise juurde. Leiame Qualys, et skaneerimine on tänapäeval haavatavuse haldamise protsessis kõige ebaolulisem asi, mis tänapäeval juhtuda saab ning et ennekõike tuleb see võimalikult palju automatiseerida, et see toimuks ilma infoturbespetsialisti osaluseta. Tänapäeval on palju tööriistu, mis võimaldavad teil seda teha. Piisab, kui neil on avatud API ja vajalik arv konnektoreid.
Näide, mida mulle meeldib tuua, on DevOps. Kui rakendate seal haavatavuse skanneri, võite DevOpsi lihtsalt unustada. Vanade tehnoloogiate puhul, mis on klassikaline skanner, teid lihtsalt ei lubata nendesse protsessidesse. Arendajad ei oota, kuni skannite ja esitate neile mitmeleheküljelise ebamugava aruande. Arendajad eeldavad, et teave turvaaukude kohta siseneb nende koodikoostesüsteemidesse veateabe kujul. Turvalisus peaks olema nendesse protsessidesse sujuvalt sisse ehitatud ja see peaks olema lihtsalt funktsioon, mille teie arendajate kasutatav süsteem automaatselt kutsub.
Samm nr 9: keskenduge põhilistele
Keskenduge sellele, mis teie ettevõttele tõelist väärtust toob. Skaneerimine võib olla automaatne, aruandeid saab saata ka automaatselt.
Keskenduge protsesside täiustamisele, et muuta need paindlikumaks ja mugavamaks kõigile asjaosalistele. Keskenduge sellele, et turvalisus oleks sisse ehitatud kõikidesse lepingutesse teie vastaspooltega, kes näiteks teie jaoks veebirakendusi arendavad.
Kui vajate täpsemat teavet selle kohta, kuidas oma ettevõttes haavatavuse haldamise protsessi üles ehitada, võtke minu ja minu kolleegidega ühendust. Aitan hea meelega.
Allikas: www.habr.com