For those of you who aren’t familiar with XSS Filter, a brief summary is that it is a client-side defense against reflected cross-site scripting (XSS) attacks.  It works by recognizing that reflected XSS attacks inject script into the string that the browser sends to the targeted web server.  If the server doesn’t neuter or strip out the injected script, it gets sent back to the browser and executed in the context of the target web page.  Bad things then happen.  At a high level, XSS Filter remembers the string that the browser sent to the server, and looks at the server’s response to see if any of the script was actually in that string.  If it was, then XSS Filter decides that it got there because it was injected by an XSS attack and blocks the script from executing.  The rest of the web page renders as usual.  This is a vastly oversimplified sketch of XSS Filter – for details, see the post by David Ross, inventor of XSS Filter on the Security Vulnerability Research and Defense blog.

So what does XSS Filter have to do with the SDL?  Well, for almost nine years, since XSS was first discovered at Microsoft, we’ve been trying to figure out effective ways to reduce vulnerability to XSS attacks.  Our focus has been on improving the ways that web page developers code their pages, and we’ve developed a lot of tools and techniques for making web content safer from XSS attacks and for detecting XSS vulnerabilities in live pages.  The SDL requires the use of many of these tools and techniques, and we’re sure we’ve prevented a lot of XSS vulnerabilities from being introduced into Microsoft web pages as a result. 

But while we identify (and the SDL requires) measures that allow developers to avoid classes of vulnerabilities, we also look to identify more sweeping solutions that can either 1) eliminate classes of vulnerabilities, 2) reduce their severity, or 3) reduce the likelihood of attacks being successful.  The process usually starts from deep understanding of a class of vulnerabilities and attacks, and then we broaden defenses from there.  In the case of XSS Filter, David’s years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today.  The solution is compatible with existing web pages (doesn’t “break the web”) and thus we were able to enable it by default for users of Internet Explorer 8.  Because it’s a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS. 

Our work on buffer overrun defenses follows a somewhat similar pattern – we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns.  As we gained a deeper understanding of how buffer overruns can be exploited, we enhanced the /GS compiler flag and added ASLR in a quest to cause classes of exploits to fail even if a buffer overrun remains.  We’re not yet close to eliminating the SDL requirements for use of tools and coding techniques, but the SDL also requires the use of the mitigations to reduce the severity of vulnerabilities that slip past.  Will we ever get to the point where the mitigating technologies are so strong that we can relax the coding requirements?  Maybe not, but we will continue to introduce technologies that reduce the chances of a successful attack.

Similarly, in the case of XSS, even after IE8 ships, the SDL will continue to require the use of safe web site coding practices and tools such as the Anti-XSS library both to protect users of browsers other than IE8 and to provide protection in recognition of the fact that XSS Filter is a mitigation or defense in depth rather than a complete solution.  But we’ll also be keeping our eyes open (and doing active research) in the quest for an even more effective defense – whether client or server side – that eliminates XSS for good.

This post is a little far afield from the normal content of the SDL blog, but I thought it was important to provide a picture of the role of security science and security research in defining SDL requirements and in making major improvements in software security.  You can read more about our work in security science in the Security Vulnerability Research and Defense blog.

“In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers."

I think it is great that Google has a security program they are willing to talk about and I could not agree more with the ‘security as a cultural value’ philosophy. But isn’t there something really fundamental missing here? Design? There is a lot more to software engineering other than coding and testing.
 
The SDL has a very large set of implementation-related requirements, but there are many design-related requirements also.

Computer security experts have known since the early 1970s that you have to get the design right; and our experiences with the SDL over the last 5 years have taught us that you need to consider security and privacy (but remember, you have to ship too!) very early in the design phase and have a consistent end-to-end process if you truly hope to reduce vulnerabilities and create more secure software. This is how the SDL is helping to create ‘security as a cultural value’ at Microsoft.

