Anbefalinger for sikkerhetstesting
Gjelder for denne Power Platform anbefalingen for sjekkliste for godt strukturert sikkerhet:
| SE:09 | Etabler et omfattende testregime som kombinerer tilnærminger for å forhindre sikkerhetsproblemer, validere implementeringer av trusselforebygging og teste trusseldeteksjonsmekanismer. |
|---|
Grundig testing er fundamentet for god sikkerhetsutforming. Testing er en taktisk form for validering for å sikre at kontroller fungerer som de skal. Testing er også en proaktiv måte å oppdage sikkerhetsproblemer på i systemet.
Etabler hyppig, streng testing og verifisering fra flere perspektiver. Du bør ta med synspunkter fra innsiden og ut som tester plattform og infrastruktur, og evalueringer fra utsiden og inn som tester systemet som en ekstern angriper.
Denne veiledningen inneholder anbefalinger for testing av sikkerhetsstatusen for arbeidsbelastningen. Implementer disse testmetodene for å forbedre arbeidsbelastningens motstandskraft overfor angrep og opprettholde konfidensialitet, integritet og tilgjengelighet av ressurser.
Definisjoner
| Term | Definisjon |
|---|---|
| Sikkerhetstesting av program (AST) | En Microsoft-teknikk for livssyklusen for sikkerhetsutvikling (SDL) der testmetoder med hvit boks og svart boks brukes til å se etter sikkerhetsproblemer i kode. |
| Testing med svart boks | En testmetode som validerer den eksternt synlige programfunksjonaliteten uten kunnskap om de interne delene av systemet. |
| Blått team | Et team som forsvarer seg mot angrepene til det røde teamet i en krigsspilløvelse. |
| Inntrengingstesting | En testmetode som bruker etiske hacketeknikker til å validere sikkerhetsforsvaret i et system. |
| Rødt team | Et team som spiller rollen som en motstander og prøver å hacke systemet i en krigsspilløvelse. |
| Livssyklus for sikkerhetsutvikling (SDL) | Et sett med fremgangsmåter fra Microsoft som støtter sikkerhetssikring og krav til forskriftssamsvar. |
| Livssyklus for programvareutvikling (SDLC) | En systematisk prosess med flere faser for utvikling av programvaresystemer. |
| Testing med hvit boks | En testmetode der strukturen til koden er kjent for utøveren. |
Viktige utformingsstrategier
Testing er en ikke-diskuterbar strategi, særlig når det gjelder sikkerhet. Den gjør at du proaktivt kan oppdage og løse sikkerhetsproblemer før de kan utnyttes, og kontrollere at sikkerhetskontrollene du implementerte, fungerer som de skal.
Omfanget av testingen må omfatte programmet, infrastrukturen og automatiserte og menneskelige prosesser.
Merk
Denne veiledningen skiller mellom testing og hendelsesrespons. Selv om testing er en registreringsmekanisme som ideelt sett løser problemer før produksjon, må den ikke forveksles med utbedring eller undersøkelse som gjøres som en del av hendelsesresponsen. Aspekter ved gjenoppretting fra sikkerhetshendelser er beskrevet i Anbefalinger for respons på sikkerhetshendelser.
Vær involvert i testplanlegging. Arbeidsbelastningsteamet utformer kanskje ikke testtilfeller. Denne oppgaven blir ofte sentralisert i virksomheten eller fullført av eksterne sikkerhetseksperter. Arbeidsbelastningsteamet bør være involvert i utformingsprosessen for å sikre at sikkerhetsforsikringer integreres med programmets funksjonalitet.
Tenk som en angriper. Utform testtilfeller der du forutsetter om at systemet er angrepet. Dermed kan du oppdage potensielle sikkerhetsproblemer og prioritere testene tilsvarende.
Kjør tester på en strukturert måte og i en gjentakbar prosess. Bygg testingsstrengheten rundt hyppighet, testtyper, drivende faktorer og tiltenkte resultater.
Bruk riktig verktøy til jobben. Bruk verktøy som er konfigurert slik at de fungerer med arbeidsbelastningen. Hvis det er et verktøy du ikke har, kjøper du det. Ikke bygg det. Sikkerhetsverktøy er svært spesialiserte, og det kan være risikabelt å bygge sitt eget verktøy. Dra nytte av ekspertisen og verktøyene som tilbys av sentrale SecOps-team, eller via eksterne hjelpemidler hvis arbeidsbelastningsteamet ikke har denne ekspertisen.
Konfigurer atskilte miljøer. Tester kan klassifiseres som destruktive eller ikke-destruktive. Ikke-destruktive tester er ikke inntrengende. De angir at det finnes et problem, men at de endrer ikke funksjonaliteten for å utbedre problemet. Destruktive tester er inntrengende og kan skade funksjonaliteten ved å slette data fra en database.
Testing i produksjonsmiljøer gir deg best informasjon, men forårsaker flest avbrudd. Det er vanlig å foreta bare ikke-destruktive tester i produksjonsmiljøer. Testing i ikke-produksjonsmiljøer er vanligvis mindre forstyrrende, men representerer kanskje ikke produksjonsmiljøets konfigurasjon nøyaktig på måter som er viktige for sikkerheten.
Du kan opprette en isolert klone av produksjonsmiljøet ved hjelp av funksjonen for miljøkopiering. Hvis du har konfigurert utrullingskanaler, kan du også rulle ut løsningen(e) til et eget testmiljø.
Evaluer alltid testresultatene. Testing er bortkastet hvis resultatene ikke brukes til å prioritere tiltak og gjøre forbedringer oppstrøms. Dokumenter retningslinjene for sikkerhet, inkludert anbefalte fremgangsmåter du finner. Dokumentasjon som viser resultater og utbedringsplaner, informerer teamet om de ulike måtene angripere kan prøve å bryte sikkerheten på. Gi utviklere, administratorer og testere regelmessig sikkerhetsopplæring.
Når du utformer testplanene, må du vurdere følgende spørsmål:
- Hvor ofte forventer du at testen skal kjøre, og hvordan påvirker den miljøet?
- Hva er de ulike testtypene du må kjøre?
Hvor ofte forventer du at testene må kjøres?
Test arbeidsbelastningen regelmessig for å sikre at endringer ikke utgjør en sikkerhetsrisiko, og at ingen regresjoner forekommer. Teamet må også være klart til å reagere på organisatoriske sikkerhetsvalideringer som kan bli utført når som helst. Det finnes også tester du kan kjøre som respons på en sikkerhetshendelse. Delene nedenfor inneholder anbefalinger om hyppigheten av tester.
Rutinetester
Rutinetester foretas med jevne mellomrom som en del av det rutinemessige arbeidet og for å oppfylle krav til forskriftssamsvar. Ulike tester kan kjøres med ulik hyppighet, men det viktigste er at de utføres regelmessig og etter en tidsplan.
Du bør integrere disse testene i SDLC-en fordi de utgjør et forsvar i dybden i hver fase. Diversifiser testserien for å bekrefte forsikringer om identitet, datalagring og overføring samt kommunikasjonskanaler. Foreta de samme testene på ulike punkter i livssyklusen for å sikre at det ikke forekommer regresjoner. Rutinetester bidrar til å etablere en innledende referanseverdi. Men dette er bare et utgangspunkt. Etter hvert som du oppdager nye problemer på de samme punktene i livssyklusen, legger du til nye testtilfeller. Testene forbedres også med repetisjon.
Disse testene skal i hver fase validere kode som er lagt til eller fjernet, eller konfigurasjonsinnstillinger som er endret, for å oppdage hvordan sikkerheten påvirkes av disse endringene. Du bør forbedre virkningen av testene med automatisering, balansert med fagfellevurdering.
Vurder å kjøre sikkerhetstester som en del av en automatisert pipeline eller planlagt testkjøring. Jo tidligere du oppdager sikkerhetsproblemer, desto enklere blir det å finne kode- eller konfigurasjonsendringen som forårsaket dem.
Ikke bruk bare automatiske tester. Bruk manuell testing til å oppdage sikkerhetsproblemer som bare menneskelig ekspertise kan finne. Manuell testing er bra i utforskende testtilfeller og til å finne ukjente risikoer.
Improviserte tester
Improviserte tester sørger for tidsvalidering av sikkerhetsforsvar. Sikkerhetsvarsler som kan påvirke arbeidsbelastningen på dette tidspunktet, utløser disse testene. Hvis varselet eskalerer til et nødstilfelle, kan organisatoriske krav gjøre at en pause-og-test-holdning blir nødvendig for å bekrefte effektiviteten til forsvarsstrategier.
Fordelen med improviserte tester er beredskap for en virkelig hendelse. Disse testene kan fungere som en tvingende funksjon for å foreta en test av brukergodkjenning (UAT).
Sikkerhetsteamet kan overvåke alle arbeidsbelastninger og kjøre disse testene etter behov. Som eier av en arbeidsbelastning må du støtte og samarbeide med sikkerhetsteam. Avtal nok leveringstid med sikkerhetsteam, slik at du kan gjøre deg klar. Gi teamet og interessentene beskjed om at disse avbruddene er nødvendige.
I andre tilfeller må du kanskje kjøre tester og rapportere sikkerhetstilstanden til systemet overfor den potensielle trusselen.
Avveining: Fordi improviserte tester er forstyrrende hendelser, kan du forvente å omprioritere oppgaver, noe som kan forsinke annet planlagt arbeid.
Risiko: Der er fare for det ukjente. Improviserte tester kan være engangstiltak uten etablerte prosesser eller verktøy. Men den mest fremtredende risikoen er det potensielle avbruddet i forretningsvirksomheten. Du må evaluere disse risikoene i forhold til fordelene.
Tester for sikkerhetshendelser
Det finnes tester som registrerer årsaken til en sikkerhetshendelse ved kilden. Disse sikkerhetsbruddene må løses for å sikre at hendelsen ikke oppstår igjen.
Hendelser kan også forbedre testtilfeller over tid ved å avdekke eksisterende brudd. Teamet bør bruke det de har lært av hendelsen, og foreta rutinemessige forbedringer.
Hva er de forskjellige testtypene?
Tester kan kategoriseres etter teknologi og etter testmetoder. Kombiner disse kategoriene og tilnærmingene i disse kategoriene for å oppnå fullstendig dekning.
Når du legger til flere tester og testtyper, kan du oppdage følgende:
- Brudd i sikkerhetskontroller eller kompenserende kontroller.
- Feilkonfigurasjoner.
- Brudd i metoder for observerbarhet og oppdaging.
En god trusselmodelleringsøvelse kan peke på viktige områder for å sikre testdekning og -hyppighet. Hvis du vil ha anbefalinger om trusselmodellering, kan du se Anbefalinger for sikring av en utviklingssyklus.
De fleste testene som er beskrevet i disse delene, kan kjøres som rutinetester. Gjentakelse kan imidlertid medføre kostnader i enkelte tilfeller og føre til avbrudd. Vurder disse avveiningene nøye.
Tester som validerer teknologistakken
Her er noen eksempler på testtyper og fokusområdene deres. Denne listen er ikke fullstendig. Test hele stakken, inkludert programstakken, frontenden, serverdelen, API-er, databaser og eventuelle eksterne integreringer.
- Datasikkerhet: Test effektiviteten til datakryptering og tilgangskontroller for å sikre at data er riktig beskyttet mot uautorisert tilgang og tukling.
- Nettverk og tilkobling: Test brannmurene dine for å sikre at de bare tillater forventet, tillatt og sikker trafikk til arbeidsbelastningen.
- Applikasjon: Test kildekoden gjennom AST-teknikker (Application Security Testing) for å sikre at du følger sikker kodingspraksis og for å fange opp kjøretidsfeil som minnekorrupsjon og rettighetsproblemer.
- Identitet: Evaluer om rolletilordningene og de betingede kontrollene fungerer etter hensikten.
Testmetode
Det finnes mange perspektiver på testmetoder. Vi anbefaler tester som gjør det mulig å jakte på trusler, ved å simulere virkelige angrep. De kan identifisere potensielle trusselaktører, teknikkene de bruker, og utnyttelsene deres som utgjør en trussel overfor arbeidsbelastningen. Gjør angrepene så realistiske som mulig. Bruk alle potensielle trusselvektorer du identifiserer under trusselmodellering.
Her er noen fordeler ved testing via virkelige angrep:
- Når du gjør disse angrepene til en del av rutinetestingen, bruker du et perspektiv fra utsiden og inn til å kontrollere arbeidsbelastningen og sørger for at forsvaret kan motstå et angrep.
- Teamet oppgraderer kunnskapen og kompetansenivået basert på erfaringen sin. Teamet forbedrer situasjonsforståelsen og kan selv vurdere hvor klare de er til å reagere på hendelser.
Eksempler på simulerte tester omfatter testing med svart boks og hvit boks, inntrengingstesting og andre krigsspilløvelser.
Testing med svart boks og hvit boks
Disse testtypene byr på to ulike perspektiver. I tester med svart boks vises ikke de interne delene av systemet. I tester med hvit boks har testeren en god forståelse av programmet og har til og med tilgang til kode, logger, ressurstopologi og konfigurasjoner i utføringen av eksperimentet.
Tester som simulerer angrep via inntrengingstesting
Sikkerhetseksperter som ikke er en del IT-teamet eller programteamene i organisasjonen, foretar inntrengingstesting eller pentesting. De vurderer systemet slik ondsinnede aktører vurderer en angrepsoverflate. Målet er å finne sikkerhetssvakheter ved å samle inn informasjon, analysere sårbarheter og rapportere resultatene.
Utøverne må kanskje ha tilgang til sensitive data i hele organisasjonen. Følg reglene for sikkerhetstesting for å sikre at tilgang ikke misbrukes. Se ressursene som er oppført i Relatert informasjon.
Tester som simulerer angrep via krigsspilløvelser
I denne metoden for simulerte angrep er det to team:
- Det røde teamet er motstanderen som prøver å modellere virkelige angrep. Hvis de lykkes, finner du svakheter i sikkerhetsutformingen og kan evaluere begrensningen av det potensielle skadeomfanget til sikkerhetsbruddene deres.
- Det blå teamet er arbeidsbelastningsteamet som forsvarer seg mot angrepene. De tester evnen til å registrere, reagere på og utbedre forsvaret mot angrepene. De validerer forsvaret som er implementert for å beskytte arbeidsbelastningsressurser.
Hvis de utføres som rutinetester, kan krigsspilløvelser gi kontinuerlig synlighet og forsikring om at forsvaret fungerer som det skal. Krigsspilløvelser kan potensielt foreta testing på tvers av nivåer i arbeidsbelastningene.
Opplæring i angrepssimulering for Microsoft Defender for Office 365 er et populært valg for å simulere realistiske angrepsscenarioer.
Hvis du vil ha mer informasjon, kan du se Innsikt og rapporter for opplæring i angrepssimulering.
Hvis du vil ha informasjon om oppsett av rødt og blått team, kan du se Rødt team for Microsoft Cloud.
Tilrettelegging for Power Platform
Med Microsoft Sentinel-løsningen for Microsoft Power Platform kan kunder oppdage ulike mistenkelige aktiviteter, for eksempel følgende:
- Power Apps-kjøring fra uautoriserte geografiske områder
- Eliminering av mistenkelige data av Power Apps
- Massesletting av Power Apps
- Phishing-angrep utført via Power Apps
- Power Automate-flytaktivitet av ansatte som har forlatt selskapet
- Microsoft Power Platform-koblinger lagt til i et miljø
- Oppdatering eller fjerning av Microsoft Power Platform-policyer for datatap
Hvis du vil ha mer informasjon, kan du se Oversikt over Microsoft Sentinel-løsningen for Microsoft Power Platform.
Hvis du vil ha produktdokumentasjon, kan du se Jaktfunksjonalitet i Microsoft Sentinel.
Microsoft Defender for Cloud byr på sårbarhetsskanning for ulike teknologiområder. Hvis du vil ha mer informasjon, kan du se Aktiver sårbarhetsskanning med Microsoft Defender Vulnerability Management.
DevSecOps integrerer sikkerhetstesting som en del av en holdning der pågående og kontinuerlig forbedring er rådende. Krigsspilløvelser er en vanlig praksis som er integrert i forretningsvirksomheten hos Microsoft. Hvis du vil ha mer informasjon, kan du se Sikkerhet i DevOps (DevSecOps).
Azure DevOps støtter tredjepartsverktøy som kan automatiseres som en del av CI/CD-pipelinene (Continuous Integration / Continuous Deployment). Hvis du vil ha mer informasjon, kan du se Aktiver DevSecOps med Azure og GitHub.
Relatert informasjon
Du kan finne de nyeste inntrengingstestene og sikkerhetsvurderingene i Microsoft Service Trust Portal.
Microsoft foretar omfattende testing av Microsoft Cloud-tjenester. Denne testingen omfatter inntrengingstesting der resultatene publiseres i Service Trust Portal for organisasjonen din. Organisasjonen din kan utføre sin egen inntrengingstest på Microsoft Power Platform og Microsoft Dynamics 365-tjenester. All inntrengingstesting må følge Reglene for inntrengingstesting for Microsoft Cloud. Det er viktig å huske at Microsoft Cloud i mange tilfeller bruker delt infrastruktur til å drifte aktivaene dine og aktiva som tilhører andre kunder. Du må begrense all inntrengingstesting til aktivaene dine og unngå utilsiktede konsekvenser for andre kunder rundt deg.
Følg reglene for sikkerhetstesting for å sikre at tilgang ikke misbrukes. Hvis du vil ha veiledning for planlegging og utføring av simulerte angrep, kan du se følgende:
Du kan simulere DoS-angrep (distribuert tjenestenektangrep) i Azure. Pass på at du følger policyene som er fremlagt i Simuleringstesting med Azure DDoS Protection.
Sikkerhetssjekkliste
Se hele settet med anbefalinger.