Penetrationstest til SOC 2: vælg en test, der informerer sikkerheden

En penetrationstest giver evidens om udnyttelige svagheder i et defineret system. Dens værdi afhænger af, hvad testerne undersøger, hvordan de undersøger det, og hvad udviklingen gør med fundene. En rapport, der udelader produktets vigtige tillidsgrænser, kan opfylde en intern frist og samtidig fortælle jer meget lidt om sikkerheden.

For en CTO er det nyttige spørgsmål ikke blot, om en test er gennemført. Det er, om opgaven udfordrer de kontroller, der beskytter kundedata, og giver fund, som teamet kan genskabe, rette og verificere.

Hvad SOC 2 kræver, og hvad den ikke kræver

SOC 2 er en erklæringsrapport, ikke en certificering. Kriterierne er principbaserede; de pålægger ikke alle organisationer ét universelt krav om penetrationstest eller en årlig kadence. Risiko, de kontroller, I beskriver, revisorens forventninger og kundekontrakter afgør, hvilken test der er passende.

Drøft formålet og den forventede evidens med jeres revisor, før I bestiller opgaven. Hvis jeres dokumenterede kontrol lover en bestemt testhyppighed eller et bestemt scope, skal I planlægge at påvise den forpligtelse.

Kundernes tillid er en separat overvejelse. En køber kan kræve en uafhængig applikationstest, selv når jeres revisionstilgang ikke foreskriver en. Afklar disse forventninger tidligt, men lad ikke en indkøbstjekliste erstatte den tekniske afgrænsning. Hverken en SOC 2-rapport eller en penetrationstest fastslår, at et system ikke har sårbarheder.

Afgræns angrebsfladen, ikke kun hjemmesiden

Start med arkitekturen, følsomme dataflow og tillidsgrænser. OWASP's vejledning om trusselsmodellering giver et nyttigt grundlag for at identificere, hvad der kan gå galt, og hvor testen bør koncentreres.

For et multi-tenant SaaS-produkt efterlader en test af kun den offentlige landingsside de vigtige applikationsgrænser uundersøgte. Giv leverandøren en fortegnelse, der omfatter API'er, baggrundsbehandling, administrative værktøjer og relevant infrastruktur, ikke kun en liste over domæner.

Angiv undtagelser og begrænsninger eksplicit. En utestet mobilklient, en utilgængelig rolle eller et utilgængeligt miljø skal forblive synligt i den endelige rapport. Scope bør også skelne mellem systemer, I ejer, og tredjepartstjenester, som I ikke kan give testerne tilladelse til at angribe.

Vælg en metode, der besvarer jeres spørgsmål

Automatiseret scanning identificerer potentielle svagheder og understøtter løbende hygiejne. En penetrationstest tilføjer kvalificeret undersøgelse af udnyttelighed og meningsfulde angrebsveje inden for et autoriseret scope. Værktøjer er nyttige; et scannerudtræk, der er omdøbt til en penetrationstest, svarer ikke til en sådan undersøgelse.

Black box-test starter med begrænset viden om systemet. Gray box-test giver udvalgte oplysninger eller adgang, ofte inklusive konti. White box-test giver dybere indsigt, eventuelt inklusive kildekode og arkitektur. Disse tilgange besvarer forskellige spørgsmål snarere end at udgøre en simpel kvalitetsrangering.

Ved test af autorisation i applikationer kan konti på tværs af flere roller og tenants gøre undersøgelsen mere effektiv. Test af ekstern infrastruktur alene kan ikke fastslå, om autentificerede brugere kan krydse tenantgrænser.

Vurdér leverandøren og leverancerne

Spørg, hvem der vil udføre arbejdet, og om de har testet sammenlignelige arkitekturer. Relevante kvalifikationer understøtter due diligence, men certificeringer alene fastslår ikke applikationsspecifik kompetence. Anmod om en anonymiseret eksempelrapport, og drøft, hvordan teamet undersøger forretningslogik og ikke kun kendte softwaresårbarheder.

Afklar inden underskrift:

• Hvilke systemer, roller og angrebsveje der er dækket, og hvordan indsatsen fordeles.
• Hvilken manuel undersøgelse der supplerer de automatiserede værktøjer.
• Hvordan presserende fund kommunikeres før den endelige rapport.
• Om fundene omfatter reproducerbar evidens, berørte komponenter, påvirkning og vejledning i afhjælpning.
• Om gentest er inkluderet, dens tidsvindue, og hvad der sker, hvis rettelserne kommer senere.
• Hvordan rapporter, legitimationsoplysninger og indsamlede data beskyttes og til sidst slettes.

