July, 2010

Hi everyone, Bryan here. If you’re at Black Hat this week, I’ll be giving a talk Thursday afternoon on the topic of cryptographic agility – the ability for applications to change which cryptographic algorithms or implementations they use without having to make changes to the source code. Cryptographically agile applications can more easily comply with various countries’ myriad cryptography requirements such as FIPS 140, and in many cases they can also outperform applications with hardcoded algorithms. Best of all, when some hotshot cryptographer breaks an algorithm, the agile application will be able to swap out to a more secure alternative in minutes rather than weeks or months.

Check out the Black Hat website for more information on my talk, “Cryptographic Agility: Defending Against the Sneakers Scenario,” on Thursday, July 29, 4:45 PM in the Roman Ballroom at Caesar’s Palace.

Hope to see you there!

Hi, Adam Shostack here.  

I just wanted to let you know that I’ll be speaking at Black Hat about “Elevation of Privilege: The Easy Way to Threat Model.” Threat modeling is critical to secure development, and people find it intimidating and tough to get started. I will present Elevation of Privilege, a simple card game that makes it easy and fun to get started threat modeling.  This turbo talk will take place in the Florentine room at 11:15 on Thursday, July 29. 

I look forward to seeing you there!

Hi everyone, this is Grant Bugher. I’ll be giving a talk Thursday afternoon at BlackHat 2010 about securely using cloud storage systems like Windows Azure Storage – how applications that use cloud storage as their database back-end can protect themselves from attacks.  Just as with traditional methods of data storage and retrieval like SQL-based relational databases, application authors must take care to use cloud storage systems correctly to avoid unauthorized data access or tampering. My presentation will cover a variety of attacks on applications using cloud storage, such as enumeration and REST/SOAP injection, to show how some of the same effects as a SQL injection attack can also be used on an application using a cloud storage system.

There’s more information on my talk on the BlackHat website, under “Secure Use of Cloud Storage.” The talk will be on Thursday, July 29 at 11:15 AM in the Augustus Ballroom (3+4) at Caesar’s Palace.

Hope to see you there!

Steve Lipner here. Next Tuesday evening (July 27), SAFECode will be sponsoring a brainstorming panel at Black Hat that’s aimed at gathering security community input on vision and approaches for improving software assurance over the next 10 years.  SAFECode members all have established software assurance programs, but we all believe it’s important to seek new ideas and approaches and then follow up on them.  Since Black Hat is one of the largest gatherings of security experts, we’re taking advantage of the opportunity to meet with the community and listen to their thoughts.  There will be several of us from SAFECode in attendance, but we hope that most of the “air time” will be taken up by community input. We look forward to a robust discussion

If you’re coming to Black Hat, please join us from 5 to 6:30pm on Tuesday at Caesar’s Palace in Room Neopolitan 4.  We’re asking attendees to register in advance at http://www.safecode.org/register.php so we can get a count of attendees and be sure we won’t overflow the space allocated.  If you’re not coming to Black Hat, you can also submit your idea on the web at the link above.

I’m looking forward to seeing some of you next Tuesday in Las Vegas!

Jeremy Dallman here. This morning Brad Arkin via the Adobe ASSET team blog announced their upcoming release of Adobe Reader Protected Mode. I wanted to take a moment to congratulate Adobe Security and the Adobe Reader team on reaching this significant milestone. As Brad mentioned in his blog post, Microsoft worked with Adobe on the design model for this security feature. This work was part of the ongoing collaboration between the Microsoft SDL team and the Adobe ASSET team. We were glad to introduce the Adobe Reader team to the Microsoft Office team and have them work closely with David LeBlanc,  Dan Jump and  other members of the Microsoft Office security team to leverage Microsoft’s sandboxing knowledge and experience. Adobe Reader Protected Mode is based on Microsoft's Practical Windows Sandboxing technique.

We look forward to the release of the Adobe Reader Protected Mode feature and the protections it will provide our mutual customers.

Arjuna Shunn here to talk with you about the importance and value of software security training when implementing the Microsoft SDL.

Product and application development too often only focuses on finding security issues late in the development lifecycle, long after developers have completed features and code. Delaying focus on security results in both significant cost and a less effective software security posture. While security testing and analysis post-development are components of the SDL, the best returns on investment – and the focus of the SDL – are much earlier in the development lifecycle. One of the earliest, and often most effective components of a secure development program is effective training for product and application development staff, so they better understand the risks they can introduce into software before any code is written and indeed before any architecture is designed. To that end, we are releasing guidance to assist you with the adoption of critical training for creating more secure software.

In recent months, there have been several instances within private and public sectors where software security training for engineers has been recommended as a key method to help solve current software security problems. To assist you with developing training capabilities which will ease your deployment and accelerate your implementation of the SDL, we are releasing a whitepaper entitled Essential Software Security Training for the Microsoft SDL.

The expected audiences for this paper are technical decision-makers, compliance managers, software developers, and systems integrators who are working within or on behalf of organizations that are looking to implement the Microsoft SDL as part of their development lifecycle. The paper is broken into easy-to-digest sections that we hope are both readable and practical:

1. Overviews of Software Security Training: purpose, goals, and characteristics

2. A description of the Microsoft SDL core training courses,

3. Descriptions of advanced training content and topics

While training regimens differ based on organization specific needs, we hope this paper will provide a viable framework for understanding your needs as a development organization and help you to create and maintain an effective software security training capability.

