Hi everyone, Bryan here. Michael wrote a great post here on SDL-required SQL injection defense techniques in the wake of the recent mass SQL injection attacks against ASP sites. Additionally, the Security Vulnerability Research & Defense blog has just posted an analysis of the attack along with guidance recommendations for IT/database admins, web developers, and end users. Finally, if you are looking for classic ASP-specific (not ASP.NET) guidance, Bala Neerumalla has posted a detailed document on preventing SQL injection in ASP on MSDN.
Hi everyone, Shawn Hernan here. Being a security guy is incredibly rewarding because you get to look at virtually any part of a product, from kernel drivers to web services to user education to sales and servicing. You have to do that because a failure in one of those areas can endanger the security of our customers. Microsoft’s SDL process reflects that reality. The process is structured so that you really do have to look at each piece before you can sign off. But sometimes when others want to emulate the success of the SDL, they want to skip steps. They try to boil the SDL down into its component parts, like training, or tooling, or security response. Maybe the most common form of that mistake is training, but you see that same thinking applied to code scanning, security response, and just about every phase of the SDL. “Let’s just train everyone, and all our security problems will go away.” If only it were so easy. I’d like to take a few minutes to try to explain why it’s not really that easy from my own experience.
Have you ever sat in a corporate training? Some are good, some are bad, but did you ever say, “man I can’t wait for training today.” What about mandatory training? What about mandatory training in a subject that you really don’t think is your area? What if you had to do it every year, and got harassed if you didn’t do it? What if you were, say, an audio engineer and were dragged into a security class?
I ran the SDL training program at Microsoft for a long time, and developed and taught a big chunk of the training. I spent hundreds of hours in front of thousands of developers, testers, and program managers. I got some really good reviews (and a few bad ones) on the classes I offered. And I tried to do a lot of things to try to make the trainings interesting. I handed out dozens of fresh peaches in an early class on fuzz testing, for example. The room smelled really nice after that, and there are probably still a few people around Microsoft who think of fuzz testing when they see a peach.
But even on my best day, I was under no illusion that the majority of the audience was excited to be there, and I was certain that they weren’t going to go back to their offices and spend weeks applying the lessons from the class, setting aside other things that are causing present and immediate problems in favor of something that is far off into the future.
You have to work at getting people’s attention – especially as it relates to security and privacy. From time to time, I would see people reading their mail in class, and I would point to them and ask them a question. That did not endear me to the audience as much as the peaches, but embarrassment is always fresh and in season. J
One student wrote of one of my classes, “the basics for secure design - could be replaced by non-anonymous site-wide exam with open material.” He was not alone, I assure you.
Is that an indication that our training, or any training, is pointless? Hardly, but training alone is not a change agent.
Richard Derwent Cooke wrote, “It is a first principle of Change Management that people will act in what they perceive as being their best interests.”
At best, training can provide people with insight into what they need to do to solve a security problem if they believe that solving that security problem is in their best interests.
To be effective, training needs to happen in an environment:
· Where expectations are clearly set (the SDL sets specific minimum requirements).
· People have appropriate incentives and consequences (security is a great career path at Microsoft, and nobody wants to be the one holding up a ship schedule for failure to meet a security requirement).
· Where tools and resources to accomplish the goals are available (we build a whole variety of tools that map to the SDL requirements).
· Where management models the behavior (recall the original BillG TWC memo).
· Where the environment reflects and supports the values presented in the training (apparent in everything Microsoft does).
Don’t make the mistake of thinking that a bunch of training, even really high quality training done periodically, will result in actual behavior change. It won’t. You have to build an environment where people perceive solving security problems as being in their best interests. You have to make security their problem – not in the sense of passing the buck, but in the sense of changing their behavior so they will bring security problems to you.
To illustrate further, I’ll cite two examples. First, fuzz testing. Fuzz testing has been a success story here at Microsoft. Tools arise spontaneously to solve new fuzzing challenges, written by people who believe the challenges are their challenges. There are people who feel ownership for our fuzzing strategy and on-going research and science, there are specific goals and requirements, we have training (remember the peaches?), and internally developed fuzzers have won prestigious awards within the company, handed out by members of the executive staff, and all of this gets revisited periodically as part of the SDL.
By contrast, I’ll choose a less successful area – defect estimation. On my own volition, I created (based mostly on some excellent material from Microsoft Research) and taught a class called “Defect Estimation and Management” and added it to the SDL curriculum. Microsoft is a great place to work in that regard. It was pretty close to the best-reviewed class I taught. But, we have not yet been able to establish a set of tools to estimate security defect density effectively, and establish a fair set of expectations, incentives, and consequences, or even decide what we should do if we had the data. We discovered some things, though. For example, based on what I observed (which should not be construed as rigorous research), it does not appear as if the density of general defects correlates closely with the density of security defects. And Microsoft Research found higher code coverage in testing correlates with higher bug rates in the field.
And so even though people like the idea of defect estimation, and we’ve got some interesting and surprising data, we’ve not yet been successful in changing people’s behavior. Generally speaking, an individual test manager does not feel that establishing a high quality estimate of their defect density is in his or her best interests, as compared to, say, improving the time in which an established series of tests can be performed .
We need to build an environment that has the tools, training, rewards and incentives, and expectations and consequences to change people’s behavior. Not that we’re not trying. But training won’t solve it alone, nor would tools, trophies, rants, testing, code review, or some edict from on high. The SDL is as much about changing the culture and influencing the behavior of individual engineers as it is anything else.
I’m convinced that Microsoft’s SDL process works because it addresses the end-to-end problem - from training through servicing, and provides a complete environment where people feel ownership of their part of the security problem and have the resources to solve it.
So the next time you find yourself sitting in some mandatory training, remember the lessons of the SDL (and most of the research on human performance management): training alone won’t cut it. If you want real behavior change, there have to be things outside the lecture room to influence people to change their behavior.
Hello, Michael here...
You may have read recently about a large number of Web servers that were compromised through a SQL injection attack. The malicious SQL payload is very well designed, somewhat database schema agnostic and generic so it could compromise as many database servers as possible. While the attack was a SQL injection attack that attacked and compromised back-end databases courtesy of vulnerable Web pages, from a user's perspective the real attack was compromised Web pages that serve up malware to attack user's through their browsers. In essence, there were two sets of victims: the Web site operators and the users who visited the affected Web sites. In this post, I want to focus on what the first set of users, the Web site operators, can do to protect themselves.
The fact that the malicious payload was so generic shows that the science of SQL injection has not taken a back seat to research in other vulnerability types, such as buffer overflows or cross-site scripting issues.
I think the first lesson from this attack is this:
If you have a Web server (doesn't matter what type), and it's hooked up to a database (doesn't matter what type) you need to go in and review your code that performs the database work.
So now that you've determined the database access code, now what? The SDL is very specific about what do here, there are three requirements - they are requirements not recommendations, which means you must do the following coding requirements and defenses
From the SDL documentation:
"Applications accessing a database must do so only using parameterized queries.
Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application. This vulnerability allows for unauthorized, interactive, logon to a SQL server which may result in the execution of malicious commands leading to the possible modification (or deletion) of Operating System or user data.
Combining the use of parameterized queries and stored procedures helps to mitigate the risk of successful exploitation of user input which is not correctly verified."
This defense has been known about forever; heck, David and I discussed this in detail in the first edition of Writing Secure Code in 2002:
From page 320, "Another way to perform this kind of processing is to use placeholders which are often referred to as parameterized commands."
Just about every database access technology supports parameterized queries; work out what they are for your DB technology and use them: the defense for a PHP/MySQL combo will not be the same as a C#/SQL Server combo.
The most likely cause of these recent compromises is using string concatenation to build SQL statements. Just don't do it, even if you think you're safe, just don't use string concatenation to build SQL statements! There are some very specialized cases where string concatenation is valid, but they are rare, especially for Web apps. In my opinion, any use of string concatenation in a Web application is a high-priority bug.
"Applications accessing databases should do so only using stored procedures. "
-and-
"Do not use "exec @sql" construct in your stored procedures.
Using stored procedures helps to mitigate the SQL injection threat to a great extent since type checking is available for parameters. If the attacker supplies input that does not match the type constraints the stored procedures will throw an exception. In the vast majority of the cases, this should be properly handled within the application.
However, if the stored procedures perform string manipulation in their code and then execute that query using the "exec @sql" construct incorrect handling of user input can produce the same SQL injection vulnerability as would be seen at the application layer."
Note the words "help mitigate," by themselves stored procedures do not remove SQL injection vulnerabilities; they just raise the bar on the attacker by hiding much of the underlying database schema from the attacker.
This next defense is interesting in that it is a defense in depth method; in this case it assumes the attacker has successfully found a SQL injection bug in your code. Now what? Thankfully, this defense will stop most every attack dead in its tracks.
"Only grant ‘execute' permission on all stored procedures, and grant that permission only for the application domain group.
Ensure that this group is granted execute permissions only on your stored procedures. Do not grant any other permission on your database to any other user or group."
This is a great defense, because if the attacker attempts to access any other database object other than through a stored procedure (you can use views also), the underlying database permissions model prevents the attack by denying access to the attacker.
It's interesting that the SDL offers three SQL injection requirements; only one actually remedies the problem (secure by design) and the other two offer mores defenses assuming failure (secure by default.)
Of course, a simple set of rules is not a substitute for careful design, implementation, and test. The SDL is a holistic process that covers the software lifecycle end-to-end, so don't mistake these simple rules as a guarantee that you will avoid SQL injection problems. You need to understand the situations in which the rules apply. You may find, for example, that string concatenation is the best - or perhaps only - solution to a particular problem and these rules may not guard against SQL injection in those situations. Follow secure development practice throughout the lifecycle of your project - including things we left out of this blog, like testing and security response, for best results.
Hi folks, Eric Bidstrup here.
As I touched on in my December posting on Common Criteria, and as Michael Howard discussed in his post on security metrics, trying to objectively quantify and measure “How secure is secure” is far more difficult than one might think. I’d like to share my perspective that there are two “dimensions” useful to consider when characterizing software security metrics: security functional requirements and security engineering quality requirements. While the SDL is focused primarily (but not exclusively) on the latter, both are ultimately important when assessing the security of a given bit of software. However, for reasons I’ll elaborate on below, the SDL does focus on trying to prevent the most common causes of vulnerabilities today and hence looking at the ways in which Microsoft tracks and measures individual products teams’ compliance with SDL requirements offers some interesting fodder for the security metrics debate. I’m not offering a complete solution, but am sharing our experience at Microsoft with measuring how development teams actually follow the SDL. It’s helped us deliver more secure software, and sharing this will hopefully help others as well as putting more data on the table for consideration when discussing security metrics.
Putting aside computer security for just a moment, it’s interesting to look at other ways in which we attempt to measure security in our society. Padlocks offer security protections, and organizations such as the American Standard for Testing and Materials (ASTM) provide standards like F883-04 Standard Performance Specification for Padlocks that characterize padlock security ratings. Prisons provide security protections as well. Prisoners reside in different facilities that vary by security level. The US Bureau of Prisons uses a numbered scale from one to six to represent the security level. Both of these examples are similar in that the threats and risks each of them must protect against are reasonably well understood and relatively static (meaning the threats don’t change much over time). Computer security is still evolving with new classes of attacks still being discovered, and while hackers understand how to exploit known types of vulnerabilities – software developers are still catching up in learning how to modify engineering practices to be resilient against both new and old types of attacks. Hence, metrics are more challenging for computer security.
Several attempts have been made by governments to come up with a security rating system similar to the examples listed above. In the 1980’s, the US Department of Defense created the “Trusted Computer System Evaluation Criteria (TCSEC)” that tried to establish a standard for measure operating system security. The “Orange Book” offered a relatively simple system for assigning “score” summarized below:
D (Minimal Protection)
C (Discretionary Protection)
C1: Discretionary Security Protection
C2: Controlled Access Protection
B (Mandatory Protection)
B1: Labeled Security Protection
B2: Structured Protection
B3: Security Domains
A (Verified Protection)
A1: Verified Design
In the 1990’s, the US and other nations combined their efforts to create an international security standard for software known as the Common Criteria (ISO 15408). Common Criteria also has a rating system that scores products with “evaluation assurance levels” (EALs):
EAL 1: Functionally Tested
EAL 2: Structurally Tested
EAL 3: Methodically Tested and Checked
EAL 4: Methodically Designed, Tested, and Reviewed
EAL 5: Semi-formally Designed and Tested
EAL 6: Semi-formally Verified Design and Tested
EAL 7: Formally Verified Design and Tested
Both TCSEC and Common Criteria (CC) are primarily focused on “security functional requirements” (as called out earlier, distinct from “security engineering quality requirements”). The EALs reflect the amount of rigor and attention to claimed security functional requirements a developer applied while creating a product. Furthermore, the EALs also reflect increasing levels of effort and resources necessary by anyone reviewing a product in order to evaluate the product’s claimed security functional requirements. However, EAL ratings for commercial products have historically not correlated with the number of vulnerabilities found in commercial products after release. As I discussed in my December posting on Common Criteria, this is because CC is primarily focused on “security functional requirements” and fails to adequately address “security engineering quality requirements”. This leads a question on how to measure those aspects of software security that earlier efforts have been unable to successfully address.
Microsoft has been releasing security bulletins since 1999. Based on some informal analysis that members of our organization have done, we believe well over 50% of *all* security bulletins have resulted from implementation vulnerabilities and by some estimates as high as 70-80%. (Some cases are questionable and we debate if they are truly “implementation issues” vs. “design issues” – hence this metric isn’t precise, but still useful). I have also heard similar ratios described in casual discussions with other software developers. In other words, most vulnerabilities can be addressed by the “security engineering quality requirements” described via SDL. This is not to say that “security functional requirements” are unimportant or that SDL ignores secure design (as Adam has described in his threat modeling series), but rather that it is not where vulnerabilities are being most frequently encountered. With SDL, we adopt a pragmatic approach in looking at identifying the root causes of security vulnerabilities, and trying to prevent those root causes from reoccurring. The challenge lies in how we actually validate that development teams are indeed adopting and executing whatever changes SDL requires in engineering (either in terms of process or tools). Process changes are often difficult to quantify, as we must rely upon development teams truthfully attesting they have followed the process. As long as development teams believe the process results in better code, they generally will adopt and follow such practices. Tool usage becomes more interesting and valuable in that using tools becomes a vehicle for objectively and independently verifying if code satisfies requirements or not. But that is just the tip of the iceberg…
As I said above in my comments on EALs, the amount of time required by anyone reviewing a product to assess “security” is relevant since security review can be a very time and resource intensive activity. However, running static code analysis tools, verifying build tools and switches, searching for banned APIs, and recording the output of other tools that inspect code and/or binaries for potential implementation vulnerabilities is a key element in how we approach the challenge of trying to measure compliance with SDL requirements from product groups at Microsoft today. While not every technique required by SDL has a corresponding tool, we try to provide both tools and automation if and wherever possible. There is still much work to be done in terms of standardizing tool output formats and creating automation to assess tool output. However, these “grass roots” metrics derive from practical experience of changing engineering requirements based on actual vulnerabilities. We look objectively at what is causing vulnerabilities, and target solutions to address the root causes of those issues. As the saying goes, “If it hurts when you do that, stop doing that”. If what we have done in the past has hurt our customers by creating vulnerabilities requiring security bulletins, we want to stop doing that. J
The challenge in using a plethora of individual detailed metrics such as I describe above (that we do internally at Microsoft for measuring SDL compliance), is that they don’t roll up into a nice aggregate score that customers can easily understand. However, they have translated into reduced numbers of vulnerabilities as Michael Howard wrote a few weeks ago. Coupling these types of scores with assessment of compliance with “security functional requirements” might be the basis for coming up with a metric that is useful to customers, both in the government and private sector.
What do you think?
Hi everyone, Bryan here. I’m speaking at BlueHat today and tomorrow about some of my experiences as a new Security PM here at Microsoft. I’d like to take this week’s blog entry to share some of my presentation with those of you that can’t make it in person. For those of you who are planning to attend, be sure to find me and say hi, and stop reading this blog entry! You’ll ruin the surprise. J
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.