PRIVÁT OFFSHORE INFRASTRUKTÚRA
Másodnapi üzemeltetésAlkalmazott · 6 perc olvasás

Gyakorlati fenyegetésmodell a hosztolt projekthez

Térképezze fel az eszközöket és a bizalmi határokat, válasszon ki néhány valósághű hibaforgatókönyvet, és alakítsa azokat tesztelhető kontrollokká.

Szerző: SwissOctet Editorial
A KÖZVETLEN VÁLASZ

Egy hasznos fenyegetésmodell elmagyarázza, mit véd, ki vagy mi befolyásolhatja azt, hol változik a bizalom, és hogyan csökkenti és teszteli a legfontosabb kockázatokat. Kezdje a tényleges projekttel, nem pedig az eszközök általános listájával.

01

Határozzon meg egy elég kicsi hatókört az átgondoláshoz

Kezdje egy működő szolgáltatással: egy ügyfélportállal, egy kiadói oldallal vagy egy belső alkalmazással. Írja le az Ön által üzemeltetett komponenseket és a támaszkodott külső rendszereket. A fenyegetésmodellnek láthatóvá kell tennie a feltételezéseket, nem pedig azt sugallnia, hogy minden lehetséges támadást megoldottak. Az első verziót tartsa elég kicsinek ahhoz, hogy az alkalmazást telepítő emberek külön tanácsadó nélkül is el tudják magyarázni a diagramot.

Sorolja fel az értékes eredményeket és eszközöket. Ezek közé tartozhat az ügyféladat, a rendszergazdai hozzáférés, a fizetési állapot, a közzétett tartalom és a szolgáltatás helyreállításának képessége. Az elérhetőség akkor is lehet eszköz, ha az információ nyilvános. Döntse el, mely meghibásodások lennének kellemetlenek, és melyek károsítanák az embereket vagy a szervezetet. Ez a megkülönböztetés segít az ellenőrzések rangsorolásában, ahelyett hogy minden figyelmeztetést egyformán kezelne.

02

Rajzolja fel azokat a helyeket, ahol a bizalom megváltozik

Az OWASP fenyegetésmodell-útmutatása adatfolyamokat és bizalmi határokat használ a tervezés érthetővé tételéhez. Egy kis tárhelyen üzemeltetett alkalmazáshoz rajzolja fel a böngészőt, a webes folyamatot, az adatbázist, a rendszergazdát, a biztonsági mentés célállomását és a külső integrációkat. Jelölje meg a köztük mozgó információkat. A nem megbízható ügyféltől egy privilegizált szerverműveletbe átlépő kérés kifejezett érvényesítést és engedélyezést érdemel.

Ne feltételezze, hogy az ugyanazon a gépen belül lévő összes komponens egyformán megbízható. Egy nyilvános feltöltési folyamatnak nem szabad ugyanazokkal a jogosultságokkal rendelkeznie, mint az adatbázis-adminisztrációnak. Egy biztonsági mentési feladatnak lehet olvasási hozzáférése anélkül, hogy módosíthatná az élő alkalmazásrekordokat. E szerepek elkülönítése megkönnyíti egy kompromittált komponens hatásának korlátozását és a szükséges jogosultságok felülvizsgálatát.

03

Válasszon konkrét meghibásodási forgatókönyveket

Használjon néhány hihető eseményt a tervezés megkérdőjelezéséhez. Egy támadó ellop egy rendszergazdai jelszót; egy felhasználó egy másik felhasználó rekordját kéri; egy feltöltés megtölti a lemezt; egy telepítés felfed egy konfigurációs fájlt; egy helyreállítási másolat nem állítható helyre. Írja le a kezdeti feltételt, az érintett komponenst és a következményt. Egy konkrét forgatókönyv könnyebben tesztelhető, mint egy általános utasítás a biztonság javítására.

A külső behatolás mellett vegye figyelembe a hibákat és a jogszerű munkafolyamat visszaélésszerű használatát is. Egy újrapróbálkozás két értékes műveletet hozhat létre, vagy két kérés versenyezhet ugyanazon objektum módosításáért. Az OWASP üzleti logikára vonatkozó útmutatása rávilágít ezekre a folyamatfeltételezésekre. Ellenőrizze, ki jogosult egy munkafolyamatot a következő állapotába léptetni, és hogy egy kérés megismétlése vagy átrendezése váratlanul megváltoztatja-e az eredményt.

ForgatókönyvVizsgálandó ellenőrzésÖsszegyűjtendő bizonyíték
Ellopott rendszergazdai hitelesítő adatKorlátozott hozzáférés és második tényező, ahol támogatottEgy jogosulatlan bejelentkezés nem tud befejeződni
Egy másik felhasználó objektumának kéréseSzerveroldali objektum-engedélyezésEgy elkülönített teszt elutasított eredményt ad
A feltöltések kimerítették a lemeztMéret-, kvóta- és megőrzési ellenőrzésekA szolgáltatás meghibásodása előtt érvényesül egy korlát
Ismétlődő munkafolyamat-kérésIdempotencia és tranzakciós határokEgy ismételt kérés egyetlen eredményt hoz létre
04

Rangsoroljon hatás és hihető útvonal alapján

Minden forgatókönyvhöz jegyezze fel a lehetséges hatást és az előfordulásához szükséges feltételeket. Kerülje annak színlelését, hogy egy kitalált numerikus pontszám pontos valószínűség. Továbbra is megkülönböztethet egy internetnek kitett gyenge jelszót egy erősen feltételes helyi eseménytől. Rendeljen felelőst és gyakorlati következő lépést a fontos kockázatokhoz, hogy a modell olyan munkát hozzon létre, amelyet valaki ténylegesen be tud fejezni.

