In Microsoft Sentinel,
you start by creating a Sentinel workspace and those
need a Log Analytics workspace, they write on top of them.
So this is why I recommend having a separate infrastructure Log
Analytics workspace and then one for Sentinel.
I've already created a Sentinel instance and put it on top
of the Sentinel workspace I created.
So if we go into my created Sentinel workspace,
we can see that the interface is very,
very different from the Log Analytics infrastructure interface.
We can see these heat maps, these geo images,
there are a lot of visualizations right out of the
box that you can take advantage of.
We've got events, alerts,
and what I think are particularly powerful in Sentinel is where
Sentinel can correlate events and alerts and roll them into incidents
which can make it easier to see a true story as opposed to just these
otherwise disparate events and alerts, you see.
But step one, of course, is we want to connect our data.
So if we go under Configuration, Data connectors,
I want you to see here that there is an enormous library of these
and these go to Azure and non‑Azure services.
We can bring in, for example,
Azure Active Directory to take a look at sign‑in behavior as you can see,
Azure Active Directory identity protection.
We can even bring in Microsoft Defender services is no surprise,
I'm sure, Defender for Cloud, Defender for Endpoint,
for Identity, and we can surface all of that data in one spot here in Sentinel.
Now there are some other assets.
We don't really need to go much deeper here,
by the way, on Sentinel, it's just a question of understanding basic use case,
basic setup behavior.
When we load in a connector, Workbooks, which again,
are Microsoft curated visualizations, queries,
those are Kusto queries,
we use Kusto here just as we do in Log Analytics infrastructure monitoring,
and then we have rules templates for creating alert rules.
Now lastly, you can get to third‑party services here as well.
It's not just Microsoft and not just Azure.
For example,
notice that you can monitor Amazon Web Services to get your CloudTrail logs,
as well as looking at the simple storage service specifically.
Nice.
So once you get your data connectors in,
then it's a question of going through some of the other threat management,
content management options and working with Sentinel from there.
Let's finish this consideration by revisiting Microsoft Defender for Cloud.
Remember that the idea here is that this is general purpose security hygiene,
not necessarily just for InfoSec professionals.
We have this security posture that we can click into where we
can see the secure score that our currently deployed
infrastructure meets with Defender for Cloud,
and we'll be given a number of recommendations to
improve the security of our environment.
Let's take a look at my Azure subscription which has
a current secure score of 54%.
What you'll find on these recommendations is that they are
written in a nice user‑friendly way.
MFA should be enabled on accounts with owner permissions.
Well that sounds pretty important.
It shows us the unhealthy resources, in this case,
it's my subscription, and then it gives us an enumeration,
in this case, of the affected user accounts.
And you'll also, depending upon the recommendation,
you could either have Azure remediate itself, or if it can't do that,
which in this case it can't,
you get manual remediation steps here or you and your
developers can create a playbook,
basically a logic app that does this operation, and then
when this recommendation comes up,
the person resolving the recommendation can trigger that logic app
from here to auto remediate those recommendations.
A lot to think about, but hopefully I've inspired you and got you thinking of different possibilities.