Course Transcript

1.

There are a couple of specific areas where we might want to restrict and control usage of Windows 10 and make it more secure. So, in particular, we might be interested in protecting our systems against the infamous rootkits. We also might be concerned about running unauthorized software and applications, and protecting our network from intrusion. All of these types of scenarios...well, we can mitigate against those with built-in technologies in the Windows 10. So, in this section, we're going to look at technology like UAC, AppLocker, Device Guard, and other types of countermeasures that help protect and secure Windows 10.

Back to top

1.

Now many of you use Windows 10 in your organization. It's joined to the domain and you've heard of this thing called Group Policy. Well, I want to describe how policies are applied to your Windows 10 machines. They have such an enormous impact, right, the enormous impact on what is available on the system. They can help us provision system, set up the system so that users can get to what they need to get to, and do what they need to do. So let's talk a little bit about how policies are applied. Because if you're like me, sometimes you're in a position where you're trying to figure out why things aren't working the way they should. And understanding how policies are applying, well, that can be a really helpful mental screwdriver and wrench. So you can dig in and get closer and close in on the problem without wasting a lot of time. So let's look at this.

[Heading: Policy Overview. A group policy can be configured for software installation or for removable devices prevention. It is configured on multiple machines such as all the machines used in the marketing department. A local policy can be a Windows firewall setting that is configured for a remote user or a password policy that is configured for an SQL Server.]

Now what this slide does for us is it gives us an overview. And there are a couple of things I want you to kind of see from this. First off, if you're new to the concept of policies, I want to impress upon you the power of policies. So notice that here we're doing the software installation and we're also preventing certain devices from being installed. So, if you have sensitive machines and I'm not talking about machines you get their feeling very easily, I'm talking about those machines that you don't want people installing USB thumb drives into them. It's for kiosk machine or something. It's in the public and it's, you know, so physically more vulnerable than other machines. Now in the past, you might just kind of fill the USB ports with glue, right. Well, you can actually use a policy to prevent devices and drivers from actually being installed. So you can prevent the entire USB class of devices. That's how powerful policies are. Installing software, preventing drivers from being installed, and the list goes on. You can actually create an exclusive list saying, "I only want this application to run." So it's a mono app operating system enforced by policy. And so this allows you to actually configure systems. And, when you're doing this as a Group Policy, you can define it for entire populations of machines and for users. So no matter where that user goes, this policy setting follows them around. So the first thing I want to convey to you is just the sheer power of policies. Because what they can do is they can give users what they need and take away what we don't want to make systems far more secure, immensely powerful.

Now the second thing I want to give an impression, I would like you to observe on this slide is that there are two basic types of policies presented here. There is the Group Policy and then there's the Local Policy. Now the Group Policy is usually distributed by Active Directory to main controllers. And we're doing that against multiple machines. Okay, so we've got these Active Directory domain-based policies and then we have Local Policies. And a Local Policy is processed by each individual machine. Every Windows machine has a Local Policy that just applies to itself. Now depending on the edition of Windows, that can actually be a factor in terms of how available and how easy to configure these local policies, but they all have them. Now the way that you edit these policies is through a tool called gpedit and you can edit the Local Policy on any Windows 10 machine. It doesn't have to be part of a domain. You just type gpedit.msc and you'll see that you have many other settings that you can do in an Active Directory domain, you can apply it to an individual machine. Now in a corporation we don't normally do much with local policies. Most of the time we're doing stuff through Active Directory Group Policies because, well, it's easier to actually effect an entire group when we have a lot of machines that need these particular settings. Nevertheless, I have worked with companies before who actually use local policies quite a bit. And they did it to in order to configure specific machines for certain functions, limited function type of machines. So they're still a viable and still possible option for you.

Now there's a third thing I want to convey to you and that's really not on this slide. And that is – in Windows 10 there's two other ways in which we might configure our devices. We can use Group Policies and Local Policies, but we also might be configuring our device via policy using MDM, Mobile Device Management. And yet that's another kind of policy or configuration provider that goes beyond what we're talking about here, it's newer. And then the fourth would be is if I was going to use a Provisioning Package. And Provisioning Package is something that's when we're talking about installing Windows 10 as an alternative to installation. But it could also be something where I might want to make some configuration changes to a machine. And so I could actually set up a Provisioning Package and it goes in and it makes changes to the system. So, keep in mind that here we're talking about traditional policies, but nevertheless with Windows 10 we've got a couple of additional options available, more choices again, more choices when it comes to applying the kind of settings that we need. And of course the scenario is going to vary, in all cases this is a really powerful way to control the system.

Back to top

1.

Alright, let's look here on how traditional policies are applied. There are two authentication events that typically Windows 10 is going to participate in. Especially, if it's in a business where it's subject to traditional policies. The first event is right after startup, the computer is going to log on. And the second event, the user is going to log on. So those two authenticating events are followed by policy processing. So walk with me through this. First off, of course, we have the system starting up, initialization. And then our local computer policy is parsed, read, and applied. Then we've got our domain authenticating. So because the typical business machine is a member of a domain, it's going to authenticate against Active Directory. And we're talking about typical on-premise Active Directory in this discussion. And then any policies that have been identified that device needs to process, well those are pulled down and the device applies those policies. And the policies themselves depend on where the computer account lives in Active Directory.

So, if that device lives in an OU we call them, in an OU called sales and if there's a policy associated with sales, then that policy is applied. And that could be more than one. Next, the user is going to be presented with its logon screen. User logs on with domain credentials. If they log on with local account credentials, then we're not going to do domain user policies here. But if they log on with domain credentials, the same is true about a domain user account as is true with a domain computer account. If that domain user account in Active Directory has some policies associated with it based on where it lives, well then those domain policies are pulled down and applied, and then the user will get the desktop. Now some of this overlaps. So the desktop could be loading while domain policies are still being processed and applied. But this gives you an important understanding of the sequence of way these events work.

Now another useful thing to recognize when it comes to troubleshooting these things is there is a specific order in which these policies will apply. And so, if you're trying to figure out why is this not working or why is this happening on the system. And you suspect that the domain administrator has done something without telling anybody and just, you know, distributed the policy which they never do, right. They never do that. But if they did that right, then what you could do is you can use a tool called gpresult. Gpresult is a command line tool and there's graphical ways of doing it as well that can give you a report of the actual policies and that can be a really useful. And looking at the actual order of the machine is going through and the specific policies that it believes it needs to apply and helping you identify, "Oh I see – that registry change – well, that's because somebody has distributed a new policy." So those things could be really useful when it comes to troubleshooting your machine. So don't forget gpresult and don't forget this order of group policy processing.

Back to top

1.

Alright, let's talk now about Multiple Local Group Policies. The Microsoft has an acronym for this, MLGPOs. I think that's kind of a big acronym. Multiple Local Group Policies is all about applying different policies for different local users. So this is an enhancement on the old-fashioned local policies. And really this is something that's a bit exotic. I actually haven't seen this used very often. One of the places where you might use it is if you have a machine that's kind of not part of the domain. Instead it's like in the lobby and for some reason you don't want it to be part of the domain, and yet you need to apply some special configuration settings, some security settings. You want to harden this system, but maybe you want to do that just for the users and not the administrator. Now in the past this is really a pain to do. And there are all kinds of like strange contortions you would have to go through in order to get this thing to work, but that's not the case anymore. Ever since we have MLGPOs, it's far easier to do this so that you can actually have a policy that applies to all of your users except for your administrator. So the administrator can have a different local policy. Let me clarify, this is local policies. This is affecting local accounts. This has nothing to do with the domain. So MLGPOs, this is a little known, little used feature helpful, very helpful though when you need it.

[Heading: Multiple Local Group Policies. Multiple Local Group Policies only apply too local user accounts or groups.]

Alright, let's configure some security policies now. Security policies are part of local policies and there are many, well probably hundreds of settings in there. But there are some categories that are really important. And so you want to acquaint yourself with these, things like user rights. Now I realize that going through these may not be the funnest activity to do on a Friday afternoon or on any other time during the week. But nevertheless, these are really useful and it's good to know where they are and what they can do for you. Let me give you an example. Let's say for instance, we have an individual at a remote office and we need to grant them the ability to back up files that they don't own. Normally, we can make them an administrator, but then that would violate all the best practices like least privilege. All we want them to do is back up files. Well we can do that by adding them to the backup write and only the backup write. That way they're not a full administrator and can restore the files, they can just back up files. So in those types of circumstances, these security policies can come in and help us create exceptions. It also helps us harden systems so that we can close gaps. A couple of examples of this, you can rename the administrator account through a policy just to ensure that that account has a very specific name. And well, everybody in the world knows in a Windows account it's called administrator. I mean that's a default account. But by renaming it, you'll just move the dial or the needle to, you know, more secure just a little bit.

Other things that you can do, do you guys have one of those messages at your work that comes up and says only authorized users are allowed to access, all trespassers will be prosecuted to the full measure of the law, blah blah blah, right? Well if you have one of those messages or you want to, you know, add one of those, you can do that. You can do that here through the security policies. Audit Policies are very, very useful. In that they allow me to track what's happening in against files, folders, and systems. Security options are really useful. And that's actually where you set up that message and a bunch of other settings in there like User Account Control and some authentication settings in there and more. And then Public Key Policies, maybe you have an application that require certificates or a security feature that will require certificate. And you have assert that everybody needs to trust. So what you could do is you could distribute the route certificate to everybody's trusted store through Public Key Policies. Or here's another example where you might use this. Let's say for instance, you don't want people doing EFS because you're not managing EFS, maybe you have another option or another solution. And then there's this pesky user over at the remote site, you know, next to the 7/11 there or whatever and that pesky user is always encrypting their files. You don't want them doing that anymore. Well, you could turn off EFS, their Public Key Policies. Okay, so there's a whole range of settings here that give you the ability to configure exceptions, harden systems, implement policies that are, you know, compliant settings and such. Maybe there are certain regulations and certain settings that you have to apply in order to be in compliance. That's the wonderful world of security policies.

Now when it comes to applying security policies, this is actually one of my friends. I like this. I like Security Compliance Manager, it's actually a solution accelerator that Microsoft offers that you can download. And it contains pre-existing security baseline. So you can review those baselines. You can read about the best practices. There's documentation that comes with it usually as well. And so that gives you an idea of why they recommend certain settings to be enabled. Like here's a quick example of this. Did you know that it's no longer recommended according to the Security Compliance Manager to set the password threshold to three to five bad password attempts? I mean how many of you have a password threshold of three to five attempts, after you know three attempts or five attempts they get locked out? Well, if you have that particular policy in place, I want to recommend that you read the Security Compliance Manager about some of the new best practices. Because that actually increases administrative cost in many cases and you're really not getting the kind of security that you think you might be getting. The math just doesn't pan out, folks. And the other fact of the matter is somebody could intentionally lock accounts out for a denial of service attack internally. So those are some things that you may not be aware of. That's why I'm a big fan of Security Compliance Manager because this is how I get educated.

[Heading: Security Compliance Manager. The various features of the Security Compliance Manager are centralized security baselines, ready-to-deploy policies, based on best practices, import and export tools, and domain-joined or non-domain.]

Back to top

1.

Alright, let's explore User Account Control. Now there might be a few of you who just kind of rolled their chairs back a little bit. What do you mean User Account Control? I thought that was a Windows Vista feature. Yes and it's also on Windows 10. And then some of you might be thinking, "Well, I know all about User Account Control. That's those pop-ups, right." The prompts to say, "Are you sure you want to do this? Are you an administrator, yes or no?" My friend, User Account Control is not the prompts. User Account Control is an essential internal security feature built into Windows 10. Let's talk about how it works. It's interesting.

What exactly is User Account Control? Well, I mentioned that it's not the prompts, but you know the prompts do come from User Account Control. But that's not the whole picture. You see UAC is a collection of technologies, a collection of security features that work together overall to secure Windows and then make it a more robust, fortressed operating system. This includes features like the secure desktop, Protected Administrator. One of my favorites – integrity levels and then other application features like IE Protected Mode. Now the primary goal of User Account Control...okay the primary goal is this right there. And that is to move organizations away from having their users run as administrators and instead operate as standard users. User Account Control is a standard user initiative by Microsoft. Now this was introduced with Windows Vista, but it's still an internal security technology and an important one in Windows 10.

[Heading: Protected Administrator System wide tasks are restricted to administrators. A Protected Administrator account is a special administrative account with a split token called Admin Approval Mode. Any application initiated by a PA account runs with a standard user token. Applications that need admin rights are easily elevated using a token with administrative rights.]

Alright, the first User Account Control technology that belongs to the UAC family is Protected Administrator. So I want to talk to you about the Protected Administrator feature. And this has to do with those users who are parts of administrator group who log in and then try to do anything, do stuff right. So here's what is going on. When you log in as an administrator account, you get a split token. The way I think of this is kind of like the Clark Kent superman thing. So you're Clark Kent most of the time, right. You got your briefcase, your glasses, you are walking around. You are checking your e-mail. You're doing your work thing, but every once in a while you have to do superman thing. You have to install something on to the system or make a system-wide configuration change. So, those times, that's when you use the other part of this token or this other token and that's the elevated administrative token.

So most of the time when you're doing regular operations, you have a limited token – a standard user that doesn't have all of the kind of admin rights. And that provides a layer of protection preventing kind of a drive by type of attack, something maliciously trying to take over your system without informing you. In other words, if you're sitting at your system and you're just doing Clark Kent things, I don't know play pinball or something, and then all of a sudden a prompt comes up and says, "Do you want to have such and such do the system-wide change?" Right, and it would tell you the name of the process that's requesting administrative rights. At that point, you are now informed not annoyed, you are informed that something is actually going to change in your system. And so you can respond accordingly, "Yes, that's what I want to do, that's what I meant to do." or "No, I don't want to do that." So that's the value of the Protected Administrator and the split token, kind of, creates a small partition in the access token so that those regular, daily e-mail reading, kind of, productive type of tasks that don't require admin rights. Those can be done with the Clark Kent token – the one with fewer privileges. But you still as an administrator have the powers you need in the event you need to do superman administrator things.

Alright, let's talk about integrity levels now. This is another feature inside or part of UAC – User Account Control. And the idea here is to add an additional governance to how objects and processes interact with each other. Another level of discretionary control might be another way of putting that. Well, what do I mean? Well, let's say we've got processes over here and we have objects over here. Now a process is something running in memory, right. It's an executable and it's sending threads to be processed by the process server. And then we have objects which would be like files and folders and such. Well, let's focus on this from the perspective of the low right here. Okay, so we've got something running and it has a low integrity level. A low integrity level means it has restrictions. Notice its restrictions. Notice that this low process can read and write to other low processes. It can also read and write to low objects. Okay, but it cannot...see this. It cannot write two processes up above it. So this low guy down here, it can read the medium process, but it cannot write to it. It cannot write to this guy here. It cannot write to this and so that's not permitted. So we've restricted the communication of this low process to talk to any of these other processes and any of these other objects. There's limited read capability, but there certainly isn't any write capability.

[Heading: Integrity Levels. The illustration shows the integrity levels between processes and objects.]

So what we've kind of done is we've kind of created a tiered system here. Those items that are high, well they have a lot more privileges and they can read and write anywhere. But those that are low, well they're kind of sandbagged. They're kind of surrounded and they're like, "Well, we're going to restrict you a whole lot more." Now why is this important? Let me give you an example. If I'm on the Internet and I'm downloading something in Internet Explorer, Internet Explorer has a feature called Protected Mode. And so Protected Mode will actually mark things coming from the Internet as low. So immediately they get sandbagged and we can restrict them from actually interacting with other parts of our system, medium processes, medium objects. Those objects, those sensitive operating system files. Things like at the root of the C drive and such, Windows Directory stuff, we don't want them to have any access to this. So, in addition to NTFS permissions, what we're also doing is UAC is using integrity levels to maintain the integrity of the system.

Back to top

1.

So we've been talking about User Account Control technologies and protections. Now what I want to do is go into the details of how User Account Control works. Now, in order to understand how it works, well we'll need a little bit of perspective. And so we're going to go back in history here and talk about how it works before it worked, right back in the XP days here. So essentially the way that a process is created in XP is user would log on, they would be inside of Explorer which is our shell. We go and launch something or they would be on the web and something would spawn something. You know they visit a web site and an install would suddenly start happening. And they wouldn't even know about it, but it would happen in it. So a request would be made to create a process and that new process would be created. Whether the user initiated it or not, this new process would be created and here's the key point. One right there, the new process would be running as an administrator because the users logged in as an administrator. It would inherit that token and they would have admin rights. So this is an inherent vulnerability in the XP system and one that Microsoft set out to correct with Windows Vista and User Account Control.

