I wanted to share my slides from the recent Layer One conference [link], where I talked about "SDL Threat Modeling: Past, Present and Future."

There are a few points that I wanted to emphasize. The first is that I'm talking about threat modeling from the perspective of the SDL. We have other threat modeling processes here at Microsoft, and we're working to bring you more clarity in how we speak about them. For my part, I'll try to clearly say "SDL threat modeling," or be explicit when I'm talking about threat modeling in broad terms.

Which brings me to my second point, and a slide I wanted to emphasize. (Shown here)

I no longer think of threat modeling as one thing. I see it as a label for a set of ways to address the question of "what could go wrong" with a design or set of requirements. The SDL has one process. The folks in ACE and Patterns and Practices each have another. All are customized to meet various needs. Much like we have lots of programming languages which address different problems, we're going to have lots of threat modeling processes.

Anyway, I hope you enjoy the slides.

Today, the single biggest threat to Web application security is the Cross-Site Scripting (XSS) vulnerability. In fact, I’ll go so far as to say that XSS is the new buffer overflow, the Public Enemy #1 for Web applications. With a successful XSS exploit, an attacker may be able to accomplish all of the following:

·         Hijack the victim’s application session and impersonate him/her

·         Phish the victim’s username and password

·         Log the victim’s keystrokes and send them back to the attacker

·         Forge malicious requests with the victim’s authentication credentials

·         Create a worm that will attack not only the victim but all of the victim’s email contacts, and all of their contacts, and so on

As bad as XSS is, it’s just the tip of the Web vuln iceberg. Let’s look at what OWASP considers to be the Top Ten list of the most important web application security issues:

1.       Cross-Site Scripting

2.       Injection Flaws

3.       Malicious File Execution

4.       Insecure Direct Object Reference

5.       Cross Site Request Forgery

6.       Information Leakage and Improper Error Handling

7.       Broken Authentication and Session Management

8.       Insecure Cryptographic Storage

9.       Insecure Communications

10.   Failure to Restrict URL Access

Looking at this list, we address Cross-Site Scripting issues in the SDL very thoroughly today: we have several XSS detection and prevention tools our development teams use to defend against XSS attacks. (As I’ve written here before, some of these tools are Microsoft-internal, but some are publicly available; I highly recommend that you use the ones you can.)

We also have guidance for preventing SQL Injection attacks, the most common form of injection flaws (#2 on the list). In a nutshell, our recommendations here are to: use parameterized queries/commands when possible; deny access to underlying database objects and use views or stored procedures to perform the data access; avoid using EXEC in stored procedures; and avoid using ad-hoc concatenated SQL statements at all times.

Next, we also have requirements concerning the use of cryptography, and a list of mandated cryptographic algorithms and key sizes (currently: AES >= 128 bits for secret-key ciphers; RSA or Diffie-Hellman >= 2048 bits or ECC >= 256 bits for public-key ciphers; SHA2 for hashing; and >= 128 bit key lengths for HMACs) for new code. This pretty much covers #8 on OWASP’s list, “Insecure Cryptographic Storage”.

As for the rest of the OWASP Top Ten list, we still have some work to do to more fully incorporate it into the SDL. Why is this? The nature of the Web application security space is that it changes very rapidly. Three of the top ten items (#3: malicious file execution, #5: cross-site request forgery, and #9: insecure communications) are new items that didn’t appear on the previous list. And items that were on the previous list were removed from this list – in fact, even the previous #1 most important issue (unvalidated input) does not appear in the current top ten (perhaps because it was deemed to be too generic). It’s possible that some security researcher will drop an 0-day at Black Hat, or Toorcon, or some other security conference that will completely change the vulnerability landscape and be next year’s new #1 top vuln.

Furthermore, it’s not just that Web vulnerabilities are churned out in record time, but Web applications are too. Web apps don’t have two- or three-year long release cycles like box products. They have two- or three-week long release cycles. This presents something of a dilemma from a security standpoint. We can’t and won’t allow our software to be released with known security vulnerabilities, but we also need to allow teams to spend the grand majority of their time implementing new features. In order to reconcile these requirements, we need to continue to adapt the SDL to the needs of lightweight, agile development teams.

I’m currently working with Michael and several other people in teams across the company (including Online Services Security & Compliance, ACE, and SWI) to make these changes in the SDL, to fine-tune it so that it works even better for online services and other short-release-cycle products than it does already. We definitely have our work cut out for us! I hope to be able to share some of the details of our process changes, and some success stories, with you here later this summer.