Implementing application security.
If you've paid attention to any of my CBT Nuggets series,
you probably know that at least one Nugget in every
series is the one that I just tend to label Miscellaneous.
There just seems to be one objective in a lot of these
certification-related series.
Or if I'm crafting a story line to help you understand
the new technology, we always seem to get one of these
Nuggets that you just sort of pack all the
little stuff into.
I don't think Microsoft was thinking that whenever they
created this objective domain called Application Security.
But what actually resulted was a whole bunch of random stuff
they got puddled into this one objective domain.
Because I tend to follow the objective domains with the
titles of these Nuggets, well, you'll find that we are going
to talk about the variety of objectives that exist here.
Some of these objectives are things that you
may never turn on.
One in particular is an objective that I have no idea
why we're still being tested on.
Because even though it's still pretends to Windows, even now
Windows 8, Windows 7, there is another technology that has
almost superseded it in a lot of ways.
That is the difference between AppLocker and our software
restriction policies down here, these first two.
SRPs have been around for a really long time.
They kind of sunsetted around, I believe, either the Vista or
Windows 7 days.
I think it was Windows 7, actually.
If you're on Windows 7, then we got this brand new, awesome
thing called AppLocker, which was sort of SRPs plus plus.
And then SRPs stuck around, so that you could still manage
your downlevel clients like 2000, 2003, and XP.
SRPs actually will work with Windows 7 and even Windows 8.
But for the most part, if you're going to do application
control, AppLocker's probably the better way to go, or
honestly some third-party solution.
So I'll show both these look like.
There's not that much to know here.
I'll give you the basics of what you need to understand if
you end up implementing them.
Be very, very careful with both AppLocker and SRPs,
because a misplaced deny instead of an allow could
force your entire domain to all of a sudden just not allow
any application to run ever.
So it can get really awful if you do the wrong thing there.
Love it or hate it, User Account Control in Windows 8
is here to stay.
In fact, if you even disable User Account Control in
Windows 8, it still kind of sticks around.
So there really is no disabling of User Account
Control, although I will show you where you can tune its
behaviors just a little bit.
So if you're familiar with the slider, if you type in
msconfig into a computer-- that's msconfig--
that will expose the slider that will let you adjust how
User Account Control will work on an individual computer.
But coming up here in just a second, I'll show you how it
works with GPOs.
There's a couple of settings.
There are some DEP settings.
DEP is an oddball.
So Data Execution Prevention, it's kind of a multi-faceted
solution that works.
There's hardware pieces to it.
There's some software pieces to it.
But the idea here is that it's supposed to protect the system
from all sorts of baddies, like
malware, things like that.
Now, the DEP is turned on by default.
But there is a setting that says, OK,
ignore any custom settings.
So you have to be careful with how this thing gets set up.
And DEP, oddly enough, is not one of those things that so
you can actually manage with Group Policy.
You can manage some of the individual per application
settings, but the master toggle, the master opt-in or
opt-out is not something that is necessarily you're going to
use Group Policy to control.
I'm going to show you where the master opt-in is in
Windows Server 2012.
It's the same place in 8.
And then for Internet Explorer, I will show you how
for that application you can actually disable DEP
if you wanted to.
The only reason you would disabled DEP for an app is
because DEP itself is causing the app to fail.
There is no other reason to disable DEP other than it's
creating a problem.
And more often than not, even though you can disable it for
IE, and you can disable it also for Microsoft Office, you
just don't want to.
It's one of those things that generally just sits out of the
way and does its work without really bothering you.
The Windows Firewall advanced control is still around in
Windows 7 and Windows 8.
It provides you the ability to do some really awesome stuff
with the Windows Firewall.
Being able to configure that Windows Firewall is something
you can do in a Group Policy, as well.
Highly recommend that you turn it on.
Even if you're not a firewall person inside your LAN.
There are some ways in which you could turn it on so that
when laptops go outside the LAN, they immediately go
shields up.
And that can protect you from all manner of baddies.
And when I say baddies, I also mean the users that would not
normally turn on the firewall what they're supposed to in
all the bad places.
So in this case, the baddies could be
both users and malware.
And then lastly is this sort of out of left field addition
of Config Manager and Endpoint Protection settings.
So built into Configuration Manager is FEP, or Forefront
Endpoint Protection.
I believe it is being termed System Center Endpoint
Protection now, or SCEP.
So there are a couple of settings in Config Manager
that I'll show you.
If you've played with Windows Defender before, then you've
seen all these settings.
In fact, if you've played with any kind of anti-malware
solution at any point in the past, you've seen settings
that look very similar to these.
For some of these, again, there are ways that you can do
it individually.
But that's not really what I think they're testing you on.
It's can you control this stuff here
inside of Group Policy.
So the first two is AppLocker and
software restriction policies.
Now, SRPs, although SRPs are available for all the modern
versions of Windows and a lot of the older ones as well, if
you have Windows 7 Enterprise edition, if you have Windows
8, just use AppLocker.
It is a much superior solution.
If you don't, then you'll be stuck with software
restriction policies.
The idea with SRPs and even with AppLocker is to create
what I like to call an
environment of approved execution.
So you, the admin, you the little happy admin over here,
you determine some list, some database of the applications
by characteristic that are approved.
So thumbs up.
These are the apps that are allowed to run.
And/or, these are the apps that are not allowed to run.
And then the computer's out the world here.
So when a user attempts to execute that app, well the
AppLocker or SRP then manages the list to say, hey, by the
way, Elf Bowling, Elf Bowling.exe, we've put that on
the Do Not Launch list, Do Not Execute list.
There are commonly two different ways in which you
can implement, really either one of them, kind of sort of.
The first ways to allow everything and then to deny
the things that are bad.
That's commonly called blacklisting.
The blacklisting world is a little bit safer, because you
are allowing everything and only saying the bad things
can't actually launch once you find them.
But the hard part about that is actually
finding the bad things.
Generally by the time you locate and can characterize
that bad thing, well, it's already done
its nefarious duty.
So the opposite of blacklisting is whitelisting.
And in whitelisting, what you're doing is essentially
saying everything, all right, nothing is allowed to run
unless I say so.
You have to be on this specially approved list, this
list right here, if you're actually going to execute.
So I think in my entire career, I have seen one
environment that has successfully done that in
operations for an extended period of time.
Although that particular admin, I'm not sure if they
ever got to go on vacation.
Because every time a new application changed a version,
or changed characteristics, or they added an app, that person
needed to add it to the whitelist.
As an aside, there's a lot of third-party solutions that can
accelerate this.
But built into Windows is the ability to move globally deny
everything except for what Microsoft needs, and then once
it's globally denied, then to add back in anything that you
have yea verily approved to be acceptable in that
environment.
So here in software restriction policies, I can
set up enforcement, all software files except for
libraries, or all software files.
Very big caution here in both SRPs and also in AppLocker,
just really ignore the DLLs.
You can turn on DLL restriction using these tools.
But doing so causes all manner of performance problems across
your environment.
So it's there, but just be aware for the test, but don't
over turn it on.
So do you want to apply SRPs to users with or
without local admins?
Are you going to enforce or ignore
certificate rules, as well?
Notice down here with SRPs that certificate rules will
also negatively impact the performance of machines.
That is not quite as bad over in the AppLocker world.
So here, I can designate some file types that I want to
actually match up for the executable code, and then
identify what trusted publishers, as well.
That whether or not I want to manage the trusted publishers
list and say, OK, well if there's a certificate that
exists in that machine, go ahead and we're going to go
ahead and call that a trust publisher.
So with that, then there are a couple security levels that we
can identify here, whether it's unrestricted, or whether
the software is disallowed.
I can even set up programs that execute as a user that
does not have admin rights but still needs to access
resources, here for this basic user security level.
This is designed, again, to give you the ability to
identify how you want to tag these pieces of software.
So additional rules here that are specific to, for example,
registry keys, or for how I want to identify what pieces
of software I want to restrict.
Now, there are four-- as you can see here-- major ways in
which we can identify the apps that we want to restrict.
These are based off of characteristics, generally, of
the primary executable associated with that
application.
So if I know, for example, that Winword is going to be
found a C program files Microsoft Office winword.exe,
for example, I could put that here as the path.
The problem with a path variable is that, well, if a
person moves Winword.exe out of that path location, well,
then they're going to be able to execute it.
So I'm only really identifying a specific path and giving my
users all manner of workarounds to get away with
things if they need to.
There's a way in which I can adjust the network zones here.
You should recognized these from Internet Explorer.
So if something actually occurs in an untrusted zone,
so one of the ones I want to restrict, well then, go ahead
and set the security level to something else, like
disallowed, for example.
I can create what is called a hash rule, as well.
Now, a hash rule is different than a path rule, in that I
hash rule actually take a look at the executable.
So I go and locate the exe that I want to install here.
And let me see if I can find one that's just a basic exe.
Once I find that executable here-- here's one-- it's going
to create a hash of that exe.
That hash will then be some digital representation of the
executable file.
That can be used for restricting
that piece of software.
The nice part about hash rules is that as that exe moves
around, if it changes its path location, I'm still going to
be able to restrict it.
The hash is based off of the contents of the file itself.
And as long as the contents of that file don't change, well
then, I can move it around, and it's going to continue to
be controlled by my software restriction policy.
Now, the problem, however, with hash rules is that when
we do any kind of an update to an executable, if we patch it,
if we add an update to it, if we change the version number
on it, well then, doing so is going to automatically force
the hash to fail.
Because as soon as I patch an exe that's been hashed, I
changed the exe.
And by changing the exe, the hash is no longer going to
work with that exe.
So the last of these, which involves a lot more work, but
can be a lot better in the end, is what's called a
certificate rule.
And here with a certificate rule, you can use a
certificate that is associated with one of the applications
that you may have so that that certificate identifies that
it's signed the code, and it identifies that application.
Certificate rules and SRPs were OK, but when we move over
into the AppLocker world, certificate rules actually get
quite a bit more exciting.
So AppLocker is here under Application Control Policies.
And if I take a look at AppLocker, the reason why you
want to use this over SRPs, not the least of which, is the
fact that it's much easier to use.
So with SRPs, there's a lot of set up I have to do, and a lot
of maintenance.
I've got all these individual policies that I have to
create, arguably one for each of the applications that I'm
attempting to control.
Now with AppLocker.
what I can do is set up entire rule bases that are associated
with exes or with Windows Installer or scripts or
packaged apps.
Now, I can also turn on that enforcement for all of those
here, just based on what I'm interested in controlling.
So if I'm interested in exes, well, let's go ahead and
enforce exes.
Or even better, let's go ahead and just audit the exes that
people are in attempting to launch.
So when I turn on auditing, what I'm doing is taking a log
through the Windows Event Log of all the attempts to
actually launch an exe that's been characterized here.
And this gives me the ability to collect all these logs,
bring them into a central location, identify the exes
that I want to put it may allow list, before I end up
switching over to enforce, and potentially cause problems.
I want audit everything.
I want to know all the executables that could
potentially be on before I ever start enforcing things
and locking people out of stuff.
So this is really nice.
This is a great, new feature here of AppLocker that allows
us to accomplish that.
I can down here with packaged apps also--
This is new, actually, in Server 2012 and 8, actually
control whether or not that packaged app itself is going
to be defined, whether or not that packaged app is going to
be controlled, as well.
Comes in handy as we start moving into the packaged app
world a little bit more.
Over here, under Advanced, I can turn on DLL rule
collection.
But again, do not do this, because it will affect your
system performance.
With enforcement turned on--
and just to be cautious here, I'm going to
set it to audit only.
With enforcement turned on, one of the nifty things about
AppLocker is that you have the ability, for any of these
major four categories, to number one, create the default
rules, which define the initial experience.
So this is, in this case, the blacklisting experience, where
everything is allowed until it is not.
I'm going to allow everything.
Now, what is really awesome about this is the fact that I
can go back, right click, and automatically generate the
rules based off of a candidate system.
Now, the candidate system we're choosing is going to be
this system, the computer that I'm on right now.
And I'm going to analyze the files in C Program Files to
identify any executables that I finds there that apply to
everyone, and with that identify the certificate rules
that are associated with it.
Excuse me, not the certificate rules, the
publisher rules here.
I could either hash all the files.
I can set up a path rule here.
I could just create all file hash rules for them if I want.
I can group the similar files so that I end up with a
smaller number of rules here.
So this actually makes things nice for me in that it will
automatically generate the rules based off
of a candidate computer.
When it creates those rules--
You'll see here, here are the rules, here are the files that
were inventoried as part of this process.
And now what I have are the list of executables that we
found inside of the Program Files location that AppLocker
recognizes as existing.
Your next step, then, would then be to identify which ones
you wanted to forbid and then turn them off.
So this gives you, again, the ability to
take a look at that.
You can go through and adjust some of the, for example, file
version information, here.
If I wanted to, instead of dealing with just the hash, I
could identify the file version exactly, or above or
below a certain value, if I wanted to.
I could even set exceptions here that are
associated with that rule.
So AppLocker, again, a much more workable solution than
software restriction policies.
But you do you have to have Windows 7, I believe
Enterprise edition, or Windows 8 in order to support it.
Shifting over for just a minute here to data.
Execution Prevention.
I did want to show you--
I believe you're probably already aware--
but if I take a look at the property of my computer, and
under the Advanced tab here, I believe this is under
Performance, and here's the Data Execution Prevention
master toggle switch, or the master opt-in.
By default, we are turning on DEP for all programs and
services except those that I select, which if I want to, I
can go in here and identify which exes I want to restrict
from Data Execution Prevention.
Don't mess with these unless you need to.
If you have the ability, I'll show you here in just a
second, to adjust Internet Explorer with Group Policy,
there are some downloadable Office administrative
templates that you can use for restricting Office.
One assumes that there are third-party solutions that may
have Group Policy that allows you to do the
same thing with theirs.
But unless you see a need for this, you probably shouldn't
mess with this too much.
Actually, I should mention here also that if you do end
up switching this to the top button here, well, this is
going to ignore any of the per-app settings that you
would set with something like Group Policy.
So be very careful about setting
that in that top button.
With that turned to the correct location, however,
what we want to take a look at here is administrative
templates, Windows components, Internet Explorer, and finally
security features, down here.
This is going to be just specific,
again, to Internet Explorer.
And you'll find Turn Off DEP as an option here.
So I can enable this for Internet Explorer.
If you Google "disable DEP for IE," you'll find about 8,000
different websites that tell you don't do that.
But there is the option for you if you need to do it, and
if you get a question on that as you begin taking this exam.
Our next topic is the Windows Firewall.
The Windows Firewall is back up here under Computer
Configuration Security Settings and then the Windows
Firewall with Advanced Security.
I suspect greatly that you've at least played with the
firewall at some point in the past.
These days with Windows, you almost can't ignore the
firewall, especially if you have laptops that are roaming
around on your network.
Now, the Windows Firewall with Advanced Security has all
kinds of features that can you can get really deep into.
You can create isolation groups, if you want.
You can set up what's called Connection Security Rules,
which is a way to take two endpoints and then turn on
authentication and IPsec, both authentication encryption,
even if you want to, between the two endpoints.
There's this notion of I think I mentioned isolation groups,
which allow your domain to get very xenophobic, so that it's
not going to talk with anybody outside the domain.
But all of that, it's exceptionally complex
technologies, here.
There's all kinds of stuff you can incorporate here.
My guess is that you're probably not going to need to
know these for the exam.
Just be aware that an isolation group is a way in
which you can take a bunch of computers on a network, such
as on a domain, and then have them only talk to each other.
I'll leave it at that, because there's all kinds
of caveats to that.
Server-to-server is exactly what you would think, two
servers authenticate connections between
themselves.
And a tunnel is also what you would think, in that I am
taking one computer and another computer and tunneling
the connection through another network so that those two
computers can talk to each other.
Now, when we talk about the Windows Firewall with Advanced
Security, most of what we're going to be talking about is
just simply turning it on.
By default, at least through Group Policy, the firewall is
not turned on.
And so if you want to bring it under control, you will go
here to the domain profile, private, and the public
profile, and adjust the firewall state to what you
think it should be.
So in the domain, let's say you're kind of an OK person
when it comes to security, on your domain you just want
things to be relatively easy.
So let's just disable the firewall when
we're on the domain.
But when we go off the domain, by golly, we're going to turn
on the firewall, and we're going to block connections
inbound and outbound, excuse me, inbound when we are
working off the domain.
By blocking the inbound connections, that means
somebody else sitting in the coffee shop can't target my
laptop and then shoot some sort of worm or virus onto
that laptop without me known.
Be careful with outbound connections, because if you
block them, like I almost did here, that would actually
block your ability to even talk with anyone else.
So just be careful with outbound connections.
Because the user can choose the private or public profile,
if I end up setting this for the private, then I probably
will want to do something at least similar for
the public, as well.
Because they can choose their home network as opposed to a
coffee shop network.
Now, Microsoft included this as a mechanism to allow users
to make the choice, make the decision, about how secure
they needed to be.
And the idea being that with a private profile, when somebody
is in home, when they've clicked on the home icon as
opposed to the public location icon or the work icon, well
then maybe I can give them just ever so slightly more
access to accomplish things in the private profile than would
I in the public.
A lot of IT pros I talk to look at that and sort of
chuckle, because we all know that the users will just
choose the wrong thing whenever we
give them that option.
But some of the more progressive IT pros I work
with will say, you know what, I'm going to turn it on for
the private profile the fact the firewall is turned on.
Whatever it's in public, let's just block everything from
coming inbound.
On the private, I'm going to set it to a block, but then
maybe create an allow rule down here--
which would be on the inbound rules--
that maybe create allow rules so that was some sort of
program or some sort of pre-defined experience, such
as file and printer sharing, for example, will be allowed
through my firewall.
This gives you, for those users, that when they know
they're at home, when they know they're in a semi-trusted
environment, well, maybe they can connect up to their
printer, their network printer, or some other device
that exists out there.
These are the tools that you will use in order to protect
those users whenever they're on those various networks.
As you start moving into more advanced networking
configurations, which is a topic way advance for what
we're talking about here, things like Direct Access
actually can modify these rules even further.
Direct Access allows you to maintain the connection to
your equipment, even as it exists out in the airports and
the coffee shops of the world.
So that can change things quite a bit.
But these inbound rule wizards allow you to define
experiences, define ports, or define the needs of a specific
program, so that when that program needs to execute,
well, we're going to dynamically open up whatever
inbound port that that program needs in order to do its job.
Obviously, you have to trust the program.
And by program, I say, literally program.
When WinZip need a port, give it to WinZip.
You have to trust the program to do good
things with that program.
You have to trust the program is using its network ports for
the forces of good.
But if you do, this provides a really easy way for you to
control that experience for your users.
So this is how, generally, you would go about
configuring the firewall.
Again, be very careful with outbound rules.
If you think of a laptop sitting in an airport, most of
the connections for that laptop start from the laptop.
Maybe easier if I draw this.
So here is my laptop in the airport.
There's a little airplane right here that's flying over.
And my laptop here in the airport needs to go to some
HTTP site out here on the other end of the internet.
So this HTTP site over here, maybe it's Google, the
connection starts in this direction.
And when a connection starts in that direction, whatever
comes back over that connection is going to come
back in a way that is not necessarily defined by an
outbound rule.
An outbound rule is going to protect anything going that
starts in that direction.
Whereas an inbound rule protects you from anything
going in that direction.
If you set up an outbound rule to just restrict anything,
your machines will never be able to connect
to anything at all.
So be very careful with those outbound rules.
What you're looking to protect against is some really bad
person sitting here in the coffee shop that's attempting
to do bad things by poking at that laptop that's sitting
next to it in the coffee shop.
So be very, again, very, very conscious of this.
The firewall is really well put together now in Windows 7.
Windows 8 is almost the same thing.
But the Windows Firewall, really a beautiful solution
for really controlling a lot about your users and how they
work when they're outside of the LAN, and also what they're
inside the LAN, as well.
One last topic here is what used to be called FEP is now
called SCEP, or System Center Endpoint Protection.
System Center Endpoint Protection is really, at least
here, kind of a skin over the top of Windows Defender.
And in fact, if we go here to the anti-malware policy inside
of Configuration Manager, you'll see that the options
that you can choose here for your anti-malware policy look
really, really close to the things that you would see if
you looked at the Windows Defender
settings on a single computer.
So all this does is it brings those settings under control.
There's really nothing more to say here, other than the fact
that you are indeed bringing those settings under control
here with these anti-malware policies.
There is also a way to create a Windows Firewall policy here
in Configuration Manager.
However, this is almost humorous.
So our firewall policy.
I just showed you this beautiful solution using Group
Policy that you can use to control the Windows Firewall.
Well gosh, we have this FEP solution here.
If I click the Next button, this is all that I get, enable
the firewall, block connections, and
then notify the user.
So there's not much here.
Use Group Policy.
It's here.
It's part of FEP.
But just use Group Policy, because the options you have
for creating exceptions as far greater using Group Policy
than what you see here in Windows Firewall policies.
So I told you here in this Nugget, what
have we talked about?
We have talked about miscellaneous.
We have discussed a variety of mostly Group Policy object
based ways in which you can secure your applications.
To me, it's kind of silly, because this whole exam is
about apps.
And most apps have nothing to do with Microsoft.
So Microsoft is, in a way, trying to collects the
different solutions that they have, I guess, so that you can
make the apps more secure.
Keeping them updated is a really good way of keeping
them secure, as well.
You can lock them down for execution using
AppLocker or SRPs.
You can selectively elevate them.
If you're an admin using a user account control, you can
protect them against various forms of bad malware or
baddies using DEP.
You can lock your machine away using the Windows Firewall.
And you can also turn on anti-malware itself using
Forefront Endpoint Protection.
So these are Microsoft's solutions that add security to
your applications, and hopefully, at the very least,
will present you with a slightly better solution or a
better environment that you can use for maintaining your
data, for preserving your data when the applications are
working with it.
So this ends this three-part series on updating, upgrading,
and securing the applications that we have in our
environment.
Coming up next, we begin an exploration into virtual
applications, which in the Microsoft world is the use of
App-V.
App-V, I'm going to tell you, is just an awesome, awesome
tool that, unfortunately, I just don't see a lot of people
using, and I don't know why.
And maybe we'll get to the end of these next couple of
Nuggets, maybe you can kind of think a little bit about why
you wouldn't use it, and then hopefully think about why you
would, because App-V is a really, really fantastic
solution, and can and greatly improve your delivery of
applications to your users.
We'll be talking about it next.
So until then, I hope this has been informative for you.
And I'd like to thank you for viewing.