Last week was (unofficially) Device Guard week here at 1E. Not only did we have our Device Guard webinar, ‘Beating Malware with Device Guard and AppLocker’ (the second in our Windows 10 Security Webinar Series), but we also unveiled an exclusive white paper, ‘Understanding and Deploying Device Guard’. The former was very well attended, meaning Dave Fuller and I were unable to respond to all of the questions submitted to us. Here are all the questions we missed, answered in full. Miss the live-broadcast? Watch the webinar on-demand now!
The PowerShell scripts used in the webinar – are they available for download?
The scripts are not my own. I got them from an Ignite session back in 2015. However, the scripts are publicly available in that they presented it publicly. We can make the scripts you saw in the demo available – we’ll figure out how and when we’re going to do that soon.
Is Device Guard dependent on TPM (Trusted Platform Module)?
No it’s not. However, TPM is essential if you want to deploy Device Guard in the most secure manner possible. That includes being able to secure the policies, and to use Measured Boot (as part of the Device Guard end-to-end security), when it comes to interacting with UEFI Secure Boot to ensure the hardware has not been compromised by rootkits and others – and to ensure that the drivers that load are actually trusted.
Are Device Guard or AppLocker actually able to report ‘security breaks’ (i.e. attempts to run unsigned software) on their own to any given database? Or do I have to collect these events for every client by myself? Also, are you planning to release a GUI for Device Guard and/or a SCCM plugin?
For the first part, Device Guard only writes to the Event Log today, on the machine that it’s running on. There’s no centralized management, no storing in the database. But the Event Log does capture when unsigned or untrusted software is attempted on the machine. That information can be collected in a centralized manner, using Windows Event Log, or you can have the events forwarded to a Syslog Server. If you want to get more advanced you can use a third party like Splunk.
Regarding the second part of the question: not at the moment. There is a need for that to help simplify things, however. As I said in the webinar, Microsoft at this point has purposefully made Device Guard a scripted solution using PowerShell scripts and has not provided any front end or UI to simplify things.
Device Guard is a very powerful tool– they want you to be very deliberate about using it. And sometimes GUIs and UIs make us to relax and trust what’s happening after you click ‘ok.’
Do I have to generate hashes for every model of hardware I have in my environment?
No. You just need to ensure that, before you deploy an operating system, the drivers that each of your supported hardware models need are actually signed by a trusted publisher. That publisher could be, and most likely will be, a hardware vendor, or the vendor who wrote the component itself in the system.
If you have unsigned drivers you use, you can sign them yourself using Catalog Files, or you can sign the driver yourself before you distribute them.
We currently use AppLocker. Would this combination protect us against the new malware that uses purely Java scripts? (We allow Java for the web browser and do not block it with AppLocker for that reason.)
Taking it back to the bouncer and bartender example: Device Guard is binary. It’s only trusted applications and publishers will be allowed to run on a machine, period. If you’re not listed in the Device Guard policy as a trusted publisher, then by default Device Guard will block it from running.
Let’s take, for an example, Microsoft Word. Word is going to be trusted because Microsoft as publisher is trusted by Microsoft. However, if when running Word you have a macro that has been written by a third party or malware writer or other, and that gets into your environment in some way – maybe via your edge network or edge security, or if your Firewall or IDS or IPS systems failed to detect that macro as malware – Device Guard is not going to be able to block that, because the application that’s running the macro is trusted by Device Guard.
It doesn’t even have to know about the macro, it’s just that Device Guard trusts Word and everything that Word does. In that regard you still need the combination of Device Guard and something like AppLocker to provide a more comprehensive and granular way of controlling how to handle exceptions – as well as a combination of intelligent anti-virus software.
What about malware that shims other application processes and looks like other applications?
While I can write something that looks like Word, and even acts like Word – it isn’t Word. What I’ve written isn’t trusted by Microsoft. That’s why it’s so important to ensure your first line of defense is that all your applications and scripts and others are digitally signed. It’s a proof of authenticity.
The second thing is, the files that I use will not have the same hash, the unique hash value, that Microsoft Word has. That’s the second line of defense: the same attributes, like hashes, that are used to further define and validate uniqueness.
We have thousands of applications; how can you add hashes or certificates after the initial scan? The installations of thousands of applications on one computer is not viable.
In an organization with thousands of applications, you’ll typically look at your environment as different departments and work out what applications are being used in each department. You may start with an initial policy with just a ‘base build’, then you can create new policies on department-specific PCs. You can merge new policies with the initial policy to add signer and hash level rules for applications that were not included in the initial policy. Alternatively, for unsigned applications you can create Catalog Files that are separate from the policy but record the file hashes for a specific application. There is a tool called PackageInspector in Windows 10 that enables you to automatically generate a Catalog File by scanning the PC before and after installation of the application – the resulting Catalog File includes hashes for all files added to the device.
Is this an enterprise solution? What about central reporting?
From a deployment standpoint, yes, you can use tools like Group Policy and Active Directory to do things like collect Catalog Files, create Catalog Files, distribute Device Guard policies and things like that. It’s probably not as enterprise ready as you may be accustomed to with other tools, but there are other enterprise tools you’re probably already using in your environment that can be used to fill those gaps that Device Guard alone might otherwise have.
Is there any way to improve the Device Guard error dialogues?
Not at this point. Those error logs are hardcoded and there’s no opportunity for customizing them yet, at least that I know of.
What would be the best mix Device Guard and AppLocker for big enterprises (>70,000 clients)? How it could be managed?
Again, our Device Guard white paper should provide some clarity on this point. But essentially it all starts with understanding and knowing your application deployment in the environment. You don’t necessarily have to know how it got there, you just need to know where it is, on what machines. From there you want to build relationships between the applications and the machines they’re installed on, and the users of those machines, as well as what users belong to what departments or business units. Once you can do those mappings, that information and data becomes alive, because now, you will be able to map and understand what the relationship is between software in my environment and what business unit or department uses it.
Once you know this you know how to build a reference model or image of your entire organization: now we can create a finance image, and then ultimately a finance policy, and deploy that. Or you can create a finance policy, one for HR, one for IT, and then merge all of them into one single enterprise policy. That’s ultimately where you want to be, that’s how you manage it.
If a 64-bit driver is self-signed, is it still 100% OK during the boot process?
As far as I know, signing of a 64-bit driver doesn’t mean it has to be signed by a known publisher: if the driver is not signed you can sign it yourself, using the process I mentioned earlier. Now, you can also co-sign drivers and applications. You can do that by having multiple digital signatures on a machine. But as far as I know a self-sign driver is just as good as a driver signed by a hardware manufacturer.