As always, we welcome your questions and feedback in comments, mail, and our forums.

Adam Shostack here.  One of the really exciting things about being in the Microsoft Security Engineering Center is all of the amazing collaborators we have around the company.  People are always working to make security engineering easier and more effective.  When we talk about security testing, we often focus on what it can’t do.  “You can’t test security in,” and “test will never find everything.”  But much like there’s code that’s easy to get wrong, there’s code that’s hard to test.  Writing code to be testable has a long history, and one we don’t often talk about in security.  Today’s post is from Hassan Sultan, who’s responsible for one of our internal fuzzing tools.   We hope it inspires you to think about the question “How can I make the security of my code more easily tested?”

And here’s Hassan:

Security testing is an integral part of the software development lifecycle. At Microsoft, the biggest part of the security testing done is usually implemented through a technique called fuzz testing: sending unexpected input to the product and checking whether it behaves in an acceptable way (i.e. it doesn’t crash, hang, leak memory…). We also use other techniques such as static source code analysis but today we’re going to focus on fuzz testing and how you can best make use of it.

Almost every software company and every software project has to perform within constraints, they can be financial, the project has to be completed within a set budget, or time-driven, the project has to ship within a specific timeframe. The corollary is that the product must be of the highest quality possible within those constraints. How then can you perform efficient, quick and cheap security testing?

One approach we have started using at Microsoft is to change our engineering and test engineering practices to make fuzz testing easier, it’s a little bit of additional upfront work but with great savings in terms of time and resources quickly appearing over the life of the project.

There are two popular approaches to fuzz testing, considering data exchanges between a producer (the software sending data) and the consumer (the target software processing the data):

• Generation fuzzing : You create unexpected input from scratch and send it to the target, the fuzzer is effectively the producer
• Man-in-the-middle(MITM) fuzzing: You intercept the data as it flows from an existing producer to the consumer and modify it on the fly before it reaches the consumer

A couple of things are obvious when comparing these two approaches:

• Generation fuzzing requires quite a bit of work to create entirely the data exchange as the generated data must be conforming enough to be accepted by the target, but you have complete control and freedom to generate anything you want, hence you control the fuzzing quality end-to-end
• MITM fuzzing requires little upfront effort but depends on existing producers to generate data that can be modified, hence the quality of the fuzz testing depends on the producer and the data it generates

The approach I’m going to talk about is based on MITM fuzzing; the goal is to develop functionality tests in a way that makes them easily reusable as producers for MITM fuzz testing, as well as to provide a bit of functionality in the actual product to make fuzz testing more efficient. This approach makes security testing much cheaper to implement, is quite efficient and allows improving the fuzzing over time without having to rewrite numerous security tests.

MITM fuzzing using functionality tests has the following drawbacks:

• Tests tend to not behave correctly when they receive an unexpected response from the target following a fuzzed exchange as they never were meant to deal with such thing, they can hang or crash
• Tests rely on a long timeout to receive a response, and thus block sometimes for many seconds when data is fuzzed and the consumer drops the request without responding
• Tests bail out at the first failure they encounter and do not execute the following test cases, the fuzz testing can thus not be applied to those exchanges
• Test setup code is mixed with test code and causes the fuzzer to corrupt the data exchange required for setup, thus preventing the actual test from running,
• Modifying data on the fly efficiently is cumbersome to impossible when the following is present in the data exchanged:
  • Encrypted data
  • Compressed data
  • Checksums & signatures

The approach here is thus to fix all these problems at the source, we have listed the steps required along with each step’s priority, obviously the more you do, the better, but if in a crunch, start from the top of the list and go down as far as you can.

Test engineering changes for functionality tests

• P1: Harden functionality tests to handle unexpected responses from the consumer gracefully
• P1: Have configurable timeouts that can be shortened when the tests are used for fuzzing
• P2: Isolate setup code in tests so that the setup part can be signaled to the fuzzer which will then pause fuzzing until setup completes
• P2: Tests containing multiple test cases should allow running an arbitrary test case individually without the need to run them all in a sequence

Engineering changes in the product

• P1: Provide a test hook in the product to disable checksum validation in components
• P1: Provide a test hook to turn compression and decompression routines into no-op : what comes in comes out unmodified, the communication will occur correctly using uncompressed data and the fuzzer can thus modify the content easily and efficiently
• P2: Provide a test hook to disable signature validation
• P2: Provide a test hook to turn encryption and decryption routines into no-op

(A test hook is a configuration option that modifies the product’s behavior when set, it can be removed before the product ships if needed)

These modifications to the way tests and products are engineered are minor and cheap to implement when planned early on and will produce tremendous benefits by:

• Enabling security testing to be applied early on in products, which will allow to find and remedy issues early in the product cycle
• Significantly reducing the cost of security testing as this can now be performed by reusing functionality tests, you can improve security testing simply by improving your functionality tests
• Allowing all security tests to improve automatically as the fuzzing engine used gets smarter, since the security tests are decoupled from the fuzzer itself, you can thus stage your investment in security testing gradually by adding more intelligence into your fuzzer
• Lessening the number of vulnerabilities and thus lessening servicing costs

Ultimately, using both Generation fuzzing and MITM fuzzing would be ideal, as generation fuzzing provides a few benefits that won’t be attained by MITM fuzzing(the ability to create very specific scenarios for example), but when dealing with time and resource constraints, the MITM fuzzing approach allows for efficient fuzzing that can be improved over time at a minimal cost.