Velg mellom sikkerhetsgjennomgang, herding og kontrollert test

Hva det er

En Security Baseline Review egner seg for å forstå en avtalt nåværende tilstand; Website Hardening gjør bekreftede konfigurasjonsprioriteringer om til kontrollerte endringer; Application Security Review tar for seg utvalgte sikkerhetsspørsmål i en applikasjon. Application Load & Stress Testing observerer avtalte bruksscenarioer, mens DDoS Resilience Testing undersøker kontrollerte robusthetsforhold med grenser for leverandører og sikkerhet. En Red Team Exercise er en målstyrt, autorisert læringsøvelse som styres av testregler. Dette er ikke utskiftbare merkelapper. En funnrapport, en konfigurasjonsendring, en ytelsesobservasjon, en robusthetsobservasjon og en organisatorisk læringsøvelse besvarer ulike spørsmål for kjøperen. Mer inngripende testing er ikke automatisk mer nyttig.

Hvem det er for

Sammenligningen hjelper kjøpere som:

• Har en bekymring om sikkerhet eller pålitelighet, men ennå ikke vet om de trenger dokumentasjon, implementering, validering eller en bredere læringsøvelse
• Må forstå om produksjonssystemer, tredjepartsleverandører, skriftlig fullmakt eller sikkerhetsgrenser påvirker de tilgjengelige valgene
• Vil sammenligne resultater og grenser før de ber en leverandør om å avgrense et oppdrag
• Erkjenner at en gjennomgang, en herdingsendring og en kontrollert test kan komme etter hverandre i stedet for å utelukke hverandre

Hva det hjelper med å klarlegge

Bruk sammenligningen til å avklare:

• Om problemet er kjent eller usikkert, og om neste steg bør gi dokumentasjon eller gjennomføre en avtalt endring
• Om den relevante ressursen er et nettsted, en applikasjon, en konfigurasjon, en kundereise, en tjeneste under forventet last eller en robusthetsvei
• Om et oppdrag krever skriftlig fullmakt, samtykke fra leverandører, sperreperioder, kontaktpersoner eller umiddelbare stoppvilkår
• Hvilket resultat som er nyttig nå: en funnrapport, en endringslogg, en ytelsesobservasjon, en robusthetsobservasjon eller en beslutningsklar oppsummering

Hva er inkludert

• En sammenligning i klarspråk av grunnlinjegjennomgang, herding av nettsted, applikasjonsgjennomgang, kontrollert lasttesting, testing av DDoS-robusthet og red team-øvelser
• Beslutningsfaktorer som dekker usikkerhet, dokumentasjon kontra implementering, påvirkning på produksjon, fullmakt, tredjeparter og forventede resultater
• Veiledning om bruk av tjenester i rekkefølge der en dokumentert gjennomgang naturlig danner grunnlag for senere kontrollert arbeid
• En påminnelse om at avklaring av omfang eller kartlegging kan være det mest fornuftige første steget når spørsmålet ennå ikke er stabilt

Hva er ikke inkludert

• En universell tjenesteanbefaling, en sertifisering eller et løfte om at et alternativ vil fjerne all risiko
• Råd om å gjennomføre kontrollert testing uten bekreftet fullmakt, trygge grenser, leverandørkrav og omfang
• Operative testtaktikker, instruksjoner for utnyttelse, metoder for forstyrrelse eller veiledning i omgåelse
• En påstand om at en gjennomgang, et herdingsoppdrag eller en øvelse sikrer etterlevelse, tilgjengelighet, ytelse, robusthet eller forhindring

Når skal den velges

Les denne veiledningen når et team sammenligner alternativer før det har valgt et oppdrag. Den er særlig nyttig når én interessent ber om «testing» mens en annen ber om en konfigurasjonsendring eller en skriftlig vurdering. Hvis systemene, den ønskede beslutningen, eierskapet eller tilgjengelig dokumentasjon er uklare, bør avklaring av omfang komme før valget. En kort samtale kan avdekke om en kjøper egentlig ber om en gjennomgang av dagens tilstand, en kontrollert implementering, et målrettet applikasjonsspørsmål, en kapasitetsobservasjon, en robusthetsvurdering eller en målstyrt øvelse.

Vår tilnærming

Start med forretningsbeslutningen, og snevre deretter inn det tekniske spørsmålet. List opp de berørte systemene, hva som allerede er kjent, hvem som eier dem, om produksjon kan bli påvirket, og hvordan et nyttig resultat ville se ut. Pek deretter ut tillatelser og tredjeparter før dere drøfter en kontrollert test. En grunnlinjegjennomgang kan skape dokumentasjonen for herding; herding kan komme før en senere test; en lastobservasjon kan avdekke et infrastrukturspørsmål; en red team-øvelse kan først være nyttig når mål og styring er modne. Poenget er ikke å lage en fast stige. Det er å velge et forholdsmessig, autorisert neste steg og la senere arbeid få eget omfang. En kjøper kan også registrere de praktiske begrensningene som former valget: tilgjengelig dokumentasjon, systemenes alder, leverandørvilkår, forpliktelser overfor kunder, sannsynlig vedlikeholdsvindu og om en endring trygt kan testes utenfor produksjon. Disse begrensningene velger ikke en tjeneste i seg selv, men de gjør et senere omfang mer sannferdig. Sammenligningen fungerer godt når teamet er villig til å la et spørsmål stå åpent i stedet for å tvinge det inn under feil oppdragsmerkelapp. Før dere tar kontakt, forbered et kort notat om beslutningsdato, berørte ressurser, forretningseier, teknisk eier, vesentlige leverandører, pågående endringsaktivitet og eventuelle kjente tilgangsbegrensninger. Disse detaljene er ikke bevis på et problem; de er konteksten som lar en leverandør si hvor et standardomfang passer, og hvor en antakelse må kontrolleres. De gjør det også lettere å unngå å be om en bred test bare fordi problemet ennå ikke er formulert. Hvis det finnes en frist, forklar om den er kommersiell, kontraktsmessig, operativ eller regulatorisk, og hva som ville gjøre beslutningen nyttig. Det gir alle anledning til å skille et ønsket utfall fra dokumentasjon som faktisk kan samles inn innenfor et ansvarlig omfang.

Ofte stilte spørsmål

Beslektede artikler