Azure Security pt 7. – Log Analytics Query’s
Log Analytics is een Azure applicatie waarmee je logboekquery's kunt bewerken en uit kunt voeren op basis van gegevens die zijn verzameld door Azure Monitor-logboeken. Deze Log Analytics query’s helpen om resultaten interactief te analyseren. Daarnaast kunnen Log Analytics-query's gebruikt worden om specifieke criteria te achterhalen, trends te identificeren, patronen te analyseren en om een breder inzicht in de gegevens te verkrijgen. Log Analytics is een zeer krachtige tool omdat Azure ontzettend veel informatie verzamelt in de Azure Monitor-logboeken en jij als gebruiker hier via Log Analytics gemakkelijk belangrijke data uit kunt filteren. Uiteraard komt Log Analytics met een groot scala aan voor- gedefinieerde query’s. Maar, laten we eerst eens kijken naar de interface Log Analyics.
Log Analytics Interface?
Azure Log Analytics is te benaderen via: https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.OperationalInsights%2Fworkspaces(externe link)
De interface ziet er als volgt uit:
Uiteraard kan met het pijltje het linkermenu uitgeklapt worden:
Globaal bestaat de interface uit 3 belangrijke onderdelen:
- Menubalk – Via het menu heb je als gebruiker de mogelijkheid om query’s te draaien, een scope voor de query te bepalen en om de query op te slaan of te exporteren.
- Dit is het query-venster. Hier type en bewerk je de query. De uitkomsten van deze query zijn onder in het lege vak te bekijken.
- Dit is het explorer menu waar je toegang hebt tot de tabellen met data, de default en opgeslagen query’s en diverse default functies. Ook kun je gedefinieerde filters maken, opslaan en terugvinden in het explorer menu.
Goed om te weten is dat je als gebruiker niet alleen losse query’s kunt maken en exporteren, maar dat je ook volledige query packs kunt maken. Deze packs zijn verzamelingen van query’s die als volledige pack geëxporteerd kunnen worden en elders weer hergebruikt kunnen worden. Deze query packs, waarvan alle default Azure query’s aanwezig zijn in het “” is te vinden onder de “Azure Query Packs” en dus niet rechtstreeks in Log Analytics.
Wanneer je weleens hebt gewerkt met Azure Data Explorer dan zal de Log Analytics interface er bekend uitzien. Dat komt doordat deze is gebouwd bovenop Azure Data Explorer en omdat hier ook dezelfde Kusto-querytaal wordt gebruikt.
Log Analytics voegt functies uit die specifiek zijn voor Azure Monitor. Zoals het filteren op tijdsbereik en de mogelijkheid om meteen een waarschuwingsregel (alert rule) te maken op basis van een query. De webinterface van Azure Data Explorer werkt voornamelijk met tabellen in Azure Data Explorer-databases. Log Analytics werkt met tabellen in een Log Analytics-werkruimte.
Wanneer logboeken en gegevens verzameld worden dan worden de gegevens opgeslagen in een werkruimte. Een werkruimte heeft een unieke werkruimte-id en resource-id. Bij kleine omgevingen wordt soms voor alle data eenzelfde werkruimte gebruikt. Bij grotere omgevingen zijn er vaak meerdere werkruimten waarin verschillende soorten data verzameld worden. Elke werkruimte heeft een ander gebruik en dus ook een eigen factuurregel zodat het gemakkelijker is om kosten te splitsen over b.v. verschillende afdelingen of gebruikers.
In deze post werken we in een demo werkruimte met demo data.
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.