Penetračné testovanie pre SOC 2: vyberte test, ktorý vypovedá o bezpečnosti

Penetračný test poskytuje dôkazy o zneužiteľných slabinách v definovanom systéme. Jeho hodnota závisí od toho, čo testeri skúmajú, ako to skúmajú a čo inžiniersky tím so zisteniami urobí. Správa, ktorá vynecháva dôležité hranice dôvery produktu, môže splniť interný termín, no o bezpečnosti povie len málo.

Pre CTO nie je užitočnou otázkou len to, či bol test dokončený. Ide o to, či zákazka preverí kontroly, ktoré chránia zákaznícke dáta, a či prinesie zistenia, ktoré tím dokáže reprodukovať, opraviť a overiť.

Čo SOC 2 vyžaduje – a čo nie

SOC 2 je atestačná správa, nie certifikácia. Jeho kritériá sú založené na princípoch; nestanovujú jednu univerzálnu požiadavku na penetračný test ani ročnú frekvenciu pre každú organizáciu. O vhodnom testovaní rozhodujú riziko, kontroly, ktoré opisujete, očakávania audítora a zmluvy so zákazníkmi.

Pred zadaním zákazky prediskutujte s audítorom cieľ a očakávané dôkazy. Ak vaša zdokumentovaná kontrola sľubuje konkrétnu frekvenciu alebo rozsah testovania, počítajte s tým, že tento záväzok budete musieť preukázať.

Uistenie zákazníkov je samostatnou otázkou. Kupujúci môže vyžadovať nezávislý test aplikácie, aj keď ho váš prístup k auditu nepredpisuje. Tieto očakávania si ujasnite včas, no nedovoľte, aby nákupný kontrolný zoznam nahradil technické vymedzenie rozsahu. Ani správa SOC 2, ani penetračný test nepreukazujú, že systém nemá žiadne zraniteľnosti.

Vymedzte útočnú plochu, nie len webovú stránku

Začnite architektúrou, tokmi citlivých dát a hranicami dôvery. Usmernenie OWASP k modelovaniu hrozieb ponúka užitočný základ na určenie, čo sa môže pokaziť a kam by sa malo testovanie sústrediť.

Pri viacnájomníckom (multi-tenant) SaaS produkte zostanú pri testovaní len verejnej úvodnej stránky dôležité hranice aplikácie nepreskúmané. Poskytnite dodávateľovi inventár, ktorý zahŕňa API, spracovanie na pozadí, administrátorské nástroje a relevantnú infraštruktúru – nie len zoznam domén.

Výnimky a obmedzenia uveďte výslovne. Netestovaný mobilný klient, nedostupná rola alebo neprístupné prostredie musia zostať viditeľné v záverečnej správe. Rozsah by mal tiež rozlišovať systémy, ktoré vlastníte, od služieb tretích strán, na ktoré nemôžete testerov oprávniť útočiť.

Zvoľte metódu, ktorá odpovedá na vaše otázky

Automatizované skenovanie identifikuje potenciálne slabiny a podporuje pravidelnú hygienu. Penetračný test pridáva odborné skúmanie zneužiteľnosti a zmysluplných útočných ciest v rámci autorizovaného rozsahu. Nástroje sú užitočné; export zo skenera premenovaný na penetračný test však takémuto skúmaniu nezodpovedá.

Testovanie black-box začína s obmedzenou znalosťou systému. Testovanie gray-box poskytuje vybrané informácie alebo prístup, často vrátane účtov. Testovanie white-box poskytuje hlbší pohľad, potenciálne vrátane zdrojového kódu a architektúry. Tieto prístupy odpovedajú na rôzne otázky a netvoria jednoduché poradie kvality.

Pri testovaní autorizácie v aplikácii môžu účty v niekoľkých rolách a u niekoľkých nájomníkov skúmanie zefektívniť. Samotné testovanie externej infraštruktúry nedokáže zistiť, či autentifikovaní používatelia môžu prekročiť hranice medzi nájomníkmi.

Vyhodnoťte dodávateľa a výstupy

Opýtajte sa, kto bude prácu vykonávať a či testoval porovnateľné architektúry. Relevantné kvalifikácie podporujú náležitú starostlivosť, no samotné certifikáty nepreukazujú odbornosť pre konkrétnu aplikáciu. Vyžiadajte si anonymizovanú vzorovú správu a prediskutujte, ako tím skúma biznis logiku, nie len známe softvérové zraniteľnosti.

Pred podpisom si ujasnite:

• Ktoré systémy, roly a útočné cesty sú pokryté a ako je rozdelené úsilie.
• Aké manuálne skúmanie dopĺňa automatizované nástroje.
• Ako sa urgentné zistenia komunikujú ešte pred záverečnou správou.
• Či zistenia obsahujú reprodukovateľné dôkazy, dotknuté komponenty, dopad a odporúčania na nápravu.
• Či je zahrnuté opakované testovanie, v akom časovom okne a čo sa stane, ak opravy prídu neskôr.
• Ako sú správy, prístupové údaje a zachytené dáta chránené a napokon vymazané.

Porovnávajte ponuky podľa pokrytia a výstupov, nie len podľa ceny. Nižšia cenová ponuka môže predstavovať užší rozsah zákazky, a nie rovnocennú prácu vykonanú efektívnejšie.

