Fenyegetésmodellezés egy kis platformhoz

A fenyegetés-modellezésnek olyan híre van, mint egy vállalati rituálénak, tele olyan diagramokkal, amelyeket senki sem olvas. Ennek nem kell így lennie. Egy kis platform esetében a hasznos változat egy órát vesz igénybe, egy rangsorolt listát eredményez, és a fő hozadéka annak ismerete, hogy az infrastruktúrával kapcsolatos döntések egyáltalán mely kockázatokat érintik — mert a legtöbbjük esetében az őszinte válasz: egyiket sem.

A sorrend fontosabb, mint a teljesség

A klasszikus hiba egy hosszú lista mindenről, ami elromolhat, amelyet egyformán sürgősként kezelnek. Ez bénultsághoz vezet, majd végül mégis egy megérzés alapján meghozott döntéshez. Egy hét tételből álló rangsorolt lista többet ér, mint egy negyven tételes kimerítő lista, mert úgyis csak az első hármat fogja megvalósítani, a többihez pedig sosem jut el.

A rangsorolás alapja a valószínűség × az Önt érintő költség legyen, nem az, mennyire riasztóan hangzik a forgatókönyv. Egy állami szintű ellenfél minden lista legijesztőbb tétele, és szinte minden kis platform esetében a legvalószínűtlenebb — miközben egy korábbi alvállalkozótól származó hitelesítőadat-szivárgás unalmas, rendkívül gyakori és rendszerint katasztrofális.

Hét ellenfél, valószínűség szerint rangsorolva

Ellenfelek valószínűség szerint és ami ellenük hat

Ellenfél	Valószínűség	A hosting segít	Ami valójában ellene hat
Ön, egy rossz napon	Biztos	Nem	Olyan biztonsági mentések, amelyekből ténylegesen már visszaállított, és egy változáskezelési folyamat mindenre, ami a hitelesítést vagy a DNS-t érinti. A legrosszabb kiesésének legvalószínűbb oka Ön saját maga.
Automatizált szkennelés	Folyamatos	Nem	Foltozás, jelszavas hitelesítés kizárása, alapértelmezett hitelesítő adatok hiánya. Ez háttérsugárzás; nem kifejezetten Ön ellen irányul, és sosem áll le.
Hitelesítőadat-kompromittálódás	Magas	Nem	Hardveres második faktor, korlátozott hatókörű API-tokenek, és a hozzáférés visszavonása még aznap, amikor valaki távozik, nem pedig a rákövetkező negyedévben.
Egy panaszos egy űrlappal	Magas	Igen	Ez az egyetlen eset, amelyet a hosting joghatósága ténylegesen érint: hogy önmagában egy levelezés le tudja-e állítani a szolgáltatását.
Volumetrikus támadás	Közepes	Részben	Tranzitszolgáltatói szintű szűrés, pontosabban egy olyan szolgáltató, amely szűr, ahelyett hogy null-routing útján kapcsolná ki Önt saját védelme érdekében.
Célzott behatoló	Alacsony	Nem	Szegmentálás, a legkisebb jogosultság elve, nyugalmi állapotban titkosított adatok, és naplók olyan helyen, ahol a behatoló nem tudja szerkeszteni őket.
Állami szereplő	Nagyon alacsony	Részben	A joghatóság a jogi utat alakítja, nem a technikait. Ha ez valóban szerepel az Ön modelljében, kérjen jogi tanácsot, ne csak egy hosting-csomagot.

Melyeket érinti a hosting-döntés

Hét közül kettőt, és részben egy harmadikat. Ez az arány önmagában a gyakorlat leghasznosabb eredménye, és emiatt éri meg elvégezni a szolgáltató kiválasztása előtt — ez több pénzt takarít meg, mint bármelyik összehasonlító táblázat.

Az egyórás változat

1. Írja össze, mit birtokol ténylegesen (10 perc). Nem rendszereket — adatokat. Felhasználói e-mail-címek, fizetési adatok, privát üzenetek, feltöltött fájlok, más szolgáltatásokhoz tartozó hitelesítő adatok. Jegyezze fel, minek az elvesztése lenne a legrosszabb, és minek a kiszivárgása; ezek ritkán ugyanazok.
2. Írja össze, ki akarná mindegyiket (10 perc). Legyen konkrét. A „hackerek” nem ellenfél; „valaki, aki hitelesítőadat-dumpokat vásárol, hogy fiókokat adjon tovább” az, és ez más védelmet igényel.
3. Rangsoroljon valószínűség × költség szerint (10 perc). Hagyja figyelmen kívül, mennyire drámainak hangzik valami. Az unalmas tételek dominálnak.
4. Az első háromhoz írja le az első órát (20 perc). Mit tenne az egyes esetek első hatvan percében. Ha erre nem tud válaszolni, az maga az eredmény — és értékesebb, mint maga a rangsor.
5. Jelölje meg, melyeket érintik az infrastrukturális döntések (10 perc). Rendszerint az első öt közül kettőt. Most már tudja, mit vásárol valójában a hosting-döntésével.

Végezze el újra, amikor valami strukturális változik — egy új adattípus, egy új integráció, valaki távozása —, ne pedig ütemterv szerint. A naptár által vezérelt felülvizsgálatokat kihagyják; az eseményvezérelteket elvégzik, mert ott áll Ön előtt egy konkrét ok.

Három hiba, amely az egészet haszontalanná teszi

Azt az ellenfelet modellezni, akit érdekesnek talál. Egy nemzetállami szintű képességen sokkal izgalmasabb elgondolkodni, mint egy nyilvános tárolóban kiszivárgott API-tokenen. Az utóbbi szinte mindenkivel megtörtént már, akit ismer. Rangsoroljon őszintén, és az unalmas tételek nyernek — ez a lényeg.

Egy intézkedést összetéveszteni egy eredménnyel. „Titkosítást használunk” nem számít védelmi intézkedésnek, amíg nem tudja megmondani, mit akadályoz meg, és mit nem. A teljes lemeztitkosítás egy futó szerveren azt akadályozza meg, hogy egy lemez elhagyja az épületet; semmit sem ér egy olyan behatoló ellen, akinek parancssori hozzáférése van az élő géphez, mert a kötet már fel van oldva.

Dokumentumot előállítani döntés helyett. Ha a gyakorlat után semmi sem változott — nem vontak vissza jogosultságot, nem teszteltek biztonsági mentést, nem tettek fel kérdést a szolgáltatónak —, akkor az nem fenyegetés-modellezés volt, hanem egy délután. Az eredménynek három olyan intézkedésnek kell lennie, amelyekhez név is tartozik.

Ha a panaszos sora az, amelyik dominálja a táblázatát, a következő kérdés az, melyik joghatóság jöhet szóba, és hogyan ellenőrizhető, amit egy szolgáltató erről állít — hat kérdés, amelyre egy délután alatt válaszolhat. Ha egyáltalán nem szerepel az első öt között, valószínűleg nincs szüksége ránk, és ez egy óra munkájához tökéletesen jó eredmény.

A platformot üzemeltető mérnökök írták, és 1 hónapja újraolvasták. Ha valami itt hibás vagy elavult, jelezze az ügyfélpanelből — ezeknek is körülbelül a fele onnan származik.