Earlier this week in a joint press release, Microsoft and BearingPoint announced the new BearingPoint Enterprise Governance, Risk, and Compliance product offering. Ok... it will be a while before the more veteran enterprise GRC vendors start really losing sleep over this deal. But BearingPoint continues to be a top risk consulting firm, and Microsoft’s reach through the business user community will be an attractive benefit for compliance and risk professionals trying to get hundreds or thousands of staff members to contribute to the GRC program. There’s potential here for sure.

With software giants IBM, Oracle, SAP, and now Microsoft increasing their level of commitment in the enterprise GRC space, the 2-3 year market outlook continues to change. The risk and regulatory landscape is only going to get tougher to handle, and the more GRC programs can run seamlessly with existing business processes and applications, the better. The vendors focused solely on GRC still have the advantage for now, but market consolidation is on its way... and it’s coming maybe just a tiny bit faster than it was at the start of this week.

WAFs generally struggle in a few different areas, the people running them are not web app. security experts and trying to apply a default deny policy, while a great idea in theory, is pretty hard in the real world . There is just way to much movement in most applications to pin it down. Even if the app does not change frequently, WAF admins are very hesitant to even come close to blocking legitimate traffic. What really sold me though is when I saw it in action for the first time. From the Sentinel UI we clicked a button that updated the F5 with a rule to block a vulnerability. The rule is automatically generated based on the vulnerability. We then clicked the retest button and the vulnerability was no longer exploitable . Note my careful choice of words, exploitable VS. “not there anymore”. The vulnerability certainly still exist in the code but now that the attack is blocked the business can decide if this is a good enough solution or they need to go fix the actual flaw.

The geek in me is screaming that it still needs to be fixed, the business side is saying that the rule is good enough and I am not going to commit resources to fixing it until that code is worked on again. From the PCI Section 6.6 perspective this gives the business some great options. As our customers are becoming aware of the PCI requirements and the PCI auditors are becoming tougher on web application vulnerabilities we run into a difficult situation. PCI audit is coming up and the app. is riddled with vulnerabilities.  I now have to dedicate precious development resources to fix these vulnerabilities ASAP. With this solution I can apply this rules and effectively mitigate the issue.

I am pretty excited to be part of this. I think we have moved the industry forward today, even if it was just a small step. People now have some more options to mitigate risk besides running to the development team with yet another fire.

Post from: Grumpy Security Guy

The Big Announcement

Also this week, the UK’s Medicines and Healthcare Products Regulatory Agency showed signs of cracking down on disclosure of drug trial results after problems persisted with certain anti-depressant drugs in relation to teenage suicide (even though criminal charges will not be filed).

The sub-prime issue may likely be the next major target for legislative changes, although most discussion seems to be focused on consumer protection at this point, not tighter control over lenders.

In all of these cases, it’s much easier to see in hindsight what companies could have done to avoid such legislative action.  However, I think a case can certainly be made for seriously supporting industry standards...for example, the general success of the PCI Data Security Standard seems to have diminished any strong push to curb data theft through tougher regulations.

For a change of pace, a few of the SDL blog crew decided to take a poke at a "Security Predictions for 2008" posting. In selecting a prediction, the only guiding rule was that the prediction had to cover something that could be influenced by application (or lack thereof) of the Security Development Lifecycle - either within Microsoft or in the industry. A few of the bolder souls among us decided to  provide a single prediction below, followed by a short paragraph or two elaborating on why they think this will occur and the relationship to SDL.

In addition, we'll take this opportunity to introduce two new folks who recently joined our team: Bryan Sullivan and Jeremy Dallman. Welcome! A brief introduction paragraph from each of them in included below, followed by the predictions. Hope you enjoy...

Bryan Sullivan: Hi everyone - my name is Bryan Sullivan and I'm new to the SDL team. I've spent the last five years as a developer and security researcher at SPI Dynamics, and I'm looking to bring the same web app security focus that I had at SPI here with me to Microsoft. I'm particularly interested in emerging security issues with Rich Internet Application frameworks like Ajax, Flash and Silverlight, so expect to see me blogging and speaking on these topics throughout the year.

Jeremy Dallman: Hi, I’m Jeremy Dallman. I’ve been at Microsoft since 2002 - starting in Windows Security on early versions of Vista. Shortly after Blaster, I was reassigned to the XP SP2 project and spent the next year as the project manager for the Windows Core Security team living the whirlwind of that release. I have spent the past three years on the Internet Explorer security team in a variety of roles managing security response as well as IE7/8 security requirements and planning. I moved over to the SDL team this past October to extend our internal SDL processes to the world and create outreach programs that will help development shops implement secure development lifecycle practices.

Now, on to the predictions!___________________________________________________________________________________________________

Eric Bidstrup:

My prediction for 2008: "Vulnerabilities in commercial and non-commercial software will continue to be reported to CVE (as tracked in the US National Vulnerability Database) at a record pace. However, the number of newly reported vulnerabilities in Microsoft products will decrease when expressed as percentage of overall CVE vulnerabilities in 2008

A query of the NVD with "Vendor=Microsoft", "Start Date= January 2007", and "End Date=December 2007" returns 254 matches. A query of NVD without selecting any vendor, and choosing "Start Date= January 2007", and "End Date=December 2007" returns 6532 matches. If my math is correct, that states that Microsoft was responsible for 3.8885 percent of the vulnerabilities in the NVD in 2007. My prediction is those same queries and same math for 2008 will be less than 3.8885 percent. Before anyone starts commenting about how good or bad the NVD is, let me just state that it's an independent baseline with metrics that (assuming no major changes in policy or tracking practices in 2008) will have the same attributes at this time next year.

The motivation for my prediction is that via application of the SDL, Microsoft will continue to reduce vulnerability rates in our products. Sadly, there are not many other software vendors that have stepped up and made the same level of commitment to delivering trustworthy software. Hence, Microsoft will be responsible for a smaller overall percentage of vulnerabilities in 2008. Ideally, I wish the overall NVD vulnerability count would decrease as an absolute number, as that would be an indicator that the industry as a whole was improving. Unfortunately, I don't think this will be the case.

Adam Shostack:

My prediction for 2008: I believe that 75% or more of all privacy breaches will not involve an exploit, but will involve some other sort of operational security failure, such as lost or stolen hardware or inadvertent sharing of data.

To be precise, 75% of the breaches listed in the attrition.org DLDOS will be categorized as something other than "hack."

Bryan Sullivan:

My prediction for 2008: I predict that in 2008 we will see at least a 50% increase in the number of Cross-Site Request Forgery (XSRF) vulnerabilities as reported in the US National Vulnerability Database. The root of request forgery vulnerabilities - relying solely on cookies for authenticating users - is more of a design flaw and not a simple implementation issue. This makes them tougher to identify and to remove. They can't be mitigated solely through input validation techniques the way that Cross-Site Scripting and SQL injection can.

As the new web application security guy on the SDL team, it's my job to improve mitigations for issues like request forgery in the SDL, so that it is just as useful and applicable to online services as it is for desktop and client/server programs. Keep watching this space for web app-specific updates to the SDL and for a more in-depth look at XSRF in the near future.