Penetracijsko testiranje za SOC 2: izberite test, ki prispeva k varnosti

Penetracijski test daje dokazila o izkoriščljivih šibkostih v opredeljenem sistemu. Njegova vrednost je odvisna od tega, kaj preizkuševalci preučijo, kako to raziščejo in kaj inženirska ekipa naredi z ugotovitvami. Poročilo, ki izpusti pomembne meje zaupanja izdelka, lahko zadosti notranjemu roku, o varnosti pa pove malo.

Za tehničnega direktorja (CTO) uporabno vprašanje ni zgolj, ali je bil test opravljen. Vprašanje je, ali posel preizkusi kontrole, ki ščitijo podatke strank, in ali da ugotovitve, ki jih ekipa lahko ponovi, odpravi in preveri.

Kaj SOC 2 zahteva in česa ne

SOC 2 je poročilo o atestaciji, ne certifikat. Njegova merila temeljijo na načelih; ne nalagajo ene univerzalne zahteve za penetracijski test ali letnega ritma za vsako organizacijo. Katero testiranje je primerno, določajo tveganja, kontrole, ki jih opisujete, pričakovanja revizorja in pogodbe s strankami.

Cilj in pričakovana dokazila se z revizorjem pogovorite, preden naročite posel. Če vaša dokumentirana kontrola obljublja določeno pogostost ali obseg testiranja, načrtujte, kako boste to zavezo izkazali.

Zagotovila za stranke so ločen vidik. Kupec lahko zahteva neodvisen test aplikacije, tudi kadar ga vaš revizijski pristop ne predpisuje. Ta pričakovanja ugotovite zgodaj, vendar ne dovolite, da bi kontrolni seznam nabave nadomestil tehnično opredelitev obsega. Niti poročilo SOC 2 niti penetracijski test ne dokazuje, da sistem nima ranljivosti.

Opredelite površino napada, ne le spletnega mesta

Začnite z arhitekturo, tokovi občutljivih podatkov in mejami zaupanja. OWASP-ove smernice za modeliranje groženj ponujajo uporabno podlago za ugotavljanje, kaj bi lahko šlo narobe in kam naj se testiranje osredotoči.

Pri izdelku SaaS z več najemniki testiranje samo javne pristajalne strani pusti pomembne meje aplikacije nepreučene. Ponudniku dajte popis, ki vključuje API-je, obdelavo v ozadju, administrativna orodja in relevantno infrastrukturo, ne le seznama domen.

Izključitve in omejitve navedite izrecno. Netestiran mobilni odjemalec, nedosegljiva vloga ali nedostopno okolje mora ostati viden v končnem poročilu. Obseg mora tudi ločevati sisteme, ki so v vaši lasti, od storitev tretjih oseb, za napad na katere ne morete pooblastiti preizkuševalcev.

Izberite metodo, ki odgovori na vaša vprašanja

Samodejno skeniranje prepoznava morebitne šibkosti in podpira ponavljajočo se higieno. Penetracijski test dodaja strokovno raziskavo izkoriščljivosti in smiselnih poti napada znotraj pooblaščenega obsega. Orodja so uporabna; izvoz skenerja, preimenovan v penetracijski test, ni enakovreden tej raziskavi.

Testiranje po metodi črne škatle se začne z omejenim poznavanjem sistema. Testiranje po metodi sive škatle zagotovi izbrane informacije ali dostop, pogosto vključno z računi. Testiranje po metodi bele škatle zagotavlja globljo vidnost, po možnosti vključno z izvorno kodo in arhitekturo. Ti pristopi odgovarjajo na različna vprašanja, ne tvorijo pa preproste lestvice kakovosti.

Pri testiranju avtorizacije v aplikaciji lahko računi v več vlogah in najemnikih raziskavo naredijo učinkovitejšo. Samo testiranje zunanje infrastrukture ne more ugotoviti, ali lahko overjeni uporabniki prestopijo meje najemnikov.

Ocenite ponudnika in rezultate

Vprašajte, kdo bo opravil delo in ali je že testiral primerljive arhitekture. Relevantne kvalifikacije podpirajo skrben pregled, vendar same poverilnice ne dokazujejo kompetenc, specifičnih za aplikacijo. Zahtevajte anonimizirano vzorčno poročilo in se pogovorite o tem, kako ekipa raziskuje poslovno logiko, ne le znanih ranljivosti programske opreme.

Pred podpisom razjasnite:

• Kateri sistemi, vloge in poti napada so zajeti ter kako je razporejen napor.
• Katera ročna raziskava dopolnjuje samodejna orodja.
• Kako so nujne ugotovitve sporočene pred končnim poročilom.
• Ali ugotovitve vključujejo ponovljiva dokazila, prizadete komponente, učinek in smernice za odpravo.
• Ali je ponovno testiranje vključeno, kakšno je njegovo časovno okno in kaj se zgodi, če popravki prispejo pozneje.
• Kako so poročila, poverilnice in zajeti podatki zaščiteni in sčasoma izbrisani.