Sammenlign tilbuddene på dækning og leverancer, ikke kun på pris. Et lavere tilbud kan dække over en snævrere opgave snarere end tilsvarende arbejde leveret mere effektivt.

Fastlæg regler for sikker udførelse

Dokumentér tilladelsen og rules of engagement, før testen begynder. Identificér godkendte hosts, konti, miljøer, testvinduer, nødkontakter og stopbetingelser. Aftal, om test af denial-of-service, social engineering, persistens eller dataudtræk er udelukket.

Test i produktion kan afsløre reelle konfigurationsproblemer, men skaber også driftsmæssig risiko. Et repræsentativt stagingmiljø kan være sikrere, forudsat at forskellene fra produktion registreres. Brug syntetiske tenantdata, hvor det er muligt, og aftal, hvilken evidens der er tilstrækkelig til at påvise påvirkningen uden at indsamle unødvendige kundeoplysninger.

Sørg for, at overvågningsteams ved, hvordan de skelner autoriseret aktivitet fra en urelateret hændelse. Test bør ikke blive en undskyldning for at deaktivere beskyttende kontroller uden at dokumentere konsekvenserne.

Gennemgået eksempel: et fund vedrørende tenantisolation

Tag en illustrativ SaaS-opgave. Antag, at produktet har to testtenants, almindelige brugere, tenantadministratorer og en supportrolle. Testen omfatter autentificerede API'er og eksportarbejdsgange; tredjeparts identitetsinfrastruktur er udelukket.

En tester opdager, at et eksportendpoint validerer login, men ikke konsekvent håndhæver tenantejerskab. Med syntetiske poster demonstrerer testeren, at en bruger fra tenant A kan anmode om en eksport, der tilhører tenant B.

Fundet bør identificere endpointet, de påkrævede privilegier, den berørte arbejdsgang, reproducerbar evidens og den forretningsmæssige påvirkning. Udviklingen sporer problemet til en baggrundsworker, der stoler på en tenantidentifikator, som anmodningen leverer.

Rettelsen håndhæver ejerskab, før eksporten planlægges, og igen, når den hentes. Regressionstest dækker anmodninger på tværs af tenants og relevante roller. Gentesten bekræfter, at den oprindelige vej er blokeret, og kontrollerer relaterede eksportveje. Teamet bevarer det oprindelige fund, implementeringsevidensen og gentestresultatet; det markerer ikke blot ticketen som “færdig”.

Gør fund til ansvarligt teknisk arbejde

Triagér fund ud fra teknisk alvorlighed og forretningsmæssig eksponering. Overvej påkrævede privilegier, eksponering mod internettet, berørte data, udnyttelsens pålidelighed og kompenserende kontroller. Et nominelt moderat problem kan fortjene presserende behandling, når det bryder en kritisk kundegrænse.

Tildel hvert fund en ejer, en måldato og en verifikationsmetode. Udrul, hvor det er relevant, en midlertidig afbødning, mens den varige rettelse forberedes. Lad en udpeget risikoejer godkende enhver accepteret restrisiko med begrundelse og en gennemgangsdato; tavshed fra udviklingen er ikke accept.

Registrér den testede produktversion og det testede miljø. Et resultat fra før en større omlægning af autorisationen kan ikke beskrive den nye implementering. Som praktisk anbefaling bør testbehovet genvurderes efter væsentlige arkitekturændringer, alvorlige hændelser eller ny eksponering, sideløbende med jeres etablerede kadence.

Hold evidensen nyttig for revisorer og købere

Bevar det aftalte scope, rules of engagement, den endelige rapport, afhjælpningsregistreringer, gentestevidens og risikobeslutninger. Hold den fulde rapport adgangsbegrænset, fordi den kan indeholde følsomme detaljer om udnyttelse.

Udarbejd et kunderettet resumé, der beskriver testdatoer, scope, metode, begrænsninger og afhjælpningsstatus uden unødigt at eksponere angrebsinstruktioner. Læs vores guide til gennemgang af sikkerhedsdokumentation for opfølgende spørgsmål.

I Secani kan I forbinde testevidensen med de relevante systemer, krav, kontroller, ejere og gennemgangsbeslutninger. Følg huller i evidensen som opgaver, og bevar den menneskelige godkendelse af konklusioner. Det holder sammenhængen mellem det, der blev testet, og det, der blev ændret, tilgængelig til senere gennemgang.

Før I anmoder om tilbud, så udarbejd et scope på én side, der dækker tillidsgrænser, testkonti, undtagelser, leverancer og forventninger til gentest. Det dokument giver leverandøren, revisoren og udviklingsteamet et fælles grundlag for en test, der informerer sikkerheden.