Del via

Anbefalinger til respons på sikkerhedshændelser

Gælder for Power Platform Well-Architected Security-tjeklisteanbefaling:

SE:11 Definere og teste effektive procedurer for hændelsesrespons, der dækker en række hændelser, fra lokaliserede problemer til it-katastrofeberedskab. Definer klart, hvilket team eller hvilken person der kører en procedure.

I denne vejledning beskrives anbefalingerne til implementering af en svar på sikkerhedshændelser i forbindelse med en arbejdsbelastning. Hvis der sker en sikkerhedsbrud af et system, kan en systematisk hændelsesrespons reducere den tid, det tager at identificere, administrere og afhjælpe sikkerhedshændelser. Disse hændelser kan være en trussel for softwaresystemers og -datas fortrolighed, integritet og tilgængelighed.

De fleste virksomheder har et centralt sikkerhedsoperationsteam (også kendt som Security Operations Center [SOC] eller SecOps). Sikkerhedsoperationsteamets ansvar er hurtigt at registrere, prioritere og undgå potentielle angreb. Teamet overvåger også sikkerhedsrelaterede telemetriske data og undersøger sikkerhedskonstroller.

Konceptbaseret illustration, der viser en samarbejdsbaseret tilgang til afhjælpning af potentielle og realiserede risici.

Du har dog også et ansvar for at beskytte din arbejdsbelastning. Det er vigtigt, at alle kommunikations-, undersøgelses- og jagtaktiviteter er et samarbejde mellem teamet bag arbejdsbelastningen og SecOps-teamet.

Denne vejledning indeholder anbefalinger til dig og dit arbejdsbelastningsteam, så I hurtigt kan registrere, identificere og undersøge angreb.

Definitioner

Begreb Definition
Advarsel En meddelelse, der indeholder oplysninger om en hændelse.
Beskedens nøjagtighed Nøjagtigheden af de data, der bestemmer en besked. Vigtige beskeder med høj sikkerhed indeholder den sikkerhedskontekst, der er nødvendig for at kunne udføre øjeblikkelige handlinger. Advarsler med få advarsler mangler oplysninger eller indeholder støj.
Falsk positiv En advarsel, der angiver en hændelse, som ikke fandt sted.
Hændelse En hændelse, der indikerer uautoriseret adgang til et system.
Hændelsessvar En proces, der registrerer, reagerer på og afhjælper de risici, der er knyttet til en hændelse.
Visiter En hændelsesresponshandling, der analyserer sikkerhedsproblemer og prioriterer afhjælpningen af dem.

Vigtigste designstrategier

Du og dit team udfører hændelsesresponshandlinger, når en hændelse eller en advarsel angiver en potentiel sikkerhedshændelse. Vigtige advarsler indeholder vigtige sikkerhedskontekster, der gør det nemt for analytikere at træffe beslutninger. Vigtige beskeder med mange egenskaber resulterer i et lille antal falske positiver. I denne vejledning antages det, at et advarselssystem filtrerer signaler med få advarsler og fokuserer på vigtige beskeder, der kan indikere en rigtig hændelse.

Tildel hændelsesmeddelelse

Sikkerhedsadvarsler skal være tilgængelige for de relevante personer i dit team og i din organisation. Opret et udpeget kontaktpunkt for dit arbejdsbelastningsteam for at modtage hændelsesmeddelelser. Disse meddelelser skal indeholde så mange oplysninger som muligt om den ressource, der er blevet kompromitteret, og om systemet. Advarslen skal omfatte de næste trin, så gruppen kan fremskynde handlinger.

Det anbefales, at du logføre og administrerer beskeder og handlinger vedrørende hændelser ved hjælp af specialiseret værktøj, der opbevarer et revisionsspor. Ved hjælp af standardværktøjer kan du bevare muligheden for, at det kan være nødvendigt i forbindelse med mulige juridiske undersøgelser. Søg efter muligheder for at implementere automatisering, der kan sende meddelelser baseret på ansvarsområderne for de ansvarlige parter. Hold styr på kommunikationen og rapporteringen under en hændelse.

