SOC 2 läbistustestimine: valige test, mis annab turvalisuse kohta teavet

Läbistustest annab tõendeid määratletud süsteemi ärakasutatavate nõrkuste kohta. Selle väärtus sõltub sellest, mida testijad uurivad, kuidas nad seda teevad ja mida inseneritöö leidudega ette võtab. Aruanne, mis jätab välja toote olulised usalduspiirid, võib rahuldada sisemist tähtaega, öeldes samal ajal turvalisuse kohta vähe.

CTO jaoks ei ole kasulik küsimus lihtsalt see, kas test on tehtud. Küsimus on selles, kas töö seab proovile kontrollimeetmed, mis kaitsevad kliendiandmeid, ja annab leiud, mida meeskond saab reprodutseerida, parandada ja kontrollida.

Mida SOC 2 nõuab ja mida mitte

SOC 2 on kinnitusaruanne, mitte sertifikaat. Selle kriteeriumid on põhimõttepõhised; need ei kehtesta igale organisatsioonile üht universaalset läbistustesti nõuet ega iga-aastast sagedust. Sobiva testimise määravad risk, teie kirjeldatud kontrollimeetmed, audiitori ootused ja kliendilepingud.

Arutage eesmärki ja oodatavaid tõendeid oma audiitoriga enne töö tellimist. Kui teie dokumenteeritud kontrollimeede lubab teatud testimissagedust või -ulatust, planeerige selle kohustuse täitmise näitamist.

Klientidele kindluse andmine on eraldi kaalutlus. Ostja võib nõuda sõltumatut rakenduse testi isegi siis, kui teie auditi lähenemisviis seda ette ei näe. Tehke need ootused varakult kindlaks, kuid ärge laske hanke kontroll-loendil asendada tehnilist ulatuse määramist. Ei SOC 2 aruanne ega läbistustest tõenda, et süsteemil pole haavatavusi.

Määrake ulatuseks ründepind, mitte ainult veebisait

Alustage arhitektuurist, tundlikest andmevoogudest ja usalduspiiridest. OWASP-i ohumodelleerimise juhend pakub kasulikku alust selle tuvastamiseks, mis võib valesti minna ja kuhu testimine peaks keskenduma.

Mitme rentnikuga SaaS-toote puhul jätab ainult avaliku sihtlehe testimine olulised rakenduse piirid uurimata. Andke teenusepakkujale inventar, mis hõlmab API-sid, taustatöötlust, haldustööriistu ja asjakohast taristut, mitte ainult domeenide loendit.

Täpsustage välistused ja piirangud selgesõnaliselt. Testimata mobiilirakendus, kättesaamatu roll või ligipääsmatu keskkond peab lõpparuandes nähtavaks jääma. Ulatus peaks eristama ka teile kuuluvaid süsteeme kolmandate osapoolte teenustest, mille ründamiseks te ei saa testijatele luba anda.

Valige meetod, mis vastab teie küsimustele

Automaatne skaneerimine tuvastab võimalikke nõrkusi ja toetab korduvat hügieeni. Läbistustest lisab volitatud ulatuses oskusliku uurimise ärakasutatavuse ja sisukate ründeteede kohta. Tööriistad on kasulikud; ümber nimetatud skanneri eksport ei ole sellise uurimisega samaväärne.

Musta kasti testimine algab piiratud teadmistega süsteemist. Halli kasti testimine annab valitud teavet või juurdepääsu, sageli ka kontosid. Valge kasti testimine annab sügavama nähtavuse, mis võib hõlmata lähtekoodi ja arhitektuuri. Need lähenemisviisid vastavad erinevatele küsimustele, mitte ei moodusta lihtsat kvaliteedijärjestust.

Rakenduse autoriseerimise testimisel võivad mitme rolli ja rentniku kontod muuta uurimise tõhusamaks. Ainult välise taristu testimine ei suuda tõendada, kas autenditud kasutajad saavad rentnike piire ületada.

Hinnake teenusepakkujat ja väljundeid

Küsige, kes töö teeb ja kas nad on testinud võrreldavaid arhitektuure. Asjakohased kvalifikatsioonid toetavad hoolsuskontrolli, kuid ainuüksi sertifikaadid ei tõenda rakendusespetsiifilist pädevust. Küsige anonüümitud näidisaruannet ja arutage, kuidas meeskond uurib äriloogikat, mitte ainult teadaolevaid tarkvarahaavatavusi.

Enne allkirjastamist täpsustage:

• Millised süsteemid, rollid ja ründeteed on kaetud ning kuidas töömaht jaotatakse.
• Milline käsitsi uurimine täiendab automaatseid tööriistu.
• Kuidas kiireloomulistest leidudest teavitatakse enne lõpparuannet.
• Kas leiud sisaldavad reprodutseeritavaid tõendeid, mõjutatud komponente, mõju ja parandusjuhiseid.
• Kas kordustestimine on hinnas, milline on selle ajaaken ja mis juhtub, kui parandused saabuvad hiljem.
• Kuidas aruandeid, volitusi ja kogutud andmeid kaitstakse ja lõpuks kustutatakse.

Võrrelge pakkumisi kaetuse ja väljundite, mitte ainult hinna põhjal. Madalam hinnapakkumine võib tähendada kitsamat tööd, mitte samaväärset tööd, mis on tehtud tõhusamalt.

Kehtestage ohutu läbiviimise reeglid

Dokumenteerige luba ja testimise reeglid enne testimise algust. Määrake heakskiidetud hostid, kontod, keskkonnad, testimisaknad, hädaolukorra kontaktid ja peatamistingimused. Leppige kokku, kas teenusetõkestuse testimine, sotsiaalne manipuleerimine, püsivuse saavutamine või andmete väljavõtmine on välistatud.

Tootmiskeskkonnas testimine võib paljastada tegelikke konfiguratsiooniprobleeme, kuid see loob ka operatiivse riski. Esinduslik testkeskkond võib olla turvalisem, eeldusel et erinevused tootmiskeskkonnast on kirja pandud. Kasutage võimaluse korral sünteetilisi rentnikuandmeid ja leppige kokku, millised tõendid on mõju tõendamiseks piisavad, ilma et kogutaks mittevajalikku klienditeavet.

Veenduge, et seiremeeskonnad teavad, kuidas eristada lubatud tegevust mitteseotud intsidendist. Testimine ei tohiks muutuda ettekäändeks kaitsvate kontrollimeetmete väljalülitamiseks ilma tagajärgi dokumenteerimata.

Näide: rentnike isoleerimise leid

Vaatleme illustreerivat SaaS-i testimistööd. Oletame, et tootel on kaks testrentnikku, tavakasutajad, rentnike administraatorid ja tugiroll. Test hõlmab autenditud API-sid ja eksporditöövooge; kolmanda osapoole identiteeditaristu on välistatud.

Testija avastab, et ekspordi otspunkt kontrollib sisselogimist, kuid ei jõusta järjepidevalt rentniku omandit. Sünteetiliste kirjete abil näitab ta, et rentniku A kasutaja saab taotleda rentnikule B kuuluvat eksporti.

Leid peaks tuvastama otspunkti, nõutavad õigused, mõjutatud töövoo, reprodutseeritavad tõendid ja ärimõju. Inseneritöö jälitab probleemi taustatöötlejani, mis usaldab päringus esitatud rentniku identifikaatorit.

Parandus jõustab omandi enne ekspordi ajastamist ja uuesti selle hankimisel. Regressioonitestid katavad rentnikevahelisi päringuid ja asjakohaseid rolle. Kordustest kinnitab, et algne tee on blokeeritud, ja kontrollib seotud eksporditeid. Meeskond säilitab algse leiu, rakendamise tõendid ja kordustesti tulemuse; ta ei märgi piletit lihtsalt „tehtuks“.

Muutke leiud vastutavaks insenertehniliseks tööks

Triažeerige leiud tehnilise raskusastme ja ärilise kokkupuute põhjal. Arvestage nõutavaid õigusi, internetile avatust, mõjutatud andmeid, ärakasutamise usaldusväärsust ja kompenseerivaid kontrollimeetmeid. Nimeliselt mõõdukas probleem võib vajada kiiret käsitlemist, kui see lõhub kriitilise kliendipiiri.

Määrake igale leiule omanik, sihtkuupäev ja kontrollimise meetod. Kus asjakohane, juurutage püsiva paranduse ettevalmistamise ajal ajutine leevendusmeede. Laske määratud riskiomanikul kiita heaks iga aktsepteeritud jääkrisk koos põhjenduse ja ülevaatuse kuupäevaga; inseneride vaikimine ei ole aktsepteerimine.

Pange kirja testitud toote versioon ja keskkond. Enne suurt autoriseerimise ümberkujundamist saadud tulemus ei saa kirjeldada uut rakendust. Praktilise soovitusena hinnake testimisvajadusi uuesti pärast olulisi arhitektuurimuudatusi, tõsiseid intsidente või uut kokkupuudet, lisaks oma väljakujunenud sagedusele.

Hoidke tõendid audiitoritele ja ostjatele kasulikuna

Säilitage kokkulepitud ulatus, testimise reeglid, lõpparuanne, parandustööde kirjed, kordustesti tõendid ja riskiotsused. Hoidke täielik aruanne piiratud juurdepääsuga, sest see võib sisaldada tundlikke ärakasutamise üksikasju.

Valmistage ette klientidele suunatud kokkuvõte, mis kirjeldab testi kuupäevi, ulatust, metoodikat, piiranguid ja parandustööde olekut, paljastamata asjatult ründejuhiseid. Järelküsimuste jaoks lugege meie kindlustandvate tõendite ülevaatuse juhendit.

Secanis siduge testitõendid asjakohaste süsteemide, nõuete, kontrollimeetmete, omanike ja ülevaatusotsustega. Jälgige tõendilünki ülesannetena ja säilitage järelduste inimpoolne heakskiit. See hoiab seose testitu ja muudetu vahel hilisemaks ülevaatuseks kättesaadavana.

Enne pakkumiste küsimist koostage üheleheküljeline ulatuse kirjeldus, mis hõlmab usalduspiire, testkontosid, välistusi, väljundeid ja kordustestimise ootusi. See dokument annab teenusepakkujale, audiitorile ja insenerimeeskonnale ühise aluse testiks, mis annab turvalisuse kohta teavet.