So in the last module we talked about how administrative templates policy can help with locked down
of the user environment.
The desktop environment.
In this module, I'm going to shift gears and talk a little bit about how security policy can help with
sort of lock down of the system itself.
So let's dig in and see what that's all about.
Security policy is really not one thing.
It's composed of a lot of different policy areas under computer configuration backslash policies.
Backslash Windows settings.
Backslash security settings.
There are a few settings under user configuration in this same path, but by and large, the majority
of security policy is configured on computers rather than on users.
And there's a lot of stuff you can do with security policies.
So, for example, account password and lockout policy, this can be set for the domain or for local
user accounts on workstations and servers.
Audit Policy Configuring Basic Auditing.
What is audited on a particular Windows system.
User Rights Assignment.
Who can do what on a system?
So who can log on locally?
Who can log on from the network?
Who can perform certain tasks?
This is all control through user rights assignment security options.
I like to call these the kind of the vulnerability switches.
So various default behaviors in terms of the Windows security subsystem and how it behaves, things
like user account control, whether you have full prompts or minimal prompts, etc., that can all be
configured through security options.
Event log size and retention configurations.
So how big should the event logs grow and what happens when they fill up?
Restricted groups.
I'm going to demo this in a little bit, but this is a feature that lets you control local group membership
on Windows servers and desktops, systems, service security and start up so you can control who can
modify the configuration of a Windows service on a system and what the default startup behavior should
be.
Should it be running automatic?
Should it be running disabled?
Those kinds of features, registry and file system permissions.
So you can actually set the permissions on registry keys and files in the file system using group policy.
And this can be very powerful.
You can make mass changes to file system security using group policy wired and wireless network security.
So whether you're on a wired network using 802.1 X authentication or on a wireless network that requires
specific passwords for SSIDs and different authentication schemes, you can set options for those within
this area, Windows Firewall and IP set configuration.
So Windows Firewall is probably one of the more common security policy areas in group policy.
And this allows you to do very fine grained control over the rules for inbound and outbound traffic
on workstations and servers.
Pcci or public key infrastructure policy lets you set behavior for certificate usage on workstations
and servers.
Ad blocker.
This is another feature I'm going to go into in a little bit.
App blocker lets you control which applications can execute on a system.
You have really fine grained control over what code runs on a particular workstation or server, and
this can be really beneficial in terms of controlling malware.
Network access protection and network list configuration.
So network access protection or an app can be configured.
The Microsoft NAP solution can be configured through group policy as can network lists, which are essentially
the things that the user sees when they're browsing their network and then advanced audit configuration.
This is the kind of a follow on capability from the basic audit policy that allows you to set subcategories
of auditing at a more granular level.
So lots of power here in terms of what you can do with security policy.
So let's talk about some tips for deploying security policy.
By and large, most security policy will tattoo a system.
So unlike administrative templates, when you apply a particular security setting, let's say it's file
system security or registry permissions.
And you remove the policy that deployed, that the permissions are not going away.
They're staying on the system.
And this really makes sense because you don't necessarily know what the previous state of some security
settings are unless it's somehow kept or recorded.
So most security policy will tattoo a system, and then by and large, most security policy will not
merge settings from different GPOs.
So as an example of this, if I have restricted groups policy that's controlling the local administrators
group and I have that defined in a GPO linked at the domain level and then I define at an EU level a
restricted groups policy that setting the local administrators membership and then defining different
groups in that.
The result that the computer at that OAU level sees is not the amalgam of both of those, but really
going back to our LSW processing order, last writer wins.
So whatever settings are defined in restricted groups at the EU level will be the ones that win account
policy.
So password lockout Kerberos must be defined on a GPO linked at the domain level in order for it to
affect ID accounts.
This is a long misunderstood concept within group policy.
In group policy, there is only one way to set domain user account policy.
In other words, password.
Minimum length password.
How long a password lasts?
90 days, 30 days, whatever.
Whether a password is locked out after a certain number of unsuccessful attempts.
All of that can be or must be defined at the domain level in order for it to affect a user's accounts,
user accounts.
Now, you can define account policies at lower levels in the hierarchy, but it's only going to effect
local user accounts on those machines that process, that policy.
So it's not for domain accounts at that level.
Now, Microsoft did introduce this thing called fine grained password policy, which is completely outside
of the realm of group policy that lets you set more granular account policy on a pro-EU or poor security
group level.
This has absolutely nothing to do with what I'm talking about here with domain account policy.
There can be only in the group policy world.
There can be only one account policy defined for a given domain, and it has to be in a GPL linked at
the domain level.
And just for the sake of discussion, what I typically recommend is the default domain policy, which
is one of the two default policies that Microsoft ships in and is a good place to put account policy,
password, policy, lockout, etc..
I would also say that you should consider applying different security locked down from servers to desktops.
The requirements are often very different.
And I think it's important to keep them separate so that you have dedicated GPOs settings, security
on desktops and dedicated GPOs setting security on servers.
And then finally, kind of harkening back to my best practices for admin template deployment.
I recommend layering security into GPOs.
So you have a base OS hardening GPO, so to speak, that does the base OS hardening security for things
like who can log on and what the basic permissions are on a particular system.
And then you layer on additional security hardening for whatever workloads or applications are running
on those systems.
So if you have a server that's running IIS, it has additional hardening that you might want to do specific
to IaaS.
And that would be implemented in an IRS hardening GPO that's applied separate from the base OS.
And that way you can reuse the base OS security for many different servers and then layer on whatever
that role the server plays.