Anbefalinger til sikkerhedstest
Gælder for denne Power Platform anbefaling af Well-Architected Security-tjekliste:
| SE:09 | Etabler et omfattende testregime, der kombinerer tilgange til at forhindre sikkerhedsproblemer, validere implementeringer af trusselsforebyggelse og teste trusselsregistreringsmekanismer. |
|---|
Strenge tests er grundlaget for et godt sikkerhedsdesign. Test er en valideringsformular, der fungerer efter hensigten. Test er også en proaktiv metode til registrering af sårbarheder i systemet.
Opret test via cadence og verificering fra flere perspektiver. Du skal inkludere interne foranstaltninger, der tester platform og infrastruktur og eksterne evalueringer, som tester systemet som en ekstern hackere.
Denne vejledning indeholder anbefalinger til test af arbejdsbelastningens sikkerhedsmæssige stilling. Implementer disse testmetoder for at forbedre arbejdsbelastningens modstand mod angreb og bevare fortroligheden, integriteten og tilgængeligheden af ressourcer.
Definitioner
| Begreb | Definition |
|---|---|
| Application security testing (AST) | En SDL-teknik (Microsoft Security Development Lifecycle), der bruger white-box- og black-box-testmetoder til at kontrollere, om der er sikkerhedsrisici i kode. |
| Black-box-test | En testmetode, der validerer den eksternt synlige programfunktionsmåde uden at have kendskab til systemets interne funktioner. |
| Blåt team | Et team, der bekæmper angreb fra det røde team i et krigsspil. |
| Indtrængningstest | En testmetode, der bruger værktøjsteknikker til at validere sikkerheden i et system. |
| Rødt team | Et team, der spiller rollen som modstander og forsøger at hacke systemet i et krigsspil. |
| Livscyklus for sikkerhedsudvikling (SDL) | En række fremgangsmåder er leveret af Microsoft, der understøtter krav til sikkerhed og overholdelse af angivne standarder. |
| Livscyklus for sikkerhedsudvikling (SDLC) | En systematisk proces i flere trin til udvikling af softwaresystemer. |
| Test i white box | En testmetode, hvor strukturen af koden kendes af forskellige metoder. |
Vigtigste designstrategier
Test er en strategi, der ikke kan forhandles om, især for sikkerhed. Du kan bruge den til proaktivt at finde og løse sikkerhedsproblemer, før de kan afhjælpes, og til at kontrollere, at de sikkerhedskontrolelementer, du har implementeret, fungerer som designet.
Omfanget af test skal omfatte programmet, infrastrukturen og automatiserede og humane processer.
Bemærk
I denne vejledning skelnes der mellem test og hændelsesrespons. Selvom test er en registreringsmekanisme, der ideelt set løser problemer før produktionen, skal den ikke forveksles med overensstemmelse eller undersøgelse, der er udført som en del af en hændelsesrespons. As aspekter ved gendannelse efter sikkerhedshændelser beskrives i Anbefalinger til respons på sikkerhedshændelser.
Vær involveret i testplanlægningen. Arbejdsbelastningsgruppen designer måske ikke testsagerne. Denne opgave centraliseres ofte i virksomheden eller fuldføres af eksterne sikkerhedseksperter. Arbejdsbelastningsgruppen skal involveres i designprocessen for at sikre, at sikkerhedsforanstaltninger integreres med programmets funktionalitet.
Tænk som en hacker. Design testsagerne ud fra den antagelse, at systemet er blevet angrebet. På den måde kan du se de potentielle sårbarheder og prioritere testene efter dette.
Kør test på en struktureret måde og med en proces, der kan gentages. Opbyg testene omkring cadence, testtyper, kørselsfaktorer og tilsigtet afhængighed.
Brug det rigtige værktøj til jobbet. Brug værktøjer, der er konfigureret til at arbejde med arbejdsbelastningen. Hvis du ikke har et værktøj, kan du købe værktøjet. Byg det ikke. Sikkerhedsværktøjer er højt specialiseret, og der kan være risici forbundet med at opbygge dit eget værktøj. Udnyt den ekspertise og de værktøjer, der findes i de centrale SecOps-teams eller eksternt, hvis arbejdsbelastningsgruppen ikke har den ekspertise.
Konfigurere separate miljøer. Test kan klassificeres som fortrolige eller ikke-strukturerende. Ikke-destruktiv test er ikke angribende. De angiver, at der er et problem, men de ændrer ikke funktionaliteten for at løse problemet. Destruktive test er angribende og kan ødelægge funktionaliteten ved at slette data fra en database.
Test i produktionsmiljøer giver dig de bedste oplysninger, men forårsager mest forstyrrelse. Du undgår kun at udføre ikke-ødelæggende test i produktionsmiljøer. Test i miljøer, der ikke bruges til produktion, forstyrrer typisk mindre, men de repræsenterer måske ikke nøjagtigt produktionsmiljøets konfiguration på måder, der er vigtige for sikkerheden.
Du kan oprette en isoleret kloning af produktionsmiljøet ved hjælp af funktionen til miljøkopiering. Hvis du har konfigureret installationspipelines, kan du også installere dine løsninger i et dedikeret testmiljø.
Evaluere altid testresultaterne. Test er en forsøgsindsats, hvis resultaterne ikke bruges til at prioritere handlinger og foretage forbedringer i forhold til tidligere. Dokumentere de sikkerhedsretningslinjer, herunder bedste praksis, du kan finde. Dokumentation, der registrerer resultater og planlægger angreb, der kan uddanne teamet om de forskellige måder, som hackere kan prøve at bryde sikkerheden på. Udfør regelmæssig sikkerhedsundervisning for udviklere, administratorer og testere.
Når du designer testplaner, skal du overveje følgende spørgsmål:
- Hvor ofte forventer du, at testen kører, og hvordan påvirker den miljøet?
- Hvad er de forskellige testtyper, du skal køre?
Hvor ofte forventer du, at testene kører?
Test arbejdsbelastningen jævnligt for at sikre, at der ikke er sikkerhedsrisici ved ændringer, og at der ikke er nogen regressioner. Teamet skal også være parat til at reagere på organisationssikkerhedsvalideringerne, der kan udføres når som helst. Der findes også test, som du kan køre som svar på en sikkerhedshændelse. Følgende afsnit indeholder anbefalinger angående testfrekvensen.
Rutinetest
Rutinemæssige test udføres jævnligt som en del af standardprocedurerne for betjening og for at overholde overholdelseskrav. Der kan udføres forskellige test med forskellige metoder, men nøglen er, at de udføres jævnligt og efter en tidsplan.
Du skal integrere disse test i din SDLC, da de giver detaljerede oplysninger i hver fase. Kontrol af testpakken for at bekræfte sikkerhed for identitet, datalagring og -transmission samt kommunikationskanaler. Udfør de samme test forskellige steder i livscyklussen for at sikre, at der ikke er nogen regressioner. Rutinemæssige test hjælper med at oprette en indledende benchmark. Det er dog kun et udgangspunkt. Når du får nye problemer på samme tidspunkt i livscyklussen, tilføjer du nye testsager. Testene bliver også bedre med mange forskellige test.
I hvert enkelt trin skal disse test validere kode, der er tilføjet eller fjernet, eller konfigurationsindstillinger, der er ændret, for at registrere sikkerhedsbelastningen af disse ændringer. Testresultaterne bør forbedres med automatisering, hvor de afbalanceres med peer reviews.
Overvej at køre sikkerhedstest som en del af en automatiseret pipeline eller planlagt testkørsel. Jo før du opdager sikkerhedsproblemer, jo nemmere er det at finde den kode eller konfigurationsændring, der forårsager dem.
Du skal ikke kun bruge automatiserede test. Brug manuel test til at registrere sikkerhedsrisici, som kun den pågældende brugers ekspertise kan gribe ind i. Manuel test er god til forsøgsbrug og til at finde ukendte risici.
Improviserede test
Improviserende test sikrer validering af sikkerhedsforsvar på fastlagte tidspunkter. Sikkerhedsbeskeder, der kan påvirke arbejdsbelastningen på det tidspunkt, udløser disse test. Det kan være nødvendigt at bruge en pause og test for at kontrollere effektiviteten af strategierne for de forskellige afdelinger, hvis advarslen eskalerer til en fare.
Fordelen ved improviserende test forberedes for en rigtig hændelse. Disse test kan være en gennemtvingende funktion til test af brugeraccept (UAT).
Sikkerhedsgruppen kan overvåge alle arbejdsbelastninger og køre disse test efter behov. Som ejer af arbejdsbelastning skal du lette og samarbejde med sikkerhedsteams. Du skal forhandle tilstrækkelig lang tid med sikkerhedsteams, så du kan forberede dig. Anerkend og kommuniker med dit team og interessenter om, at disse forstyrrelser er nødvendige.
I andre tilfælde skal du måske køre test og rapportere systemets sikkerhedstilstand mod den potentielle trussel.
Afvejning: Fordi improviserede tests er forstyrrende begivenheder, skal du forvente at omprioritere opgaver, hvilket kan forsinke andet planlagt arbejde.
Risiko: Der er risiko for det ukendte. Test af improviserende programmer kan udføres én gang uden etablerede processer eller værktøjer. Men den overvejende risiko er den potentielle afbrydelse af virksomhedens drift. Du skal vurdere disse risici i forhold til fordelene.
Test af sikkerhedshændelser
Der findes test, som registrerer årsagen til en sikkerhedshændelse ved kilden. Disse sikkerhedsmæssige problemer skal løses for at sikre, at hændelsen ikke gentages.
Hændelser forbedrer også testsagerne med tiden ved at finde frem til eksisterende problemer. Teamet bør anvende de erfaringer, der er lært af hændelsen, og rutinemæssigt indarbejde forbedringer.
Hvad er de forskellige testtyper?
Test kan kategoriseres efter teknologi og efter testmetoder. Du kan kombinere disse kategorier og fremgangsmåder inden for disse kategorier for at få fuldstændig dækning.
Ved at tilføje flere test og typer af test kan du finde ud af følgende:
- Huller i sikkerhedskontrollen eller kompenserende kontrol.
- Fejlkonfigurationer.
- Huller i overvågnings- og registreringsmetoderne.
En god trusselsmodellering kan pege på nøgleområder for at sikre testdækning og hyppighed. Du kan finde anbefalinger til trusselsmodeller i Anbefalinger til sikring af livscyklussen for udviklingen.
De fleste test, der beskrives i disse afsnit, kan køres som rutinetest. Ensartethed kan i visse tilfælde medføre omkostninger og medføre forstyrrelse. Overvej disse situationer omhyggeligt.
Test, der validerer teknologistakke
Her er nogle eksempler på testtyper og deres fokusområder. Denne liste er ikke udtømmende. Test hele stakken, herunder programstakke, frontend, backend, API'er, databaser og eventuelle eksterne integrationer.
- Datasikkerhed: Test effektiviteten af datakryptering og adgangskontrol for at sikre, at data er korrekt beskyttet mod uautoriseret adgang og manipulation.
- Netværk og forbindelse: Test dine firewalls for at sikre, at de kun tillader forventet, tilladt og sikker trafik til arbejdsbelastningen.
- Program: Test kildekoden ved hjælp af AST-teknikker (Application Security Test) for at sikre, at du følger sikker kodningspraksis og for at fange kørselsfejl som f.eks. hukommelsesbeskadigelse og problemer med rettigheder.
- Identitet: Evaluer, om rolletildelingerne og de betingede kontroller fungerer efter hensigten.
Testmetode
Der er mange perspektiver på testmetoderne. Vi anbefaler test, der aktiverer trusselsangreb ved at simulere angreb som fra den virkelige verden. De kan identificere mulige trusler, deres teknikker og deres bedrifter, der udgør en trussel for arbejdsbelastningen. Gør angrebene så realistiske som muligt. Brug alle de potentielle trusler, du kan identificere under opbygning af trusselsmodeller.
Her er nogle fordele ved at teste via angreb fra den virkelige verden:
- Når du gør disse angreb til en del af en rutinetest, skal du bruge et udefra-perspektiv til at kontrollere arbejdsbelastningen og sikre dig, at angrebsbelastningen kan håndtere et angreb.
- På baggrund af de erfaringer, teamet har gjort sig, kan de opgradere deres viden og erfaringsniveau. Teamet øger den situationsbaserede opmærksomhed og kan selv vurdere, om de er parate til at reagere på hændelser.
Eksempler på simulerede test kan være test af black-box og white-box, indtrængningstest og øvelser i forskellige krigsspil.
Black box- og white box-test
Disse testtyper giver to forskellige perspektiver. I black box-test er systemets interne systemer ikke synlige. I white box-test har testeren en god forståelse af programmet og har endda adgang til kode, logge, ressourcetopologi og konfigurationer til udførelse af eksperimentet.
Test, der simulerer angreb via indtrængning
Sikkerhedseksperter, der ikke er en del af organisationens it- eller programteam, udfører indtrængningstest eller pentesting. De vurderer systemet, som ondsindede hackere vurderer en angrebsoverflade. Deres mål er at finde sikkerhedsmæssige sårbarheder ved at indsamle oplysninger, analysere sårbarheder og rapportere resultaterne.
Det kan være nødvendigt at få adgang til følsomme data i hele organisationen. Følg reglerne for engagement for at sikre, at adgang ikke misbruges. Se de ressourcer, der er angivet i Relaterede oplysninger.
Test, der simulerer angreb via øvelser i krigsspil
I denne metode med simulerede angreb findes der to grupper:
- Et rødt team, som er den modstander, der forsøger at skabe et angreb fra den virkelige verden. Hvis de har succes, opdager du sårbarheder i dit sikkerhedsdesign, og du kan se omfanget af deres indtrængen.
- Et blåt team, som er det arbejdsteam, der skal modkæmpe angrebene. De tester deres mulighed for at registrere, reagere og håndtere angrebene. De validerer de foranstaltninger, der er implementeret for at beskytte arbejdsbelastningsressourcer.
Hvis de udføres som rutineprægede test, kan øvelser i krigsspil give løbende synlighed og sikkerhed for, at dit forsvar fungerer som designet. Simuleringsøvelser i krigsspil kan potentielt testes på tværs af niveauer i dine arbejdsbelastninger.
Et populært valg til simulering af realistiske angrebsscenarier er Microsoft Defender for Office 365 Træning i angrebssimulering.
Du kan finde flere oplysninger i Indsigt og rapporter om træning i angrebssimulering.
Du kan finde oplysninger om opsætningen af rødt team og blåt team i Microsoft Cloud Red Teaming.
Power Platform-processtyring
Med Microsoft Sentinel-løsningen til Microsoft Power Platform kan kunderne registrere forskellige aktiviteter, f.eks.:
- Power Apps-eksekvering fra uautoriserede geografiske områder
- Destruktion af mistænkelige data af Power Apps
- Massesletning af Power Apps
- Phishing-angreb foretaget gennem Power Apps
- Power Automate-flowaktivitet efter medarbejdere, som ikke længere er ansat
- Microsoft Power Platform-connectorer, der er føjet til miljøet
- Opdatering eller fjernelse af Microsoft Power Platform-politikker til forebyggelse af datatab
Du kan få flere oplysninger i Oversigt over Microsoft Sentinel-løsning til Microsoft Power Platform.
Produktdokumentation i Jagtfunktioner i Microsoft Sentinel.
Microsoft Defender for Cloud tilbyder sårbarhedsscanning for forskellige teknologiområder. Du kan finde flere oplysninger under Aktivering af scanning af sårbarheder med Microsoft Defender Vulnerability Management.
Med DevSecOps-praksis integreres sikkerhedstest som en del af en løbende forbedring. Simuleringsøvelser i krigsspil er en almindelig praksis, der er integreret i virksomhedsdriften hos Microsoft. Du kan finde flere oplysninger under Sikkerhed i DevOps (DevSecOps).
Azure DevOps understøtter tredjepartsværktøjer, der kan automatiseres som en del af CI/CD-pipelines (continuous integration/continuous deployment). Du kan finde flere oplysninger under Aktivering af DevSecOps med Azure og GitHub.
Relaterede oplysninger
De nyeste gennemtrængningstest og sikkerhedsvurderinger kan findes på Microsoft Service Trust Portal.
Microsoft udfører omfattende test af Microsoft Cloud Services. Testen omfatter indtrængningstest med resultater, der er publiceret på Service Trust Portal for din organisation. Din organisation kan udføre din egen indtrængningstest i Microsoft Power Platform og Microsoft Dynamics 365-services. Alle test af indtrængning skal følge Microsoft Cloud-testreglerne for indtrængning. Det er vigtigt at huske på, at i mange tilfælde bruger Microsoft Cloud delt infrastruktur til at være vært for dine aktiver og aktiver, der tilhører andre kunder. Du skal begrænse alle test til dine aktiver og undgå utilsigtede konsekvenser for andre kunder omkring dig.
Følg reglerne for engagement for at sikre, at adgang ikke misbruges. Du kan finde en vejledning i planlægning og udførelse af simulerede angreb under:
Du kan simulere DoS-angreb (Denial of Service) i Azure. Sørg for at følge de politikker, der er fastlagt i Simuleringstest af Azure DDoS Protection.
Kontrolliste til sikkerhed
Se det fuldstændige sæt anbefalinger.