Udnyt SIEM-løsninger (Security Information Event Management) og SOAR-løsninger (Security Orchestration Automated Response), som din organisation kan levere. Du kan også vælge at bruge værktøjer til administration af hændelser og opfordre organisationen til at standardisere dem for alle arbejdsbelastningsteams.

Undersøg med et prioriteret team

Det teammedlem, der modtager en hændelsesmeddelelse, er ansvarligt for at konfigurere en prioriteret proces, der involverer de relevante personer på baggrund af de tilgængelige data. Det prioriterede team, der ofte kaldes det forbundne team, skal være enige om tilstanden og kommunikationsprocessen. Kræver denne hændelse asynkrone diskussioner eller forbundne opkald? Hvordan skal teamet spore og kommunikere status for undersøgelser? Hvor kan teamet få adgang til hændelsesaktiver?

Hændelsesrespons er en væsentlig årsag til at holde dokumentationen opdateret, f.eks. systemets arkitektoniske layout, oplysninger på komponentniveau, klassifikation af personlige oplysninger eller sikkerhed, ejere og vigtige kontaktpunkter. Hvis oplysningerne er unøjagtige eller forældede, spilder teamet tid på at forsøge at forstå, hvordan systemet fungerer, hvem der er ansvarlig for de enkelte områder, og hvilken effekt begivenheden kan få.

I forbindelse med yderligere undersøgelser skal de relevante personer involveres. Du kan inkludere en hændelsesstyring, en sikkerhedsadministrator eller kundeemner, der er centreret om arbejdsbelastningen. Hvis du vil holde prioriteringen fokuseret, skal du udelukke personer, der ikke er omfattet af problemet. Undertiden undersøger separate teams hændelsen. Der kan være et team, som oprindeligt undersøger problemet og forsøger at afhjælpe hændelsen, og et andet specialiseret team, der måske udfører omfattende undersøgelser for at afhjælpe omfattende problemer. Du kan bruge arbejdsbelastningsmiljøet til at gøre det muligt for teamet at udføre deres arbejde. I visse tilfælde kan det samme team håndtere hele undersøgelsen.

I den indledende fase er den prioriterede gruppe ansvarlig for fastlæggelse af den potentielle risiko og dens indvirkning på systemets fortrolighed, integritet og tilgængelighed (også kaldet CIA).

Inden for kategorierne af CIA skal du tildele et første alvorlighedsniveau, som angiver dybden af skaderne og afhjælpningens vigtighed. Dette niveau forventes at ændre sig med tiden, efterhånden som der bliver fundet flere oplysninger i prioritetsniveauerne.

I registreringsfasen er det vigtigt at fastlægge en øjeblikkelig handlings- og kommunikationsplan. Er der ændringer i systemets køretilstand? Hvordan kan man standse angrebene for at standse den videre udnyttelse? Skal teamet udsende intern eller ekstern kommunikation, f.eks. ansvarlig videregivelse? Overvej registrerings- og svartid. Du er muligvis nødt til at rapportere visse typer oplysninger til en lovgivende myndighed inden for en bestemt tidsperiode, som ofte er timer eller dage.

Hvis du beslutter dig for at lukke systemet, fører de næste trin til arbejdsbelastningens it-katastrofeberedskabsproces (DR).

Hvis du ikke lukker systemet, skal du finde ud af, hvordan hændelsen skal afhjælpes, uden at det påvirker systemets funktionalitet.

Gendannelse efter en hændelse

Behandl en sikkerhedshændelse som en katastrofe. Hvis reparationen kræver fuld gendannelse, skal du bruge de rette DR-mekanismer fra et sikkerhedssynspunkt. Gendannelsesprocessen skal forhindre, at risikoen for gentagelser. Ellers opstår problemet igen, når du gendanner en beskadiget sikkerhedskopi. Genudrulning af et system med samme sårbarhed fører til den samme hændelse. Valider failover- og failbacktrin og -processer.