Stanovte pravidlá bezpečného vykonávania

Pred začatím testovania zdokumentujte autorizáciu a pravidlá zapojenia (rules of engagement). Určte schválené hostiteľské systémy, účty, prostredia, časové okná testovania, núdzové kontakty a podmienky zastavenia. Dohodnite sa, či je vylúčené testovanie odmietnutia služby, sociálne inžinierstvo, perzistencia alebo extrakcia dát.

Testovanie v produkcii môže odhaliť skutočné konfiguračné problémy, no zároveň vytvára prevádzkové riziko. Reprezentatívne staging prostredie môže byť bezpečnejšie, ak sa zaznamenajú rozdiely oproti produkcii. Kde je to možné, používajte syntetické dáta nájomníkov a dohodnite sa, aké dôkazy postačujú na preukázanie dopadu bez zbytočného zhromažďovania zákazníckych informácií.

Zabezpečte, aby monitorovacie tímy vedeli rozlíšiť autorizovanú aktivitu od nesúvisiaceho incidentu. Testovanie by sa nemalo stať zámienkou na vypnutie ochranných kontrol bez zdokumentovania dôsledkov.

Praktický príklad: zistenie v izolácii nájomníkov

Zoberme si ilustratívnu SaaS zákazku. Predpokladajme, že produkt má dvoch testovacích nájomníkov, bežných používateľov, administrátorov nájomníkov a rolu podpory. Test zahŕňa autentifikované API a exportné pracovné postupy; infraštruktúra identít tretej strany je vylúčená.

Tester zistí, že exportný endpoint overuje prihlásenie, ale nedôsledne vynucuje vlastníctvo nájomníka. Pomocou syntetických záznamov preukáže, že používateľ nájomníka A si môže vyžiadať export patriaci nájomníkovi B.

Zistenie by malo uvádzať endpoint, potrebné oprávnenia, dotknutý pracovný postup, reprodukovateľné dôkazy a biznis dopad. Inžiniersky tím vystopuje problém k procesu na pozadí, ktorý dôveruje identifikátoru nájomníka zadanému v požiadavke.

Oprava vynucuje vlastníctvo pred naplánovaním exportu a znova pri jeho načítaní. Regresné testy pokrývajú požiadavky naprieč nájomníkmi a relevantné roly. Opakovaný test potvrdí, že pôvodná cesta je zablokovaná, a preverí súvisiace exportné cesty. Tím uchová pôvodné zistenie, dôkazy o implementácii a výsledok opakovaného testu; tiket jednoducho neoznačí ako „hotový“.

Premeňte zistenia na zodpovednú inžiniersku prácu

Triedenie zistení robte podľa technickej závažnosti a biznis expozície. Zohľadnite potrebné oprávnenia, vystavenie internetu, dotknuté dáta, spoľahlivosť zneužitia a kompenzačné kontroly. Nominálne stredne závažný problém si môže zaslúžiť urgentné riešenie, ak narúša kritickú hranicu zákazníka.

Každému zisteniu priraďte zodpovednú osobu, cieľový termín a metódu overenia. Kde je to vhodné, nasaďte dočasné zmiernenie, kým sa pripravuje trvalá oprava. Akékoľvek akceptované zvyškové riziko nechajte schváliť určeným vlastníkom rizika, s odôvodnením a dátumom preskúmania; mlčanie inžinierskeho tímu nie je akceptácia.

Zaznamenajte testovanú verziu produktu a prostredie. Výsledok spred zásadného prepracovania autorizácie nemôže opisovať novú implementáciu. Ako praktické odporúčanie prehodnoťte potrebu testovania po podstatných architektonických zmenách, vážnych incidentoch alebo novej expozícii, popri zavedenej frekvencii.

Udržiavajte dôkazy užitočné pre audítorov a kupujúcich

Uchovávajte dohodnutý rozsah, pravidlá zapojenia, záverečnú správu, záznamy o náprave, dôkazy z opakovaného testu a rozhodnutia o rizikách. Úplnú správu udržiavajte s obmedzeným prístupom, pretože môže obsahovať citlivé podrobnosti o zneužití.

Pripravte zhrnutie pre zákazníkov, ktoré opisuje termíny testu, rozsah, metodiku, obmedzenia a stav nápravy bez zbytočného odhaľovania návodov na útok. Pri doplňujúcich otázkach si prečítajte náš návod na preskúmanie uistenia.

V Secani prepojte dôkazy z testu s relevantnými systémami, požiadavkami, kontrolami, zodpovednými osobami a rozhodnutiami z preskúmania. Medzery v dôkazoch sledujte ako úlohy a zachovajte ľudské schvaľovanie záverov. Vzťah medzi tým, čo sa testovalo, a tým, čo sa zmenilo, tak zostane dostupný na neskoršie preskúmanie.

Pred vyžiadaním ponúk pripravte jednostranový rozsah, ktorý pokrýva hranice dôvery, testovacie účty, výnimky, výstupy a očakávania týkajúce sa opakovaného testovania. Tento dokument poskytne dodávateľovi, audítorovi aj inžinierskemu tímu spoločný základ pre test, ktorý vypovedá o bezpečnosti.