The general Microsoft Sentinel setup workflow works like this. You'll
want the Log Analytics workspace in place. Then you'll lay in an
instance of the Microsoft Sentinel service.
Once you've got it up and running, it's then time
to wire up your data collectors.
These are going to be your data sources.
You then can set up watch lists, you can use the Kusto Query
Language to do threat hunting, and you can create automations,
what are called playbook automation.
As a matter of fact, I forgot to explain the holistic nature of Sentinel.
I want to come back temporarily to this slide, but I want to
draw your attention to the right side where I provide an
attribution to the source at microsoft.com.
This is a great marketing diagram.
It is outdated inasmuch as it says Azure Sentinel, but those four pillars
of the service are just as relevant today as they were when Microsoft
released this. So let's go in a clockwise fashion,
starting at the 12 o'clock position.
As I said, the data collection is pretty universal.
So the value prop is that instead of having a patchwork of
different security monitoring solutions,
you may be able to do everything all under one roof, as it were, with
Microsoft Sentinel. The detection means that you're able to tap into
Microsoft's Intelligent Security Graph, as well as any AI or capabilities
that are coming from your data sources themselves to give you and your team a
proactive heads up on anomalous behavior,
active threat events,
whatever, vulnerabilities that may exist in software on some of your machines,
etc. Investigate, at the 6 o'clock position, means that Sentinel
works with Jupyter Notebooks, if you're familiar with those. These
are specialized web pages that integrate a runtime environment with
Markdown so that you and your teammates can actually assign events
and assign tasks.
It's basically a ticketing work item system built into Sentinel. It's
really an all under one roof kind of situation here.
And the Jupyter Notebooks are great because, as I said,
you can blend live source code investigation where you can run
the code in the context of the notebook and then keep your
documentation using Markdown syntax in there as well, and then
use those notebooks as a vehicle,
as a deliverable, for your reports and presentations and so on.
And then lastly, in the 9 o'clock position, the concept of the playbook. If
you're not familiar with Azure Logic Apps, they're using the same engine as
what was called Microsoft Flow and is now called Power Automate, where you
can stitch together various APIs, REST APIs, in an event‑driven way such
that you can configure a playbook that when a certain alert is triggered or
when a certain KQL query, a threat hunting query, that you have configured
to run on a loop triggers, the playbook/Azure Logic App is then kicked into
action, and it can do a number of different things.
I mean you could have events get posted into your Microsoft Teams channel
or your Slack channel. You can trigger code to run.
You can create a ticket.
You know, it allows you to, again, create these business workflows for automated response.