Ponudbe primerjajte po pokritosti in rezultatih, ne le po ceni. Nižja ponudba lahko pomeni ožji posel in ne enakovrednega dela, opravljenega učinkoviteje.

Določite pravila za varno izvedbo

Pred začetkom testiranja dokumentirajte pooblastilo in pravila sodelovanja. Opredelite odobrene gostitelje, račune, okolja, časovna okna testiranja, kontakte za nujne primere in pogoje za ustavitev. Dogovorite se, ali so testiranje zavrnitve storitve, socialni inženiring, ohranjanje dostopa ali izvlečenje podatkov izključeni.

Testiranje v produkciji lahko razkrije resnične težave s konfiguracijo, ustvarja pa tudi operativno tveganje. Reprezentativno testno okolje (staging) je lahko varnejše, pod pogojem, da so razlike od produkcije zabeležene. Kjer je izvedljivo, uporabljajte sintetične podatke najemnikov in se dogovorite, katera dokazila zadoščajo za dokaz učinka, ne da bi zbirali nepotrebne podatke strank.

Zagotovite, da ekipe za spremljanje vedo, kako pooblaščeno dejavnost ločiti od nepovezanega incidenta. Testiranje ne sme postati izgovor za onemogočanje zaščitnih kontrol brez dokumentiranja posledic.

Praktični primer: ugotovitev o izolaciji najemnikov

Vzemimo ponazoritveni posel SaaS. Predpostavimo, da ima izdelek dva testna najemnika, običajne uporabnike, skrbnike najemnikov in vlogo podpore. Test vključuje overjene API-je in delovne tokove izvoza; infrastruktura identitet tretje osebe je izključena.

Preizkuševalec odkrije, da končna točka za izvoz preverja prijavo, ne uveljavlja pa dosledno lastništva najemnika. S sintetičnimi zapisi pokaže, da lahko uporabnik najemnika A zahteva izvoz, ki pripada najemniku B.

Ugotovitev mora opredeliti končno točko, zahtevane privilegije, prizadeti delovni tok, ponovljiva dokazila in poslovni učinek. Inženirska ekipa težavo izsledi do delovnega procesa v ozadju, ki zaupa identifikatorju najemnika iz zahteve.

Popravek lastništvo uveljavi pred načrtovanjem izvoza in ponovno pri njegovi pridobitvi. Regresijski testi zajemajo zahteve med najemniki in relevantne vloge. Ponovno testiranje potrdi, da je prvotna pot blokirana, in preveri povezane poti izvoza. Ekipa ohrani prvotno ugotovitev, dokazila o izvedbi in rezultat ponovnega testa; zahtevka ne označi preprosto kot „opravljeno“.

Ugotovitve spremenite v inženirsko delo z jasno odgovornostjo

Ugotovitve razvrstite glede na tehnično resnost in poslovno izpostavljenost. Upoštevajte zahtevane privilegije, izpostavljenost internetu, prizadete podatke, zanesljivost izkoriščanja in nadomestne kontrole. Nominalno zmerna težava si lahko zasluži nujno obravnavo, kadar poruši kritično mejo med strankami.

Vsaki ugotovitvi dodelite lastnika, ciljni datum in način preverjanja. Kjer je primerno, med pripravo trajnega popravka uvedite začasen ublažitveni ukrep. Morebitno sprejeto preostalo tveganje naj odobri imenovani lastnik tveganja, z utemeljitvijo in datumom pregleda; molk inženirske ekipe ni sprejem.

Zabeležite preizkušeno različico izdelka in okolje. Rezultat izpred večje prenove avtorizacije ne more opisovati nove izvedbe. Kot praktično priporočilo potrebe po testiranju ponovno ocenite po bistvenih arhitekturnih spremembah, resnih incidentih ali novi izpostavljenosti, poleg uveljavljenega ritma.

Dokazila naj ostanejo uporabna za revizorje in kupce

Ohranite dogovorjeni obseg, pravila sodelovanja, končno poročilo, zapise o odpravi, dokazila o ponovnem testiranju in odločitve o tveganjih. Celotno poročilo naj ostane omejeno, ker lahko vsebuje občutljive podrobnosti o izkoriščanju.

Pripravite povzetek za stranke, ki opisuje datume testiranja, obseg, metodologijo, omejitve in status odprave, ne da bi po nepotrebnem razkril navodila za napad. Za nadaljnja vprašanja preberite naš vodnik za pregled zagotovil.

V Secaniju dokazila testa povežite z relevantnimi sistemi, zahtevami, kontrolami, lastniki in odločitvami pregledov. Vrzeli v dokazilih spremljajte kot naloge in ohranite človeško odobritev sklepov. Tako ostane razmerje med tem, kar je bilo preizkušeno, in tem, kar se je spremenilo, na voljo za poznejši pregled.

Pred zahtevanjem ponudb pripravite enostranski obseg, ki zajema meje zaupanja, testne račune, izključitve, rezultate in pričakovanja glede ponovnega testiranja. Ta dokument ponudniku, revizorju in inženirski ekipi da skupno podlago za test, ki prispeva k varnosti.