Het incidentbeoordelingsproces

Een belangrijk onderdeel van een incidentbeoordeling is de constructie van een gedeelde, nauwkeurige chronologie die de niet-lineaire aard van een incident weerspiegelt.

Door niet-lineair te bedoelen, bedoelen we dat incidenten bijna nooit alleen maar "dit ding gebeurt, en dan gebeurde dat, toen merkten we het op, toen deden we iets, en dan zijn we klaar." Mensen komen binnen en buiten, verschillende mensen merken dingen op en proberen verschillende dingen uit; sommige werken, andere niet. En als meerdere mensen tegelijkertijd werken, kunnen deze dingen ook tegelijkertijd gebeuren, dus het is iets ingewikkelder.

Als u een dergelijke tijdlijn wilt maken, zelfs een complexe, is er altijd een belangrijke eerste stap: de gegevens verzamelen.

De gegevens verzamelen

Voordat u een incidentbeoordeling kunt uitvoeren, moet u eerst gegevens verzamelen. In het bijzonder moet u zoveel mogelijk gesprekken en context (zowel technisch als niet-technisch) rondom de gebeurtenis verzamelen, zodat u alle cruciale gegevens in de gebeurtenis kunt gebruiken. Het gesprek dat tussen teamleden plaatsvond tijdens de storing of het incident, zal een van uw meest uitgebreide informatiebronnen zijn.

U zou ook gegevens moeten verzamelen van uw bewakingssysteem en andere bronnen waar de betrokken personen context uit hebben gehaald. Welke informatie kregen ze van uw systemen toen het incident aan de gang was?

En ten slotte zou het nuttig zijn om, indien mogelijk, een beter beeld te krijgen van wat er net vóór en tijdens het incident is gewijzigd, omdat wijzigingen vaak factoren bijdragen wanneer een incident optreedt.

We kunnen dit proces als drie afzonderlijke onderdelen bekijken:

• Verzamel het gesprek: In andere modules in dit leertraject hebben we vermeld dat het belangrijk is om een specifieke plek te maken waar mensen tijdens een incident kunnen communiceren. Tijdens het incident delen mensen idealiter wat heeft gewerkt en wat is mislukt, wat ze aarzelen om te proberen, wat ze in het verleden hebben geprobeerd. Dit gesprek tussen mensen tijdens het doorlopen en oplossen van het probleem is uw beste bron van leren.
• Bepaal de context: de personen in een incident ontvangen signalen van verschillende plaatsen. Eén primaire plaats is uw bewakingssysteem. We hebben het belang besproken van een solide bewakingssysteem in een eerdere module in dit leertraject. In het ideale geval moeten we het bewakingssysteem kunnen bekijken om een momentopname van een bepaald tijdstip te maken voor de periode rond of gerelateerd aan het incident.
• Zoek de wijzigingen: U kunt dit doen via activiteiten- en auditlogboeken.

Azure-hulpprogramma's om de gegevens te verzamelen

Azure biedt een aantal hulpprogramma's die u kunnen helpen bij dit proces:

Azure DevOps voor het bewaren van metagegevens over het incident

In een vorige module in dit leertraject hebben we het gehad over het gebruik van Azure Boards in de Azure DevOps-suite als één plek om alle informatie over een incident te verzamelen dat begint met het eerste antwoord. Het helpt ons met vragen over wanneer een incident voor het eerst werd gedeclareerd, wie er op oproep was, wie aan het incident was toegewezen, enzovoort. U kunt de Azure DevOps-wiki ook gebruiken als gecentraliseerde manier om een deel van de informatie op te halen over zowel het incident zelf als het gesprek dat is opgetreden tijdens het incident.

Microsoft Graph API voor het extraheren van het gesprek

Microsoft Graph API biedt een programmatische manier om het gesprek te vinden, te exporteren en binnen te brengen dat is verzameld in het Teams-kanaal dat is gewijd aan dit specifieke incident. De opgehaalde gegevens bevatten ook metagegevens die nuttig zijn bij het samenstellen van een chronologie, waaronder wie deelneemt aan het kanaal (en wanneer) en tijdstempels voor afzonderlijke delen van het gesprek.

Een eenvoudige manier om aan de slag te gaan met Microsoft Graph API is het gebruik van Microsoft Graph Explorer. Microsoft Graph Explorer is een webgebaseerde API-browser waarmee u de API-aanroepen kunt kiezen door vooraf ingevulde opties te kiezen. Dit ziet er als volgt uit:

We doorlopen een reeks API-aanroepen van 'Microsoft Teams' en 'Microsoft Teams (bèta)' om het gesprek op te halen. Bij elke stap kiezen we een query, voeren we de query uit en selecteren we de informatie in het antwoord dat ons helpt bij de volgende stap. Vervolgens gebruiken we deze informatie om de volgende aanvraag te maken. We voeren bijvoorbeeld eerst een query uit op een lijst met team-id's om de teams weer te geven waarvan we deel uitmaken. We kiezen het antwoord dat we nodig hebben en voegen deze id in de volgende query-URL in om een lijst met kanalen in dat team op te halen.

