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.

Hello S-1-1-0 again, I'm back!

In the first part we discovered basic OCSP requests and responses. Today's stories:

• Nonce
• Service Locator

Nonce

By default, Online Responder may pre-cache OCSP response for particular certificate, especially if the certificate is used very frequently (for example, SSL certificate at login.live.com) until it (response) is expired. This reduces server load, because there is no need to sign the same response for each incoming request. And this behavior is recommended by RFC5019. Here is an example for StartSSL/StartCom SSL certificate: