Microsoft Sentinel.
Now, one of my goals, it's a self‑stated goal, but it's a goal nonetheless,
is to make sure that you're not only well prepared for your AZ‑801 exam,
but you're also well prepared to discuss Azure in all of its glory and
with all of its warts accurately and intelligently.
Let's take a look again at the recurring concept of Azure product
naming. Now, what's now called Microsoft Sentinel was originally
called Azure Sentinel, all right. So if you sometimes see a
reference to Azure Sentinel,
just substitute in your mind Microsoft Sentinel. And the reason why
Microsoft did that makes a lot of sense. Sentinel is meant to be a
multi‑cloud hybrid cloud security solution, and Azure Sentinel might
lead one to mistakenly believe that you can only use Sentinel in
Azure, and that's not true.
It's a Microsoft technology, so it's called Microsoft Sentinel.
Similarly, the Microsoft Azure hybrid cloud security hygiene tool,
Azure Security Center, went through a number of name changes,
Azure Defender and then Microsoft Defender.
So if you're wondering, well, what's the difference between
Azure Security Center and Azure Sentinel,
hang on. That's one of my goals.
Again, by the end of this lesson,
you'll understand the differentiation very clearly. For here, I'm
just giving you a heads up on these name changes.
Now we'll see that both Microsoft Sentinel and Microsoft Defender rely upon
Azure Log Analytics for log ingestion and querying, etc. Now that collection,
Log Analytics and its related services, at one time originally was called
Operations Management Suite, or OMS. Now it's called Azure Log Analytics with
its various management solutions. And for Windows Server, you'll want to install
the Microsoft Monitoring Agent, also called the Log Analytics agent, originally
called the OMS agent,
to onboard those Windows Server machines into your Log Analytics workspace. Yes,
it's confusing, and yes, it's annoying, but because it's a fact of life,
it's important that you, as a hybrid cloud Windows Server
administrator, know about these so that you can instantly
understand what's being talked about,
whether it's on your AZ‑801 exam or whether it's a blog article or a Stack
Overflow question and answer set that you're examining.
I want to make sure that you're equipped for success.
Let's look at a definition here.
SIEM/SOAR or SIEM/SOAR.
Doesn't matter to me so much what the pronunciation is.
You should know what the acronym means from a definitional standpoint.
Security information and event management, that's SIEM. Security
orchestration, automation, and response, that's SOAR.
This is a unified security solution that has as its
audience InfoSec professionals.
Not just ordinary systems administrators,
developers, and architects, but really full‑time InfoSec team members.
Examples of SIEM/SOAR products include Splunk Enterprise Security, SolarWinds
Security Event Manager, OSSEC, and we're going to see momentarily that
Microsoft Sentinel is Microsoft's SIEM/SOAR solution.
In fact, we're going to see something momentarily
just turned into now. As I said,
Microsoft Sentinel was formally called Azure Sentinel.
It's a SIEM/SOAR solution that supports all environments.
This, again, is why the name was changed to
Microsoft rather than Azure Sentinel.
So you can support cloud‑native deployments in Azure, hybrid cloud,
which means that you can touch your on‑premises infrastructure, as well
as your infrastructure that's located in other clouds.
As I said,
a key differentiator for Microsoft Sentinel is that its toolset is really
intended for dedicated information security personnel.
We're going to see in the demo that the Sentinel platform is heavily extensible.
It uses a connector model where as long as you have a connector
that provides connectivity into a given service,
you can monitor and alert and do threat hunting and all that good stuff
from within one control plane in Sentinel. As I mentioned,
there's tight integration with other Azure services.
You'll need an Azure Log Analytics workspace, for example,
to deploy Microsoft Sentinel. But then we have native integration with
other Azure Resource Manager services like Azure Monitor and Azure Logic
Apps, which are called playbooks in Sentinel.
Here's a lucid chart diagram I've created to help illustrate
some of Microsoft Sentinel's value propositions. Up at the
top of the diagram, as I said,
we've got a one‑to‑one dependency between your Sentinel instance and
your Log Analytics workspace. I would suggest, as I always do, that
you have separate workspaces for your infrastructure monitoring and
your security monitoring.
You can, in fact, configure Windows machines to report to more than one
Log Analytics workspace, so you're not limited there.
And as you can see here, we can tap in, or enroll, our Azure VMs,
both Windows, as well as Linux, into Microsoft Sentinel.
We can touch other clouds, like ingesting Amazon Web Service's CloudTrail logs,
monitoring Amazon EC2 virtual machines.
And then lastly, for your on‑premises data center,
you can monitor physical and virtual servers, as well as
Arc‑enabled servers if you've decided to already enroll certain servers into Azure Arc.