Fenyegetésmodellezés: alakítsa az architektúrát biztonsági döntésekké

A fenyegetésmodellezés azt kérdezi, mi romolhat el egy adott rendszerben, és mit kell ezzel kapcsolatban tennie a csapatnak. Hasznos eredménye nem ijesztő lehetőségek katalógusa, hanem az architektúrához kötött tervezési és megvalósítási döntések összessége, felelősökkel és bizonyítékokkal arra, hogy a választott védelmek működnek.

A technológiai vezető (CTO) számára a központi kérdés az, hogy a mérnöki csapat meg tudja-e magyarázni, hogyan maradnak fenn a fontos biztonsági tulajdonságok a rendszer valós működése során: újrapróbálkozások, háttérfeladatok, kiemelt jogosultságú ügyfélszolgálati műveletek, beszállítói kiesések és rosszindulatú bemenetek esetén. Egy ábra konkréttá teszi ezeket a beszélgetéseket. Egy karbantartott fenyegetésmodell a következtetéseket megvalósítási munkává alakítja.

Az OWASP fenyegetésmodellezési útmutatója hasznos alapot ad: értse meg a rendszert, azonosítsa a fenyegetéseket, döntse el, hogyan reagál, és értékelje, elegendő-e a munka. Az alábbi munkafolyamat ezt a gondolkodásmódot alkalmazza a mérnöki döntésekre.

Írja le a rendszert, mielőtt a támadásokról beszélne

Kezdjen egy körülhatárolt képességgel, például az ügyféladatok exportálásával, a fizetéskezdeményezéssel vagy az eszközfrissítésekkel. Egy teljes platform egyszerre történő modellezése gyakran felszínes megfigyelésekhez vezet, mert senki sem tudja minden függőséget kellő részletességgel elmagyarázni.

Az eszközöket és a biztonsági célokat működési fogalmakkal fogalmazza meg. A „védje az ügyféladatokat” túl tág. Az „egy hitelesített felhasználó csak a jogosult bérlőjéhez tartozó rekordokat exportálhatja” olyan tulajdonságot ad a csapatnak, amelyet tesztelni lehet. Más célok vonatkozhatnak a tranzakciók sértetlenségére, a szolgáltatás rendelkezésre állására, a helyreállításra vagy az adminisztratív műveletek hozzárendelhetőségére.

Azonosítsa a felhasználókat, szolgáltatásokat, adattárakat, külső függőségeket, belépési pontokat és bizalmi határokat. Rajzolja meg a fontos adatáramlásokat, beleértve az aszinkron feldolgozást és az adminisztratív útvonalakat. Ahol ez befolyásolja az elemzést, lássa el az áramlásokat a szállított adatok, a hitelesítési mechanizmus és a jogosultsági kontextus feliratával.

A bizalmi határ a feltevések vagy a jogkör változását jelöli, nem feltétlenül hálózati peremet. Egy API-t hívó böngésző átlép egy határt. Egy ügyfél nevében eljáró közös feldolgozó egy másikat, még ha mindkét szolgáltatás ugyanabban a fürtben fut is.

Egy több bérlős alkalmazásnál mutassa meg, hol jön létre a bérlői identitás, és hogyan jut el a jogosultság-ellenőrzésekhez, a háttérfeladatokhoz és az exportokhoz. Vegye fel a szolgáltatásidentitásokat, az objektumtárhoz való hozzáférést, az ügyfélszolgálati eszközöket és a külső visszahívásokat. Ellenkező esetben az ábra a zökkenőmentes útvonalat írja le, miközben kihagyja azokat az útvonalakat, amelyek a legnagyobb valószínűséggel kerülik meg az elkülönítést.

A feltevéseket a tényektől elkülönítve rögzítse. „Az ügyfelek nem írhatnak a sorba” – ehhez alátámasztó konfigurációs bizonyíték szükséges. Az ismeretlenekből vizsgálati feladatok legyenek, ne csendben elfogadott védelmek.

Válasszon olyan módszert, amely segíti a csapat gondolkodását

Egy módszer kérdéseket és struktúrát ad. Nem dönti el, mely fenyegetések számítanak a legjobban, nem bizonyítja, hogy egy terv biztonságos, és nem helyettesíti a rendszer ismeretét.

STRIDE a szisztematikus kérdésfeltevéshez

A STRIDE hat kategóriát vizsgál. Alkalmazza őket a releváns komponensekre, áramlásokra és határokra, ahelyett hogy minden kategóriát erőltetetten minden ábraelemre ráhúzna.

Egy forgatókönyv több kategóriára is kiterjedhet. Ahol indokolt, egyetlen végrehajtható rekordot vezessen, ahelyett hogy a taxonómia kedvéért duplikált jegyeket hozna létre.

Más módszerek más kérdésekre

A PASTA (Process for Attack Simulation and Threat Analysis) hétlépcsős, kockázatorientált megközelítést kínál, amely összekapcsolja az üzleti célokat, a műszaki hatókört, a dekompozíciót, a fenyegetés- és sebezhetőségelemzést, a támadásmodellezést és a kockázatkezelést. Olyan mélyebb elemzéshez illik, ahol a támadói viselkedés és az üzleti következmények kifejezett figyelmet igényelnek.

A támadási fák egy támadói célból indulnak ki, és azt alternatív vagy kombinált útvonalakra bontják. A „megszerezni egy másik bérlő exportját” célnál az alternatívák között szerepelhet az API-jogosultságkezelés megkerülése, a feldolgozó bérlői kontextusának összezavarása vagy egy letöltési hitelesítő adat ellopása. Az ÉS-kapcsolatok olyan feltételeket jelölnek, amelyeknek együtt kell teljesülniük; a VAGY-kapcsolatok alternatívákat.

A VAST (Visual, Agile, and Simple Threat modeling) az alkalmazási és működési nézőpontokon átívelő, skálázható modellezést hangsúlyozza. Azoknak a csapatoknak, amelyek ezt fontolgatják, meg kell vizsgálniuk, képesek-e eszközeik és fejlesztési folyamatuk következetesen karbantartani ezeket a nézeteket.

Gyakorlati kiindulási ajánlás egy adatáramlási ábra a STRIDE-dal kiegészítve, amelyet a legsúlyosabb következményekkel járó forgatókönyvre egy támadási fa követ. A több módszertan csak akkor hasznos, ha jobb döntésekhez vezet.

Tartsa a felülvizsgálatot konkrét forgatókönyvek köré szervezve

Hívja meg azokat, akik értik a megvalósítást és a működést: egy fejlesztőt, egy architektet vagy műszaki vezetőt, egy biztonsági felülvizsgálót, és valakit, aki ismeri a termelési környezet viselkedését. Vonja be a termék-, adatvédelmi vagy beszállítói szakértőket, ha tudásuk befolyásolja a hatókört.

Az ülés előtt küldje körbe az ábrát, a biztonsági célokat, a releváns konfigurációt és a tisztázatlan feltevéseket. A felülvizsgálat során kövessen végig egy kérést vagy eseményt a belépéstől a befejezésig. Kérdezze meg, hol változik az identitás, hol tárolódnak tartósan adatok, mit próbálnak újra, és melyik komponensnek van jogköre egy művelet jóváhagyására.

A fenyegetéseket forgatókönyvként írja le, ne címkeként. A „jogosultsági probléma” nem elég hasznos. Erősebb megfogalmazás: „Egy hitelesített felhasználó egy másik bérlő exportazonosítóját helyettesíti be; a letöltési végpont ellenőrzi a bejelentkezést, de az objektum tulajdonjogát nem, így ügyfélrekordok válnak elérhetővé.”

Válasszon szét három fogalmat:

• A fenyegetés egy kedvezőtlen műveletet vagy eseményt ír le, például egy export jogosulatlan lekérését.
• A sebezhetőség egy olyan gyengeség, amely ezt lehetővé teheti, például egy hiányzó tulajdonjog-ellenőrzés.
• A kockázat a forgatókönyv valószínűségét és következményét veszi figyelembe a tényleges környezetben.

