Penetrációs tesztelés SOC 2-höz: olyan tesztet válasszon, amely a biztonságról is tájékoztat

A penetrációs teszt bizonyítékot szolgáltat egy meghatározott rendszer kihasználható gyengeségeiről. Az értéke attól függ, mit vizsgálnak a tesztelők, hogyan járnak utána, és mit kezd a fejlesztés a megállapításokkal. Egy olyan jelentés, amely kihagyja a termék fontos bizalmi határait, kielégíthet egy belső határidőt, miközben keveset árul el a biztonságról.

Egy CTO számára nem az a hasznos kérdés, hogy elkészült-e a teszt. Hanem az, hogy a megbízás próbára teszi-e az ügyféladatokat védő kontrollokat, és olyan megállapításokat hoz-e, amelyeket a csapat reprodukálni, kijavítani és ellenőrizni tud.

Mit követel meg a SOC 2 – és mit nem

A SOC 2 igazolási (attesztációs) jelentés, nem tanúsítvány. A kritériumai elvalapúak; nem írnak elő minden szervezet számára egyetlen egységes penetrációsteszt-követelményt vagy éves gyakoriságot. Hogy milyen tesztelés megfelelő, azt a kockázat, az Ön által leírt kontrollok, az auditor elvárásai és az ügyfélszerződések határozzák meg.

A megbízás előtt egyeztesse az auditorral a célt és a várt bizonyítékokat. Ha a dokumentált kontrollja meghatározott tesztelési gyakoriságot vagy hatókört ígér, készüljön fel arra, hogy ezt a vállalást igazolja.

Az ügyfelek felé nyújtott bizonyosság külön szempont. Egy vevő akkor is megkövetelhet független alkalmazástesztet, ha az Ön auditmegközelítése ezt nem írja elő. Ezeket az elvárásokat korán tisztázza, de ne engedje, hogy egy beszerzési ellenőrzőlista helyettesítse a műszaki hatókör meghatározását. Sem egy SOC 2-jelentés, sem egy penetrációs teszt nem igazolja, hogy egy rendszerben nincsenek sérülékenységek.

A támadási felületet határozza meg, ne csak a weboldalt

Induljon ki az architektúrából, az érzékeny adatfolyamokból és a bizalmi határokból. Az OWASP fenyegetésmodellezési útmutatója hasznos alapot ad annak azonosításához, mi romolhat el, és hová kell a tesztelésnek összpontosítania.

Egy több bérlős (multi-tenant) SaaS-terméknél, ha csak a nyilvános nyitóoldalt tesztelik, a fontos alkalmazáshatárok vizsgálatlanok maradnak. Adjon a szolgáltatónak olyan leltárt, amely az API-kat, a háttérfeldolgozást, az adminisztrációs eszközöket és a releváns infrastruktúrát is tartalmazza – ne csak egy domainlistát.

A kizárásokat és a korlátozásokat kifejezetten rögzítse. Egy nem tesztelt mobilkliensnek, egy elérhetetlen szerepkörnek vagy egy hozzáférhetetlen környezetnek láthatónak kell maradnia a zárójelentésben. A hatókörnek azt is meg kell különböztetnie, mely rendszerek az Önéi, és melyek azok a harmadik féltől származó szolgáltatások, amelyek támadására nem adhat engedélyt a tesztelőknek.

Olyan módszert válasszon, amely megválaszolja a kérdéseit

Az automatizált szkennelés azonosítja a lehetséges gyengeségeket, és támogatja a rendszeres alapszintű biztonsági higiéniát. A penetrációs teszt ehhez hozzáadja a kihasználhatóság és az érdemi támadási útvonalak szakértői vizsgálatát egy engedélyezett hatókörön belül. Az eszközök hasznosak; egy penetrációs tesztnek átcímkézett szkennerexport azonban nem egyenértékű ezzel a vizsgálattal.

