SOC 2 skverbties testavimas: pasirinkite testą, kuris iš tikrųjų informuoja apie saugumą

Skverbties testas pateikia įrodymų apie išnaudojamus apibrėžtos sistemos trūkumus. Jo vertė priklauso nuo to, ką testuotojai tiria, kaip jie tai daro ir ką inžinerijos komanda nuveikia su radiniais. Ataskaita, kurioje praleistos svarbios produkto pasitikėjimo ribos, gali padėti įvykdyti vidinį terminą, bet mažai ką pasakyti apie saugumą.

Technologijų vadovui naudingas klausimas yra ne tik tai, ar testas atliktas. Svarbu, ar užsakymas iš tikrųjų išbando kontrolės priemones, saugančias klientų duomenis, ir ar pateikia radinius, kuriuos komanda gali atkurti, ištaisyti ir patikrinti.

Ką SOC 2 reikalauja ir ko nereikalauja

SOC 2 yra patvirtinimo ataskaita, o ne sertifikatas. Jos kriterijai grindžiami principais; jie nenustato vieno visuotinio skverbties testavimo reikalavimo ar metinio periodiškumo kiekvienai organizacijai. Tinkamą testavimą lemia rizika, jūsų aprašytos kontrolės priemonės, auditoriaus lūkesčiai ir sutartys su klientais.

Prieš užsakydami testą, aptarkite tikslą ir laukiamus įrodymus su savo auditoriumi. Jei dokumentuota kontrolės priemonė žada tam tikrą testavimo dažnumą ar apimtį, planuokite šį įsipareigojimą įrodyti.

Klientų pasitikėjimo užtikrinimas yra atskiras klausimas. Pirkėjas gali reikalauti nepriklausomo programos testo net tada, kai jūsų audito metodas jo nenumato. Šiuos lūkesčius nustatykite anksti, tačiau neleiskite pirkimų kontroliniam sąrašui pakeisti techninio apimties nustatymo. Nei SOC 2 ataskaita, nei skverbties testas neįrodo, kad sistemoje nėra pažeidžiamumų.

Apibrėžkite atakos paviršių, o ne tik svetainę

Pradėkite nuo architektūros, jautrių duomenų srautų ir pasitikėjimo ribų. OWASP grėsmių modeliavimo gairės suteikia naudingą pagrindą nustatyti, kas gali nepavykti ir kur testavimas turėtų būti sutelktas.

Kelių nuomininkų SaaS produkto atveju testuojant tik viešą nukreipimo puslapį svarbios programos ribos lieka neištirtos. Pateikite paslaugų teikėjui inventorių, apimantį API, foninį apdorojimą, administravimo įrankius ir susijusią infrastruktūrą, o ne vien domenų sąrašą.

Išimtis ir apribojimus nurodykite aiškiai. Netestuotas mobilusis klientas, neprieinamas vaidmuo ar nepasiekiama aplinka turi likti matomi galutinėje ataskaitoje. Apimtis taip pat turėtų atskirti jums priklausančias sistemas nuo trečiųjų šalių paslaugų, kurių atakuoti testuotojams negalite leisti.

Pasirinkite metodą, kuris atsako į jūsų klausimus

Automatinis skenavimas nustato galimus trūkumus ir padeda palaikyti reguliarią higieną. Skverbties testas papildomai suteikia kvalifikuotą išnaudojamumo ir reikšmingų atakos kelių tyrimą leistinoje apimtyje. Įrankiai yra naudingi, tačiau skenerio eksportas, pervadintas skverbties testu, nėra lygiavertis tokiam tyrimui.

Juodosios dėžės testavimas pradedamas turint ribotų žinių apie sistemą. Pilkosios dėžės testavimas suteikia pasirinktą informaciją ar prieigą, dažnai įskaitant paskyras. Baltosios dėžės testavimas suteikia gilesnį matomumą, galbūt įskaitant išeitinį kodą ir architektūrą. Šie metodai atsako į skirtingus klausimus, o ne sudaro paprastą kokybės reitingą.

Testuojant programos autorizavimą, paskyros keliuose vaidmenyse ir keliems nuomininkams gali padaryti tyrimą veiksmingesnį. Vien išorinės infrastruktūros testavimas negali nustatyti, ar autentifikuoti naudotojai gali peržengti nuomininkų ribas.

Įvertinkite paslaugų teikėją ir rezultatus

Paklauskite, kas atliks darbą ir ar jie yra testavę panašias architektūras. Atitinkama kvalifikacija padeda atlikti išsamų patikrinimą, tačiau vien sertifikatai neįrodo konkrečiai programai reikalingos kompetencijos. Paprašykite nuasmeninto ataskaitos pavyzdžio ir aptarkite, kaip komanda tiria verslo logiką, o ne tik žinomus programinės įrangos pažeidžiamumus.

Prieš pasirašydami išsiaiškinkite:

• Kurios sistemos, vaidmenys ir atakos keliai apimami ir kaip paskirstomos pastangos.
• Koks rankinis tyrimas papildo automatinius įrankius.
• Kaip apie skubius radinius pranešama dar prieš galutinę ataskaitą.
• Ar radiniuose pateikiami atkuriami įrodymai, paveikti komponentai, poveikis ir šalinimo rekomendacijos.
• Ar įtrauktas pakartotinis testavimas, koks jo laikotarpis ir kas nutinka, jei pataisymai pateikiami vėliau.
• Kaip saugomos ir galiausiai ištrinamos ataskaitos, prisijungimo duomenys ir surinkti duomenys.

Palyginkite pasiūlymus pagal aprėptį ir rezultatus, o ne vien pagal kainą. Mažesnė kaina gali reikšti siauresnį užsakymą, o ne lygiavertį darbą, atliktą efektyviau.