We’ve seen a general trend downward in security vulnerabilities in Microsoft products, and the IBM X-Force 2008 mid-year report backs the assertion that we’re making progress; according to the report Microsoft’s share of total vulnerabilities decreased from 3.7% in 2007 (1st place) to 2.5% (that’s 2.5% for all Microsoft products; a more appropriate comparison might be Windows vs Linux vs Mac OSX, or SQL Server vs Oracle vs DB2) in the first 6 months of 2008 (3rd place.) This is an encouraging signal that the SDL is working on a large scale… of course, it might also show that vulnerability researchers are moving to easier targets, which, to me shows the SDL is working too.
 
What do you think?

Changing Behavior

1. Educate yourself.
At least every 6 to 12 months, surfers should browse the educational information provided by their operating system and security vendors and subscribe to any security-related newsletters they might offer. According to David Perry, familiarity with the latest threats, dangers, and recommended safety tips will allow surfers to make safe choices. “Until you know what’s out there, you’re just flying blind. Without an education, you’re wide open”.
2. Avoid suspect sites.
While criminals can infect even mainstream Web sites, sites such as gambling sites, adult Internet sites, and illegal file-sharing sites are far more likely to carry malicious code. Web sites that offer “something for nothing” frequently recoup their losses by infecting visitors’ PCs.
3. Lose Your Comfort Zone.

Recommended Technology

4. Use an updated virus scanning suite.
The most important component of any threat mitigation system is a virus scanning suite. In addition to detecting and removing known viruses and malware, modern virus scanning suites provide additional protections against new attacks by disabling their known protocols. For example, Trend Micro™ Internet Security encrypts keyboard traffic, protecting personal data from keyboard logging programs that might go unnoticed. Users should update their scanner and virus definitions as frequently as possible to ensure the best possible coverage.
5. Upgrade your OS and browser.
In addition to offering more features, Microsoft’s Internet Explorer version 7 and the latest Mozilla Firefox are both substantially more secure than previous-generation browsers. Users of older browsers should upgrade immediately to take advantage of increased security. Similarly, Windows Vista and Mac OS X are more secure than their predecessors, and users of older operating systems should consider upgrading, as well.
6. Disable scripting and “widgets.”
Many Web-based attacks use various scripting languages to run infectious programs in a browser or use downloadable “widgets” to execute infections locally. By disabling scripting and avoiding downloadable widgets wherever possible, surfers disable these common attack vectors.
7. Rate your Web pages.
Some available services rate the risk of Web pages in search results, allowing surfers to avoid unwanted content and hidden threats before viewing the pages. Rating applications (e.g., Trend Micro TrendProtect™) consume few system resources and run unobtrusively, so they are suitable for any Web-enabled personal computer.
8. Ask your provider.
Commerce companies, banks, and credit card associations are all interested in computer security, and many offer additional features. For example, Visa’s Verified By Visa program requires cardholders to enter a second password to identify themselves during a transaction, while businesses in Poland require cell-phone confirmation of credit card purchases. While nothing will be 100 percent effective, any additional security measure provided by a trusted source will increase protection, and surfers should adopt as many as possible.

This article provided for your reading pleasure by Trend Micro.

What you need to make these cocktails:

Six pack of Corona Extra
Bottle of Bacardi Limon
Lime
Coctail stirrer (a chopstick works fine)

Pop a slice of lime into a Corona and hand to a friend. Have them drink the neck, then refill with Bacardi Limon (putting the lime in first seems to reduce fizzing). Stir and hand back to them so they can drink it down as it fizzes up a bit.

Mixing rum and beer may sound nasty, but this actually results in a very smooth, tasty drink. It's our favorite accompaniment when we are playing Rock Band.

We took this recipe and applied it to one of our other favorite beers as well: Honey Moon Summer Ale (also works with Blue Moon, or any other typically orange-flavored beer). Just use Barcardi O instead of Limon.

Enjoy!

Braving the Cold (Boot) – A Sneak Peek of My Presentation at Black Hat

by Patrick McGregor

Cold boot attacks aren’t theoretical academic exercises. Cold boot attacks are real. And they’re serious.

In the past few years, companies have poured hundreds of millions of dollars into full disk encryption technologies. Companies expect full disk encryption to reduce the risk of exposure of sensitive information such as intellectual property or customer data. Reality often deviates from what is expected, however. Researchers from Princeton shocked the industry earlier in 2008 when they released a research paper that showed that low-cost “Cold Boot” attacks could be used to defeat the security of most full disk encryption systems. They recently even published all the tools needed to do this at home!

Some have argued that Cold Boot attacks are not serious security threats. I disagree! First, an unskilled person can capitalize on the exploit using simple, automated steps and publicly available tools. In fact, Cold Boot attacks require nothing more than plugging a USB drive into a laptop. Second, the physical target of a Cold Boot attack, such as a laptop, is very easily obtainable (see the recent Ponemon report on laptops lost/stolen in airports – scary!). Third, although many laptops and desktops are stolen via random acts of theft, it is well known that some criminals profit from organized, calculated data theft. It is only a matter of time before we hear of a high-profile data breach that results from a simple Cold Boot attack.

I am excited to present at Black Hat several innovations for preventing Cold Boot attacks. In addition to summarizing how a Cold Boot attack works, I’ll describe four new software techniques for hardening full disk encryption against the attacks. The software technology was developed by myself, Tim Hollebeek, Alexander Volynkin, and Matt White. All of us work for BitArmor, an exciting security startup based in Pittsburgh. Here’s a sneak peek:

· Wash up: Wipe keys immediately before certain OS state transitions, such as before the computer shuts down or goes into hibernation mode – accessing the memory will yield nothing.

· Take advantage of BIOS memory smashing: By strategically placing keys in certain regions of memory, we can rely on the BIOS boot process to overwrite keys before any operating system can dump the contents of memory.

· Is it chilly in here?: Using built-in temperature sensors, we can lock down the system in reaction to temperature drops that may indicate a Cold Boot attack is in progress.

· Create a virtual enclave for keys: We can implement special cryptographic, OS and processor architecture techniques to provide robust protection for keys against the most aggressive cold boot attacks. By creating a “virtual secure enclave” for encryption keys in software, an attacker cannot extract critical keys from memory – even if the RAM is super-cooled.

Hope you can join us at Black Hat as we take an in-depth look at the future of full disk encryption technology.

However, I should briefly clarify Paul’s note that “blackboard systems historically used a single memory model (i.e. multiple threads or processes using a single machine’s memory model)“.

In fact, there were many blackboard systems, some more than a decade old, that used a distributed memory data-model. What I think Paul meant to say, and my apologies to Paul for being so literal, is that “blackboard systems originally used a single memory model (i.e. multiple threads or processes using a single machine’s memory model)”

John McManus, former CTO of NASA, wrote an excellent PhD dissertation in 1992, Design and Analysis Techniques for Concurrent Blackboard Systems. John’s thesis, now more than 16 years old, examined many details of concurrent blackboards where memory is distributed. For example, refer to Figure 2.3. Distributed Blackboard System with Distributed Blackboard Data Structure, page 36 of John’s dissertation.

Quoting directly from page 37 of John’s disseration;

Rice, Aiello and Nii [20] present several options for gaining speedups in a distributed blackboard system.

• 1) Eliminate the centralized scheduling mechanism
• 2) Optimize system design for a distributed memory, message-passing hardware
• 3) Distribute the data across the blackboard to reduce hotspots

Quoting further from the same page;

Poligon [21] is based on a distributed memory hardware model when each processor is viewed as a blackboard node. They define a blackboard node as follows: “a blackboard node is a process on a processor, surrounded by a collection of processors able to service its requests to execute rules.” [22] The implicit assumption in this definition is that all knowledge sources are rule–based systems. This assumption may severely limit the performance of systems implemented using Poligon, and limits the types of problems it is suited to address.

In Blackboards for Complex Event Processing, Paul concludes,

“One suspects the blackboard systems domain and terminology is overdue some updates thanks to developments in the Complex Event Processing space.”

If you look at the historical literature, I would say that the following restatement is more accurate:

“The CEP domain and terminology is overdue some updates because folks working in CEP did not reference or incorporate the advanced event processing prior art in a number of very important areas, blackboard systems being only one.”

On the other hand, commercial off-the-shelf rule-processing technology such as TIBCO’s BusinessEvents (BE), advances the ability to economically implement myriad complex problems that blackboard systems are designed to address.