Overlevering av tilgang for tryggleikstesting: omfang, kontoar og tilbakekalling

Ein testar ber om ei gateway-adresse, interne DNS-detaljar og VPN-legitimasjon, og førespurnaden vert vidaresend til deg med emnet «tilgang trengst». Førespurnaden aleine fortel deg ikkje om dette er ei intern vurdering, ein test av ein autentisert applikasjon eller eit oppdrag på ein offentleg nettstad der nokon har misforstått omfanget. Køyr overleveringa som ein sekvens med ei port ved kvart steg, og stopp ved den første porten som ikkje opnar seg. Det gjer ein vag førespurnad om til noko du kan autorisere, levere og seinare kalle tilbake.

Byrj med autorisasjonen, ikkje med legitimasjonen

Før noka adresse forlet innboksen din, må du fastslå kven som eig måla og kven som har lov til å godkjenne testing på dei. Verifiser testaren gjennom oppdragskontakten organisasjonen din alt nyttar, ikkje gjennom personen som vidaresende e-posten. Eit kundeforhold er ikkje løyve til å teste kvart system som er tilgjengeleg frå ein konto, og ein innkjøpsordre er ikkje eit omfangsdokument.

Skriv det godkjende målet i éi setning og ha det ved sida av overleveringa. «Vurder autentiseringa til kundeportalen» og «vurder det interne nettet» fører til heilt ulike pakkar, og skilnaden må avklarast før klargjeringa, ikkje etter at eit funn har kome inn. Setninga gjev deg òg noko å peike på når førespurnaden veks midt i oppdraget.

Viss ein hostingleverandør eller ein annan tredjepart er i vegen, kjem krava deira før di eiga bekvemmelegheit. Å teste andre sin infrastruktur utan løyve deira er eit anna problem enn å teste applikasjonen som køyrer på han.

Nemn synspunktet og måla

Synspunktet er spørsmålet vurderinga prøver å svare på, og det avgjer tilgangspakken meir enn noko verktøy testaren planar å bruke. Ein offentleg ikkje-autentisert test treng ein URL og eit tidsvindauge. Ein autentisert test treng dedikerte kontoar for dei spesifikke rollene i omfanget, og ei intern vurdering treng eit definert inngangspunkt med eksplisitte målområde.

Kvar ein tunnel kjem inn er ikkje det same faktumet som kva applikasjon som ligg bak han, og det autoriserer absolutt ikkje å undersøkje inngangspunktet. Sei det eksplisitt i overleveringa, for setninga «du gav meg tilgang til det subnettet» kjem raskt så snart eit funn vert omstridd. Ei skriftleg målliste er det einaste som avgjer det i etterkant.

Oppgje TLS-vertsnamnet saman med URL-en. Ei bar IP-adresse tvingar testaren til å gjette namnet, og eit gjett namn gjev sertifikatfeil som vert rapporterte som funn i staden for som ein feil i overleveringa.

Utsted dedikerte identitetar med ein utløpsdato

Klargjer kontoar som berre finst for dette oppdraget; lån ikkje den daglege innlogginga til ein tisett. Set nettverkstilgjenge og applikasjonstillatingar til dei avtalte oppgåvene, ordna autentiseringsregistrering gjennom ein støtta veg, og fest ein utløpsdato med ein namngjeven person som er ansvarleg for tilbakekallinga. Lever legitomasjonen gjennom ein avtalt trygg kanal, åtskild frå omfangsdokumentet som vert vidaresendt rundt.

sudo useradd -m -e 2026-12-31 tester01
sudo passwd -S tester01
id tester01
lastlog -u tester01

Registrer kven som tok imot kva, og når. Den registreringa er skilnaden mellom ei kontrollert overlevering og eit delt passord ingen kan spore, og det er det første alle spør om etter ein hending. Oppbevar henne saman med omfangsdokumentet i staden for i ein chat-tråd, og noter leveringskanalen ved sida av mottakaren. Ei linje med tidsstempel slår ei minning kvar gong.

Utløpsfeltet er eit sikkerheitsnett, ikkje planen. Nokon må framleis fjerna nettverksvegen og applikasjonsrolla til slutt, fordi ei utløpt innlogging på eit nettverk som framleis er tilgjengeleg ikkje er tilbakekalla tilgang.

Prov at overleveringa verkar før vindauga opnar seg

Køyr den første hoppet til testaren sjølv, frå ein posisjon så nær hans som mogleg. Slå opp namnet, kontroller identiteten til sertifikatet, og stadfest at vegen når den tiltenkte adressa og ikkje ei nabo-adresse.

dig +short app.example.com
openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates
ip route get 10.60.0.25

Viss vegen ikkje kan nå eit mål, stopp og avstem overleveringa i staden for å la testaren oppdage ein alternativ rute. Improvisert tilgjenge er korleis ei vurdering stille veks utover omfanget sitt, og det vert nesten aldri dokumentert etterpå.

Send den operative kontakten, tillatne timar, utelukka handlingar og stoppvilkår saman med legitimasjonen. Ein testar som ikkje når nokon klokka 02:00 vil ta ei avgjerd du ikkje har autorisert, og den avgjerda vil verte skildra i rapporten som om ho var innanfor omfanget.

NIST SP 800-115 rammar inn ei teknisk vurdering som planlagd testing etterfylgd av analyse og avbøting, og det er forma denne overleveringa følgjer. Portane ovanfor er redaksjonelle designval for ein støtteingeniør, ikkje ei sjekkliste sitert frå den publikasjonen.

Avslutt oppdraget ved å fjerna tilgangen

Kall tilbake i omvend rekkjefølgje av klargjeringa: applikasjonsroller, deretter nettverkstilgang, deretter sjølve identiteten. Stadfest kvart steg i staden for å gå ut frå at konsollen gjorde det knappen lova. Lås kontoen før du drep øktene hans, elles autentiserer økta seg berre på nytt via den gamle vegen. Kontroller deretter dei etablerte sambanda ein gong til før du kallar det stengt.

sudo passwd -l tester01
sudo pkill -u tester01
ss -tn state established '( sport = :443 )'

Gjer opp eventuelle tilbakehaldne testdata, og følg deretter utbetringa gjennom rapporteringsprosessen de vart samde om i starten. Rapporten bør oppgje miljøet, tilgangsnivået, omfanget og avgrensingane, fordi han registrerer funn frå éi vurdering og er ikkje ei permanent fråsegn om at nettstaden er trygg.

Oppbevar tilbakekallingsregistreringa saman med overleveringsregistreringa. Når det neste oppdraget opnar seg, vil du vite nøyaktig kva som vart fjerna sist og kven som godkjende det, i staden for å byggje opp att biletet frå minnet.