Aanbevelingen voor reactie op beveiligingsincidenten

Is van toepassing op de aanbeveling van de controlelijst voor beveiliging van Azure Well-Architected Framework:

SE:12	Definieer en test effectieve procedures voor het reageren op incidenten die betrekking hebben op een spectrum van incidenten, van gelokaliseerde problemen tot herstel na noodgevallen. Definieer duidelijk welk team of persoon een procedure uitvoert.

In deze handleiding worden de aanbevelingen beschreven voor het implementeren van een reactie op beveiligingsincidenten voor een workload. Als er sprake is van een beveiligingsinbreuk in een systeem, helpt een systematische incidentresponsbenadering om de tijd te verkorten die nodig is om beveiligingsincidenten te identificeren, te beheren en te beperken. Deze incidenten kunnen een bedreiging vormen voor de vertrouwelijkheid, integriteit en beschikbaarheid van softwaresystemen en gegevens.

De meeste ondernemingen hebben een centraal beveiligingsteam (ook wel Security Operations Center (SOC) of SecOps genoemd). Het beveiligingsteam is verantwoordelijk voor het snel detecteren, prioriteren en sorteren van potentiële aanvallen. Het team bewaakt ook beveiligingsgerelateerde telemetriegegevens en onderzoekt beveiligingsschendingen.

U hebt echter ook een verantwoordelijkheid om uw workload te beschermen. Het is belangrijk dat communicatie-, onderzoeks- en opsporingsactiviteiten een gezamenlijke inspanning zijn tussen het workloadteam en het SecOps-team.

Deze handleiding bevat aanbevelingen voor u en uw workloadteam om u te helpen snel aanvallen te detecteren, te sorteren en te onderzoeken.

Definities

Termijn	Definitie
Waarschuwing	Een melding met informatie over een incident.
Waarschuwingskwaliteit	De nauwkeurigheid van de gegevens die een waarschuwing bepalen. Waarschuwingen van hoge kwaliteit bevatten de beveiligingscontext die nodig is om onmiddellijk actie te ondernemen. Waarschuwingen met een lage kwaliteit hebben geen informatie of bevatten ruis.
Fout-positief	Een waarschuwing die een incident aangeeft dat niet is opkomen.
Incident	Een gebeurtenis die wijst op onbevoegde toegang tot een systeem.
Reageren op incidenten	Een proces dat risico's detecteert, reageert en vermindert die aan een incident zijn gekoppeld.
Sorteren	Een reactiebewerking voor incidenten die beveiligingsproblemen analyseert en prioriteit geeft aan de beperking ervan.

Belangrijke ontwerpstrategieën

U en uw team voeren incidentresponsbewerkingen uit wanneer er een signaal of waarschuwing is voor een mogelijke inbreuk. Waarschuwingen van hoge kwaliteit bevatten voldoende beveiligingscontext waarmee analisten eenvoudig beslissingen kunnen nemen. Waarschuwingen van hoge kwaliteit resulteren in een laag aantal fout-positieven. In deze handleiding wordt ervan uitgegaan dat een waarschuwingssysteem signalen van lage kwaliteit filtert en zich richt op waarschuwingen van hoge kwaliteit die kunnen duiden op een echt incident.

Melding van incident toewijzen

Beveiligingswaarschuwingen moeten de juiste personen in uw team en in uw organisatie bereiken. Stel een aangewezen contactpunt in uw workloadteam in om incidentmeldingen te ontvangen. Deze meldingen moeten zoveel mogelijk informatie bevatten over de resource die is aangetast en het systeem. De waarschuwing moet de volgende stappen bevatten, zodat uw team acties kan versnellen.

We raden u aan om incidentmeldingen en -acties te registreren en te beheren met behulp van gespecialiseerde hulpprogramma's die een audittrail bijhouden. Met behulp van standaardhulpprogramma's kunt u bewijs bewaren dat mogelijk vereist is voor mogelijke juridische onderzoeken. Zoek naar mogelijkheden om automatisering te implementeren die meldingen kan verzenden op basis van de verantwoordelijkheden van verantwoordelijke partijen. Houd een duidelijke keten van communicatie en rapportage tijdens een incident.

Profiteer van SIEM-oplossingen (Security Information Event Management) en SOAR-oplossingen (Security Orchestration Automated Response) die uw organisatie biedt. U kunt ook hulpprogramma's voor incidentbeheer aanschaffen en uw organisatie aanmoedigen om deze te standaardiseren voor alle workloadteams.

Onderzoeken met een triageteam