Dit zijn onze stappen:

1. HAAL 'mijn gekoppelde teams' op (om de team-id te vinden van het team dat we gebruiken).
2. GET "kanalen van een team waarvan ik lid ben" (om de kanaal-id te vinden van het kanaal dat we voor dat incident hebben gebruikt).
3. GET 'berichten in een kanaal' (om het gesprek op te halen).

Als we later een programma willen maken om elk van deze stappen uit te voeren (en inderdaad doen), is er een optie voor codefragmenten in het aanvraagvenster met voorbeeldcode voor die query in een aantal verschillende programmeertalen.

Doeldashboards voor contextweergave

Met dashboards in Azure kunnen we de informatie verzamelen van Azure Monitor die voor ons belangrijk is voor operationele kennis op één pagina. Met de gebruikersinterface kunnen we de weergegeven tijdsperiode kiezen, dus het is mogelijk om 'terugspoelen tijd' weer te geven en de dashboardgegevens weer te geven voor de periode die is gekoppeld aan een incident als we dit kiezen (mits de informatie niet te oud is om niet langer te worden bewaard in Azure Monitor). Deze gereconstrueerde gebruikersinterface kan nuttig zijn bij het bepalen wat de personen in een incident tijdens dat incident hebben gezien, maar de persoon die de incidentbeoordeling uitvoert, moet handmatig naar de juiste periode zoeken.

Een functie van dashboards in Azure die vaak over het hoofd worden gezien, is de mogelijkheid om een sjabloon te dumpen van een dashboard dat wordt weergegeven in een JSON-bestand met behulp van de knop Downloaden (pijl-omlaag) en om ze weer te laden met de knop Uploaden (pijl-omhoog). Dit betekent dat we handmatig naar het juiste moment kunnen zoeken, het dashboard in die status kunnen downloaden en het JSON-bestand met anderen kunnen delen, of gewoon het huidige dashboard kunnen downloaden en de JSON kunnen wijzigen in onze specificatie. Als u zoekt naar de tekenreeks 'tijd' in een gedownload JSON-dashboardbestand, ziet u een sectie die er als volgt uitziet:

"metadata": {
  "model": {
    "timeRange": {
      "value": {
        "relative": {
          "duration": 24,
          "timeUnit": 1
        }
      },
      "type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
    },
    "filterLocale": {
      "value": "en-us"
    },
    "filters": {
      "value": {
        "MsPortalFx_TimeRange": {
          "model": {
            "format": "utc",
            "granularity": "auto",
            "relative": "24h"
          },
          "displayCache": {
            "name": "UTC Time",
            "value": "Past 24 hours"
          },

Wijzig deze sectie in uw specificatie en laad opnieuw. Als u niet bekend bent met de indeling die wordt gebruikt, kunt u het dashboard handmatig wijzigen, downloaden en de vereiste indeling bekijken.

Auditlogboeken en Log Analytics voor wijzigingsverkenning

Een Log Analytics-werkruimte kan gegevens uit veel bronnen opnemen, waaronder het Azure-activiteitenlogboek. Maak eerst een nieuwe Log Analytics-werkruimte. Ga vervolgens naar de functie Activiteitenlogboek in de portal en kies Diagnostische instellingen. Dit biedt de optie om het activiteitenlogboek voor een Azure-abonnement naar uw nieuwe werkruimte te verzenden.

In korte tijd kunt u alle kracht van de Kusto Query Language (KQL) gebruiken om gedetailleerde informatie op te halen over wijzigingen die in dat abonnement hebben plaatsgevonden sinds u de gegevensbron hebt verbonden.

In de volgende query ziet u bijvoorbeeld informatie over resources die zijn gewijzigd of zijn verwijderd. We kunnen het tijdsbereik voor de query in de queryverkenner instellen om nauwkeuriger in te gaan op de tijd kort vóór het incident, indien gewenst.

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first

Een korte opmerking: wanneer u het Azure-activiteitenlogboek instelt als een gegevensbron, begint de informatie vanaf dat moment naar de Log Analytics-werkruimte te stromen. U kunt die werkruimte niet met terugwerkende kracht opvragen voor gebeurtenissen die plaatsvonden voordat u verbinding maakte.

Deze hulpprogramma's moeten u een goed begin kunnen geven met het verzamelen van informatie die nodig is voor een chronologische beoordeling in een incidentbeoordeling. Voordat u meteen een beoordeling van het incident ingaat, willen we u waarschuwen voor enkele veelvoorkomende valkuilen. Dat is het onderwerp van onze volgende eenheid.