A black-box tesztelés korlátozott rendszerismerettel indul. A gray-box tesztelés kiválasztott információkat vagy hozzáférést biztosít, gyakran fiókokat is. A white-box tesztelés mélyebb rálátást ad, akár a forráskódra és az architektúrára is. Ezek a megközelítések különböző kérdésekre válaszolnak, nem pedig egyszerű minőségi rangsort alkotnak.

Az alkalmazás jogosultságkezelésének teszteléséhez a több szerepkörre és bérlőre kiterjedő fiókok hatékonyabbá tehetik a vizsgálatot. A külső infrastruktúra tesztelése önmagában nem tudja megállapítani, hogy a hitelesített felhasználók átléphetik-e a bérlők közötti határokat.

Értékelje a szolgáltatót és az átadandó eredményeket

Kérdezze meg, ki végzi a munkát, és teszteltek-e már hasonló architektúrákat. A releváns képesítések támogatják az átvilágítást, de a tanúsítványok önmagukban nem igazolják az alkalmazásspecifikus szakértelmet. Kérjen anonimizált mintajelentést, és beszélje meg, hogyan vizsgálja a csapat az üzleti logikát, nem csak az ismert szoftveres sérülékenységeket.

Az aláírás előtt tisztázza:

• Mely rendszerek, szerepkörök és támadási útvonalak tartoznak bele, és hogyan oszlik meg a ráfordítás.
• Milyen manuális vizsgálat egészíti ki az automatizált eszközöket.
• Hogyan közlik a sürgős megállapításokat a zárójelentés előtt.
• Tartalmaznak-e a megállapítások reprodukálható bizonyítékot, az érintett komponenseket, a hatást és javítási útmutatást.
• Benne van-e az újratesztelés, mekkora az időablaka, és mi történik, ha a javítások később érkeznek.
• Hogyan védik, majd végül hogyan törlik a jelentéseket, a hitelesítő adatokat és a rögzített adatokat.

Az ajánlatokat a lefedettség és az átadandó eredmények alapján hasonlítsa össze, ne csak az ár alapján. Egy alacsonyabb ajánlat szűkebb megbízást is jelenthet, nem feltétlenül ugyanazt a munkát hatékonyabban elvégezve.

Rögzítsen biztonságos végrehajtási szabályokat

A tesztelés megkezdése előtt dokumentálja az engedélyt és a végrehajtási szabályokat (rules of engagement). Határozza meg a jóváhagyott hosztokat, fiókokat, környezeteket, tesztelési időablakokat, vészhelyzeti kapcsolattartókat és leállítási feltételeket. Egyezzenek meg abban, hogy ki van-e zárva a szolgáltatásmegtagadásos (DoS) tesztelés, a social engineering, a perzisztencia vagy az adatkinyerés.

Az éles környezetben végzett tesztelés valós konfigurációs problémákat tárhat fel, de működési kockázatot is jelent. Egy reprezentatív staging környezet biztonságosabb lehet, feltéve, hogy az éles környezettől való eltéréseket rögzítik. Ahol lehetséges, használjon szintetikus bérlői adatokat, és egyezzenek meg abban, milyen bizonyíték elegendő a hatás igazolásához anélkül, hogy szükségtelen ügyféladatokat gyűjtenének.

Gondoskodjon arról, hogy a monitorozó csapatok meg tudják különböztetni az engedélyezett tevékenységet egy nem kapcsolódó incidenstől. A tesztelés nem lehet ürügy a védelmi kontrollok kikapcsolására anélkül, hogy a következményeket dokumentálnák.

Gyakorlati példa: egy bérlőelkülönítési megállapítás

Vegyünk egy szemléltető SaaS-megbízást. Tegyük fel, hogy a terméknek két tesztbérlője van, valamint egyszerű felhasználói, bérlői adminisztrátorai és egy támogatási szerepköre. A teszt kiterjed a hitelesített API-kra és az exportálási munkafolyamatokra; a harmadik féltől származó identitásinfrastruktúra ki van zárva.

