![]() Easy.įigure 2 ' Automatically Creating Whitelist Rules AppLocker figures out what's on it, and generates rules to allow all of those applications. ![]() Most companies will start with a standard corporate desktop image that has all the standard corporate apps, and use that as their reference machine. The idea is that you take some machine that represents an 'allowed' set of applications. The sheer magnitude of an inventory project can often consume more time and more resources than you'll pay back with AppLocker, especially in smaller- and medium-sized businesses that don't have extra IT resources lounging around the datacenter.ĪppLocker works by scanning one or more reference machines. We're not talking about copies of Office, we're talking about the litany of line-of-business applications, tools, utilities, and other little pieces of software that people run. The problem is that modern organizations have hundreds, if not thousands of applications. Blocking applications isn't a new idea what's supposedly new is the ease with which you can construct that whitelist. After all, AppLocker's roots are in SRP, which goes all the way back to Windows XP. The problem with AppLocker all comes down to how you generate that whitelist. By poring through the log entries (sounds fun, right?) you can ensure that you've accounted for every permitted application. This is a key part of setting up AppLocker: By configuring those event logs to forward to a central computer, you can see which applications AppLocker might have blocked simply because you forgot to create a rule. AppLocker can also be run in audit-only mode, wherein it generates event log messages about the applications that are running. AppLocker intends to deny applications by default, only allowing those that have a rule permitting them to run. Configure rules in a GPO as well, and you're up and running.įirst, a couple of differences between the old SRP and the new AppLocker, lest you think that AppLocker is just a quick way of generating SRP rules. On the face of it, this is pretty easy: Just get the service up and running on your client computers, something you can do with a Group Policy object (GPO) if you prefer. If an application isn't permitted by your rules, then AppLocker prevents it from executing.ĪppLocker logs verbose information to the Windows event log system, showing you which file was affected, whether it was blocked or allowed by a rule, the name of the rule, and so forth. Once enabled and running, the service reads application rules from Group Policy and evaluates every application that attempts to execute on the computer. In other words, this service basically makes AppLocker work. This service is designed to read application rules from Group Policy, and then identify applications accordingly. To begin with, inventorying applications requires configuring client computers to run the new Application Identity Service, something that ships with Windows 7 but isn't enabled by default. To be sure, AppLocker is still a complex piece of business, and it's far from perfect. You can, of course, edit that to remove the already-installed applications that you don't want to permit, and you can maintain the list going forward. On paper, AppLocker scans your environment to find the installed apps and automatically constructs the whitelist for you. It is a new feature of Windows 7 billed as the solution to SRP's tedious application whitelist maintenance. Many, many organizations simply didn't have the time or resources, and so they gave SRP a miss. Oh, organizations definitely used it, and it works as advertised, but the process of assembling and maintaining that list of approved applications was incredibly complicated and time-consuming. With SRPs, you'd make a big list of all the applications you wanted to permit, and nothing else could execute. ![]() In Windows XP and Windows Server 2003, Microsoft introduced a technology called Software Restriction Policies (SRP), a part of Group Policy that was intended to keep unwanted applications from running. Getting it to not run applications kind of goes against the grain. Windows' primary function, after all, is to run applications, and it does a pretty good job at it. Those can not only cause support issues, but outright financial damage if you're caught. There's also that whole class of 'quasi-business' applications that have an arguable business benefit ' but which your company hasn't paid for, isn't licensed to use, and doesn't want. And those are just the applications your users know they're not supposed to be running. These things kill productivity, hammer the network, and half the time seem packed with junkware, spyware, and who knows what else. Try as you might, you'll never stop your users from getting to all of them. For one, there are those our users aren't supposed to be running: Streaming video. None of us love all applications equally.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |