Hello everyone! Last time I was busy on other stuff and haven’t enough time to continue the topic. Today I want to talk about SRP rule ordering and how rule conflicts are resolved.

When you define SRP rules, you may have 2 or more conflicting rules. For example, you have a rule that allows to run any software signed by a certain certificate. For some reasons you decided to block one or more specified applications that are signed by the allowed certificate. Or you have two path rules that points to the same file, but have opposite security levels. It is important to understand how SRP processes rules and decides resulting action (allowed or blocked).

Multiple policies

The first thing we should learn is how multiple policies are applied. As you already know (at least, I assume that you know, because you have to know this), in a domain environments you can define multiple policies at various levels. Normally, such policies are applied by following the following sequence: LSDOU (local, site, domain and GPO linked to an OU). The latest policy object applied becomes effective. However this is not true for SRP. When you look at RSOP (Resultant Set Of Policies) for other settings (for example, account lockout settings), you can see which policy wins:

Today we will talk about rule types, their characteristics and some best practices.

When we open Additional Rules section, we will see two predefined rules:

• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRoot%
• %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir%

They doesn’t look as usual path rules, instead they refer to registry keys. If you open Regedit and check these keys you will see that registry key values contains corresponding folders paths: C:\Windows and C:\Program Files. This means that SRP can read file paths from registry keys and values. In the default state, SRP allows to run anything that is stored in system folders and anything from other folders (say, from user profile) is prevented. In most cases it is enough. However, certain business applications are not installed in the default program folders (C:\Program Files). for example, they can be installed in the system drive root, different drive or in the network folder. As the result, you may have to create additional rules.

In previous post I gave a short intro to Software Restriction Policies (SRP) and today we will talk about basic principles and management UI.

As already said, SRP is a whitelisting technology, therefore it works under the following principle: you are not allowed to run (launch) anything that is not explicitly allowed. Although, SRP can work in blacklist mode, it is not so efficient as in a whitelist mode.

How to launch SRP console?

SRP is a part of group policy and is configured by the Group Policy Editor. In order to launch SRP on a standalone machine, run the following:

• Start –> Run… –> type”secpol.msc”

to edit SRP in a domain environment, do the following:

Today I’m starting a post series that will describe a great security addition, whitelisting technology — Software Restriction Policies (SRP). I already posted a ton of exclusive Secret Knowledge (aka Тайное Знание) on my Russian weblog: SRP. If you are familiar with Russian or have a good translator — try Russian version. In this series I’ll post a summarized information.

What is Software Restriction Policies?

One smart guy (I think it was Richelieu, not Rothschild) told: who owns the information owns the world. With computer era started a new wave of information battle — computer information battle. Some want to get information, some want to protect it. This is why there are computer viruses, worms and other malware. some malware was written just for lulz, some not. Malware and antimalware was born at the same time, but the result is not very good — thousands infected computers every day. Many of them are protected by the most modern antiviruses and result is still the same — fail. Format-reinstall and new live from scratch till another infection. There is no end with just antivirus protection.

Update 01.12.2012: clarified Applocker support on server core installations.

Hello folks! Today I want to share some personal opinions about one Windows whitelisting technology — Applocker, especially about the future.

Why Applocker?

Not all know that this is not something new (as Microsoft promotes), but a next generation of Software Restriction Policies (SRP). SRP is original Microsoft whitelisting technology which was introduced in 2001 (with Windows XP release). Due to various reasons, SRP didn’t become a popular technology that was used by systems administrators (not talking about home users). Microsoft attempted to make SRP more flexible, user-friendly and simple in configuration and usage. As the result, we got SRPv2 called Applocker, which was introduced in Windows 7 and Windows Server 2008 R2.