Nustatykite saugaus vykdymo taisykles

Prieš pradėdami testavimą, dokumentuokite leidimą ir užsakymo taisykles. Nurodykite patvirtintus serverius, paskyras, aplinkas, testavimo laikotarpius, avarinius kontaktus ir sustabdymo sąlygas. Susitarkite, ar neįtraukiami paslaugos trikdymo (DoS) testai, socialinė inžinerija, įsitvirtinimas ar duomenų išgavimas.

Testavimas gamybinėje aplinkoje gali atskleisti realias konfigūracijos problemas, tačiau jis kelia ir veiklos riziką. Reprezentatyvi parengiamoji aplinka gali būti saugesnė, jei užfiksuojami jos skirtumai nuo gamybinės aplinkos. Kur įmanoma, naudokite sintetinius nuomininkų duomenis ir susitarkite, kokių įrodymų pakanka poveikiui įrodyti nerenkant nereikalingos klientų informacijos.

Užtikrinkite, kad stebėsenos komandos žinotų, kaip atskirti leistiną veiklą nuo nesusijusio incidento. Testavimas neturėtų tapti pasiteisinimu išjungti apsaugos priemones nedokumentavus pasekmių.

Pavyzdys: nuomininkų izoliacijos radinys

Panagrinėkime iliustracinį SaaS užsakymą. Tarkime, produktas turi du testinius nuomininkus, įprastus naudotojus, nuomininkų administratorius ir palaikymo vaidmenį. Testas apima autentifikuotas API ir eksporto darbo eigas; trečiosios šalies tapatybės infrastruktūra neįtraukta.

Testuotojas nustato, kad eksporto galinis taškas patikrina prisijungimą, bet nuosekliai neužtikrina nuomininko nuosavybės. Naudodamas sintetinius įrašus, jis parodo, kad nuomininko A naudotojas gali užklausti nuomininkui B priklausančio eksporto.

Radinyje turėtų būti nurodytas galinis taškas, reikalingos teisės, paveikta darbo eiga, atkuriami įrodymai ir poveikis verslui. Inžinerijos komanda nustato, kad problemos šaltinis yra foninis procesas, pasitikintis užklausoje pateiktu nuomininko identifikatoriumi.

Pataisymas užtikrina nuosavybės patikrą prieš suplanuojant eksportą ir dar kartą jį gaunant. Regresijos testai apima užklausas tarp nuomininkų ir atitinkamus vaidmenis. Pakartotinis testavimas patvirtina, kad pradinis kelias užblokuotas, ir patikrina susijusius eksporto kelius. Komanda išsaugo pradinį radinį, įgyvendinimo įrodymus ir pakartotinio testo rezultatą; ji ne šiaip pažymi užduotį kaip „atlikta“.

Paverskite radinius atskaitingu inžineriniu darbu

Radinius rūšiuokite pagal techninį sunkumą ir poveikį verslui. Atsižvelkite į reikalingas teises, pasiekiamumą iš interneto, paveiktus duomenis, išnaudojimo patikimumą ir kompensuojamąsias kontrolės priemones. Formaliai vidutinė problema gali reikalauti skubaus sprendimo, jei ji pažeidžia kritinę kliento ribą.

Kiekvienam radiniui paskirkite atsakingą asmenį, tikslinę datą ir patikros metodą. Kur tinka, įdiekite laikiną rizikos mažinimo priemonę, kol rengiamas ilgalaikis pataisymas. Bet kokią priimtą liekamąją riziką turi patvirtinti paskirtas rizikos savininkas, nurodydamas pagrindimą ir peržiūros datą; inžinerijos komandos tylėjimas nėra rizikos priėmimas.

Užfiksuokite testuotą produkto versiją ir aplinką. Rezultatas, gautas prieš esminį autorizavimo pertvarkymą, negali apibūdinti naujojo įgyvendinimo. Praktiškai rekomenduojama iš naujo įvertinti testavimo poreikį po esminių architektūros pakeitimų, rimtų incidentų ar naujo poveikio, šalia nustatyto periodiškumo.

Išlaikykite įrodymus naudingus auditoriams ir pirkėjams

Saugokite suderintą apimtį, užsakymo taisykles, galutinę ataskaitą, trūkumų šalinimo įrašus, pakartotinio testo įrodymus ir rizikos sprendimus. Visos ataskaitos prieigą ribokite, nes joje gali būti jautrios informacijos apie išnaudojimą.

Parenkite klientams skirtą santrauką, kurioje aprašytos testavimo datos, apimtis, metodika, apribojimai ir trūkumų šalinimo būsena, be reikalo neatskleidžiant atakos instrukcijų. Dėl tolesnių klausimų skaitykite mūsų patikinimo vertinimo vadovą.

Secani susiekite testo įrodymus su atitinkamomis sistemomis, reikalavimais, kontrolės priemonėmis, atsakingais asmenimis ir peržiūros sprendimais. Įrodymų spragas sekite kaip užduotis ir išsaugokite žmogaus atliekamą išvadų patvirtinimą. Taip ryšys tarp to, kas buvo testuota, ir to, kas pasikeitė, lieka prieinamas vėlesnei peržiūrai.

Prieš prašydami pasiūlymų, parenkite vieno puslapio apimties aprašą, apimantį pasitikėjimo ribas, testines paskyras, išimtis, rezultatus ir pakartotinio testavimo lūkesčius. Šis dokumentas suteikia paslaugų teikėjui, auditoriui ir inžinerijos komandai bendrą pagrindą testui, kuris iš tikrųjų informuoja apie saugumą.