Sikkerhedsgennemgang, hærdning eller kontrolleret test: valget

Hvad det er

En Security Baseline Review egner sig til at forstå en aftalt nuværende tilstand; Website Hardening omsætter bekræftede konfigurationsprioriteringer til kontrollerede ændringer; Application Security Review ser på udvalgte spørgsmål om applikationssikkerhed. Application Load & Stress Testing observerer aftalte brugsscenarier, mens DDoS Resilience Testing undersøger kontrollerede forhold for modstandsdygtighed med grænser for udbydere og sikkerhed. En Red Team Exercise er en målrettet, autoriseret læringsøvelse, der styres af testregler (rules of engagement). Det er ikke udskiftelige betegnelser. En rapport med fund, en konfigurationsændring, en observation af ydeevne, en observation af modstandsdygtighed og en organisatorisk læringsøvelse besvarer forskellige spørgsmål for køberen. Mere indgribende test er ikke automatisk mere nyttig.

Hvem er det for?

Sammenligningen hjælper købere, der:

• Har en bekymring om sikkerhed eller pålidelighed, men endnu ikke er sikre på, om de har brug for dokumentation, implementering, validering eller en bredere læringsøvelse
• Skal forstå, om produktionssystemer, tredjepartsudbydere, skriftlig bemyndigelse eller sikkerhedsgrænser påvirker de tilgængelige valg
• Vil sammenligne resultater og grænser, før de beder en leverandør om at afgrænse arbejdet
• Erkender, at en gennemgang, en hærdningsændring og en kontrolleret test kan følge efter hinanden i stedet for at udelukke hinanden

Hvad det hjælper med at afklare

Brug sammenligningen til at afklare:

• Om problemet er kendt eller usikkert, og om det næste skridt skal give dokumentation eller gennemføre en aftalt ændring
• Om det relevante aktiv er et website, en applikation, en konfiguration, et kundeforløb, en tjeneste under forventet belastning eller en vej for modstandsdygtighed
• Om en opgave kræver skriftlig bemyndigelse, samtykke fra udbydere, spærreperioder, kontakter eller øjeblikkelige stopbetingelser
• Hvilket resultat der er nyttigt nu: en rapport med fund, en ændringslog, en observation af ydeevne, en observation af modstandsdygtighed eller en beslutningsklar debriefing

Hvad er inkluderet

• En letforståelig sammenligning af baseline-gennemgang, hærdning af website, applikationsgennemgang, kontrolleret belastningstest, test af DDoS-modstandsdygtighed og red team-øvelser
• Beslutningsfaktorer om usikkerhed, dokumentation over for implementering, påvirkning af produktion, bemyndigelse, tredjeparter og forventede resultater
• Vejledning om at bruge tjenester efter hinanden, hvor en dokumenteret gennemgang naturligt danner grundlag for senere kontrolleret arbejde
• En påmindelse om, at afklaring af omfang eller discovery kan være det mest fornuftige første skridt, når spørgsmålet endnu ikke er stabilt

Hvad er ikke inkluderet?

• En universel anbefaling af en tjeneste, en certificering eller et løfte om, at en given mulighed fjerner al risiko
• Råd om at udføre kontrolleret test uden bekræftet bemyndigelse, sikre grænser, krav fra udbydere og omfang
• Operationelle testtaktikker, instruktioner i udnyttelse, metoder til forstyrrelse eller vejledning i omgåelse
• En påstand om, at en gennemgang, en hærdningsopgave eller en øvelse sikrer compliance, tilgængelighed, ydeevne, modstandsdygtighed eller forebyggelse

Hvornår du skal vælge det

Læs denne guide, når et team sammenligner muligheder, før det har valgt en opgave. Den er særlig nyttig, når én interessent beder om „test“, mens en anden beder om en konfigurationsændring eller en skriftlig vurdering. Hvis systemerne, den ønskede beslutning, ejerskabet eller den tilgængelige dokumentation er uklare, bør afklaring af omfanget komme før valget. En kort samtale kan afdække, om en køber reelt beder om en gennemgang af den nuværende tilstand, en kontrolleret implementering, et målrettet applikationsspørgsmål, en observation af kapacitet, en vurdering af modstandsdygtighed eller en målrettet øvelse.

Vores tilgang

Start med forretningsbeslutningen, og indsnævr derefter det tekniske spørgsmål. Opstil de berørte systemer, hvad der allerede vides, hvem der ejer dem, om produktion kan blive påvirket, og hvordan et nyttigt resultat ville se ud. Udpeg dernæst tilladelser og tredjeparter, før nogen kontrolleret test drøftes. En baseline-gennemgang kan skabe dokumentationen til hærdning; hærdning kan gå forud for en senere test; en observation af belastning kan afsløre et infrastrukturspørgsmål; en red team-øvelse kan først være nyttig, når mål og styring er modne. Pointen er ikke at skabe en fast stige. Den er at vælge et forholdsmæssigt, autoriseret næste skridt og lade senere arbejde blive afgrænset separat. En køber kan også notere de praktiske begrænsninger, der former valget: den tilgængelige dokumentation, systemernes alder, leverandørvilkår, forpligtelser over for kunder, sandsynligt vedligeholdelsesvindue, og om en ændring sikkert kan testes uden for produktion. Disse begrænsninger vælger ikke en tjeneste i sig selv, men de gør et senere omfang mere retvisende. Sammenligningen fungerer bedst, når teamet er villigt til at lade et spørgsmål stå åbent i stedet for at presse det ind under den forkerte betegnelse for en opgave. Før I tager kontakt, så forbered en kort note med beslutningsdato, berørte aktiver, forretningsejer, teknisk ejer, væsentlige leverandører, igangværende ændringsaktivitet og eventuelle kendte adgangsbegrænsninger. Disse oplysninger er ikke bevis for et problem; de er den kontekst, der gør det muligt for en leverandør at sige, hvor et standardomfang passer, og hvor en antagelse skal kontrolleres. De gør det også lettere at undgå at bede om en bred test, blot fordi problemet endnu ikke er formuleret. Hvis der er en frist, så forklar, om den er kommerciel, kontraktuel, driftsmæssig eller regulatorisk, og hvad der ville gøre beslutningen nyttig. Det giver alle mulighed for at skelne et ønsket resultat fra den dokumentation, der faktisk kan indsamles inden for et ansvarligt omfang.

Ofte stillede spørgsmål

Relaterede artikler