Microsoft
Cyber Campfire Necessities: Part 2
Did you hear that? Yes, this is BlueVoyant’s second blog in our campfire blog series. Today, we are investigating logs that go bump in the night and other noisy things in your Sentinel.
If you missed Cyber Campfire Necessities: Part 1, we started with the most important things, like how to construct our s’mores and queries and not overcook our marshmallows. Whether you’re just toasting your first query or a seasoned Sentinel Ninja, let’s listen for crashes, bangs, and booms to see if we can identify what went “bump” in your ingestion.
Ghostly or Ghastly?
Every Sentinel environment has its ‘loud’ ghosts or ghouls, or maybe even a log poltergeist! How noisy can a Sentinel table be? Get your P.K.E. Meter spun up and let's go noise hunting…
=====================================================================
AzureDiagnostics
| where TimeGenerated > ago(7d)
| summarize count() by bin(TimeGenerated,1d)
| render columnchart
=====================================================================
How “does” our equipment detect noisy specters?
=====================================================================
AzureDiagnostics //<--Define the table to query
| where TimeGenerated > ago(7d) //<-- how far back the query will look in the Usage table.
| summarize count() by bin(TimeGenerated,1d) //<--Return count per day
| render columnchart //<--Graph a column chart
=====================================================================
Campfire Tip:
By changing Line 1, you can run the query against different types of ghouls (tables) without re-writing the entire query
The output of this query shows that the AzureDiagnostics logsource stopped sending logs, time to convey this story to the administrator of abhorritions!
Summary
Bumps should be accounted for--whether they go in the night or during the day, really. Some basic KQL syntax made the difference between ghostly and ghastly! . Whether you find any ghosts around the campfire is up to your query skills :D
In this post, we broke down the KQL s’more as follows:
Defining table to query against (think of it like the top graham cracker)
Defining time period (Hershey’s milk chocolate, of course)
Summarizing the number of hits to this table by day (gotta get the chocolate to marshmallow ratio just right for it to make sense, you know?)
Rendering output to a column chart (give it context, the bottom graham cracker)
