Are additions for Exploit Guard and Application Control coming any time in foreseeable future? (Or at all?) #64
Comments
|
This repo is pretty out of date at this point. I'm not sure if we're even going to continue updating it because there doesn't seem to be much interested. Might put it into archive mode. WDEG, yes... as far Exploit Protection ( which is the closest equivalent to EMET) is concerned. The latest SHB download has an XML file implementing Exploit Protection in a way that is similar to previous guidance for EMET. I believe the latest Windows 10 STIG download has a copy of this XML file in the support files folder once the STIG is unzipped. The rest of WDEG requires WDAV to be the active AV and DoD doesn't currently use WDAV. I wouldn't expect anything to be published anytime soon, but the other components are mostly binary (on or off) configurations. We had some scripts to create a WDAV configuration. It was removed in the commit that corresponds to #59 since it never made it into the SHB. I wouldn't expect any updates to that anytime soon. You can grab the Device Guard (since that's what it was called at the time) files from the repo at that commit state (or the commit prior). Those files probably need to be updated. |
|
Latest STIG for Windows 10 is here as zip file: https://iase.disa.mil/stigs/os/windows/Pages/win10.aspx It should have the most recent XML config for WDEG Exploit Protection. It is pretty basic, but we needed to start simple and not repeat the mistakes we made with EMET (being too aggressive with settings). |
|
As far as additional guidance, there isn't anything coming soon because DoD doesn't use all the Windows Defender product line security features at this time due to using a solution from another vendor. It is sort of a chicken and egg problem though. If the guidance doesn't exist, then that probably means those features won't be used. Creating that guidance doesn't mean those features will be used either since other vendors are the mandated solution. |
So, when you refer to "this repo", do you mean this section of the SHB or the entire SHB as a project? In general, what is the status of the SHB with regard to the DoD? After upgrading to Windows 10, are the various commands simply ignoring the directive to enforce the SHB? Is this related to IAD being folded back into NSA? Any information you can share would be helpful -- thank you! |
|
@iadgovuser1 It's been a while since I looked at that STIG, so I'm actually glad to see that the latest version of the EP xml ruleset isn't just a port over of the EMET rules but also configures at least a few of the newer Win 10 EG specific settings (like blocking child process creation). I will merge some of those EP rules into my own rulesets. As for not encompassing the new ASR rules that currently require WD AV or WD ATP to be configured as the "primary" AV, that's understandable for the reasons you note. (Hopefully, MS will remove that dependency at some point.) I'm puzzled as to why the STIG doesn't configure a Windows Defender Application Control policy, though. If you want to effectively port over the old EMET ASR rules on module loading (to block flash.ocx in Office, for eg.), that's now the supported way. Likewise if you want application control/whitelisting to (at least in theory) be protected by virtualization-based security. I had recently seen the Device Guard scripts you mention (after reading the old associated IAD item about using Device Guard to configure administrative workstations), and gave them a quick look. Potentially useful, but, as you said, in some need of updating for 2017 & 2018 Win 10 developments. When I get some time I might try to modernize them a bit and publish the results to my repo of App Control/Device Guard/Exploit Guard content. (Ultimately, it would be fantastic if the new "NSA Cyber" itself were to start producing detailed, well-explained guidance for newer Windows security capabilities on the NSA website, as the old IAD did so usefully for many years. But I get the impression that's unlikely. A shame.) |
Think of this repository as a lightweight SHB framework without using the real SHB framework. This repository was meant to help DoD customers who couldn't access the CAC protected SHB framework download. This repository was also meant to help some federal government customers we are legally allowed to support who will never be able to access the SHB framework download due to licensing issues. We've had little, if any demand, from those set of customers of the last year or two to use this repository. The Windows SHB framework is alive and well. It has two major releases a year corresponding with Windows 10 releases and then a number of minor maintenance releases between those two. DoD service components are generally doing well with the majority of office IT systems being on a supported release of Windows 10 thanks to Microsoft continually extended the support dates. This doesn't have anything with the NSA re-org. The IA mission still exists, but it has been distributed across NSA instead of being a separate directorate and rebranded as NSA Cybersecurity. It has more to do with that we have limited resources on the IA side and need to apply those resources where we have the biggest bang for the taxpayer buck. NSA is a co-lead of the Windows SHB and is very involved with it and the Windows STIGs. I could go on why the approach we used in this repo is the wrong approach and why the right approach would need major changes (technically and bureaucratically). Maybe we can discuss it more when I help teach the GCWN class! ;) |
That would be great! :-) I'm at all the big conferences, like CDI this December in WashDC.
I understand, and I'm glad to hear that, internally, the SHB framework is alive and well. I was worried that there would be less funding or support for these kinds of projects after IAD was merged into NSA proper. Anyway, thanks for the info, and feel free to contact me offline (jason[at]sans.org) or come find me at any of the big SANS conferences! Cheers, |
|
We are definitely looking at adding more to the EP XML over time. We will likely start by adding some auditing settings for some more processes (lsass is a good example). One thing we learned that we messed up with EMET was that we were probably a little too aggressive on the settings at first. There was a lot of push back from DoD service components on EMET. As far as WDAC goes, you bring up a good point on converting the EMET ASR rules. I think the next Windows STIG update is January so we could investigate for that. We haven't touched WDAC because it is like AppLocker on hard mode. A few years ago DoD service components tried to deploy AppLocker and it didn't go well despite our published (and internal) AppLocker guidance which is now outdated since the folks who wrote it all moved on. Maybe that will change with AaronLocker, but I doubt it. In my opinion, Microsoft needs to create a cloud service offering that can ingest AppLocker and WDAC audit events and help you author policies to really see wide adoption. I'm not a fan of Managed Installer, but I don't know if it is really used inside or outside DoD. NSA Cybersecurity still produces guidance like IAD did. It is just buried now that iad.gov has migrated to nsa.gov. See the Resources for Cybersecurity Professionals section of the https://www.nsa.gov/what-we-do/cybersecurity/ page. I actually have a script that parses both the old site and new site and grabs all the links to published guidance. It could generate a convenient markdown page, but some folks might not like that. We used to produce more guidance, but everyone uses STIGs because there is an inspection program for compliance to STIGs (called CCRI). Contracts are literally written with requiring compliance to STIGs. NSA uses STIGs over the IA/cybersecurity guidance that we publish. Back around Windows Vista, NSA decided (it might have been Tony Sager) to have vendors write security guidance instead of NSA because it would be officially supported, not break the OS, and be more reasonable. It made sense, but STIGs took off in the absence of NSA Security Configuration Guides. We generally recommend using vendor guidance (100% gov guidance and 100% vendor guidance models both have flaws in my opinion). Internally, guidance isn't as "cool" as other projects (yay, I wrote a paper that I can't prove anyone used). Policy wise, NSA SCGs and DISA STIGs have the same level of authority, but due to reasons I already mentioned no one really uses SCGs. There are lot of hurdles to overcome for publishing guidance and it is the same level of difficulty whether or not the changes are major, minor, or a new publication. The IA/cybersecurity mission is already severely underfunded and understaffed so there's little incentive to put a lot of effort into something that has little bang for the taxpayer buck. There are so many other areas where we have provable positive impact. That being said, I could see guidance being published if DoD allowed more than one security provider. Currently only one provider is allowed. |
Believe me, I concur. I most definitely concur. Setting aside the frustration of rule & policy creation (about which I could write a great deal), a substantial problem currently with the overall idea of replacing EMET ASR protections on Windows 10 with WDAC block rules--which, after all, is the official word from Microsoft about what we're supposed to do-- is that today there's still no supported way to configure any User-Mode Code Integrity rules without putting Constrained Language Mode into effect. There is (as you may know) an option documented for WDAC called "Disabled: Script Enforcement" that obviously supposed to deal with that. And it was apparently introduced in fall 2017 right along with the actual ability to specify rules for modules/addins/etc. The problem is that "Disabled: Script Enforcement" doesn't actually work, and it has never worked. Now, for many, many common user cases having CLM enabled is fine. Often quite desirable, indeed. But if you're an org that, for example, does some really important administrative tasks via Powershell scripts that aren't CLM compliant that makes turning on any WDAC UMCI rules a problematic thing. A service that could read logs and configurations from numerous diverse machines and come up with a few centralized lists of AppLocker and WDAC rules might well be very helpful. (I've had similar thoughts as well.) The closest--and it's not that close, really--to anything like that MS has announced or shipped is, I think, WDAC integration with the Microsoft Intelligent Security Graph app reputation service. Which basically amounts to Microsoft maintaining a single, huge cloud-based list of programs that have developed significant positive app reputation and their associated executable files, any of which (when this option is enabled) WDAC is supposed to authorize to run without needing specific allow rules. This is something I've been looking at recently, and so far... well, I'll just say in sum it seems to "sort-of work" right now. The concept has some major appeal to it (as well as a few inherent tradeoffs), but really the implementation seems somewhat technically immature/buggy at this point. (In my own testing experience, anyway.) Finally, on the guidance question, let me just say this: I think I understand well what you're saying about limited resources, and about expending those resources on things that will deliver the most value. From everything I've read and heard in recent years, I'm sure that even if headcount and budget for NSA's defense-related mission/s could somehow magically multiply three-fold (or more, likely) tomorrow there would still be absolutely no shortage of important work to go around. I'm also not surprised that guidance isn't seen as quite as cool internally as some other, more technical activities. That said, as a complete outsider to both the IC and DoD, I wonder if everyone inside NSA fully appreciates how influential NSA explanatory guidance was before the apparent 2016-ish change of priorities away from producing in-depth materials. AaronLocker is actually a great example: despite being from Microsoft, in approach and some details it represents (as far as I can tell) basically an evolved version of NSA's AppLocker work you mentioned. My guess is that other things like EMET (pre-Win10) and Windows event logging & forwarding would have seen significantly less adoption than they have without NSA IAD guidance and advocacy. People listen when NSA talks, both because of the touted technical excellence of its personnel and it's pretty much unique position, with a role that cuts across defensive operations, red teaming, offensive operations, etc. I'm not sure that any other institution can fill what used to be its role here. Certainly, so far I don't think anyone else really has. Thanks for the very insightful reply. And for all the things you folks on the defensive part of things are trying to do, day-in and day-out. |
I use your SHB toolkit at github for study of security settings and scanning of the systems and applications. it would be a pity to end the development. this repo is very usefull. |
|
@michalzobec Thanks for the feedback. I think archiving the repository is still going to be its ultimate fate. |
and others
With Microsoft's replacement of EMET by a combination of Windows Defender Exploit Guard (exploit mitigations) and Windows Defender Application Control (module loading controls) on Windows 10, EMET was removed from SHB and this site. However, after at least a year post-replacement, guidance and GPOs for the successor technologies still remain notably un-released.
Remembering the quality of guidance that accompanied the EMET rules, and especially considering the paltriness of guidance & documentation on these integrated defenses from other sources so far (even MS doesn't have useful documentation available for many of the security features released in 2017 & 2018), is the development of similar rules and guidance (plus, hopefully, some work on the actually new security options introduced in WDEG and WDAC) for use of these follow-on Win 10 security capabilities underway? If so, might we expect to arrive sometime in the near-ish future?
The text was updated successfully, but these errors were encountered: