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:

Hello folks, PowerShell Crypto Guy is again on the board! Today I want to talk about a useful OCSP Client Tool which is available in my PowerShell PKI module.

A long time ago in a galaxy far, far away....

A time ago I started Online Responder deployment and was faced the problem that there are no good tools to test it's configuration and how it works. PKIView.msc and certutil.exe just can tell whether the OCSP is functional or not. No details about request and/or response details. After a little research I found pretty useful and nice tool called Ascertia OCSP Client Tool. Actually this is a great tool with a lot of powerful features, including raw ASN.1 traces and so on. I thought that it is worth to buy the tool and contacted their sellers. Holy ****, the price killed me. They asked about 1,800 (1.8k) euros for a single license! Even though the tool is very cool, I wasn't ready to spend such money for it. But, if you manage Lorne Greene or Johnny Cash, then Ascertia's product may be for you.

Hi S-1-1-0! Today I've released a new version of my PowerShell PKI module. It took a bit more that 1 month from previous release. I didn't expected to develop new version too fast. I just got a free time to work on my module and I had few ideas (mostly, based on customer feedbacks) which should significantly improve module usage area and user experience.

New features

The major improvement in PSPKI v2 is Standalone CA and non-domain environment support. Now you can manage Standalone CAs in Active Directory domain or in workgroup environment. I tried several approaches to integrate this support to an existing Get-CertificationAuthority command. Eventually, I decided to create a new universal command which connects to a specified CA server (regardless, it is Enterprise or Standalone CA) — Connect-CertificationAuthority. The idea is that in most cases Enterprise CAs have almost similar configuration and Standalone CAs slightly different due to their different usage. Therefore, Get-CertificationAuthority is still used to manage Enterprise CAs and Connect-CertificationAuthority is used to manage a single CA instance, either Enterprise or Standalone. The output objects are the same (with an exception that Get-CertificationAuthority can return multiple objects) and its result can be piped to all commands that support pipeline input from Get-CertificationAuthority command.