Egy fenyegetést érdemes lehet megvizsgálni már azelőtt, hogy egy sebezhetőséget megerősítenének. Ugyanígy egy gyengeség megtalálása nem igazolja, hogy minden elképzelhető támadás kivitelezhető.

A külső támadások mellett vegye figyelembe a jogosult felhasználók általi visszaéléseket, a kiemelt jogosultságú belső szereplőket, a konfigurációs hibákat és a beszállítói kieséseket. Kérdezze meg, mi történik, ha egy függőség időtúllépéssel válaszol vagy váratlan választ ad. A nyitva hibázó (fail-open) viselkedés és a következetlen újrapróbálkozások gyakran ezekből a beszélgetésekből derülnek ki.

Kidolgozott példa: egy több bérlős exportfolyamat

Az alábbi példa szemléltető jellegű. Tegyük fel, hogy egy SaaS-alkalmazásnak van böngészős kliense, API-ja, közös adatbázisa, feladatsora, exportfeldolgozója és objektumtára. A bérlői felhasználók CSV-exportokat kérnek; a feldolgozó előállítja a fájlokat, az API pedig ideiglenes letöltési linkeket ad ki. Az ügyfélszolgálati adminisztrátoroknak külön hibaelhárítási felületük van.

A biztonsági célok: a bérlők elkülönítése, az exportok jogosult indítása, korlátozott erőforrás-felhasználás és az ügyfélszolgálati műveletek hozzárendelhetősége. Tegyük fel, hogy a feldolgozó adatbázis-hozzáférése elég tág ahhoz, hogy több bérlőt is kiszolgáljon. Ezáltal a bérlői kontextus kezelése központi döntéssé válik, nem csupán apró megvalósítási részletté.

Kövesse a jogkört az áramláson keresztül

Az API-nál a hitelesített megbízót a megengedett bérlői tagsághoz társítják. A böngésző által megadott bérlőazonosító kiválasztási kérés, nem a jogosultság bizonyítéka. Az API ellenőrzi a tagságot és az exportjogosultságot, mielőtt létrehoz egy megváltoztathatatlan feladatrekordot, amely tartalmazza a jogosult bérlőt, a kérelmezőt és a megengedett exporthatókört.

A sorban lévő üzenet erre a rekordra hivatkozik. A feldolgozó validálja a feladatot, és az export előállításakor bérlőhöz kötött adathozzáférést kényszerít ki. A tár metaadatai az eredményül kapott objektumot a feladathoz és a bérlőhöz társítják. Mielőtt letöltési linket adna ki, az API ezzel a társítással szemben ellenőrzi az aktuális kérelmező jogosultságát.

Ez a terv továbbra is kifejezett döntéseket igényel a hozzáférés visszavonásáról: megtarthatja-e a hozzáférést a kész fájlhoz egy olyan felhasználó, aki az export kérése után elveszíti tagságát? A csapatnak meg kell határoznia ezt a szabályt, és következetesen meg kell valósítania.

Alakítsa a forgatókönyveket kontrollokká és tesztekké

Az ideiglenes linkek maradvány-kitettségi időablakot nyitnak: a mechanizmustól függően a link birtoklása a lejáratig hozzáférést biztosíthat. A csapatnak el kell döntenie, hogy ez elfogadható-e az érintett adatoknál, vagy a letöltésekhez olyan hitelesített közvetítőre van szükség, amely aktuális jogosultság-ellenőrzést végez.

Ne zárja le a modellt pusztán a szinkron API tesztelése után. Ellenőrizze a késleltetett feladatokat, az újrapróbálkozásokat, a visszavont kéréseket, a lejárt tagságokat, a törölt bérlőket és a részleges hibákat. Egy újrapróbált feladat például nem használhat újra egy másik bérlőhöz társított objektumot, és nem tehet közzé egy hiányos exportot sikeresként.

Az eredménytermék egy felülvizsgált architektúra, egy fenyegetésnyilvántartás, megvalósítási feladatok és kapcsolt ellenőrzési eredmények. Nem csupán az ábra.

