Tartalom
- Csak a tények
- Nincsenek hibák, nincs stressz - Az Ön életét megváltoztató szoftverek készítésének lépésről lépésre történő leírása az élet megsemmisítése nélkül
- A hatás elszámolása?
- Ideje megváltoztatni a rendszert?
Forrás: BrianAJackson / iStockphoto
Elvitel:
Ideje megvizsgálni, hogyan gondolkodunk a nyílt forrású komponensek kockázatának felmérésében.
Könnyen fogalmazva kihívás egy olyan rendszer kidolgozása, amely felméri, hogy a szoftverfejlesztő közösség mennyire komolyan veszi a sebezhetőségeket. A kódot az emberek írták, és mindig lesznek hibái. Akkor az a kérdés, ha feltételezzük, hogy semmi sem lesz tökéletes, hogyan lehet a kategóriákat a lehető legjobb módon besorolni az összetevők kockázata alapján úgy, hogy lehetővé tegyük a produktív munka folytatását?
Csak a tények
Noha számos különféle megközelítés alkalmazható e probléma megoldására, mindegyiknek megvan a saját megalapozott indokolása, úgy tűnik, hogy a leggyakoribb módszer kvantitatív modelln alapul.
Egyrészt a sebezhetőség súlyosságának megítélésében alkalmazott mennyiségi megközelítés hasznos lehet, mivel objektívebb és mérhetőbb, kizárólag a sebezhetőséggel kapcsolatos tényezők alapján.
Ez a módszertan megvizsgálja, hogy milyen károkat okozhat a biztonsági rés kihasználása, figyelembe véve, hogy az összetevőt, könyvtárat vagy projektet milyen széles körben használják a szoftveriparban, valamint olyan tényezőket, mint például, hogy milyen hozzáférést biztosíthat a támadó számára roncs pusztítás, ha arra használják fel, hogy megszerezzék a célpontjukat. Az olyan tényezők, mint a könnyű potenciális kihasználhatóság, nagy szerepet játszhatnak a pontszám befolyásolásában. (Ha többet szeretne tudni a biztonságról, olvassa el a kiberbiztonságot: Hogyan hoznak új veszélyek új fenyegetéseket - és a Versa vice.)
Ha makro szinten akarjuk nézni, akkor a kvantitatív perspektíva azt vizsgálja, hogy egy sérülékenység hogyan sértheti az állományt, és kevésbé összpontosít arra a kárra, amely a támadás által ténylegesen sújtott vállalatokra eshet.
A Nemzeti biztonsági rés adatbázis (NVD), a sebezhetőség talán legismertebb adatbázisa, ezt a megközelítést alkalmazza mind a 2., mind a 3. verzióra, a közös biztonsági rés pontozási rendszerére (CVSS). A biztonsági rés felmérésére szolgáló mutatókat elmagyarázó oldalukon leírják módszerüket:
Kvantitatív modellje biztosítja az ismételhető, pontos mérést, miközben lehetővé teszi a felhasználók számára, hogy megtekintsék az alapul szolgáló sérülékenységi jellemzőket, amelyeket a pontszámok létrehozásához használtak. Így a CVSS jól alkalmazható szabványos mérési rendszerként az iparágak, szervezetek és kormányok számára, amelyeknek pontos és következetes sebezhetőségi pontszámokra van szükségük.
A kvantitatív tényezők alapján az NVD ezután súlyossági pontszámot tud elérni, mind a skálán lévõ számmal - 1-tõl 10-ig, 10-nek a legsúlyosabbnak -, mind a LOW, MEDIUM és HIGH kategóriákkal. .
Nincsenek hibák, nincs stressz - Az Ön életét megváltoztató szoftverek készítésének lépésről lépésre történő leírása az élet megsemmisítése nélkül
Nem javíthatja a programozási képességeit, ha senki sem törődik a szoftver minőségével.
A hatás elszámolása?
Úgy tűnik azonban, hogy az NVD erőfeszítéseket tesz arra, hogy tisztában maradjon azzal, hogy mi minősülhet inkább a sebezhetőség kvalitatív mérőszámának, annak alapján, hogy egy adott kizsákmányolás milyen hatást gyakorolt a károsodásra. A méltányosság kedvéért beépítik a hatást, amennyiben megmérik a sebezhetőség rendszerre gyakorolt hatását, figyelembe véve a titoktartás, az integritás és a rendelkezésre állás tényezőit. Ez mind fontos elem, amelyet meg kell vizsgálni - mint például a könnyebben mérhető hozzáférési vektorral, a hozzáférés bonyolultságával és a hitelesítéssel -, de nem éri el a valós hatás összekapcsolásának feladatát, amikor a sebezhetőség valós veszteségeket okoz a szervezetnek.
Vegyük például az Equifax megsértését, amely körülbelül 145 millió ember személyes adatait fedte fel, ideértve a járművezetői engedély részleteit, a társadalombiztosítási számokat és az egyéb biteket, amelyeket a gátlástalan szereplők felhasználhattak hatalmas csalási műveletek végrehajtására.
Az Apache Struts 2 projekt során a sérülékenységet (CVE-2017-5638) fedezték fel az Equifax webes alkalmazásában, amely lehetővé tette a támadóknak, hogy a bejárati ajtóban járhassanak, és végül kiálljanak karjukkal, lédús személyes információkkal. .
Míg az NVD jogosan adta a 10-es és a HIGH-os súlyossági pontszámot, döntésük a potenciális károk mennyiségi felméréséből fakad, és nem érintette őket az Equifax-jogsértés nyilvánosságra hozatalakor később bekövetkezett kiterjedt károk.
Ez nem az NVD felügyelete, hanem az általuk megfogalmazott politika része.
Az NVD CVSS „alap pontszámokat” nyújt, amelyek az egyes sebezhetőségek veleszületett jellemzőit mutatják. Jelenleg nem nyújtunk „időbeli pontszámokat” (mutatókat, amelyek idővel megváltoznak a sebezhetőségen kívüli események miatt) vagy „környezeti pontszámokat” (olyan pontszámokat, amelyek testreszabhatók, hogy tükrözzék a biztonsági rés hatását a szervezetére).
A döntéshozók számára a kvantitatív mérési rendszernek kevésbé számíthat, mivel megvizsgálja annak esélyét, hogy a kár eloszlik az iparban. Ha Ön egy bank CSO-ja, akkor aggódnia kell annak a kvalitatív hatásnak, amelyet egy kizsákmányolás okozhat, ha azt felhasználják az ügyfelek adataihoz, vagy ami még rosszabb, a pénzükhöz. (Tudjon meg többet a biztonsági rések különféle típusairól az 5 legfélelmetesebb fenyegetésben.)
Ideje megváltoztatni a rendszert?
Tehát, ha az Equifax-ügyben alkalmazott Apache Strusts 2 sérülékenységét magasabb rangsorolnánk, figyelembe véve azt, hogy a károk milyen mértékűek voltak, vagy ha a váltás túlságosan szubjektív lenne egy olyan rendszer számára, mint az NVD lépj tovább?
Annak biztosítása, hogy az NVD által leírt „környezeti pontszám” vagy „időbeli pontszám” elkészítéséhez szükséges adatok előállítása rendkívül nehéz lenne, ha az ingyenes CVSS csapat vezetőit megnyitnánk a végtelen kritika és egy csomó munka mellett. az NVD-nek és másoknak az adatbázisuk frissítéséért, az új információk megjelenésekor.
Természetesen felmerül a kérdés, hogy egy ilyen pontszámot miként állítanának elő, mivel valószínűleg nagyon kevés szervezet nyújtja be a jogsértés hatásával kapcsolatos szükséges adatokat, kivéve, ha a közzétételi törvény előírja. Az Uber esetéből láthattuk, hogy a vállalatok hajlandóak gyorsan kifizetni abban a reményben, hogy a jogsértést körülvevő információk nem kerülnek a sajtóba, hogy ne kerüljenek nyilvánosságra.
Talán szükség van egy új rendszerre, amely beépítheti a sebezhetőségi adatbázisok erőfeszítéseit, és hozzáadhatja saját kiegészítő pontszámát, amikor az információk rendelkezésre állnak.
Miért indíthatja el ezt a pontozási extra réteget, ha az előző úgy tűnik, hogy elég jól végzett a munkájával ezekben az években?
Őszintén szólva, a szervezetek elszámoltathatósága a felelősséget vállalja alkalmazásáért. Egy ideális világban mindenki megvizsgálná a termékekben használt összetevők pontszámát, mielőtt hozzáadná azokat a készletükhöz, riasztásokat kapna, ha új biztonsági réseket fedeznek fel a korábban biztonságosnak ítélt projektekben, és önmagában végrehajtja a szükséges javításokat. .
Lehet, hogy ha lenne egy lista, amely megmutatná, hogy ezeknek a sebezhetőségeknek milyen romboló hatásai lehetnek egy szervezet számára, akkor a szervezetek nagyobb nyomást érezhetnek, hogy ne kerüljenek bele kockázatos összetevőkbe. Legalábbis lépéseket tehetnek annak érdekében, hogy valódi leltárt készítsenek már meglévő nyílt forráskódú könyvtárakról.
Az Equifax fiaskó következményeként valószínűleg egynél több C szintű ügyvezető csapkodott be, hogy megbizonyosodjon arról, hogy termékeikben nincs-e a Struts sebezhető változata. Sajnálatos, hogy ilyen nagyságrendű eseményre került sor, hogy arra késztesse az iparágat, hogy komolyan vegye a nyílt forrású biztonságot.
Remélhetőleg az a lecke, miszerint az alkalmazások nyílt forrású összetevőinek sérülékenysége nagyon valós következményekkel járhat, befolyásolja azt is, hogy a döntéshozók miként rangsorolják a biztonságot, a megfelelő eszközöket választva a termékek és az ügyfelek adatainak biztonságához.