Today's conventional wisdom when it comes to IT security software is all backwards. Driven as much by the need to sell software as it is for truly protecting your environment, security software seems to be more about adding band-aids than creating true protection.
Think for a minute about the types of security solutions you install to your desktops. Antivirus, antimalware, and even firewalling solutions are necessary add-ons because your core operating system wasn't correctly protected in the first place. Code that should have never been executed on your desktops is allowed to run because of the outwardly permissive nature of the Windows OS.
As a result, numerous software companies have developed some intelligent solutions for protecting systems against the threat of malware execution. By scanning for malware's presence on your system and actively looking for its signatures, these solutions take a reactive approach to keeping systems clean. In effect, their job doesn't start until after an infection has already begun. It's then that they do their best to clean up the mess and prevent further outbreak.
The problem with this approach lies in the OS itself. As an entity that's designed to execute code no matter what that code attempts to do, you can argue that the core operating system is the reason why malware exists. Without an operating system to run atop, today's malware writers wouldn't have a platform on which to execute their nefarious activities.
All of this talk of reactive solutions begs an alternative approach, one that proactively prevents code from ever executing in the first place.
Consider a situation where you the administrator determine exactly what codes can and cannot be launched on your systems. If you haven't specifically allowed an executable to run, it will not run. Whether that code is malware, games, inappropriate and unapproved software, or even the most recent version of Microsoft Office, such a system would enable you to retain ultimate control over what software executes on your network. Such an environment would prevent anything inappropriate from ever executing unless you preapproved it, because your operating systems at their core simply would not allow it.
Such a security nirvana is Microsoft's new AppLocker feature.
The concepts behind AppLocker are not entirely new to Windows environments. With its roots in Group Policy's Software Restriction Policies (SRP), AppLocker arrives as an evolutionary advancement in a technology that didn't get much attention in its previous version. With both AppLocker and SRP, individual operating systems in your network environment gain a centrally-manageable policy infrastructure that determines the exact executables and DLLs which are permitted to execute.
The Power in whitelisting
Consider how virtually every piece of code in your environment today operates. In order for code to function, some form of executable must be instantiated on a system. The payload of that executable accomplishes some form of work. That work can be the running of an Office application. It can be a line-of-business application. Over your lunch hour, it can be Solitaire's sol.exe file. In any of these cases, the only way to accomplish the task is to run the executables.
In a normal environment, any executable is automatically run as it is instantiated. This is by design with the Windows operating system, enabling it to retain compatibility with applications that users might need to run. Unfortunately, this permissiveness enables malware to run just as easily.
AppLocker changes this by requiring the preapproval of executables before they are allowed to be run on a system. With AppLocker, any time an executable attempts to run, it is checked against a preapproved list. If the executable is on the "whitelist", it is allowed to run on the system; if it isn't, its code is prevented from execution. This can be regular EXE files, as well as individual DLL files for extremely high-security environments.
Obviously, maintaining such a list will require a bit of effort on the administrator's part. Creating and maintaining such a list requires vigilance, as the key is to ensure that users cannot introduce unnecessary or unapproved software into your domain environment. AppLocker leverages three types of rules to assist with correctly categorizing applications:
- Path rules define an executable by the location where it resides. This location can be comprised of a specific filename or path, or one that includes wildcards. For example, if you know you always want Microsoft Word's WINWORD.EXE file to execute out of its default location, you can create a rule to allow %PROGRAMFILES%\Microsoft Office\Office12\WINWORD.EXE.
Alternatively, if you wanted to allow all the executables in this path to run, use a wildcard for %PROGRAMFILES%\Microsoft Office\Office12\*. Path rules ease the creation of whitelists, but their use of wildcards can create some obvious holes in a security infrastructure.
- File hash rules improve upon path rules at the cost of flexibility. With a file hash rule, a cryptographic hash of each allowed file must be specifically entered into the rule. By creating a hash, you can be assured that malware-patched files will not run, nor will files that happen to exist in locations which are permitted by a loosely-bound file path.
While substantially more powerful in its security, the downside of such a rule occurs when a file is legitimately changed by a regular update. Updating WINWORD.EXE with a new patch or service pack, for example, requires a new hash for the file to remain on the approved whitelist.
- Publisher rules can come in handy when your applications' files have already been digitally signed by their software vendors. Since the certificates used to digitally sign a file are a way to authenticate the file's authenticity, you can be assured that they come from a legitimate software vendor. For greater granularity, publisher rules come with a sliding scale and custom value option that enables each file to be approved by combinations of publisher, product name, file name, and file version.
AppLocker gains its abilities for centralized control through its integration with Group Policy. Creating rules and delivering AppLocker policies is a task that is accomplished via the Group Policy Management Editor, ensuring that any targeted desktop is sure to enforce the policy once received.
While AppLocker as a technology has been around for a while in its previous form with SRP, one of its implementation hurdles has involved actually defining what executables should be on that whitelist. No administrator wants to configure an application execution prevention solution to quickly find out that they've missed a few key applications.
To aid in this process, AppLocker's Group Policy wizards come equipped with a mechanism to automatically generate rules. Pointing this wizard against a reference computer that contains the software composition you want approved results in a report that can be easily converted into a list of rules. Another useful application is the incorporation of an audit mode, which is used to monitor for application use without actually preventing any application execution. This audit mode further ensures that you're making good decisions about which executables to restrict before you start actively restricting.
Microsoft today includes AppLocker in all versions of Windows Server 2008 R2 except Web and Foundation Edition, as well as Windows 7 Ultimate and Enterprise Editions. This means that an upgrade is likely necessary to enjoy its benefits. On the other hand, if you're looking for a good reason to jump-start your migration, AppLocker can be a valid business justification.
For those who didn't implement SRP, AppLocker is indeed a new way of thinking about systems security. Shunting off the possibility of application execution can go far into preserving the sanctity of your pristine domain environment. Eliminating the chance that rogue or inappropriate code can ever be implemented will go a long way toward assuring the highest levels of security, while at the same time making the IT organization itself the true gatekeeper for approving new applications.
|
Greg Shields, MVP, is a co-founder and IT guru with Concentrated Technology with nearly 15 years of IT architecture and enterprise administration experience. He is an IT trainer and speaker on such IT topics as Microsoft administration, systems management and monitoring, and virtualization.
His recent book Windows Server 2008: What's New/What's Changed is available from SAPIEN Press. |
|
