Most observers would agree that Microsoft's Security Development Lifecycle (SDL) has come a long way since the early 1990s, when the software giant's product teams implemented security and privacy protections at their own discretion.
When you put in place different mitigations, if a bug gets through, the potential impact is much lower.
directorMicrosoft Trustworthy Computing Group
In an effort to show its continued progress, Microsoft issued its 2010 report card Wednesday, outlining the impact the SDL has had on Microsoft and the software development processes at many other companies. The 2010 "SDL Progress Report" praised the SDL initiative for creating Microsoft's systematic approach to secure software development, and outlined where there's room for improvement.
Jeff Jones, director of the Microsoft Trustworthy Computing Group, said the report highlights how far Microsoft's security efforts have come since Bill Gates issued his now-famous 2002 Trustworthy Computing memo, which sought to stem the tide against a stream of virulent malware -- such as Melissa, Code Red and Nimda -- that used application coding flaws to infiltrate Windows-based systems. Two years later, Microsoft issued SDL 2.0 to the public, codifying the company's ongoing security development processes.
"We've been continuing to raise the bar making attackers seek easier targets," Jones said in an interview with SearchSecurity.com. "When you put in place different mitigations, if a bug gets through, the potential impact is much lower."
Despite coming off a year that included patches for a record number of vulnerabilities and the growing number of zero-day vulnerabilities surfacing on public message boards, Jones said a lot of progress can be seen. He said attacks specifically targeting Windows and Internet Explorer are becoming more complicated for attackers to pull off. Jones pointed out that at the recent Pwn2Own hacking contest at the CanSecWest Applied Security Conference in Vancouver, B.C., a hacker used three vulnerabilities, in a complex, four-part attack, to bypass security mechanisms in Internet Explorer 8 running on Windows 7. As a result of the complexity, he added, attackers are turning to the "low-hanging fruit" using automated attacks against third-party browser plug-ins and other non-Microsoft applications.
"It's a challenge that has to be met by the broader industry as a whole and if we can play a role in getting our partners to support new security features, we'll do that," Jones said.
ASLR and DEP adoption
In conjunction with the release of the report, Microsoft is calling on its partners and other independent software vendors to support Address Space Layout Randomization (ASLR), a security feature long used in the open source community that makes it difficult to use automated attacks against Windows. The feature, which positions application data in memory randomly, is supported in Windows Vista and Windows 7.
Microsoft studied 41 applications widely used on Windows and found that only 34% fully enabled support for ASLR, 46% partially enabled support, and 20% did not enable any support for the security feature. "This data clearly shows that ASLR adoption by applications in most market segments has been very slow, despite the technology being available for more than four years," Jones said.
Jones said the adoption has been sluggish because many applications are created to work on older platforms, such as Windows XP, where the technology is not supported. Microsoft's development platform, Visual Studio 2010, enables ASLR by default. Developers had to manually support the feature in earlier versions.
"Developers tend to do things their way and always do them that way," Jones said. "Our work has been to be an agent of change to get [developers] to do things they haven't normally been doing."
Gary McGraw, a noted software security expert and chief technology officer of Washington D.C.-based software security consulting firm Cigital Inc., said the issue of supporting ASLR has also been more technical for developers. McGraw said he thinks the data shows that Microsoft is close to a tipping point in ASLR adoption.
"Certain memory tricks give you better performance and some are easier from a programming perspective, but some of those tricks have negative ramifications," McGraw said. "If leading applications are supporting [ASLR], that's going to leave a few stragglers sticking out like a sore thumb and it's more likely that those applications will be targeted."
In addition, the Microsoft report analyzed application support for data execution prevention (DEP), a feature introduced in Windows XP Service Pack 2 that prevents an attacker from directly injecting and executing code in regions of memory that are intended for data. The feature is more broadly adopted by applications, with 71% of applications studied by Microsoft enabling DEP and 29% failing to enable the technology. McGraw said DEP is probably more broadly adopted because the technology has less to do with inner workings of an application.
Microsoft is issuing a "call to action," urging software developers to configure their applications to support DEP and ASLR. The company said users should demand that software vendors enable DEP and build support for ASLR into their applications.