Rangsoroljon a kitettség és a következmények alapján

A valószerű forgatókönyveket a kitettség, a hatás, az előfeltételek és a meglévő védelmek alapján rangsorolja. Különböztesse meg a közvetlenül elérhető jogosultságkezelési hibát egy olyan forgatókönyvtől, amely több, nem bizonyított kompromittálódást igényel. Ahol releváns, vegye figyelembe az érintett adatokat, a szolgáltatáskiesést, a pénzügyi következményeket, a biztonsági (safety) vonatkozásokat és a helyreállítás nehézségét.

Ha segíti a csapatot, használjon egyszerű, következetes skálát, de rögzítse a besorolás mögötti indoklást. Egy megmagyarázatlan bemenetekből álló numerikus pontszám hamis pontosságot teremt. A CVSS segítheti egy konkrét sebezhetőség értékelését; nem helyettesíti az üzleti hatás vagy egy architekturális visszaélési eset megértését.

A kezelési lehetőségek közé tartozik a terv módosítása, a kitettség csökkentése, megelőző vagy felderítő kontrollok bevezetése, a képesség elhagyása vagy a fennmaradó kockázat elfogadása. A beszállítói szerződések feloszthatják a felelősségeket, de nem szüntetik meg a műszaki hibamódokat.

A maradványkockázathoz megnevezett döntéshozó, indoklás, lejárat vagy felülvizsgálati kiváltó ok, valamint az esetleges működési feltételek tartoznak. A mérnöki befejezés és a kockázatelfogadás különböző döntések. Egy jegy lezárható, miközben jelentős kockázat marad fenn.

Vigye át a modellt a megvalósításba és a bizonyítékokba

Minden lényeges forgatókönyvhöz rögzítse az azonosítóját, az érintett komponenseket, az előfeltételeket, a következményt, a meglévő védelmeket, a kezelést, a felelőst és az ellenőrzési módszert. Kapcsolja a rekordot az architektúra verziójához és a releváns megvalósítási munkához, hogy a felülvizsgálók lássák, melyik tervet értékelték.

A kezelési intézkedéseket alakítsa tesztelhető elfogadási kritériumokká. A „javítsa a hozzáférés-szabályozást” homályos. Az „A bérlő egyetlen támogatott végponton keresztül sem kérheti le, kérdezheti le, vonhatja vissza vagy töltheti le B bérlő exportját” olyan viselkedést azonosít, amelyet a mérnöki csapat ellenőrizni tud.

Az állításhoz illő bizonyítékot használjon:

• A kódfelülvizsgálat megállapíthatja, hol kényszerítik ki a jogosultságkezelést.
• A konfiguráció vizsgálata megállapíthatja a szolgáltatások jogosultságait és a tár kitettségét.
• A negatív integrációs tesztek próbára tehetik a bérlők közötti és a jogosultsági határokat.
• A terheléses és hibainjektálásos tesztek vizsgálhatják a rendelkezésre állást és a hibaviselkedést.
• A célzott behatolásteszt olyan támadási útvonalakat vizsgálhat, amelyek független feltárást igényelnek.

Egyetlen műtermék sem bizonyítja a teljes modellt. Egy beállításról készült képernyőkép nem bizonyítja, hogy minden feldolgozó használja azt, és egy sikeres teszt nem igazol egy nem tesztelt útvonalat. Rögzítse a tesztkörnyezetet, a hatókört, az eredményeket és a korlátokat.

A fenyegetésmodellezés kiegészíti a biztonságos kódolást, a függőségek értékelését, a sebezhetőségvizsgálatot és a behatolástesztet. Sajátos hozzájárulása az architekturális gondolkodás: feltárhatja a jogkör veszélyes elosztását akkor is, ha az egyes komponenseknek nincs ismert sebezhetőségük.

Az eszközök és az automatizálás maradjanak a modellnek alárendelve