Het teamlid dat een incidentmelding ontvangt, is verantwoordelijk voor het instellen van een triageproces waarbij de juiste personen betrokken zijn op basis van de beschikbare gegevens. Het triageteam, ook wel het brugteam genoemd, moet het eens worden over de modus en het communicatieproces. Vereist dit incident asynchrone discussies of bruggesprekken? Hoe moet het team de voortgang van onderzoeken bijhouden en communiceren? Waar kan het team toegang krijgen tot incidentassets?

Reactie op incidenten is een belangrijke reden om documentatie up-to-date te houden, zoals de architectuurindeling van het systeem, informatie op onderdeelniveau, privacy- of beveiligingsclassificatie, eigenaren en belangrijke contactpunten. Als de informatie onjuist of verouderd is, verspilt het brugteam kostbare tijd aan het begrijpen van de werking van het systeem, wie verantwoordelijk is voor elk gebied en wat het effect van de gebeurtenis kan zijn.

Betrek voor verder onderzoek de juiste personen. U kunt een incidentmanager, beveiligingsmedewerker of workloadgerichte leads opnemen. Als u de sortering gefocust wilt houden, moet u personen uitsluiten die zich buiten het bereik van het probleem bevinden. Soms onderzoeken afzonderlijke teams het incident. Er kan een team zijn dat het probleem in eerste instantie onderzoekt en probeert het incident te verhelpen, en een ander gespecialiseerd team dat forensische gegevens kan uitvoeren voor een grondig onderzoek om algemene problemen vast te stellen. U kunt de workloadomgeving in quarantaine plaatsen om het forensische team in staat te stellen hun onderzoek uit te voeren. In sommige gevallen kan hetzelfde team het hele onderzoek afhandelen.

In de eerste fase is het triageteam verantwoordelijk voor het bepalen van de potentiële vector en het effect ervan op de vertrouwelijkheid, integriteit en beschikbaarheid (ook wel de CIA genoemd) van het systeem.

Wijs binnen de categorieën van CIA een initiële ernstniveau toe dat de diepte van de schade en de urgentie van herstel aangeeft. Dit niveau verandert naar verwachting in de loop van de tijd naarmate er meer informatie wordt gedetecteerd in de niveaus van triage.

In de detectiefase is het belangrijk om direct een actie- en communicatieplan te bepalen. Zijn er wijzigingen in de actieve status van het systeem? Hoe kan de aanval worden ingeperkt om verdere exploitatie te stoppen? Moet het team interne of externe communicatie verzenden, zoals een verantwoorde openbaarmaking? Overweeg detectie- en reactietijd. Mogelijk bent u wettelijk verplicht om bepaalde soorten schendingen binnen een bepaalde periode, die vaak uren of dagen is, te melden bij een regelgevende instantie.

Als u besluit het systeem af te sluiten, leiden de volgende stappen tot het herstelproces van de workload.

Als u het systeem niet afsluit, bepaalt u hoe het incident moet worden opgelost zonder dat dit van invloed is op de functionaliteit van het systeem.

Herstellen van een incident

Een beveiligingsincident behandelen als een noodgeval. Als voor het herstel volledig herstel is vereist, gebruikt u de juiste DR-mechanismen vanuit een beveiligingsperspectief. Het herstelproces moet de kans op terugkeer voorkomen. Anders wordt het probleem opnieuw veroorzaakt door herstel van een beschadigde back-up. Het opnieuw implementeren van een systeem met hetzelfde beveiligingsprobleem leidt tot hetzelfde incident. Stappen en processen voor failover en failback valideren.

Als het systeem blijft functioneren, beoordeelt u het effect op de actieve onderdelen van het systeem. Blijf het systeem bewaken om ervoor te zorgen dat andere betrouwbaarheids- en prestatiedoelen worden bereikt of opnieuw worden aangepast door de juiste degradatieprocessen te implementeren. Maak geen inbreuk op privacy vanwege risicobeperking.

Diagnose is een interactief proces totdat de vector en een mogelijke oplossing en terugval worden geïdentificeerd. Na de diagnose werkt het team aan herstel, waarbij de vereiste oplossing binnen een acceptabele periode wordt geïdentificeerd en toegepast.

Metrische herstelgegevens meten hoe lang het duurt om een probleem op te lossen. In het geval van een afsluiting kan er een urgentie zijn met betrekking tot de hersteltijden. Om het systeem te stabiliseren, kost het tijd om fixes, patches en tests toe te passen en updates te implementeren. Bepaal insluitingsstrategieën om verdere schade en de verspreiding van het incident te voorkomen. Uitroeiingsprocedures ontwikkelen om de bedreiging volledig uit het milieu te verwijderen.

