From here

We have the following this month:
5 Critical
3 Important

Details:

Bulletin 1 (Critical - Remote Code - Office)
Affects:
- Microsoft Project 2000 SR1
- Microsoft Project 2002 SP1
- Microsoft Project 2003 SP2

Bulletin 2 (Critical - Remote Code - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1
- Windows Server 2008

Bulletin 3 (Critical - Remote Code - Windows)
Affects:
- VBScript 5.1
- VBScript 5.6
Operating Systems (2000, XP, 2003)

Bulletin 4 (Critical - Remote Code - Windows / IE)
Affects:
- IE 5.01
- IE 6 SP1
- Affects all Operating Systems as well as the W2K Browsers
Operating Systems - ALL

Bulletin 5 (Critical - Remote Code - Windows / IE)
Affects:
- IE 5.01
- IE 6 SP1
- IE 7
Operating Systems - ALL

Bulletin 6 (Important - Spoofing - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1

Bulletin 7 (Important - Elevation of Privilege - Windows)
Affects:
- Windows 2000 SP4
- Windows XP SP2
- Windows 2003 SP1 & SP2
- Windows Vista Release & SP1
- Windows Server 2008

Bulletin 8 (Important - Remote Code - Office)
Affects:
- Visio 2002 SP3
- Visio 2003 SP2
- Visio 2003 SP3
- Visio 2007
- Visio 2007 SP1

I just got an email from my director who's attending a PCI event in Las Vegas. It seems that the PCI Standards Council has finally released clarification to the often-debated Requirement 6.6 of the PCI SSC. In this section, the standard currently identifies two options: Application Code Review or implementation of Web Application Firewalls. The PCI DSS Information Supplement was completed in February and has a Release Date of April 15, 2008 (yesterday). It is scheduled for publishing online within the next week or so. Here is a snippet from the document:

The application code review option does not necessarily require a manual review of source code. Keeping in mind that the objective of Requirement 6.6 is to prevent exploitation of common vulnerabilities (such as those listed in Requirement 6.5), several possible solutions may be considered. They are dynamic and pro-active, requiring the specific initiation of a manual or automated process. Properly implemented, one or more of these four alternatives could meet the intent of Option 1 and provide the minimum level of protection against common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning) tools
3. Manual web application security vulnerability assessment
4. Proper use of automated web application security vulnerability assessment (scanning) tools

I think that we'll see a lot of good come out of this... it really broadens the options of what companies can and cannot do to satisfy Requirement 6.6. This doesn't mean that static source code review should be forgotten or discarded, only that there's now a cost effective option between the two previous options. This will benefit a number of companies, giving them an alternative that isn't as expensive as a manual source code review and also doesn't depend on the company's specific configuration of a web application firewall (Chris Eng of Veracode has a great post on why WAFs just don't cut it).

This also seems to be the exact opposite of what Jeremiah Grossman interpreted Bob Russo's recent quote as meaning. Instead of narrowing the definition the PCI Standards Council has broadened the definition. I guess this is the update/clarification that they mentioned in their response to Dennis Hurst last year.

Hats off to Dennis Hurst, Jeremiah Grossman and others in the industry, along with the PCI Security Standards Council. Many of us have been lobbying for clarification to these requirements and this is a perfect example of how things can improve if you have input from industry experts and responsiveness from the standards bodies. I won't get into debating the "responsiveness" side of the equation in this post, but the update has been made so let's move forward.

In the end though, it's up to the company interested in becoming PCI certified to decide which approach is the right one to take. While I'm sure a number of companies will appreciate this new option, many will deploy web application firewalls, and I'm sure many will still want the peace of mind offered by an exhaustive static code review.

A couple of days ago Digital Bond posted a short blog post on Server 2008 Core. They had written about it previously and done a podcast (One of their partners is developing software to run on Server 2008 Core). One of the common themes for Server 2008 Core is the limited attack surface that it presents, as it essentially "console-only". Actually everyone refers to it as an OS without a GUI, yet cmd.exe is open as a window that you can minimize/maximize and you can run task manager, notepad, regedit and a couple of control panel applets, but close enough I suppose. Also when logging in you get "Preparing your desktop"... really all "GUI-less" means is explorer.exe isn't around. Also folders in C:\Users\administrator: Saved Games, Music, Pictures, Links, Favourites, Videos (etc). Alt+Tab still works as well (with a GUI showing you icons).

Anyways, in this Digital Bond blog post, they talked about how the decreased attack surface meant that out of the 25 security bulletins released by Microsoft only 4 would apply to Server 2008 Core. The problem with that? Only 4 of the advisories applied to Server 2008 at all... so Digital Bond has just said that Server 2008 and Server 2008 Core had the same number of patches.

As a side note the decreased attack surface for Server 2008 Core seems to really be on the client-side. I counted 20+ running services on a fresh install, including services like Remote Registry (which doesn't even run on Vista by default) are running on Server 2008 Core.

The four updates that affected Server 2008: MS08-021 (GDI), MS08-023 (ActiveX Killbits), MS08-024 (IE), MS08-025 (Windows Kernel Privilege Escalation).
The three updates that installed on Server 2008 Core: MS08-021, MS08-024, MS08-025.

So 75% of the patches released for Server 2008 also apply to Server 2008 Core... but let's think about this:

• Server 2008 allows you to disable metafile processing, mitigating MS08-021.


• Server 2008 has IE7 which has the affected ActiveX control in MS08-023 disabled by default and Yahoo! Music Jukebox wouldn't be installed on a server (unless you weren't using it as a server).


• With MS08-024 we're back to IE again... Why are you using IE on your server in the first place?.


• With MS08-025 this is local and credentialed, which generally implies insider threat.

So out of the 4 patches, only one isn't mitigated by practical server hardening... and that patch applied to both Server 2008 and Server 2008 Core. I'm not sure why Digital Bond was making a big deal out of "only 4 would apply to Server Core.", one thought might be they are pushing their partners product but a more likely thought is that they were saying *IF* (and that's a big, and useless if) all 25 bulletins applied to 2008, only four would have applied to 2008 Core.

[Disclaimer, I would never attempt to do this if I didn't think it was the only semi-plausible explanation for their report]
Well let's think about that... We can immediately eliminate all the Office patches (Common Sense: You don't install Office on a server). That leaves us with 15 / 25 (10 are pure office only). Out of these 15, we know that MS08-025 existed, and MS08-002 was also privilege escalation and it affected lsass (which exists on Server 2008 Core... So that gives us 2 / 13 / 10 (possible, undecided, impossible). We also saw that the IE patch was installed... so let's accept that one all the way across. That's another 2... bringing us up to 4 / 11 / 10. We know that GDI was installed... that's 5 / 10 /10. I have confirmed that wscript exists (even though it is 5.7... let's follow the rules and include it as a "possibility")... that's 6 / 9 / 10. There are two TCP/IP and one AD, so we'll include those... that brings us to 9 / 6 / 10. Now IIS exists on Server 2008 Core, so we'll have to include those two bulletins. That brings us to 11 / 4 / 10. Now the ActiveX Killbits update wasn't installed -- 11 / 3 / 11, and that leaves us with WebDav Mini-Redirector, OLE Automation and DNS Spoofing. DNS Spoofing we'll put on the yes side... 12 / 2 / 10. Web-Dav redirector I'll assume doesn't exist -- 12 / 1 / 11 and OLE Automation... well the DLL exists in Server 2008 Core... so I'll go yes.. 13 / 0 / 11.

That means that *IF* we had taken this approach to determine the size of the attack surface (which means assuming vulnerable versions of software which don't exist on Server 2008), that 13 out of 25 Bulletins would have applied.

So in the end, I'm not sure how Digital Bond came up with 4... however I'd love it if they shared their process. Does Server 2008 Core have a smaller attack surface... theoretically, however I'm not sure if the attack surface is any less than that of a properly hardened and maintained Server 2008 install. In fact, as I pointed out earlier (with Remote Registry) in some cases it's less secure than previous versions of Windows. This doesn't mean people shouldn't use Server 2008 Core, they should just make sure they have a full understanding of what's happening in their environment and not take advantage of Server 2008 Core as an alternative to hardening their server properly.

There's an interesting story up on The Register from Toorcon. Since I wasn't at Toorcon, I can't confirm it, and I haven't seen any other stories that don't solely reference The Register's article.

Katie Moussouris, a Microsoft security strategist, told the crowd that Microsoft would not sue or press charges against ethical hackers who report security flaws in their websites.

This is a huge move in the right direction in my opinion. Web security is something that plagues almost everyone and it's good to see Microsoft making a move to improve their web security. Let's hope that more companies will follow Microsoft's move.

Let's also hope that Microsoft puts out something official on this subject, because so far... the only original piece I've seen is The Register's article.

If more comes on this subject, I'll be sure to blog about.

I blogged earlier today about this story posted on The Register regarding Microsoft's promise to not sue or press charges against ethical hackers reporting flaws in their websites. It's been picked up by a number of people, including Ryan Naraine, Dave Lewis and LinuxSecurity.com.

I wanted to know more on the subject, so I decided to contact Microsoft directly and ask for official clarification (since I wasn't at Toorcon to hear it first hand). The response came from Bill Sisk, Microsoft Security Response Communication Manager. Bill had the following comment:

Microsoft did not announce anything new at ToorCon Seattle regarding its position on responsible disclosure, but we did mention our industry leading online services acknowledgement, which went public in July of 2007. Because we will not pursue legal action against researchers who report vulnerabilities to us responsibly, we hope to encourage those who want to help us protect customers to feel free to do so without fear of repercussions.

As we have done for many years, we continue to work closely with security researchers and encourage responsible disclosure of vulnerabilities in our products as well as for online services. If a vulnerability is responsibly disclosed, we will publicly credit the researcher for his/her assistance. We believe responsible disclosure serves everyone's best interests, by helping to ensure that customers receive comprehensive, high-quality updates for security vulnerabilities with no exposure to malicious attackers while the update is being developed. For additional information on how Microsoft credits researchers for responsibly disclosed online services security vulnerabilities, visit: http://www.microsoft.com/technet/security/acknowledge/faq.mspx.

So it looks like this has existed for a while, and has just been overlooked (or perhaps forgotten); either way, it's great to see that Microsoft has the FAQ available on their website and, as Ryan pointed out on SecurityWatch, has setup a page to acknowledge people who responsibly disclose vulnerabilities in online services.

It looks like the PCI Security Standards Council has posted their update to Requirement 6.6 (available here). They have provided information above and beyond what I mentioned last week. They have also provided a great deal of clarification around Web Application Firewalls.

Some interesting notes:

• Reviews can be performed by qualified internal or external individuals. However, internal auditors should not fall into the same organizational unit as the developers.


• There is text that identifies examples of where reviews will meet or exceed the quality of Web Application Firewalls. The two provided examples are:
  
  • Security reviews of source code during the development process.
  
  
  • Testing for the presence of web application vulnerabilities either manually or via a specialized tool


• Testing must occur prior to the Web Application going live (Note: Of course this doesn't mean testing should stop there, on going testing is key. As Braden Williams put it today, "You have to MAINTAIN what is assessed")

Trey Ford has a great write-up and answers some additional questions that people may have... I highly recommend reading it.