Azure Security pt 7. – Log Analytics Query’s

Log Analytics Query’s

Feit is dus dat er diverse data aanwezig is binnen een log analytics werkruimte en dat we die data inzichtelijk willen maken. Laten we eens gaan kijken hoe dit eruit ziet met een standaard query.

Laten we als voorbeeld eens nemen dat we willen weten hoe de laatste Windows updateronde gegaan is op de Azure VM’s. Deze informatie is voorhanden binnen de werkruimte want we beschikken over de 'Update Management' tabellen:

Het volgende wat we kunnen doen is bij de queries zoeken naar een query om de missende updates inzichtelijk te maken. We vinden hier de 'Computer with missing updates' query. Wanneer we hierop dubbelklikken wordt de voor gedefinieerde query ingevuld in het query veld:

En wanneer we op 'Run' klikken om de query te draaien dan zien we de uitkomsten in het result venster:

Wanneer de resultaten compact genoeg zijn om in een grafiek te tonen dan kun je op het 'Chart' tab klikken op het result pane om een chart van de resultaten te bekijken. In dit geval is het maken van een chart met de huidige data onmogelijk.

We kunnen de uitkomsten exporteren naar een CSV en naar PowerBI (wanneer deze in gebruik is).

De 'Format query' button maakt de query beter leesbaar:

En wanneer we klikken op 'New alert rule' dan kunnen we meteen op basis van deze query een nieuwe alert rule instellen.

Erg krachtig dus. Laten we eens kijken naar een wat simpelere query. We kiezen voor 'Applications – Failed Operations'. Deze resultaten zijn compact genoeg om in een chart te tonen:

Maar hoe zijn deze query’s opgebouwd?

Azure Log Analytics Query

Zoals al gezegd worden query’s geschreven in de 'Kusto Query Language (KQL)'. Kusto Query Language is een krachtig querytaal om uw gegevens te verkennen, patronen te ontdekken en om anomalies te identificeren. Een KQL query maakt gebruik van schema-entiteiten die zijn georganiseerd in een hiërarchie welke vergelijkbaar zijn met die van SQL: databases, tabellen en kolommen. Een Kusto-query is een read-only verzoek om gegevens te verwerken en resultaten te retourneren. De resultaten worden in plain-tekst geretourneerd, met behulp van een gegevensstroommodel welke gemakkelijk te lezen, te schrijven en te automatiseren is. Kusto-query's worden gemaakt van een of meer query-statements. Er zijn drie soorten query-statements:

• Een 'tabular expression statement'
• Een 'let statement'
• Een 'set statement'

De meest voorkomende soort query-instructie is een tabular-expression-statement. Dit betekent dat zowel de invoer als de uitvoer bestaat uit tabellen of gegevenssets in tabelvorm. Deze tabular statements kunnen nul of meerdere operators bevatten die allemaal beginnen met een invoer in tabelvorm en vervolgens de uitvoer ook in tabelvorm retourneren. Operators worden gesequenced door een | (pipe). Gegevens stromen, of worden doorgesluisd, van de ene operator naar de volgende. De gegevens worden bij elke stap gefilterd of gemanipuleerd en vervolgens ingevoerd in de volgende stap. Dit werkt als een trechter (funnel). Je begint met een hele gegevenstabel en iedere keer dat de gegevens door een andere operator gaan worden ze gefilterd, herschikt of samengevat. Zodat uiteindelijk het gewenste eindresultaat overblijft. Omdat het doorsturen van informatie van de ene operator naar de andere sequentieel is, is de volgorde van de queryoperator belangrijk en kan deze zowel de resultaten als de prestaties beïnvloeden.

Laten we eens kijken naar de eerste query, waar we de computers opvragen met missende updates:

Wat gebeurt hier?

Het eerste wat we zien is 'Update'. Dit definieert de starttabel. We halen onze brongegevens dus uit de 'Update' tabel.

Op de volgende regels zien we een pipe operator waar onze gegevens dus doorgegeven worden aan de volgende stap. Dit is een 'where' functie. We zien: 'where OSType != "Linux' and UpdateState == 'Needed' and Optional == 'false'.

We halen dus alle computers uit het resultaat waarvan het OS niet gelijk is aan Linux. We houden dus alleen de Linux machines over die een updatestatus hebben die gelijk is aan 'Needed' en waarbij niet gekeken wordt naar de optionele updates. En deze dataset wordt weer doorgegeven aan de volgende functie. Deze is: 'project TimeGenerated, Computer, Title, KBID, Classification, MSRCSeverity, PublishedDate, _ResourceId'. Deze regel bepaald het 'project' ofwel de uitkomst. We zien als resultaat dus de vermelde kolommen terug. We kunnen hier zelf naar wens kolommen bijplaatsen of afhalen.

Tenslotte bepalen we in de laatste regel waar de resultaten op gesorteerd worden. In dit geval is dat de 'TimeGenerated' kolom waarbij we de resultaten van nieuw naar oud laten zien (desk).

Zelf een Log Analytics Query schrijven

Met deze kennis kunnen we dus ook onze eigen query schrijven. Laten we hetzelfde format eens aanhouden van de vorige query, maar nu gaan we de protectionstatus ophalen van alle JBOX Windows machines op het netwerk. Hiervan willen we terugzien wat de Detection ID’s zijn samen met de ProtectionStatur en AV SignatureVersion eventueel in aanvulling met de ThreadStatusDetails. Deze query ziet er dan als volgt uit:

We kunnen een timeframe kiezen in het menu maar ook in de query zelf. Wanneer we de timeframe in de query willen plaatsen zie dit er als volgt uit:

Op deze manier kunnen we query’s uitbreiden om uiteindelijk de data te achterhalen welke voor jou relevant is.

Belangrijk om op te merken is dat Log Query’s case-sensitive zijn. Let dus goed op het gebruik van hoofdletters bij het aanroepen van tabellen en kolomnamen.