Afweging: Er is een afweging tussen betrouwbaarheidsdoelen en hersteltijden. Tijdens een incident voldoet u waarschijnlijk niet aan andere niet-functionele of functionele vereisten. Mogelijk moet u bijvoorbeeld delen van uw systeem uitschakelen terwijl u het incident onderzoekt, of moet u zelfs het hele systeem offline halen totdat u het bereik van het incident hebt bepaald. Zakelijke besluitvormers moeten expliciet bepalen wat de acceptabele doelen zijn tijdens het incident. Geef duidelijk de persoon op die verantwoordelijk is voor die beslissing.

Leren van een incident

Een incident legt hiaten of kwetsbare punten in een ontwerp of implementatie bloot. Het is een verbeteringskans die wordt aangedreven door lessen in technische ontwerpaspecten, automatisering, productontwikkelingsprocessen waaronder testen en de effectiviteit van het incidentresponsproces. Houd gedetailleerde incidentrecords bij, inclusief uitgevoerde acties, tijdlijnen en bevindingen.

We raden u ten zeerste aan om gestructureerde post-incidentbeoordelingen uit te voeren, zoals hoofdoorzaakanalyse en retrospectieven. Houd de resultaten van deze beoordelingen bij en geef prioriteit aan, en overweeg het gebruik van wat u leert in toekomstige workloadontwerpen.

Verbeterplannen moeten updates bevatten voor beveiligingsanalyses en -tests, zoals BCDR-oefeningen (business continuity and disaster recovery). Gebruik beveiligingsinbreuk als scenario voor het uitvoeren van een BCDR-analyse. Met drills kunt u valideren hoe de gedocumenteerde processen werken. Er mogen niet meerdere playbooks voor incidentrespons zijn. Gebruik één bron die u kunt aanpassen op basis van de grootte van het incident en hoe wijdverbreid of gelokaliseerd het effect is. Drills zijn gebaseerd op hypothetische situaties. Voer oefeningen uit in een omgeving met een laag risico en neem de leerfase op in de oefeningen.

Voer post-incidentbeoordelingen uit, of postmortems, om zwakke plekken in het reactieproces en gebieden voor verbetering vast te stellen. Werk het incidentresponsplan (IRP) en de beveiligingscontroles bij op basis van de lessen die u van het incident leert.

De benodigde communicatie verzenden

Implementeer een communicatieplan om gebruikers op de hoogte te stellen van een onderbreking en om interne belanghebbenden te informeren over het herstel en de verbeteringen. Andere personen in uw organisatie moeten op de hoogte worden gesteld van wijzigingen in de beveiligingsbasislijn van de workload om toekomstige incidenten te voorkomen.

Genereer incidentrapporten voor intern gebruik en, indien nodig, voor naleving van regelgeving of juridische doeleinden. Gebruik ook een standaardindelingsrapport (een documentsjabloon met gedefinieerde secties) dat het SOC-team gebruikt voor alle incidenten. Zorg ervoor dat aan elk incident een rapport is gekoppeld voordat u het onderzoek sluit.

Azure-facilitering

Microsoft Sentinel is een SIEM- en SOAR-oplossing. Het is één oplossing voor waarschuwingsdetectie, zichtbaarheid van bedreigingen, proactieve opsporing en reactie op bedreigingen. Zie Wat is Microsoft Sentinel? voor meer informatie.

Zorg ervoor dat de Azure-inschrijvingsportal contactgegevens van beheerders bevat, zodat beveiligingsbewerkingen rechtstreeks via een intern proces kunnen worden gewaarschuwd. Zie Instellingen voor meldingen bijwerken voor meer informatie.

Zie E-mailmeldingen configureren voor beveiligingswaarschuwingen voor meer informatie over het instellen van een aangewezen contactpunt dat Azure-incidentmeldingen ontvangt van Microsoft Defender voor cloud.

Uitlijning van de organisatie

Cloud Adoption Framework voor Azure biedt richtlijnen voor het plannen van incidentrespons en beveiligingsbewerkingen. Zie Beveiligingsbewerkingen voor meer informatie.

Verwante koppelingen

• Automatisch incidenten maken vanuit Microsoft-beveiligingswaarschuwingen
• Voer end-to-end-opsporing van bedreigingen uit met behulp van de hunts-functie
• E-mailmeldingen voor beveiligingswaarschuwingen configureren
• Overzicht van reactie op incidenten
• Gereedheid voor Microsoft Azure-incidenten
• Door incidenten navigeren en onderzoeken in Microsoft Sentinel
• Beveiligingsbeheer: reactie op incidenten
• SOAR-oplossingen in Microsoft Sentinel
• Training: Inleiding tot azure-incidentgereedheid
• Instellingen voor Azure Portal-meldingen bijwerken
• Wat is een SOC?
• Wat is Microsoft Sentinel?

Controlelijst voor beveiliging

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor beveiliging