[Heading: How UAC Works: Before UAC. In Windows XP, the process creation path would create a process with the user's token. The new process would essentially run as admin. The Windows XP process is Explorer.exe - ShellExecute - CreateProcess - New Process Created.]

Introducing here – User Account Control, okay. Now the way User Account Control works is there is a set of filters now that's injected itself here in the create process flow. Now what it's going to do is it's going to examine the create process request using a series of filters and manifests and detection techniques like it can detect if it's an installer or not. So, if it recognizes the extension or it recognizes the behavior, then what it can do is respond to them. So, if it's like a process like a standard application, like the thing we want users to experience on a regular basis like normal, like launching Word right. So they launch Word, they get the create process here to start winword.exe. And then the question comes up, "Does that app require elevation?" User Account Control looks at this and goes, "No, it's Word dude. Just get on with it." And so the process is created with the user token and the user is a standard user. So now winword is running as a standard user and not running with an elevated, you know more powerful token. Okay, so this is going to be the normal or typical type of experience our Windows 10 users will have as they are using their applications and running the standard users.

[Heading: How UAC Works: No Elevation. In Vista and later, Windows checks to see if the app requires admin privileges through a variety of checks. If elevation is not required, a new process is created using the limited user token. The Vista and Windows 10 process, in case of no elevation, is Explorer.exe - ShellExecute - CreateProcess - Does the app require elevation? (AppCompat, Heuristics, Manifests, and Installers) - New Process Created.]

However, there are going to be cases where elevation is required because the filter detects that something is happening that requires admin rights. For instance, it could be that the filter comes along and says, "Hey, that's an MSI." This is going to require an admin in order to do an installation. It detects the file or maybe the process itself just outright says, "I need admin rights." Right, because it can. It can be configured in such a way to make that call. Now here's an interesting thing. In terms of application compatibility, if the application and if this filter detection doesn't work, then it will attempt to launch the application under standard user credentials or standard user token. And, if it's an app that's like a really old app, it could break it because the app needs admin rights. So it was written for XP. So, as an administrator, you might actually have to go in and change the app compact settings and indicate to UAC that this app requires elevation. Or you might want to sunset the application or maybe shim the application, right. So there are some things that you could possibly do. But my point being here is this filter doesn't always detect if the application needs admin rights or not. If it fails to do that then you could, you know, have a very different experience that may not work. Alright, moving on, so we have this elevation request come along because we've detected the application requires admin rights.

[Heading: How UAC Works: Elevation Needed. The Vista and Windows 10 process, if elevation is needed, is Explorer.exe - ShellExecute - CreateProcess - Does the app require elevation? (AppCompat, Heuristics, Manifests, and Installers) - Isolated Admin Process. If elevation is required, Application Information Service (AIS) intervenes.]

So now here's what happens. Look at this, an isolated admin process. There's a parallel process that starts. There's this service called the Application Information Service. And it will start another desktop, this is a different session. Okay, so you got the user log on session. And in the older Windows systems, everything would happen in this session. But Microsoft realized for security purposes, we can do things in other sessions as well. So for instance, a system session will be used. The screen will go black and this command, these consent or credential prompts will happen. This is when the screen goes black and you see a message that comes up saying, "This such and such requires administrator privileges, yes or no?" And so consent comes up if you're an administrator, right you are logged in within the administrator group. So you can say yes or a credential box comes up asking you for your credentials if you're logged in as the standard user. And your current account doesn't have admin rights.

Now this is all happening in a different user environment called the secure desktop. Okay, and that's the reason why it's kind of black when the messages come up and everything gets kind of goes to that except for the prompts themselves. That's because what the system did is actually took a screenshot of the user session and used using that as the wallpaper for the secure desktop. Now this is one of the things that will occur so that users who need to supply administrative credentials and they have them can do that in order to continue with the create process task. If you're logged in as an administrator and you have a split token then all you need to do is the consent prompt and it will continue with the create process. What this is doing is this is informing the user, the secure desktop piece is informing the user that administrative rights are about to be exercised. And, if it's malware and if it's something that I did not know is going to occur, then that might be something I don't want to do. And so I'm thankful for UAC for informing me.

Now you can't turn off secure desktop. If you do turn off secure desktop then those prompts that we were talking about here actually will run inside the actual standard user session over here. It's not recommended that you disable that. It's more secure to have the actual secure desktop here. But for compatibility reasons, for those one-off applications that might require it, don't like that other session then you might actually disable it. Nevertheless, this just gives you an idea what happens with secure desktop on or off.

Back to top

1.

Let's look now at configuring User Account Control. There are two ways in which you can configure it. You can do this in Policies or you can do this in Control Panel. I encourage any of you who are taking the certification exams to acquaint yourself with the Policy method as well as the Control Panel method simply because the Policy settings themselves are not named in the most intuitive fashion. So your acquaintance will be beneficial. So acquaint yourself with those settings. But let's look at how you configure in Control Panel. Now, in Control Panel, you got the sliding bar and they introduced this back in Windows 7. Because when it came out in Windows Vista, there was a lot of prompting going on, a lot of annoyance and people were not quite ready for User Account Control. So they've streamlined it in Windows 7 and this is essentially the same kind of control we had in Windows 7. So the default setting is right here and this says, "This and this is important, notify me only when programs try to make changes to my computers." So whenever a program is detected in trying to invoke administrative rights then you're going to get alerted. That's the default setting. So, if you're doing something administratively, you're not going to get prompted for that. Now the kind of the Vista prompts you every single time, that's the Always notifier and you could turn that on if you wanted to. And then this one right here actually turns off secure desktop, not recommended and definitely not recommended is turning the UAC all the way off. But, if you need to make a change maybe even temporarily, this is a convenient way of doing it.

[Heading: UAC Settings. The User Account Control Settings dialog box is displayed. The dialog box has a slider bar ranging from Always notify to Never notify. The slider bar is set to the default settings. The presenter sets the slider bar to Always notify.]

Back to top

1.

In this next section, you'll walk away knowing more about why the boot path is so important to protect. Now boot is historically one of the most vulnerable periods of the operating system's life. Because it's during to that time that the operating system isn't in full control. And a lot of its security measures – like anti-malware and such, well – those haven't even started yet. You can have the most secure operating system in the world. But, if its initialization isn't protected, then – well – that's like putting kryptonite in Superman's water. So there's a whole class of malware that specifically targets the early boot routines of an operating system. And these are really dangerous. And one of the things that they do is they inject themselves into system files or the malform, you know, different operating system files. And they are insidious because they appear to be legitimate. These are called rootkits. And rootkits themselves may not be malicious per se. They might be part of a larger scale type of attack. But they're highly dangerous because what they'll do is they will pry open a system like a pry bar. They pry open a system and then what follows are these malicious toxic payloads – like, you know, grenades if you will. And that opens up the system. So all sorts of different types of attacks from there – things like keyloggers and ways of capturing passwords and monitoring the system and elevating malware to administrative privileges – all very, very dangerous.

[Heading: Boot Time Threats: RootKits. Rootkits are a dangerous malware threat. They operate at the same privilege level as the OS. Rootkits start before the OS boots and uses sophisticated stealth technologies, making them difficult to detect. Often, rootkits are part of larger attacks that include bypassing local logins, recording passwords and keystrokes, transferring private files, and capturing cryptographic data.]

Alright, so here's a look at different types of rootkits – firmware rootkits, bootkits, kernel rootkits, driver rootkits. Now the word itself – rootkit – is a melding or concatenation of two words, root and kit. Now root is actually in reference to the administrator account. And it comes from, you know, Unix world. We don't refer to the Windows administrator account as root, but that's, you know, still what it's referring to. And so the idea here is simple – rootkit seek to gain and abuse administrative rights. That's the pry bar that they're leveraging here. And what they do is they try to make themselves hidden. So they hide in plain clothes. And they hook into operating system components or they pretend to be operating system files. I mean it's like invasion of the body snatchers here – that is you've got real people replaced by aliens. We're talking about real aspects of the operating system altered and replaced by alien malware. Now rootkits are also described in terms of two categories. You might refer to them as user mode or you might refer to them as kernel mode. User-mode rootkits – well, they're operating and attacking what is called ring 3 or kind of higher-level services. But those kernel mode – well, those are the more advance type of rootkits. And they're out to subvert the actual inner workings of the Windows operating system. So...and they're hiding among low-level files and folders and registry and trying to subvert processes and know key aspects of the operating system.

[Heading: Types of RootKits. Firmware rootkits override device firmware for pre-OS boot. Bootkits attack the OS bootloader for pre-OS boot. Kernel rootkits replace parts of the OS kernel for Autostart. Driver rootkits impersonate trusted drivers.]

Now, if you go to some security sites – like for instance if you go to bleepingcomputer.com or some of the other security vendor site – you often see a list of notorious, bad rootkits, known rootkits. And it reads like a list of files that you would see inside the operating system. And that's because they are files or components that are posing to be and pretending to be a legitimate. And these will have malware names. They will have names like HackStore and Backdoor. And even the stuxnet's worm used to have a rootkit attached to it. Now there are also notorious rootkits that you may have heard about in the press. So, for instance, there was a case of rootkit being used to tap government phones. There was a case of a security firm – a legitimate kind of security firm – that is well known. They were caught using a rootkit in some of their security software and stopped doing that. And then there's one particular case where rootkits really started hitting kind of everybody's top of mind. And that was when Windows internals guy Mark Russinovich detected a well-known music label was using rootkits on their CDs infecting people's computers to monitor users for the purpose of digital rights. Well, of course, that was a real embarrassing moment for that record label company. But it demonstrated how unconventional or undetectable some of these rootkits could be and how difficult they are. And Mark Russinovich now works for Microsoft in lot of these tools. And amazing work and books that he has written in such that talks about this. Mark Russinovich I think should be knighted as the defender of the Windows realm, but I digress.

Back to top

1.

Alright, rootkits are dangerous threats to our system and to the software and all the business we want to do online. And, if we're infected, oftentimes there is only one thing we can do and that's reinstall the operating system. But Windows 10 is a set of countermeasures that hardens the boot process and makes it truly resistant to these things called rootkits. Now my goal in this section is to just survey the different countermeasures and to give you a basic understanding of how they work so that when you walk away, you'll be able to really describe the difference between Secure Boot and Trusted Boot and the importance of UEFI in your system.

[Heading: RootKit Countermeasures. Secure boot only allows UEFI systems to load trusted OS components. Trusted boot enables Windows to perform integrity checks during startup. Antimalware scans drivers before they load. Measured boot and TPM systems can securely audit the boot process. Device guard is a new protection available in Windows 10.]

So here's a look at these countermeasures that are part and built into Windows 10. And these are threat-resisting technologies. And really these are evolving technologies. Some of them were introduced with Windows Vista and they have been progressing from there. So you can see, we've got Secure Boot, Trusted Boot, Anti-malware, Measured Boot, and Device Guard. And Device Guard here is new with Windows 10. Now, in Windows 10, these technologies work together to resist different threats especially rootkits. And essentially what they do is they ensure the integrity of the different components – the firmware, the boot files, the kernel files. And they ensure that they aren't altered or they aren't malformed or hooked in any way. That they maintain the integrity of those. And so, by safeguarding these early routines, you know, you're getting a fresh, clean boot each time you turn your system on when these are actually enabled and running. You might think of these threat-resisting technologies as like a tamper seal. Like, for instance, if you get a bottle of pain medication and you'll put it up, there's usually a little foil cap there. And, if it's been broken – well – then you're going to take it back, right, because you can't trust the content. Well, that's the case with these technologies.

Now I should point something out. This list isn't exhaustive. There are other security measures and other types of protections that are built into Windows, such as there's a technique called SmartScreen filter. There's a known list of bad applications out there that Microsoft maintains its list. And Smart Screen Filter will compare an application to that list. And, if it detects it and it knows it's an untrustworthy app, it will let you know. It will say, "Hey I recognize this is malware." So they're smart screen filter. And then there's User Account Control – a Windows Defender – which is your anti-malware that's built in. Many of these features though – all require an uncompromised operating system. So even some of the other security technologies don't protect the boot process like Trusted Boot and Secure Boot does.

Okay, to understand how those rootkit countermeasures work, we want to review the boot process. Now, for now, ignore a label Secure Boot and Trusted Boot. Let's just talk about the boot process itself. So we start with the firmware phase. This is the BIOS phase or in this case we have UEFI, which is a newer firmware standard. And this is before the operating system is running. So this is software that's on the motherboard who serves multiple purposes. One of its jobs is to help find an operating system and the initial bootstrap files to get the OS, you know, start it up. The bootstrap file or Boot Manager kind of fits in between these two. So we use the firmware to find Boot Manager in Windows 10. Boot Manager then reads what is called Boot Configuration Data and loads what is called winload. So it launches winload.exe. And winload.exe – its job is then to start the kernel. Okay, so we have kind of this chain taking place. Now, once the kernel gets executed, its job is to complete the initialization of the operating system. So it reads the registry. And, in the registry, there are instructions about what to boot and when to boot them. And so here we're talking about services, we're talking about drivers, we're talking about files. Some of those can be third-party drivers.

[Heading: RootKit Countermeasures in Action. The Windows boot process is UEFI - OS Load - Kernel - System drivers and files - Third-party drivers – Antimalware - Windows Logon.]

Now this process here is all governed by instructions in the registry, but I want to point something out. Notice here that malware executes later on after the operating system runs. And often it's too late for it to detect rootkits effectively. That's why there's new levels of protection that you see here. And these additional levels of protection are running during these phases of boot before the operating system is fully on its feet. Now some of these technologies require a hardware. Like, in order to use Secure Boot, you want to have UEFI. And enhancements come with the help of TPM, Trusted Platform Module. Now some of these have been...these firmware or hardware requirements actually been out there for a while. So it's likely, if you have some devices you've purchased in a last couple of years, that you'll have the necessary hardware. But you want to check in order to see if you can actually apply some of these protections.

Back to top

1.

Imagine this now. Imagine you have a runner in a track race. It's in the blocks, waiting for the gun to go off. And then somebody from the stands yells go or has an air horn. And so that's going to be potentially confusing, right, to the runner. Imagine if that runner was your PC and it was using BIOS-based firmware – if it was using a BIOS-based firmware – then it would not be able to tell the difference between a legitimate start and an illegitimate start. In other words, he would take off. And that's because the BIOS-based firmware doesn't provide any way to tell the PC what boot components are trustworthy and what boot components are not. Without Secure Boot and UEFI, your PC will run whatever boot loader is on its hard drive or yelling from the stands because it doesn't know the difference between a race official and somebody posing as a race official – a rootkit.

[Heading: Secure Boot. Secure boot verifies integrity of the boot loader and firmware. Secure boot requires Unified Extensible Firmware Interface or UEFI 2.3.1 or greater. Heading: What Is UEFI? UEFI is a newer firmware standard that replaces legacy BIOS firmware.]

So, when a PC has Secure Boot, what it does is it relies on UEFI to help protect the initial start of the actual PC. UEFI will verify the firmware. Okay, it verifies the actual initial software. And it does this by examining what are called digital signatures on the firmware components and making sure that those signatures are tied to trusted entities, to their trusted components. Now, if you're familiar with digital signatures, the whole idea of a digital signature is trust and integrity. And it's using cryptographic technology, using certificates. And so, with UEFI, we're actually able to validate certificates and digital signatures in a pre-boot basis. Now that's something that's not able or available to us with a BIOS because a BIOS is 16-bit addressing space. And it's a minimal amount of functionality. And it was never intended to do these kind of additional security checks. It was intended strictly to start the PC because there really was no thought of a rootkits in that time. That means, with UEFI, what you have is something more sophisticated. It's newer. It's a unified extensible firmware initiative. And Windows 10 supports UEFI. In fact, it's recommended you run Windows 10 on UEFI systems. So, to actually take advantage of Secure Boot, UEFI is critical. You have to have it, okay. Alright,

so now let's look at Trusted Boot. Trusted Boot picks up where Secure Boot left off. Now it's interesting to me that you can have Trusted Boot without Secure Boot. So that begs the question – what is the difference between Trusted Boot and Secure Boot? Good question. Now, with Trusted Boot, what we're doing is we're validating the components after the firmware. So...but what happens is the boot loader examines the kernel to ensure it has not been altered or tampered with. The way it does that is it validates its digital signature and it checks to see if it has been altered. And the way it determines that is if the signature doesn't match what it is expecting, then it knows that that's no longer a legitimate kernel. So, once the kernel has been validated, it will trust it, load it, execute it. Then the kernel turns around and does the same thing. So, when it looks into the registry and identifies what kind of drivers and files that it needs to execute, all of those are going to be verified by their digital signatures to ensure that they can be trusted. You might even have what is called Early Launch Anti-Malware. So there is support here for anti-malware to run if the anti-malware supports executing within this process right here. So what Trusted Boot essentially does is it kind of creates an airport security style type of protection here where all the different files – including the kernel itself – has to take off its shoes, has to show its passport essentially, and walk through a scanner to make sure if they haven't been altered with or tampered with. Here's something that's pretty cool about this. If, for instance, the OS loader finds that the kernel signature doesn't match – meaning the kernel has been altered, tampered, or maybe it's been damaged – then it will simply replace it, automatically fix it. And that creates an additional resiliency to this whole process – pretty cool.

[Heading: Trusted Boot. Trusted boot was introduced with Windows 8.1. It secures the OS boot process. It ensures Windows components have not been tampered with. It can also ensure Early Launch Antimalware (ELAM) launches before third-party drivers and applications. The trusted boot process is OS load - Kernel - System drivers and files.]

Alright, Measured Boot – now, if you have a TPM chip, you can also leverage a technology called Measured Boot. Now what Measured Boot does is it basically allows networking services to see or have some insight into the boot process, kind of like a doctor with a stethoscope. And this doctor with the stethoscope...well, it's able to perform remote attestation. Basically what happens here is Windows 10 can measure the boot process using hash cryptographic algorithms – using things like the boot files, the hardware, and so forth – and creating a mathematical measurement. Securing that in the TPM on boot, it can turn around and present that to a networking service. And the networking service can then validate it and issue a device claim or a bill of health like a doctor would. And so, with this bill of health, then this client can be able to use its attestation claim whenever it's requested. So it can go out on the network. It might talk to a resource, might talk to an application. And it's able to present this bill of health – this device claim. Now these measurements here are essentially not unlike other types of boot protections. And that we're using cryptography, we're using digital signatures to examine the boot process and identify it. And the remote attestation service itself – well, this is actually third party. So Microsoft currently doesn't have anything in terms of Windows Server that performs this, but they're working with third-party vendors to supply this piece of it.

[Heading: Measured Boot. Rootkit infected devices often appear healthy. Measured boot allow a trusted server to verify the boot process. Measured boot relies on TPM 1.2+ to store boot time hashes and digitally sign the audit log.]

Back to top

1.

Time for Device Guard. Now this is a new feature in Windows 10. And, when we're done with this topic, my hope is that you'll be able to fully understand what it is and why it's so useful and so powerful and an important addition to Windows 10 security. Now, as I stated earlier, Windows has multiple security features – multiple methods to deal with different types of threats. So we also now have this thing called Device Guard. Why do we have Device Guard? Well, Device Guard is different than the other security technologies. And let me explain why. Device Guard is a countermeasure. Well, it provides – as it says here, you know, on the slide – stiff malware protection, tamper resistance. And the key thing I want to highlight for you is it only runs trusted applications and services. In short, the way that this works is whenever an application is executed, Windows actually determines if the app is trustworthy or not. So like some of the other technologies where with Trusted Boot the kernel is evaluating the different components before it executes it, now we're looking at other applications and services as well as the operating system components and we're making sure that they're trustworthy before we execute them. So, in some ways, this is a protection that includes the entire system – the rest of the system. That means Device Guard is amazingly strong.

The other aspect of this is the decision-making that it has to go through to analyze these different components. Well, those decision-making parts could be isolated from the rest of the operating system. Then Device Guard is not vulnerable to the types of pass-the-hash attacks or kernel mode types of events, types of threats because there is this enhanced barrier. And those operations are kept separate from the rest of the operations in the system. That means Device Guard is ideal for zero-day type of exploit. And what I mean by that is when there is some vulnerability detected in the system, there's this period of time where it takes traditional anti-malware to catch up to write the definitions, to be able to have, you know all the...get the KB and hotfixes posted, downloaded, and applied to systems, get them up to date. And the response time by the industry in regards to a new threat can be too long. And, in the meantime, malware is taking advantage of the system. Well, this is a proactive approach where Device Guard actually locks the system down. And it will not permit anything else to run if it has not been granted permission ahead of time. If it's not on its trusted list, it's not part of its policy, it doesn't get executed. And what it does is it protects the system from what they call advanced persistent threats – those threats which take advantage of a system exploit and continue to kind of attack that exploit in multiple ways – as well as a way of protecting the system from zero-day exploits.

Now, to further explore Device Guard, let's talk about the story behind the Device Guard. Because you might be thinking, "Well it sounds a lot like Trusted Boot and Secure Boot." And in many ways you're right. Looking back, we can see how over the different editions of Windows, Microsoft just created technologies whose primary job is to validate different parts of the boot process or different parts of the operating system or even the case with AppLocker, which is meant to kind of only allow trusted applications and services to run. So Device Guard does a similar type of thing in establishing a trustworthy environment, but it does it differently. You see, with AppLocker over here...AppLocker – if you are not familiar with it – is a service that you can set up a list of only of trusted applications and run only those trusted applications, but that's dependent on security service. What makes Device Guard stronger or better is that it actually is a combination of hardware and software. So it's not just a service like AppLocker is, it actually leverages hardware. The second thing I want to point out is it supports Code Integrity at all the different levels – so the application, but also the kernel. So that's important thing to remember – Code Integrity. The third thing is that it can leverage virtualization to protect the operating system. And that's different than these other approaches. And that's where we're able to actually isolate some of Device Guard's processes and integrity scans in a separate container isolated from the other parts of the operating system. And the fourth thing I want to mention about Device Guard is it is manageable. You can manage Device Guard and its features centrally.

Now Device Guard is not for everybody. There are some scenarios where it works best – the ideal. And then there are those scenarios where you don't want to apply Device Guard. So, for instance, BYOD. This is where users are local admins and they're installing their own software and a lot of its personal software. So this is a situation where you're not going to be using Device Guard. Device Guard is really designed for business-class devices, sensitive machines. This is where you have specialized function machines, dedicated workloads – like the machine on the factory floor, or the HR manager's laptop, maybe schools because a Device Guard also works with Windows 10 education edition. So that would be another place, right. Those poor teachers, right. If you might be a school administrator yourself, then might be able to identify with this. But I've done consulting with school administrators and they tell me some amazing stories. They have got this hostile user base, right, especially in high schools. And so they're not there to get paid. They are there because they have to, right. And so, using the computer lab, sometimes school administrators – and I'm speaking of IT administrators – encounter some interesting things. And so, because you've got such a hostile user base, something like Device Guard would restrict the system completely except for only those authorized applications.

So viruses and malware wouldn't be an issue. Unauthorized software wouldn't be an issue. And you could prevent even social media from executing on these systems. It could be really locked down because of Device Guard. I'm just smiling because I'm remembering a story one school administrator told me. That at the end of the year, some of the seniors took the thread off of a mouse and attached it to the CD-ROM. And the CD-ROM has got a motor in there. So, when you close the CD-ROM, it would spin up, right. And, as it spun up, it just pulled the thread right off of the mouse pad and created a big ball of string. And she had to deal with that at the end of one of her school years. She has told me that every year there's something new that the seniors would introduce her to. She didn't think you could do that, but anyway Device Guard would cut out at least some of the software aspects of it – doesn't protects mouse pads and CD-ROMs.

Back to top

1.

So let's look now at how Device Guard works. After this topic, you should have a much better understanding of the Device Guard components and how they work. And I'll also show you how to enable them. So, taking a deep dive into the workings of Device Guard, require that we start with some key points. And we address this question – how does Device Guard work? Device Guard is more than a simple one-button feature or a next-next finish wizard. It's actually a combination of multiple features – hardware and software. It's relying on things like Secure Boot and TPM and digital signatures. It's also at the heart of Device Guard. And how it works is a Code Integrity service. Now this Code Integrity is what is used to kind of determine if the code that it's about to execute is trustworthy or not. And that Code Integrity service can be further fortified if it's running in virtualization. So virtualization might be another component. In fact, let's look at the components.

[Heading: How Does Device Guard Work? Device guard is a combination of hardware and software security technologies. It relies on code integrity service that runs in an isolated, virtualization based container. It is managed with PowerShell, GPO, and MDM.]

Here's a list of the components that I was just describing. So once again, here we're relying on digital signatures. Now digital signatures – as a refresher – this is our mathematical component that enables us to prove that a file came from a certain origin and that has not been changed. So we can validate mathematically through digital signatures that the file has maintained integrity, has not been cooked in any way, has not been malformed in any way, has not been hooked in any way. And we can prove that it came from Microsoft or it came from Adobe or whoever the vendor is, we can prove that through digital signatures. If the file doesn't match its digital signature check, then that will fail validation, right. Digital signature is our basis of truth. And so, with this, you know, the system has a degree of certainty that things were published by who they say they were published by. Now Device Guard also relies on Secure Boot. And I mentioned earlier the Code Integrity service. Secure Boot is important because it's going to protect the system at the boot level. Okay, so as I mentioned earlier, when we talked about Secure Boot, the system is at one of its most vulnerable points during boot initialization. So Secure Boot is required to complement the other aspects of Device Guard namely Code Integrity. Now, to further protect Code Integrity which is doing the decision making, we want to use virtualization-based security. And virtualization-based security puts Code Integrity into an isolated secure container so that its operation is protected from the rest of the OS.

Now kernel mode has two different Code Integrity components – User Mode Code Integrity and kernel mode code integrity. Now kernel mode code integrity – its job is to ensure that the operating system is protected. And one of the dangers is without kernel mode code integrity in an isolated container, you run the risk of malware executing through buffer overflow types of attacks. So, if you're familiar with the idea of buffer overflow attacks – that's essentially code, you know basically – it uses a buffer overflow to attempt to execute in other memory addresses. And so you run the risk of this malicious code executing in a memory space that belongs to the kernel or has sensitive information in it. And so one of the things that we can do to address these types of attacks with Device Guard is we can take the kernel mode code integrity piece and isolate it through virtualization.

By isolating it through virtualization, we basically restrict memory. We abstract it through virtualization. Memory rights are enforced between these two different containers. Here's the ordinary operating system kernel, but then there is a specialized kernel over here that can run and execute Code Integrity without interference from the other aspects of the system. And the memory address spaces are abstracted and secure from each other, so this essentially shuts down and prevents buffer overflow attacks. With virtualization enabled, buffer overflow attacks are really now part of history. They are, you know, virtually impossible to actually run and execute. So Device Guard provides a kind of protection we haven't seen in Windows ever. And this makes it far, far more secure.

Okay, so how do I enable Device Guard? Well, Device Guard is really enabled as part of your image build. Essentially what you're doing is you're creating an image and in that image you're including a policy to tell Device Guard what applications are trustworthy, which ones you're going to permit to run on that image. And this is something that requires several components in order to get up and running. So you're going to need to have the right edition of Windows 10. This is not for every type of the Windows 10 that's out there. This is for Enterprise Edition. This is for Windows 10 Education. This is for Windows Server. In addition to that, you need to have the hardware features and virtualization features I was talking about. So, for Secure Boot, you'll need UEFI. It's recommended to have TPM. And it's also recommended to have virtualization so that you can run your kernel mode and the Code Integrity in an isolated container.

Now you also have to build what is called a code integrity policy. Now the Code Integrity Policy can be built. There's an XML configuration and some PowerShell commands that go along with this process. And, with those tools, you actually identify which applications are trusted, which ones are allowed to run on your Device Guard protected machine. And that's all going to be baked into your reference computer image. And you can manage some of this through policies. You could use PowerShells, I said, to create the actual Code Integrity Policy. But this means...and this is a big one that your apps have to be digitally signed. So you create your Code Integrity Policy, but that's going to be tied into the digital signature of your applications. That's where the truth comes. So the Code Integrity Service can look at the application by its digital signature and from that make its decision. You might have lined a business applications that are not digitally signed. So then another step into enabling Device Guard is building a process and going through a process of identifying those apps that need to be included with this Code Integrity Policy and ensuring your apps get digitally signed. And so that means you need a code signing certificate. You need to have a signing tool. You need to have the procedure in place to sign these. And thankfully, Microsoft has got a tool for you called sign tool. And the process is documented in TechNet. You can review that. But you also need to have your own certificate and likely to have a public key infrastructure. So that's going to be a piece for a lot of organizations who are looking for this kind of additional protection the Device Guard offers. That's going to be probably the more time-consuming piece. And that is getting your applications digitally signed and included in your Code Integrity Policy.

The final thing I want to make mention of is this is something that has, you know, a lot of value in a variety of different scenarios and places. As we've talked about, this is something that schools can take advantage of. This is something that organizations with sensitive machines and laptops can take advantage of, special limited function machines can take advantage of. So what that means is that if there is a rash of malware that's released in the wild, that malware will fail validation. It will not be permitted to run period on a Device Guard machine. And that makes Device Guard one of the most secured features in Windows 10 and maybe the most secured feature in operating system period – I don't know, but it's a very powerful measure for protecting my systems.

Back to top

1.

So the next thing I want to look at is AppLocker. AppLocker was introduced with Windows 7. It's also available in Windows 10. Let's learn some more about it. What is AppLocker? Well, here's a quick and dirty definition. AppLocker is a proactive security technology that enforces application restriction policies. Now, by proactive, we're not talking reactive. So this is an after infection. This is before infection. Preventative might be a better way of putting it. So AppLocker is a preventative security technology. And the way it does that is through application restriction policies enforcing a set of rules that say only these applications are allowed to run or not.

Well, here are some of the key advantages and the why behind AppLocker. One of the key things is it prevents malware from running because it's not included on the authorized list. And so what you can do with AppLocker is you can define the specific function of your systems – what software is allowed, what scripts are allowed, who is allowed to run those – and enforce those through Group Policy. So you specify the software. And, by virtue of doing that, you eliminate anything else that's not authorized including malware. Now, for those of you looking at this, you might be thinking, well, that sounds a lot like another Windows 10 technology called Device Guard. Well, they're very similar, but they're also different. AppLocker relies on a service and Group Policy. Device Guard – on the other hand – is a mixture of software and hardware. And it has support for Code Integrity inside of a virtualization container. It also has a different kind of policy that's enabled. So it's applied at the image level. And so they are similar to each other, but you can use them at the same time. They are – in many ways – meant to complement each other on certain systems. Microsoft put it this way when referring to AppLocker and Device Guard working together on the same system – one Microsoft representative said that – "Think of AppLocker as the bartender controlling what drinks are served. But Device Guard is like the bouncer at the door determining who even gets in the bar in the first place."

[Heading: AppLocker Advantages. AppLocker protects against malware by restricting the files that run on a system. It can protect applications against unauthorized access, which protects sensitive data from being accessed. It reduces the total cost of ownership as it lets you specify what software can be installed on systems. It enables you to restrict unauthorized applications from being installed.]

Right, so here's a summary list really of the different functions of AppLocker. I mentioned a few of these already. We're controlling what apps users can run. Now the following bullets give you a little bit more detail as to how we accomplish that. So what we have is we create these rules. Those rules are what are used to kind of examine an application. So you can set up a rule based on certain file attributes like, for instance, who publishes the file, maybe the digital signature on the file, the version of the file, and so forth. And that's how you can control that application is permitted or not or that file is able to execute or not. And you can assign those rules to users or groups. And one of the things that's important here is you can also audit your rules before you turn on enforcement. So, if you're thinking of doing an AppLocker project, auditing is going to be an essential part of your implementations. You're going to have kind of an audit phase. You can control not just standard applications, but the point here is you can control also packaged applications. And then you can manage these with PowerShell and also through Group Policy. That's one of the primary ways we manage. Notice it says here it requires Enterprise Edition down here at the bottom. In addition to that, the new Windows 10 Education Edition also supports AppLocker. So this is a business-class feature designed to provide additional protection for our business-class devices.

[Heading: AppLocker Functions. With AppLocker, you can control which apps users can run, define rules based on file attributes, assign rules to users or groups, test and audit rules before enforcement, control package apps (Windows Store apps), and manage with PowerShell. AppLocker requires Enterprise Editions.]

Back to top

1.

So now what I want to do is talk about configuring AppLocker policies. We're going to be looking at the different types of rules you can create and how to distribute those rules through an AppLocker policy. So what is an AppLocker policy? One AppLocker policy is going to contain some rules and there are different types of rules that you can enforce. We've got executable rules. We have Windows Installer rules. We got scripting rules, DLL rules, and packaged app rules. So what you're going to do is you're going to build this policy and you're going to distribute it here through Group Policy. And inside this Group Policy are your rules. It's the rule that controls the what and the who and whether or not they can run.

Now, to understand the contents of an AppLocker rule, let's break it down and look at its components. To start off with, we have these things called rule conditions. Rule conditions help us identify and detect the application properly. There are a couple of ways in which we can define our conditions. We can define it based on the path which is where the file of the application is at, you know, the executable where it's located. The problem with that is you run the risk of that application been moved somewhere and not been able to run. So, if I create a path rule that says I want this executable to be permitted because it's located in C:\ whatever and if for some reason it gets installed in another department or branch office into C:\ somewhere else, then it's not going to run. So I need to create a rule that's going to follow the scenario the best. So, if the path is the best, then fine. Alternatively, I can use a file hash. And a file hash is kind of like a digital signature. It looks at the binary of the file, creates a mathematical version of it, and then that can be used to identify the file. The problem with that is if you update, the file – right – gets a patch or something. Now the hash doesn't match anymore, so that's not going to work.

But then we have the publisher. And the publisher is important. And, in many ways, it's the publisher piece that makes AppLocker stand out from software restriction policies. If you remember from XP 2003, Microsoft had something like this AppLocker thing called SRPs – software restriction policies. The problem with software restriction policies is they were hard to manage every time an application gets updated or patched and that going back in and recreating some rules. With AppLocker, you can create a publisher rule and it's based on digital signatures, based on who created or issued the application. So you can set up a rule say for Adobe. And the AppLocker rule is if it's been digitally signed by Adobe, let it run no matter where it is, no matter what version it is. So, if it gets patched, not a problem if AppLocker can still validate that that application came from Adobe or whoever. Now we have rule behavior. Most of the time you're going to be defining your rules based on allows, that's what you're going to do. So you're going to set up conditions and you're going to define them with allow. That's because the way AppLocker works is it works on a white list type of approach meaning every application that's in your policy will be permitted. And, if it's not in the policy, it's not allowed. It's automatically denied. If however, for some reason you need to define a policy where you explicitly deny an application, there is the Deny option. But keep in mind that's implied when you define AppLocker according to best practices.

Now here's a nice, convenient set of steps to configure AppLocker. And this kind of relates the basic procedure for us. The first thing is we'll need to inventory the applications. One of the problems with AppLocker and you could say other technologies like this, like Device Guard would be the fact that you could restrict legitimate applications. So you don't want to overlook a mission-critical app – a line-of-business app – that, you know, that department is dependent on. So a very important step in all of this is inventory or applications. Then you need to associate the appropriate rules to each one of those applications. It mentions here in number two also defining enforcement. Now you're going to probably do this in the stages, so you're going to start with like auditing and then you're going to consider enforcement. Auditing would just track usage and would indicate in your reports, you know, whether or not the application would have been prevented or not. But it wouldn't do an actual enforcement until you're ready. You want to be sure that you've properly tested and designed your implementation. And look number six right here – audit and tester rules – before you enable enforcement. First few steps are all about planning.

Now next thing I want to point out is number four right here in the middle. Number four brings out the fact that this is Application Identity service, so this is another one of the distinctions of AppLocker from other security technologies and then it's reliant on their service. So, not only are you building a policy that contains rule conditions and rule behavior, you're also going to have to create a policy that enables this service on your machines because it's not turned on by default. So you would have to turn this service on as well. So now that you understand kind of the ins and outs and the parts of an AppLocker policy and you're acquainted with building rules and conditions and targeting, the next thing we'll talk about is distributing the AppLocker policy and configuring enforcement. And this again is going to be done through Group Policy. We need to include – in our distribution strategy – the service. We need to enable the Application Identity service. We're going to be targeting Windows 10 devices that are Enterprise edition or Education edition. Notice it does support other versions out. It also supports a Windows 7 Enterprise edition as well. And so, once we've got these other components in place, those devices will pull down, enable the service and pull down and enforce our AppLocker policies.

Back to top

1.

Among the many security features in Windows 10, there's also a built-in firewall. And there are actually couple of ways in which we can manage this. One is to use the basic Windows Firewall, which is more designed for the consumer. But then we also have this Windows Firewall with Advanced Security. And so now what we want to do is explore the Windows Firewall with Advanced Security in Windows 10. Let's talk about the features of the Windows advanced firewall. There's more to it than your basic client firewall. Microsoft says it has business-class features. Why? Well, let's look at some of the features. That's because it supports multiple types of rules – inbound and outbound and a couple of other types of rules. It's stateful. So it's aware of different sessions. So it's aware of different types of traffic belonging to different sessions. It is also integrated with IPSec and Group Policy. So there's centralized management. And there's another type of rule that can enforce authentication and encryption – that's IPSec. It also supports Network Location Awareness, which is a pretty neat feature. And that it dynamically can apply a different profile of rules based on the type of network at the techs. So, if it's a network it doesn't recognize – like it's the Wild Wild West of your local coffee shop – then it can enforce some more stringent kind of public profile set of rules, turning off things like file sharing and those types of things, making you less discoverable on that network. And then there are features that support application isolation for like Windows Store apps, centralized management through Group Policy, and then PowerShell management as well – got to love PowerShell.

Back to top

1.

Now the next thing I want to explore with you is how to configure firewall rules. So, when you're done with this, you understand the different components, the management and how profiles work and the other types of components that are part of an advanced firewall rule. Now we're going to look at the different components and three different categories. Now the first categories are management category. In this category, we look at the different ways in which we can manage the Windows Firewall. So we've got our console kind of the client configuration piece. But we can also centrally manage or automate the management of the advanced firewall and its rules through PowerShell and Group Policy. Both of these are enormously powerful. Group Policy has the advantage of the familiar UI. PowerShell has enormous rich scripting capability.

Now the next category of firewall components is the profiles. And this is one of the features I really like about the advanced firewall is its Network Location Awareness. Essentially, what this does is – when the Windows advanced firewall is on a network connection, there's a live network connection – it makes a decision as to where to put that network connection. There are three choices. Either it's going to be a domain connection, a private connection or a public connection. Now between those three what it does is it tries to automatically apply kind of a bank of firewall rules. So, for instance, if it sees a connection it doesn't recognize – so you're at the coffee shop or wherever, right – then it's going to automatically choose public profile which is likely to have the more restrictive firewall rules. So it's a profile of firewall rules that match kind of the idea that this is a less safe network.

On the other hand, if it recognizes the network – it's your home network. And you've indicated that it's a private network. It's a home network or your business or work – then what it does is it will apply the firewall rules associated with the private profile. And, if it's a machine that's a member of the domain and it detects a domain controller, then it will apply any rules that have been grouped together as part of the domain profile. All three of these can be alive at the same time in the sense that a Windows 10 machine can have three different categories of rules. And then when you take it from one type of network to another – so it's currently in a corporate environment, it's on premise, on campus, you take it home – then it will switch from domain to private automatically for you. You then walk into the coffee shop later that evening and it will go in. It will reconnect to the coffee shop network and it will be public. So what that does is it saves you. You know the headache of having to go in there and adjust the firewall settings all the time depending on what network you are, it automatically switches into a different category based on the network. And, if it doesn't recognize it, it's always going to choose public. And as a user, right, as an administrator, you can actually change that and say, "Well, no this is a private network instead."

Third category of our firewall components is that's the rules themselves. Now there are four different types of rules. There are the inbound rules, the outbound rules, connection security rules, and network isolation rules. Your inbound and outbound rules, those are probably more common and more straightforward. You're creating a rule to permit certain types of traffic inbound. You're controlling, restricting, preventing traffic from leaving the machine that would be outbound. Connection security rules though are authenticated-based rules and these are where we're applying authentication requirements, where we might be applying encryption as well. So that would be like an IPSec set of rules. And then network isolation rules. Well, those allow me to kind of restrict those Windows Store applications. So I have a particular application that has certain functions to it like it has access to My Documents library. I can restrict it and prevent it from accessing the outside world. So it's kind of a variation really of what network isolation is.

Now here's a further look into some of the ways in which we can use those different types of rules. Now I'm not going to read all of this, but it's pretty useful in describing for us what kind of situations I might use these rules. So, for instance, I could use the rules to harden my system. I might use the rules to enforce authentication or authenticated bypass which means we're going to permit connections so long as they have been authenticated and protected by IPSec. I can set up a rule that simply blocks it. Okay, preventing certain types of traffic if I need to. And that's kind of part of the service hardening idea. And then there might be rules that specifically permit traffic. So I'm blocking most traffic, but I'm actually guaranteeing certain types of traffic are been allowed. And then there might be a default rule which is where any of these other types of rules don't apply. We might have a rule that says, "Well, we're going to block that type of traffic." So that's kind of a catch all or it could be allow all that kind of traffic, but that wouldn't be the best practice. So these are the different types of firewall rules, variations of some of those four different types of rules I was describing earlier – inbound, outbound, connection security rules, and network isolation rules.

[Heading: Types of Firewall Rules. Windows Service Hardening restricts services attempting to make a connection. Here OOB configuration is used. Connection Security describes how and when it's necessary to IPsec when authenticating. Authenticating Bypass lets a configuration go through if it's protected by IPsec, though other inbound rules may be in place. Block explicitly bans specific traffic, incoming and outgoing, and even overrides allow rules unless authenticated bypass is enabled. Allow guarantees entry for specific traffic, incoming or outgoing. Default determines what happens if a particular connection is not subject to any of the above rules, for example Windows 7 default rule will block incoming connections while allowing outgoing connections.]

Back to top

1.

So now I want to talk to you about configuring connection security rules. These are kind of advanced rules and really these are the rules that make the Windows Firewall – the advanced firewall. These rules allow me to do more than just configure basic inbound and outbound types of restrictions, but now I can do things like require authentication or encryption. So let me show you how to configure connection security rules. Now, before we get into the next-next and all the actual clicking and creating these rules, the first thing we want to make sure we understand is what they are and why we would do a connection security rule. Look at this. The reason why is because we can use it to create circles of trust. And those devices that are outside of the circle, well they can't participate and access resources inside the circle. If you're inside the circle then you can access these resources.

Now the way I like to think of this is what we're doing is we're creating software-based screened networks. They don't really tie to the physical network topology, but essentially we're providing some of the same network capability that we used to do or might still do with our network topology. Let me explain. You see with the network topology, you may have heard the term DMZ, right. And so with the network topology we've got this physical area of our network...that we have some network appliances are guarding and we're permitting limited access to certain resources. And then we have the public Internet which is on the other side of the DMZ. And then we have our private network, which is protected by these network appliances, firewalls, intrusion detection systems, those things. And we're permitting access into our private portion of our network or corporate area, but only if you're authenticated through a VPN or something like that. So we have these different areas of our physical topology sometimes called screen subnets. And what we're doing is we're controlling access with the help of our physical topology in the network appliances or switches and routers in our firewall appliances.

Now, with connection security rules, we're basically doing a very similar thing. But it's not based on the wire. It's based on software. So what we're doing is we're saying we want to allow this device to have permitted access in here. We're not using a VPN so much as we are using technology very so much a VPN and that this device here has to authenticate with this device here. And they have to negotiate a secure connection with each other. That's the circle of trust. So both of these devices, this device and this device, they have firewall rules that enable them to negotiate a secure connection. That means you're in the circle of trust. Now, if you got this device out here that doesn't have a rule, then it's not going to be permitted to make a connection. This will be prevented. No, cannot do that because it doesn't have a connection security rule that will allow it to communicate with these devices here.

This is software-based enforcement, but it's highly secure with a physical topology doesn't apply or would be impossible to do. So let's say for instance, you have a machine that is like an HR machine or research and development or something that has intellectual property on it of such nature that we want to ensure that anybody connecting to it is authenticated and validated in the traffic going to and from this device is encrypted. Okay, can you imagine that with me? Now we are having this project going on. And another project going on that's requiring a lot of interaction with consultants and partners and they're coming in. And they're taking their wireless laptops and they're connecting to a wireless network. We're in conversation about this other project. Now there are different ways in which we can make sure those folks don't communicate to this sensitive machine. What I want is to use the topology, to use VLANs, to use access control list. But another way we could do this is with connection security rules. You can put a rule around your server that has this high degree of intellectual property. And even if the consultant is on the same wire, if he doesn't have the policy, the policy mean the firewall rule, he or she is not going to be able to communicate securely with that machine. You can protect that machine and isolate it using these advanced firewall rules. So that's just one example where these connection security rules in the advanced firewall becomes very, very useful.

Back to top

1.

Now this graphic shows us a little bit more about what makes up a connection security rule. It also shows us different ways in which we can verify or audit the connection. So the first point here is that connection security rules are based on IPsec. Now IPsec is an industrial standard protocol. It has a long list here of features in terms of security. So it prevents replay. It prevents somebody from stealing the packet out there and replaying it on the network. It prevents eavesdropping so people can't snoop in on your packets going by. It prevents cooking and data modification. It prevents DoS attacks. But we're not talking Windows Microsoft DOS right. We're talking about denial of service attacks. It prevents identity spoofing. So we really like IPsec. It's got industrial strength security.

Now here's a look at the IPsec protocol, the components behind the IPsec protocol. And, when you look at it, it's made up of different configuration. So you can actually choose what kind of authentication, what kind of integrity, a checking you want to include, what kind of encryption you want to use. So without going too deep into this you've got different choices here. You can do encapsulated security protocol that's what ESP stands for, and that's going to encrypt your traffic. So you can create a connection security rule that encrypts the packet as part of the rule so two devices going to talk. They both have these connection security rules and they negotiate an IPsec encrypted connection, or you can elect to use the authentication header which just simply applies digital signatures to the packets hashing to the packets basically to ensure integrity. There is a way of doing ESP without encryption and just relying on its authentication piece. So there's a couple of varieties and then you can combine them but that's usually not recommended. So if you are going to go with encryption you can choose with the different types of encryption you want. Triple DES, advanced encryption for integrity for assigning the packets like with authentication header you have MD5 and SHA and so these are different kinds of protocols. If you're interested, you know, you might look these up on Wikipedia or Microsoft TechNet to get a kind of a better idea of what those are, but that's kind of cryptographic stuff. The point I'm trying to make here is that the connection security rules support a variety of different ways you can configure your rules to support IPsec in different kinds of implementations.

Now the next thing we want to look at is how to verify you have active IPsec connections. So what you can do is you can go into your firewall environment, the firewall console. And in there, there's a section that allows you to monitor your connections and you can actually see the different connection security rule associations as they call them. And they're already listed as Main Mode or Quick Mode. Main Mode is what is done initially to negotiate the rest of the session. So during Main Mode, you have...they actually negotiate how they're going to secure the channel, how they're going to authenticate, so the initial kind of steps. And then Quick Mode, and with Quick Mode, they've got an established what they call Hard Security Association. So they're negotiated and channel is protected. Now this is driven by and agreed upon configuration between the two machines. So if there's a failure in actually the main mode or, you know, disagreement the two would try to find a common ground, but both of them have to have compatible connection security rules. If they don't, then you're going to discover these are not showing up in the console, and that's an indication that there's something wrong with the two devices if you're expecting security associations and you're not seeing them. And then that brings us to the final way in which we can evaluate our connection security rules, and that's with good old-fashioned event viewer. Where would the world be without event viewer? I wish I had event viewer in other parts of my life. Actually event viewer would be great for things like my car and my kids, maybe. Anyway you can use event viewer for IPsec as well. And there's a whole actual log in there where you can evaluate the activity, and get a better idea of what is working and potentially what is not working.

Back to top

1.

Now, because there's a new application model starting around Windows 8, Microsoft also configured some new type of rules in the Advanced Firewall to support those new applications. This is called the network isolation rules. The network isolation rules are set of rules that allow you to apply rules against Windows Store applications based on that application itself or the application's abilities or capabilities. Let me show you what I mean.

[Heading: Network Isolation: Overview. For more control over packaged apps, Windows Firewall rules can be created to restrict network access. This allows admins to control the scope of access and isolate apps from malicious networks, while still granting access on trusted networks.]

Let's begin with an overview, okay. So the idea here is we want more control over these packaged applications. And so what Windows Firewall lets me do is restrict network access for packaged apps. Packaged apps is a.k.a. Windows Store app or those AppX packages. That's what package app means. So what you can do is as an administrator you can go in and you can scope the level of network access these different applications have. And so you can keep them off the network if you want to, but you can also set it up so that they're only allowed access on trusted networks. That's the general idea behind these network isolation rules.

Now these network isolation rules have some requirement. They require that you have some domain membership because we're going to probably enforce these from over the network. You need to have the appropriate tools enable. Now RSAT tools...I'm not referring so much to having tools in all the clients as much as it is. You're going to need to have the ability to edit and manage group policy here to work with these network isolation rules. So there's a Group Policy Management Console you need to have access to. And then when you configure these on the machine. You configure this on the Windows Store app that you want to restrict or isolate or apply rules to needs to be available on that machine. It's ideal if it's installed and available on that machine so that when you build the rules for that particular application, it will see that application.

Now one of the other requirements is to define the boundaries of the network so that your devices properly understand what the intranet is versus the internet. Now one of the interesting thing is Windows Store apps might have a variety of capabilities that are included in its manifest. It might declare to Windows that it wants to use, you know, your outbound internet connection or it wants to use Near Field Communication. These parameters can factor also into the design of your network isolation policy or firewall rule. So controlling those applications based on what type of networks application wants to access. It's group policy though where you go and actually define what the networks are. So you have to have group policy as part of defining network isolation.

[Heading: Network Isolation: Networks. Windows Store Apps interact with four types of networks: Home/Work (inbound and outbound) Internet client (outbound) Internet client and server (inbound and outbound), and Proximity (near-field communication) Networks are defined using AD sites or Group Policy.]

The rules themselves are created much like other rules. You're going to go into the Windows Advanced Firewall and there are going to be some advanced options where you can indicate specifically applications with certain capabilities and restrict them or isolate them. And say, "I only want that Windows Store app to work on the Internet." So after you define your network, you can tell the Windows Firewall rule to enforce some rules around an application with that capability or you can target a specific application. So you can target capabilities or target applications and define your firewall rules around those.

Back to top

1.

A discussion about Windows threat resistance and security wouldn't be complete without Windows Defender which is Microsoft's built-in antimalware. Now let me be a little honest here. Some of you might be like me and you use a third-party antimalware for your Windows 7 machines. And so you might disable Windows Defender. And if you're like me, you see a topic like this, you might be tempted to fast forward to something maybe little bit more interesting. Windows Defender is probably not on your top 10 list as to what you want to learn about Windows 10. It's not the sexiest technology or feature. But as I was researching this content I was not really expecting much, but I got to tell you I was surprised by Windows Defender. Let me show you why.

[Heading: Malware Advantages. Malware authors know the product. Industry reactions to malware threats is approximately eight hours. Signature-based projections are too slow to react. In 2012, MS says that 40 million computers were infected. Google research says that the best antivirus scanners only detect 25% of malware.]

Now we need to look here for a moment at the key advantages that the malware author has. If you're a malware author, you have some key advantages over the average Windows user. This includes of course a strong understanding of the operating system and some of those malware writers that are out there, well you guys are pretty clever people. The other advantage here is the window of opportunity that you're given when you deliver a malware that's targeting a particular exploit. You see once a vulnerability is identified and published and exposed out there, a malware is quickly written. They call this zero-day exploit. It's quickly written. It's unleashed upon an unsuspecting, unprotected world. And the industry and the vendors rely on update systems that are just, you know, inherently slow. It takes a while to write the updates, get them up there, and clients download them in a while for those all to be written and applied. In the meantime, the malware is running amok and it's hammering away at systems. Do you remember the Heartbleed exploit? That was a problem with SSL implementation on some web servers and how cyber catastrophic that was. So there's something here that I want to point out and that is malware has some key advantages. And one of the goals behind Windows Defender is really meant to kind of eat into or cut into these advantages. So I want to show you how Windows Defender seeks to do that.

Now remember when Windows Defender first came out, it was not call Windows Defender. It actually had its roots in another antimalware product from Giant software. So Microsoft acquired Giant software and it was a well-rated security tool. And I used it quite frequently, and I was excited when Microsoft acquired it, and it became part of Windows. Now it was not long after it was acquired by Windows though that I stopped recommending it to my customers and instead of looking at third-party solutions. And part of that has to do with the fact that it had limited features. And I quote, "Microsoft here they referred to Windows Defender as a limited antispyware solution. And some of the features that was in the original product, they moved to Windows Security Essentials." So you either were using Windows Security or Microsoft Security Essentials as it was called, or you were using a third-party solution. Alright, but what is the deal with Windows Defender in Windows 10? Because Windows Defender in Windows 10 is not the same as Windows Defender in Windows 7. Windows Defender in Windows 10 has seen multiple enhancements over Windows 7. In fact, Windows Defender replaces Microsoft Security Essentials, and Microsoft would tell you it's now a full-featured security solution. Well what does that mean? Well, as I was saying it has range of enhancements over its predecessors, and I want to explore these in the upcoming sections here. That include things like real-time scanning and background updating and a lot more.

[Windows Defender has full-featured security solution, it provides real-time protection, it has enhancements over Windows 7, and it is designed to be unobtrusive with automatic updating.]

Back to top

1.

All right, so here's a look at these new features in Windows Defender that make it stand apart from what it was in Windows 7. A just quick summary here. We've got now antirootkit protection. So, in addition to real-time scanning, we have antirootkit protection – so the ability to protect the boot process. We also have in Windows Defender, the ability to extend its brain so that we're not just relying on definitions, but there's an ability for to tap into global sensors and to actually monitor the behavior of the files themselves. And that's a technology called Shields UP. And we'll talk a little bit more about that in a moment. There's also background updating. That's also a part of the new features in Windows 10 to basically mean for it to be as unintrusive as possible, so it's not interrupting the user. Now, in terms of managing Windows Defender, there are some centralized ways in which it can be managed. So it has improved manageability capability. PowerShell commandlets with the noun MP for malware protection that's what that means. Now one of the things I should point out is that it's not exclusively a client feature. Windows Defender is also built into Windows Server which is pretty cool. Now another point I should make here is that Windows Defender – Microsoft says – is ideal for consumers or unmanaged PCs. So it has the management capability. But, for a business, you probably have some alternate solutions for this. It's also interesting to me that Windows Defender is actually the same engine that Microsoft uses for Endpoint Protection which is really what they use to target businesses for corporate protection antimalware.

[Heading: New Features in Windows Defender. The scanning Improvements in Windows Defender are Early Launch Antimalware or ELAM support to prevent rootkits and protect drivers, ability to tap into Global Sensors, and new intelligent scanning with Shields UP! And Antimalware Scan Interface or AMSI components. The management improvements are improved manageability tools and methods. It is also built into Windows Server.]

So here's what actually surprised me in regards to Windows Defender. And that is it has additional awareness of risk levels and they can monitor the network and respond accordingly based on, you know, the risk level. In other words, it has like this ability to know the difference between your backyard, a neighborhood park, and a dark alley. So you might be, you know, playing badminton or handball in your yard, but playing that in a dark alley – you know – at night time, well, there's additional risks that are inherent with that. What is the same could be said about files and file operations? Some of those files might be coming from your local network or they might be coming from a USB stick or they might be coming from the Internet. And they might be asking to do something that is a bit more risky, more suspicious. They might be trying to change a Kerberos ticket, might be trying to perform an authentication event. So these are the types of things that Windows Defender has been made more aware of so that it can actually respond to that. Here's another interesting thing that's been enhanced in Windows Defender and that's AMSI capability. AMSI is Antimalware Scripting Interface. And it's supported by Windows Defender. But it can also be accessed by other third-party antimalware solutions. And the idea here is this is specifically meant to kind of address some of the techniques that malware writers use to fool antimalware by, you know, obfuscating their scripts. Ultimately, any kind of input into the scripting engine has to be deobfuscated. And so AMSI is an opportunity for that information to be intercepted by Windows Defender. And so it makes it more resilient to more responsive when it comes to running scripts which, you know, could potentially be trying to sneak their way past Windows Defender.

[Heading: Shields UP! In Windows Defender. The features of Shields UP! are awareness of risk levels behind file sources and actions, network behavior monitoring for richer content, and it scans downloaded deobfuscated scripts using AMSI.]

Now here's just a quick example of how that Shields UP feature in Windows Defender works. Now remember, Windows Defender is more context aware and that's the idea that its scanning intensity and its level of alertness goes up based on the context. So a file might arrive via e-mail and the operating system indicates the files from the network. Now this is a common even enough kind of activity, right. But it's also a common type of attack vector. So Windows Defender begins to scan this file in response to that. But then if the files activity becomes more suspicious like it starts requesting admin rights, well, then the scanning for Windows Defender becomes more intense. And so additional resources in terms of the way Windows Defender kind of antimalware countermeasures that it evokes will get more intense and the activity will be more focused on trying to determine if that file is actually trustworthy or not.

[Heading: How Shields UP! Works. Shields UP! works in the following way. A file arrives via email. With Windows Defender Scan, the OS indicates that the source of the file is the network. Then it processes a request for admin rights. The increased scanning intensity is due to untrusted source of the file and admin rights request.]

Now here's another way in which Windows Defender is trying to cut into malware advantage. Remember, malware advantage means it's got that period of time where the industry in the market and everybody using the systems are trying to respond. And so the security vendors are getting updates, mugshots are getting updates, clients are downloading those updates. Well, one of the ways in which there can be kind of a cut into that advantage is taking advantage of the cloud. One of the things that the cloud does is the cloud has given Microsoft a great deal of opportunity to gather unprecedented amount of data regarding what is going on out there. So you might have malware detections and malware alerts that are occurring in another continent and because it's occurring over there, that gives a greater degree of response capability for protecting systems, you know, in another continent. And so the cloud creates a place where all that information can be gathered around the globe. And then action can be taken in a far, faster way. So you can shorten that window of opportunity that malware has – making it more and more difficult for malware to kind of unleash and spring across the globe.

Another enhancement to Windows Defender is management. The fact that we can manage Windows Defender in some rich ways...big one I think is PowerShell, but there are other ways in which it can be managed. Group Policy capabilities, and then because it's the same engine with Endpoint Protection, there's also some enhancement in terms of kind of corporate management. So managing Endpoint Protection through Configuration Manager. You have the ability with MDM – so management capability in there. And then some management capability for reporting purposes through System Center Operations Manager. So System Center Operations Manager can interact with that information because it's, you know, a warehouse of alerting and auditing information across multiple systems. And so you can install Operation Manager agents and the appropriate management pack and monitor and audit your systems that way as well.

Back to top

1.

Now Windows has some other internal protections. Some of these are new. Some of these have been around for a while. But all of these give an additional threat resistance. So we've got font block. We have ASLR, DEP, and SmartScreen. Now let's start with font block. What is font block? Well, fonts are notorious ways of attacking the system. So it's not uncommon for someone to inject like a PowerPoint file or some other content with a malicious font and use that as a way of attacking the system. In order to prevent that I should say, Microsoft has a feature called font block. And basically it prevents fonts from requesting elevation and attacking the system in the same way they have been doing for years. So this is a nice, little enhancement. But it's got big impact.

Now a couple of other additional features in Windows and that is the Address Space Layout Randomization. A lot has to do with the way attackers address memory. So buffer overflow attacks and other ways of crawling memory, pass the hash type of attacks, those types of things. So the more we can protect our memory spaces, the more secure the system will be overall. So Address Space Layout Randomization does just what its name implies. It's a big, long acronym, which enables Windows 10 to kind of randomize memory locations to make it a little bit more difficult for malware. We also have DEP. DEP has been around for a while. This is data execution prevention. And the idea behind this is it reduces memory available for code execution. So again, we're talking about restricting and controlling memory. And what we're doing here is – with the help of processor and hardware – restricting different addresses and preventing execution. So, when it comes to memory, some memory permits been written to, some memory permits been read from, and some memory prevents or allows execution. Data execution prevention kind of quarantines certain areas of memory to prevent code execution because it's like read-only areas. And so that way those read-only areas don't become attack vectors, don't become areas where code can be injected into it. And, from there, take advantage of the system.

And finally, we've got SmartScreen and phishing protections. Now SmartScreen and phishing protections, this is based on application reputation. So Microsoft maintains a list of known applications that are suspicious or known to have a reputation of been malware. And so the SmartScreen feature in Windows can pair an application against that list. So you might think of this as kind of like the FBI most wanted. There is this known list and so application execution can be prevented by simply the SmartScreen Filter saying, "This guy is on the bad application list." I'm not going to run this, so this is just another enhancement that makes the system far more resilient otherwise.

Back to top

1.

So here's a challenge for you. Let's say you wanted to exclude a process from being scanned by Windows Defender. So let's say, for example, I've got this tool here Bginfo.exe which is actually writing this information here for me up here in the corner as you can see. So my question to you is how do I exclude Bginfo.exe from Windows Defenders scans? Think about that for a moment. Feel free to pause the video and then resume it when you're ready.

[The SysinternalSuite folder is open in Windows Explorer. The presenter points to the Bginfo.exe file in the SysinternalSuite folder.]

Okay, so the challenge in front of us is how do I configure Windows Defender to exclude a process. In this example, we're doing Bginfo.exe. First things first, let's bring up Windows Defender. And once I've got Windows Defender up and running, the configuration settings is found here, which brings me up into the Settings application. And notice, I'm in the UPDATE & SECURITY categories. So the other way of getting to this would be from Settings and choosing UPDATE & SECURITY. And then I can configure real-time protection and all of those different settings. But, if I scroll down, here's the category we need to go to and that's Exclusions. So you need to come here. Choose Add an exclusion. There we go. And the next thing you can do is define Files, Folders, File types – again scroll down – Processes. So the solution to the challenge is to come into the Settings of Windows Defender, scroll down the Processes under Exclusions and then select that specific process like so.

[The presenter opens Windows Defender. He clicks the Settings option to open the UPDATE & SECURITY page. The presenter navigates to the Exclusions section and clicks the Add an exclusion link to open the ADD AN EXCLUSION page. He navigates to the Processes section and clicks the Exclude a .exe, .com or .scr process button. A dialog box opens and the presenter selects the Bginfo.exe file and clicks the Exclude this file button.]

Back to top