SOC 2 ielaušanās testēšana: izvēlieties testu, kas sniedz informāciju par drošību

Ielaušanās tests sniedz pierādījumus par izmantojamām nepilnībām definētā sistēmā. Tā vērtība ir atkarīga no tā, ko testētāji pārbauda, kā viņi to izpēta un ko inženieri dara ar konstatējumiem. Ziņojums, kurā izlaistas produkta svarīgās uzticamības robežas, var apmierināt iekšēju termiņu, vienlaikus maz pastāstot par drošību.

Tehnoloģiju direktoram noderīgais jautājums nav vienkārši, vai tests ir pabeigts. Jautājums ir, vai uzdevums pārbauda kontroles, kas aizsargā klientu datus, un rada konstatējumus, kurus komanda var atkārtot, novērst un verificēt.

Ko SOC 2 prasa un ko neprasa

SOC 2 ir apliecinājuma ziņojums, nevis sertifikācija. Tā kritēriji balstās uz principiem; tie neuzliek katrai organizācijai vienu universālu ielaušanās testa prasību vai ikgadēju ritmu. To, kāda testēšana ir piemērota, nosaka risks, jūsu aprakstītās kontroles, auditora gaidas un klientu līgumi.

Pirms uzdevuma pasūtīšanas apspriediet mērķi un sagaidāmos pierādījumus ar savu auditoru. Ja jūsu dokumentētā kontrole sola noteiktu testēšanas biežumu vai tvērumu, plānojiet šo saistību apliecināt.

Klientu pārliecība ir atsevišķs apsvērums. Pircējs var pieprasīt neatkarīgu lietotnes testu pat tad, ja jūsu audita pieeja to neparedz. Noskaidrojiet šīs gaidas agri, taču neļaujiet iepirkuma kontrolsarakstam aizstāt tehnisko tvēruma noteikšanu. Ne SOC 2 ziņojums, ne ielaušanās tests nepierāda, ka sistēmai nav ievainojamību.

Nosakiet uzbrukuma virsmas tvērumu, ne tikai tīmekļa vietni

Sāciet ar arhitektūru, sensitīvo datu plūsmām un uzticamības robežām. OWASP draudu modelēšanas norādījumi sniedz noderīgu pamatu, lai identificētu, kas varētu noiet greizi un kur testēšanai jākoncentrējas.

Vairāku nomnieku SaaS produktam tikai publiskās sākumlapas testēšana atstāj svarīgās lietotnes robežas nepārbaudītas. Iedodiet pakalpojumu sniedzējam uzskaiti, kas ietver API, fona apstrādi, administratīvos rīkus un attiecīgo infrastruktūru, nevis tikai domēnu sarakstu.

Skaidri norādiet izņēmumus un ierobežojumus. Netestētam mobilajam klientam, nepieejamai lomai vai nepieejamai videi jāpaliek redzamiem galīgajā ziņojumā. Tvērumā jānošķir arī jums piederošās sistēmas no trešo pušu pakalpojumiem, kuriem jūs nevarat atļaut testētājiem uzbrukt.

Izvēlieties metodi, kas atbild uz jūsu jautājumiem

Automatizēta skenēšana identificē iespējamās nepilnības un atbalsta regulāru higiēnu. Ielaušanās tests papildina ar prasmīgu izmantojamības un jēgpilnu uzbrukuma ceļu izpēti atļautā tvērumā. Rīki ir noderīgi; skenera eksports, kas pārdēvēts par ielaušanās testu, nav līdzvērtīgs šādai izpētei.

Melnās kastes testēšana sākas ar ierobežotām zināšanām par sistēmu. Pelēkās kastes testēšana nodrošina atlasītu informāciju vai piekļuvi, bieži vien ietverot kontus. Baltās kastes testēšana sniedz dziļāku redzamību, iespējams, ietverot pirmkodu un arhitektūru. Šīs pieejas atbild uz dažādiem jautājumiem, nevis veido vienkāršu kvalitātes reitingu.

Lietotnes autorizācijas testēšanai konti vairākās lomās un nomniekos var padarīt izpēti efektīvāku. Tikai ārējās infrastruktūras testēšana nevar noteikt, vai autentificēti lietotāji var šķērsot nomnieku robežas.

Novērtējiet pakalpojumu sniedzēju un nodevumus

Pajautājiet, kas veiks darbu un vai viņi ir testējuši līdzīgas arhitektūras. Attiecīgas kvalifikācijas atbalsta pienācīgu pārbaudi, taču sertifikāti vieni paši nepierāda lietotnei specifisku kompetenci. Pieprasiet anonimizēta ziņojuma paraugu un apspriediet, kā komanda pēta biznesa loģiku, nevis tikai zināmas programmatūras ievainojamības.

Pirms parakstīšanas precizējiet:

• Kuras sistēmas, lomas un uzbrukuma ceļi ir aptverti un kā tiek sadalīta piepūle.
• Kāda manuāla izpēte papildina automatizētos rīkus.
• Kā par steidzamiem konstatējumiem tiek ziņots pirms galīgā ziņojuma.
• Vai konstatējumi ietver atkārtojamus pierādījumus, ietekmētos komponentus, ietekmi un novēršanas norādījumus.
• Vai atkārtota testēšana ir iekļauta, kāds ir tās laika logs un kas notiek, ja labojumi tiek veikti vēlāk.
• Kā ziņojumi, akreditācijas dati un iegūtie dati tiek aizsargāti un galu galā dzēsti.

Salīdziniet piedāvājumus pēc pārklājuma un nodevumiem, ne tikai pēc cenas. Zemāka cena var nozīmēt šaurāku uzdevumu, nevis līdzvērtīgu darbu, kas paveikts efektīvāk.

