Fight Malware With Software Restriction Policies

Good news for Department of Defense folks. They can now start using USB flash drives again -- provided there's absolutely no other way to transfer the data from point A to point B. OK, so maybe it isn't time to rejoice just yet.Strict rules are still in place limiting removable media use to mission-essential operations after meeting stringent compliance requirements. According to an article from Federal Computer Week, "randomly selected users and drives will be subject to periodic auditing under the new policy." The article went on to state that the Army plans to continue the ban for now.

I know I wrote before how I thought this was a knee-jerk reaction similar to the quick ban on social networking sites by Marines. Unfortunately, I don't have an inside look at what really went down, but I'm curious about what steps they took to triage the situation. Did they just cut it off because they didn't have the manpower to deal with the issue? I'm guessing it's the latter because, as one of my readers pointed out, doing so is the easiest and nips it in the bud quickly.

I was doing research a few months ago because I knew of several organizations having a problem with USB flash drive-based malware infections. The solution I came up with used nothing but built-in functionality in Windows that was then configured throughout their networks by pushing out policies via Group Policy. At first, it seemed too brain-dead simple to be a workable solution, but sure enough, Software Restriction Policies (SRPs) worked like a charm.

SRPs are essentially a built-in whitelisting capability included in Windows since XP. The configuration options aren't as powerful and easy to manage as some of the commercial offerings, but it does a good job of keeping malware that spreads via removable devices. It also does a good job of preventing drive-by downloads from running from a user's temporary Internet files folder.

The way the policies work is they prevent executables from running unless they match a cryptographic hash (MD5, SHA1, or SHA-256 depending on the version of Windows), are signed with a specific certificate, are located in a particular path, or are downloaded from a certain network zone.

Microsoft's documentation on SRPs is OK, but I ended up finding an excellent resource that walked through how to configure the policies specifically with the idea of using it to combat malware.

So SRPs keep malware and other executables from running from that don't fit the policy, but they won't keep malicious executables from being copied to approved paths. While that may be a gotcha, some antivirus products, like McAfee VirusScan Enterprise, have Access Protection rules that prevent executables from being copied into commonly SRP-exempted areas, like "C:\Program Files" and "C:\Windows\."

Adding those to things together result in an extremely limited attack surface. Of course, I don't know what the actual DoD environment is like and how easy it would have been to enact SRP quickly, but I would have liked to have been there and given it a shot ... instead of seeing them shoot themselves in the foot.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.