Az alkalmazás kompromittálódása mellett vegye figyelembe az információ életciklusát is. Egy diagnosztikai export egyébként normál működés közben szükségtelen adatokat fedhet fel. Egy megőrzött fiókmező hosszú ideig kitettséget teremthet a célja megszűnése után. Az adatvédelmi felülvizsgálat ezért eltávolíthat információt vagy lerövidítheti a megőrzést, míg a biztonsági felülvizsgálat korlátozza a hozzáférést a megmaradóhoz. Mindkét változtatás a modellbe tartozik, amikor védi a projektet.

05

Tesztelje az ellenőrzéseket engedélyezett környezetben

Hozzon létre egy átmeneti környezetet reprezentatív jogosultságokkal és fiktív rekordokkal. Tesztelje a megtagadott hozzáférést, a kéréskorlátokat, a munkafolyamat-újrapróbálkozásokat és a helyreállítást. Ne használjon valós ügyféladatokat, ha szintetikus adatok is bemutathatják a viselkedést. A cél a vezérlés ellenőrzése, nem lenyűgöző támadási forgalom generálása. Maradjon azon rendszereken belül, amelyek az Ön tulajdonában vannak, vagy amelyek értékelésére kifejezetten felhatalmazást kapott.

Rögzítse, mi sikerült, mi nem, és mi maradt ismeretlen. A szkenner eredménye bizonyítékkal szolgálhat, de nem helyettesíti az alkalmazás üzleti szabályainak tesztelését. Hasonlóképpen, egy hálózatvédelmi beállítás nem igazolja az objektumengedélyezést vagy a titkos fájlok kezelését. Csatolja a hasznos eredményeket a forgatókönyvhöz, hogy a jövőbeli karbantartók megértsék, miért létezik egy adott vezérlés.

06

Tartsa a modellt a változásokhoz kapcsolva

Tekintse át az érintett részeket, amikor integrációt ad hozzá, új végpontot tesz elérhetővé, jogosultságot módosít, vagy adatot helyez át más célhelyre. Egy kisebb szövegmódosítás miatt nem kell újrarajzolnia a teljes architektúrát. A kiváltó ok a hozzáférésre, információra vagy rendszerviselkedésre vonatkozó megváltozott feltételezés. Tartsa a modellt a telepítési és helyreállítási dokumentáció mellett, ne hagyja egyszeri workshop-eredményként.

A SwissOctet infrastruktúra-választási lehetőségek katalógusát kínálja, nem egy elkészült alkalmazásfenyegetés-modellt. Válassza ki a vezérléseit támogató konfigurációt és beállításokat, majd ellenőrizze az általa létrehozott telepítést. Egy kicsi, karbantartott modell tesztelt műveletekkel hasznosabb, mint a biztonsági termékek nagy gyűjteménye, amelyeknél nincs világos magyarázat az általuk kezelt kockázatokra.

FORDÍTSA CSELEKVÉSRE

Az Ön gyakorlati ellenőrzőlistája.

  • Sorolja fel az eszközöket és a meghibásodás következményeit.
  • Rajzolja fel az adatfolyamokat és a bizalmi határokat.
  • Válasszon konkrét behatolási, hiba- és munkafolyamat-forgatókönyveket.
  • Rendeljen vezérléseket és felelősöket a fontos kockázatokhoz.
  • Teszteljen szintetikus adatokkal engedélyezett környezetben.
  • Tekintse át a modellt, amikor egy releváns feltételezés megváltozik.
GYAKORI KÉRDÉSEK

A fontos részletek.

Szükségem van formális keretrendszerre az induláshoz?+

Nem. Egy kis diagram és dokumentált forgatókönyvek hasznosak lehetnek. A keretrendszer segít abban, hogy következetesen vizsgálja felül a kockázatokat.

Helyettesíti a sebezhetőségi szkenner a fenyegetésmodellezést?+

Nem. A szkennerek technikai gyengeségeket találhatnak, míg a fenyegetésmodell a tervezési feltételezéseket, jogosultságokat és üzleti munkafolyamatokat is vizsgálja.

Milyen gyakran frissítsem a modellt?+

Frissítse az érintett részeket, amikor az adatfolyamok, integrációk, jogosultságok vagy elérhetővé tett funkciók megváltoznak, és rendszeresen vizsgálja felül a megoldatlan kockázatokat.

ELSŐDLEGES HIVATKOZÁSOK

Menjen a forráshoz.

Ezek a hivatkozások támogatják az útmutató műszaki fogalmait. Kövesse az aktuális dokumentációt, mielőtt éles rendszert módosítana.

  1. OWASP: Fenyegetésmodellezési gyorssegédlet cheatsheetseries.owasp.org
  2. OWASP: Fenyegetésmodellezés a gyakorlatban devguide.owasp.org
  3. OWASP: Üzleti logika biztonsága cheatsheetseries.owasp.org

Szerkesztői útmutatás: SwissOctet. A példák tájékoztató jellegűek. A szolgáltatási specifikációkat, az elérhető opciókat és a szerződéses feltételeket külön kell ellenőrizni.

KAPCSOLJA ÖSSZE A TUDÁST

Kapcsolódó infrastruktúra.

TARTSA A FONALAT

Az Ön következő terepjegyzetei.

Fedezze fel az összes útmutatót