Back to the Future: Attack Surface Analysis and Reduction

Hi, Michael here.

A couple weeks back we released a beta version of the Attack Surface Analyzer tool. Hopefully, you’ve downloaded and looked at it by now!

This tool is one of many tools we use as part of the SDL to help software developers make their products more secure. But we didn’t always have a tool like this; we used a collection of tools to measure various attack surface elements, such as open ports or services running by default. Clearly running lots of little tools is tedious, so we created the attack surface analyzer tool.

In the rest of this article, I’d like to spend some time explaining how we’ve refined the attack surface analysis process at Microsoft over the years.

Prior to working on the SDL, I worked on the IIS4, 5 and 6 teams and one of the items I created in 2000 was a simple checklist for web server administrators to use to lock down IIS4 and IIS5 servers. The checklist was not required for IIS6, but more on this later.

In 2002, Steve Lipner asked me how I would measure security progress in Windows .NET Server (it later became Windows Server 2003.) His question was totally open-ended, so I thought about it for a while. After a couple of days, I told him I thought that designing products as securely as possible and writing code that’s as secure as possible were lofty goals and we need to also think about not exposing features to attackers that are not commonly used. I had created some metrics that became known as the Relative Attack Surface Quotient or “RASQ.” Yes, many people tried to find ways of deriving RASCAL or RASQAL acronyms, but none succeeded!

The data elements we measured included:

· Open ports

· Named pipes

· RPC endpoints

· Null Sessions

· Installed Services

· Services running default

· Services running as SYSTEM

· IIS web directories (including sample apps)

· Users

· Etc.

Enumerating all these elements took about a dozen tools. The output of each tool was tallied to create a graph like this that showed the RASQ for each version of Windows since Windows NT4 through Windows XP. Smaller is better.

clip_image002

Notice the delta from “Windows NT 4 SP6a + Option Pack” to “Windows NT 4 SP6a + Option Pack + IISChk” and “Windows 2000” to “Windows 2000 + IISChk.” IISChk is the checklist I mentioned, and the “Option Pack” is IIS4. Clearly, part of a checklist’s goal is to reduce attack surface.

I think the most telling delta is from “Windows 2000 + IISChk” to “Window Server 2003.” The default install of Windows Server 2003 has a smaller attack surface than the default install of Windows 2000 after the checklist is applied. This was a watershed moment for Microsoft Windows, and the biggest change was IIS was no longer installed by default.

As the SDL started to evolve, we invented the slogan “Secure by Design, Secure by Default.” The first clause means “get the design and code secure” and the last clause means “the product will never be 100% secure, so reduce the product’s attack surface.”

Once development teams inside Microsoft saw the value of a reduced attack surface: fewer security bulletins and lower severity bulletins, it was obvious we had to streamline how we measured attack surface. So the attack surface analysis tool was born in our group. This tool is a standard tool run by all teams as part of their SDL requirements.

An important success factor to using this tool is to run it often, preferably on every build, to make sure you catch anything that might unnecessarily increase attack surface.

Next week at the RSA Conference 2011 in San Francisco, Bryan Sullivan and I will present a paper entitled, “[AND-108] Stop Exposing Yourself: Principles of Attack Surface Analysis and Reduction” that explains the process of attack surface analysis and provide guidance for reducing attack surface without annoying your customers.

So, if you’re at the conference, please stop by. Even if it’s just to say “hi!” or see a demo of the new tool.

Speaking of demos, one of the team members that created the tool, Solomon Lukie, will be at the Microsoft booth at the RSA Conference giving hands-on demos and explaining the tool’s value.

And speaking of the RSA Conference, Scott Charney, corporate vice president of Trustworthy Computing at Microsoft, will present a keynote session on Collective Defense: Collaborating to Create a Safer Internet. Scott will highlight computing trends and discuss the reality of evolving cyber threats. He will share Microsoft’s vision about how we can collectively work together to improve security protections for all Internet users. The keynote will be at 9:00 am on Tuesday, February 15, in North Hall D, Moscone Center (KEY-101).

Follow @MSFTSecurity on Twitter for news and information and @msdl for SDL info.

About the Author
Michael Howard

Principal Security Program Manager

Michael Howard is a principal security program manager on the Trustworthy Computing (TwC) Security team at Microsoft, where he is responsible for managing secure design, programming, and testing techniques across the company. Michael is an architect of the Security Development Read more »