Hvis systemet ikke længere fungerer, skal du vurdere effekten på de kørende dele af systemet. Fortsæt med at overvåge systemet for at sikre, at andre mål for stabilitet og ydeevne opfyldes eller justeres ved at implementere korrekt forringelsesprocesser. Gå ikke på kompromis med beskyttelse af personlige oplysninger på grund af afhjælpning.

Identifikation er en interaktiv proces, indtil der identificeres en potentiel rettelse og fallback-proces. Efter reparation arbejder teamet på at identificere og anvender den påkrævede rettelse inden for en acceptabel periode.

Gendannelsesmetrikværdier måler, hvor lang tid det tager at løse et problem. Hvis systemet lukkes, kan der være forskellige oplysninger angående afhjælpningstiderne. Hvis du vil udnytte systemet, tager det tid at installere programrettelser, teste og installere opdateringer. Fastslut inddæmningsstrategier for at forhindre yderligere skade og udspredningen af hændelsen. Udarbejd procedurer til fjernelse af truslerne helt fra miljøet.

Afvejning: Der er en afvejning mellem pålidelighedsmål og afhjælpningstider. Under en hændelse er det sandsynligt, at du ikke overholder andre ikke-funktionalitets- eller funktionalitetskrav. Det kan f.eks. være nødvendigt at deaktivere dele af systemet, mens du undersøger hændelsen, eller du skal endda gøre hele systemet offline, indtil du bestemmer omfanget af hændelsen. Beslutningstagerne i virksomheden skal eksplicit beslutte, hvad de acceptable mål er under hændelsen. Angiv tydeligt den person, der er ansvarlig for denne beslutning.

Lær fra en hændelse

En hændelse afslører mangler eller sårbare punkter i et design eller en implementering. Det er en forbedringsmulighed, der drives af lektioner i aspekter inden for teknisk design, automatisering, produktudviklingsprocesser, der omfatter test og effektiviteten af hændelsesresponsprocessen. Vedligeholde detaljerede hændelsesposter, herunder handlinger, der er foretaget, tidslinjer og resultater.

Det anbefales på det kraftigste, at du foretager strukturerede gennemgange efter hændelsen, f.eks. analyse af rodårsag og uheldsanalyser. Spor og prioriter resultatet af disse gennemgange, og overvej at bruge det, du får at vide i fremtidige design af arbejdsbelastning.

Forbedringsplanerne skal omfatte opdateringer af sikkerhedsøvelser og -test, f.eks. øvelser til forretningskontinuitet (BCDR) og it-katastrofeberedskab. Brug sikkerhedsbrud som scenarie for udførelse af en BCDR-øvelse. Øvelser kan validere, hvordan de dokumenterede processer fungerer. Der skal ikke være flere strategiplaner til hændelsesresponser. Brug en enkelt kilde, som du kan justere på baggrund af hændelsens størrelse, og hvor udbredt eller lokaliseret effekten er. Øvelser er baseret på hypotetiske situationer. Udfør øvelser i et miljø med lav risiko, og inkluder læringsfasen i øvelserne.

Udfør efter hændelsesgennemgange eller kritiske gennemgange bagefter for at identificere svagheder i responsprocessen og områder, hvor der kan forbedres. Baseret på de erfaringer, du har lært af hændelsen, skal du opdatere planen for hændelsesrespons (IRP) og sikkerhedskontrolelementerne.

Send den nødvendige kommunikation

Implementer en kommunikationsplan for at give brugere besked om forstyrrelser og informere interne interessenter om afhjælpningerne og forbedringerne. Andre personer i organisationen skal have besked om eventuelle ændringer af arbejdsbelastningens grundlæggende sikkerhedslinje for at forhindre fremtidige hændelser.

Opret hændelsesrapporter til internt brug og om nødvendigt til overholdelse af lovgivningen eller juridiske formål. Indfør også en rapport i standardformat (en dokumentskabelon med definerede sektioner), som SOC-teamet bruger til alle hændelser. Sørg for, at alle hændelser har en rapport tilknyttet, før du lukker undersøgelsen.