Egy tesztelő felfedezi, hogy egy exportálási végpont ellenőrzi a bejelentkezést, de nem érvényesíti következetesen a bérlői tulajdonjogot. Szintetikus rekordok segítségével bemutatja, hogy az A bérlő egyik felhasználója lekérhet egy B bérlőhöz tartozó exportot.

A megállapításnak meg kell neveznie a végpontot, a szükséges jogosultságokat, az érintett munkafolyamatot, a reprodukálható bizonyítékot és az üzleti hatást. A fejlesztés a problémát egy olyan háttérfolyamatra vezeti vissza, amely megbízik a kérésben megadott bérlőazonosítóban.

A javítás az export ütemezése előtt, majd a lekéréskor ismét érvényesíti a tulajdonjogot. Regressziós tesztek fedik le a bérlők közötti kéréseket és a releváns szerepköröket. Az újratesztelés megerősíti, hogy az eredeti útvonal blokkolva van, és ellenőrzi a kapcsolódó exportálási útvonalakat is. A csapat megőrzi az eredeti megállapítást, a megvalósítás bizonyítékait és az újratesztelés eredményét; nem egyszerűen „kész” állapotúra állítja a jegyet.

Alakítsa a megállapításokat elszámoltatható fejlesztési munkává

A megállapításokat a műszaki súlyosság és az üzleti kitettség alapján priorizálja. Vegye figyelembe a szükséges jogosultságokat, az internetes kitettséget, az érintett adatokat, a kihasználás megbízhatóságát és a kompenzáló kontrollokat. Egy névleg közepes probléma is sürgős kezelést érdemelhet, ha egy kritikus ügyfélhatárt tör át.

Minden megállapításhoz rendeljen felelőst, céldátumot és ellenőrzési módszert. Ahol indokolt, vezessen be átmeneti kockázatcsökkentést, amíg a tartós javítás elkészül. Az elfogadott maradványkockázatot egy kijelölt kockázatgazda hagyja jóvá, indoklással és felülvizsgálati dátummal; a fejlesztés hallgatása nem elfogadás.

Rögzítse a tesztelt termékverziót és környezetet. Egy jelentős jogosultságkezelési átalakítás előtti eredmény nem írhatja le az új megvalósítást. Gyakorlati ajánlásként a megszokott gyakoriság mellett jelentős architekturális változások, súlyos incidensek vagy új kitettség után is értékelje újra a tesztelési igényeket.

Tartsa a bizonyítékokat hasznosan az auditorok és a vevők számára

Őrizze meg az egyeztetett hatókört, a végrehajtási szabályokat, a zárójelentést, a javítási nyilvántartásokat, az újratesztelés bizonyítékait és a kockázati döntéseket. A teljes jelentéshez korlátozza a hozzáférést, mert érzékeny részleteket tartalmazhat a kihasználásról.

Készítsen az ügyfeleknek szóló összefoglalót, amely leírja a teszt dátumait, hatókörét, módszertanát, korlátait és a javítások állapotát anélkül, hogy szükségtelenül felfedné a támadási utasításokat. A további kérdésekhez olvassa el a bizonyosság értékeléséről szóló útmutatónkat.

A Secaniban kapcsolja össze a teszt bizonyítékait a releváns rendszerekkel, követelményekkel, kontrollokkal, felelősökkel és felülvizsgálati döntésekkel. Kövesse nyomon a bizonyítékhiányokat feladatként, és őrizze meg a következtetések emberi jóváhagyását. Így a tesztelt elemek és a változások közötti kapcsolat a későbbi felülvizsgálathoz is rendelkezésre áll.

Az ajánlatkérés előtt készítsen egyoldalas hatókörleírást, amely kitér a bizalmi határokra, a tesztfiókokra, a kizárásokra, az átadandó eredményekre és az újratesztelési elvárásokra. Ez a dokumentum közös alapot ad a szolgáltatónak, az auditornak és a fejlesztőcsapatnak egy olyan teszthez, amely valóban tájékoztat a biztonságról.