What's Microsoft Defender for Endpoint?
Well, like I mentioned,
it's an intelligent security graph‑powered threat
vulnerability management client.
Wow, that's a mouthful.
Say that three times quickly.
Some nice things to know about Defender for Endpoint or Microsoft Defender,
is that it's a really nice unified application,
it's available for Windows, Linux, macOS,
Android, and iOS, so it has great reach as far as cross‑platform use.
And because Microsoft Defender for Endpoint is cloud‑based,
you have centralized web portal API access.
The Client UI in Windows is, again,
going to be through that Security Settings app.
When you have an Azure subscription and you're using Microsoft
Defender for Cloud and you turn on Defender for Servers,
paying for Defender for Servers grants you license for
defender for endpoint so that's a way around having a separate
license for those protected machines, and again,
remember,
I know I just mentioned this in passing that Microsoft
Defender for Cloud works hybrid cloud so you don't have to
just limit that protection to Azure VMs,
but you can also come on‑premises or to other clouds as well.
And lastly,
another advantage of using a cloud‑based cross‑platform solution like
Defender is that it has native integration with all the other Microsoft
Cloud Services like Microsoft Sentinel, Intune,
and the other defenders.
What is Windows Defender Credential Guard.
Now, did I make a typo here by saying Windows rather than Microsoft?
No, actually because Credential Guard is a client‑side application.
It's meant to protect credentials,
specifically password hashes and Kerberos tickets for currently
logged‑on users that would normally be available in memory and
could be snatched by a rogue process.
You might be familiar with pass the hash or past the ticket attacks.
How can you better protect those credentials when they're
in working memory on a Windows system?
Well, that's what Credential Guard is all about.
And as I said before, because it's protection is based on Hyper‑V virtualization,
you're going to have to have a pretty current motherboard on your
servers in order to implement Credential Guard.
You're going to need UEFI firmware,
you're going to need a trusted platform module chip.
You'll also need to do Secure Boot as well.
There is a PowerShell script that I reference in the
exercise files if you want to look into it.
It's a hardware readiness tool script that gives you a nice
report on what aspects of your system may not yet be
compatible with Credential Guard, so that's something to use in your environment.
As far as managing and setting up Credential Guard,
you can do that with Group Policy, or if you have an Intune subscription,
Microsoft Intune is a cloud‑based mobile device
management and endpoint management solution.
You can set up Credential Guard there as well.
Lastly, we have SmartScreen.
What is SmartScreen?
Well, SmartScreen is, again, a client‑side tool,
but this one does talk to the cloud quite a bit.
Microsoft describes it as reputation‑based protection
against malicious websites and applications.
So this is a built‑in capability on Windows Server and Windows Client
that can help protect users against phishing attempts,
software that may be suspect in some degree or another,
particularly nowadays if software is not digitally signed,
that would normally trigger the SmartScreen filter to come into
action and prevent execution of that code.
Now there is Microsoft curated filter list.
Now to protect customers against malicious users,
Microsoft doesn't publish the algorithms that SmartScreen uses to determine
what is a suspected malicious website or application.
They do that intentionally because they don't want
to leak any info to bad actors.
We as hybrid cloud administrators can manage the behavior of the filter though,
again, using either Group Policy and/or Microsoft Intune.
Group Policy based OS security.
Yeah, so this is kicking it old school.
If you've been a Window systems administrator for a while,
you know that in terms of basic Windows Server,
and I dare say even Windows Client Security,
we're talking about account policies and local policies,
and in Group Policy for account policies you have
stuff like your password policy, your account lockout policy,
and the password policy, in particular,
has undergone quite a sea change over the last few years.
Whereas in the earlier time in my career,
it was recommended that we force users to change passwords more often.
Of course that leads to weaker passwords because you wind up with password1,
password2, password3.
Account lockouts is not so much about inconveniencing users,
although it can, it's more about inconveniencing bad actors.
If somebody is attempting brute force attacks
against your account on your system, on your server or your client machine,
the lockout policy is going to dramatically slow them down
because after every X number of failed attempts,
they have to wait Y minutes for the account to be activated again.
The idea, of course,
is that we want to discourage the attacker so that they either lose
interest or lose patience or both and move on.
On the local policy side, this is where you've got your audit policy,
you can see successful and failed access attempts,
user rights assignment,
which is a core component of your built‑in local and Active Directory groups,
and then we have our various what are called security options, kind of a catch‑all bucket in Windows.