Nosakiet drošas izpildes noteikumus

Pirms testēšanas sākuma dokumentējiet atļauju un uzdevuma noteikumus (rules of engagement). Identificējiet apstiprinātos resursdatorus, kontus, vides, testēšanas logus, ārkārtas kontaktus un apturēšanas nosacījumus. Vienojieties, vai pakalpojuma atteices testēšana, sociālā inženierija, noturības iegūšana vai datu izvilkšana ir izslēgta.

Testēšana ražošanā var atklāt reālas konfigurācijas problēmas, taču tā rada arī darbības risku. Reprezentatīva sagatavošanas (staging) vide var būt drošāka, ja tiek reģistrētas atšķirības no ražošanas. Kur iespējams, izmantojiet sintētiskus nomnieku datus un vienojieties, kādi pierādījumi ir pietiekami ietekmes pierādīšanai, nevācot nevajadzīgu klientu informāciju.

Pārliecinieties, ka uzraudzības komandas zina, kā atšķirt atļautu darbību no nesaistīta incidenta. Testēšana nedrīkst kļūt par attaisnojumu aizsardzības kontroļu atspējošanai, nedokumentējot sekas.

Praktisks piemērs: nomnieku izolācijas konstatējums

Apsveriet ilustratīvu SaaS uzdevumu. Pieņemsim, ka produktam ir divi testa nomnieki, parastie lietotāji, nomnieku administratori un atbalsta loma. Tests ietver autentificētas API un eksporta darbplūsmas; trešās puses identitātes infrastruktūra ir izslēgta.

Testētājs atklāj, ka eksporta galapunkts validē pieteikšanos, bet konsekventi nenodrošina nomnieka īpašumtiesības. Izmantojot sintētiskus ierakstus, viņš parāda, ka lietotājs no nomnieka A var pieprasīt eksportu, kas pieder nomniekam B.

Konstatējumā jānorāda galapunkts, nepieciešamās privilēģijas, ietekmētā darbplūsma, atkārtojami pierādījumi un ietekme uz biznesu. Inženieri izseko problēmu līdz fona apstrādātājam, kas uzticas pieprasījumā norādītajam nomnieka identifikatoram.

Labojums nodrošina īpašumtiesību pārbaudi pirms eksporta ieplānošanas un vēlreiz to izgūstot. Regresijas testi aptver pieprasījumus starp nomniekiem un attiecīgās lomas. Atkārtota testēšana apstiprina, ka sākotnējais ceļš ir bloķēts, un pārbauda saistītos eksporta ceļus. Komanda saglabā sākotnējo konstatējumu, ieviešanas pierādījumus un atkārtotās testēšanas rezultātu; tā vienkārši neatzīmē pieteikumu kā „pabeigts”.

Pārvērtiet konstatējumus atbildīgā inženiertehniskā darbā

Šķirojiet konstatējumus, izmantojot tehnisko smagumu un biznesa atklātību. Apsveriet nepieciešamās privilēģijas, atklātību internetā, ietekmētos datus, izmantošanas uzticamību un kompensējošās kontroles. Nomināli mērenai problēmai var būt nepieciešama steidzama apstrāde, ja tā pārkāpj kritisku klientu robežu.

Katram konstatējumam piešķiriet īpašnieku, mērķa datumu un verificēšanas metodi. Kur piemērots, izvietojiet pagaidu mazināšanas pasākumu, gatavojot ilgtspējīgu labojumu. Lieciet norīkotam riska īpašniekam apstiprināt jebkuru pieņemto atlikušo risku ar pamatojumu un pārskatīšanas datumu; inženieru klusēšana nav pieņemšana.

Reģistrējiet testēto produkta versiju un vidi. Rezultāts no laika pirms būtiskas autorizācijas pārprojektēšanas nevar aprakstīt jauno ieviešanu. Kā praktisks ieteikums: papildus iedibinātajam ritmam pārvērtējiet testēšanas vajadzības pēc būtiskām arhitektūras izmaiņām, nopietniem incidentiem vai jaunas atklātības.

Uzturiet pierādījumus noderīgus auditoriem un pircējiem

Saglabājiet saskaņoto tvērumu, uzdevuma noteikumus, galīgo ziņojumu, novēršanas ierakstus, atkārtotās testēšanas pierādījumus un riska lēmumus. Pilno ziņojumu glabājiet ar ierobežotu piekļuvi, jo tajā var būt sensitīvas izmantošanas detaļas.

Sagatavojiet klientiem paredzētu kopsavilkumu, kurā aprakstīti testa datumi, tvērums, metodoloģija, ierobežojumi un novēršanas statuss, nevajadzīgi neatklājot uzbrukuma instrukcijas. Papildjautājumiem izlasiet mūsu pārliecības pārskatīšanas ceļvedi.

Secani sasaistiet testa pierādījumus ar attiecīgajām sistēmām, prasībām, kontrolēm, īpašniekiem un pārskatīšanas lēmumiem. Sekojiet pierādījumu robiem kā uzdevumiem un saglabājiet cilvēka apstiprinājumu secinājumiem. Tas uztur saikni starp to, kas tika testēts, un to, kas mainījās, pieejamu vēlākai pārskatīšanai.

Pirms piedāvājumu pieprasīšanas sagatavojiet vienas lappuses tvēruma aprakstu, kas aptver uzticamības robežas, testa kontus, izņēmumus, nodevumus un atkārtotās testēšanas gaidas. Šis dokuments sniedz pakalpojumu sniedzējam, auditoram un inženieru komandai kopīgu pamatu testam, kas sniedz informāciju par drošību.