Power Platform-processtyring

I følgende afsnit beskrives de mekanismer, du kan anvende som del af procedurerne for respons på sikkerhedshændelser.

Microsoft Sentinel

Med Microsoft Sentinel-løsningen til Microsoft Power Platform kan kunderne registrere forskellige aktiviteter, herunder:

  • 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.

Microsoft Purview-aktivitetslogning

Power Apps, Power Automate, connectorer og aktiviteter til at forhindre datatab og administrativ Power Platform-aktivitetslogning spores og vises fra Microsoft Purview-portalen for overholdelse af angivne standarder.

Du kan finde flere oplysninger i:

Kundelockbox

De fleste handlinger, support og fejlfinding, der udføres af Microsoft-medarbejdere (herunder underprocessorer), kræver ikke adgang til kundedata. Med Power Platform-kundelockbox'en giver Microsoft en grænseflade, hvor kunder kan gennemse og godkende (eller afvise) anmodninger om dataadgang i de sjældne tilfælde, hvor der er behov for dataadgang til kundedata. Det bruges i de tilfælde, hvor en Microsoft-tekniker skal have adgang til kundedata, uanset om det er som svar på en kundeinitieret supportanmodning eller et problem, der identificeres af Microsoft. Du kan finde flere oplysninger i Sikre adgang til kundedata ved hjælp af Kundelockbox i Power Platform og Dynamics 365.

Sikkerhedsopdateringer

Customer Engagement-teamet foretager regelmæssigt følgende for at sørge for sikkerhed i systemet:

  • Scanner servicen for at identificere mulige sikkerhedsmæssige sårbarheder.
  • Vurderinger af servicen for at sikre, at de vigtigste sikkerhedskontrolsystemer fungerer effektivt.
  • Evalueringer af servicen for at vurdere sikkerhedssvagheder, der er identificeret af MSRC (Microsoft Security Response Center), som regelmæssigt overvåger eksterne websteder om sårbarheder.

Disse teams identificerer og registrerer også problemer og handler hurtigt for at reducere risici, når det er nødvendigt.

Hvordan finder jeg oplysninger om sikkerhedsopdateringer?

Da serviceteams bestræber sig på at anvende risikoafhjælpning på en måde, der ikke kræver nedetid i servicen, får administratorer normalt ikke vist meddelelser fra meddelelsescenter vedrørende sikkerhedsopdateringer. Hvis en sikkerhedsopdatering påvirker servicen, betragtes den som planlagt vedligeholdelse, og varigheden af den estimerede påvirkning og det vindue, som arbejdet vil blive udført indenfor, slås op.

Du kan få flere oplysninger om sikkerhed under Microsoft Sikkerhedscenter.

Administrere dit vedligeholdelsesvindue

Microsoft udfører regelmæssigt opdateringer og vedligeholdelser for at sikre sikkerhed, ydeevne og tilgængelighed og for at levere nye funktioner og funktionalitet. Denne opdateringsproces leverer forbedringer af sikkerheden og mindre tjenester på ugebasis, hvor hver opdatering udrulles område for område i henhold til en sikker tidsplan for installation, arrangeret i stationer. Du kan finde oplysninger om standardvinduet for vedligeholdelse af miljøer under Politikker og kommunikation for servicehændelser. Also see Administrer vinduet til vedligeholdelse.

Sørg for, at Azure-tilmeldingsportalen omfatter administratorens kontaktoplysninger, så sikkerhedshandlinger kan underrettes direkte via en intern proces. Du kan finde flere oplysninger under Opdater meddelelsesindstillinger.

Organisatorisk justering

Cloud Adoption Framework til Azure indeholder en vejledning i planlægning af hændelsesrespons og sikkerhedshandlinger. Du kan finde flere oplysninger i Sikkerhedshandlinger.

Kontrolliste til sikkerhed

Se det fuldstændige sæt anbefalinger.

Tjekliste for sikkerhed