Egy közös ábra és egy strukturált nyilvántartás támogathat egy fókuszált első felülvizsgálatot. A dedikált eszközök akkor válnak hasznossá, amikor a csapatoknak újrahasznosítható komponenskönyvtárakra, következetes azonosítókra, együttműködésre és a fenyegetések és megvalósítási rekordok közötti megbízható kapcsolatokra van szükségük.

Értékelje, hogy egy eszköz támogatja-e a bizalmi határokat, az egyéni forgatókönyveket, a verzióelőzményeket, az exportálható rekordokat, a felelősségeket és a bizonyítékhivatkozásokat. Az automatikusan generált fenyegetések megvizsgálandó felvetések, nem megerősített megállapítások. A kontextus nélküli hosszú listák elrejthetik azt a néhány döntést, amely számít.

Az MI-támogatás megfogalmazhat forgatókönyv-leírásokat, javasolhat hiányzó útvonalakat, vagy összevetheti a változásokat egy korábbi modellel. Az emberi felülvizsgálóknak továbbra is validálniuk kell az architektúrát, a kivitelezhetőséget, a kockázatcsökkentés lefedettségét és a maradványkockázatot. A bizalmas ábrákat és hitelesítő adatokat tartsa távol a nem jóváhagyott szolgáltatásoktól. A fenyegetésmodell generálása ráadásul különbözik a futásidejű észleléstől; egy modell előállítása nem jelent folyamatos monitorozást vagy automatikus hibaelhárítást.

Vizsgálja felül, amikor az architektúra vagy a feltevések változnak

Frissítse a modellt új integrációk, hitelesítési változások, kiemelt jogosultságú műveletek, adatkategóriák, hálózati kitettség és jelentős függőségi változások esetén. Egy incidens vagy egy váratlan teszteredmény is érvénytelenítheti egy korábbi feltevést.

A különböző rendszerek eltérő hangsúlyt igényelnek. A felhőalkalmazásoknál figyelmet kell fordítani az identitásjogosultságokra és a felügyeleti síkhoz (management plane) való hozzáférésre. A mobilklienseket támadó által ellenőrzött környezetként kell kezelni, nem megbízható kikényszerítési pontként. A csatlakoztatott eszközök fizikai hozzáférési, frissítésintegritási, helyreállítási és esetleg biztonsági (safety) következményekkel járnak. Az MI-alapú funkciók nem megbízható tartalmat és eszközhasználati határokat hoznak be; a jogosultságkezelésnek a modell kimenetétől függetlenül korlátoznia kell a műveleteket.

Mérje, hogy a fontos áramlásokhoz tartozik-e aktuális modell, a magas prioritású kezelési intézkedésekhez van-e ellenőrzési bizonyíték, maradtak-e tisztázatlan feltevések, és van-e lejárt felülvizsgálatú elfogadott kockázat. A fenyegetések puszta számlálása a mennyiséget jutalmazza, nem a hasznos elemzést. Időnként kérjen meg egy független felülvizsgálót, hogy kérdőjelezzen meg egy kritikus forgatókönyvet és annak bizonyítékait.

Az első felülvizsgálat legyen elég kicsi ahhoz, hogy befejezhető legyen

A Secani megőrizheti az e döntések körüli munkafolyamatot: modellezheti a releváns rendszereket és függőségeket, kijelölheti a felelősöket és felülvizsgálókat, és a bizonyítékokat követelményekhez, kontrollokhoz és döntésekhez kapcsolhatja. A tisztázatlan feltevésekből feladatok lesznek; a forrásanyagok és az emberi jóváhagyások a felülvizsgálathoz csatolva maradnak. Minden MI által támogatott javaslatot ellenőrizni kell a jóváhagyás előtt.

Kezdjen egyetlen kritikus adatáramlással. Kövesse végig a jogkört elejétől a végéig, azonosítson néhány valószerű forgatókönyvet, és fejezze be felelőssel rendelkező kezelési intézkedésekkel és kifejezett ellenőrzési kritériumokkal. A következő felülvizsgálatot azokhoz az architektúraváltozásokhoz ütemezze, amelyek érvényteleníthetik ezeket a döntéseket.