Hi, this week is a post from Michael Howard and Laura Machado de Wright, who both attended and presented at TechEd 2008 in Orlando the week of June 2nd.
First up is Laura.
I have been a Security Program Manager for the last 3 years, working as a security advisor for a variety of products across Microsoft and the last seven months as a member of the SDL policy team.
It's been a few years since I've been to TechEd, and this was my first time attending as a member of the security team. TechEd is now a two week conference, with one week dedicated to developers and the other to IT professionals. I think that breaking down the conference into a Developer week and an ITPro week was a good idea, and it allowed us to have good conversations with people who wanted more information about the SDL. I did two main things at TechEd:, I presented on threat modeling, and I spent a lot of time talking to customers at the SDL booth. At the SDL booth, we heard questions ranging from "What does the SDL stand for?" to "Our Web site was hacked; how do I stop it from happening again?" It was encouraging hearing people interested to hear more specifics about how we implement the SDL at Microsoft, and thinking through how they can apply it in their own companies. My understanding from other TechEd veterans in our booth is that interest in the SDL seemed higher, which is great.
During my Threat Modeling session, , most of the feedback and follow-up questions were similar to the ones in the booth: how to expand the threat modeling processes to their own companies, and how to get started.
My typical response to both questions is to start small and do what makes sense for your organization. At Microsoft, for example, when we introduce new SDL requirements, we usually start with a few teams so we can refine the requirement and supporting tools before expanding the requirements to a broader group. Similarly, while we have a core set of requirements that all teams have to meet, there are other requirements that are specific to a platform, scenario, or functionality. For example, there are some requirements that make sense for desktop-oriented products, but do not make sense for mobile devices. You may very likely have to make changes to our policies to make them relevant to your organization, your scenarios, and functionality.
Now over to Michael.
Hi, Michael here.
One of the joys of presenting at TechEd each year is hearing from real people about the issues they face using our products in the real world; rarely are the issues pure philosophical security geekness. This year I gave two talks and one "chalk talk." The talks were "Top Ten Strategies To Secure Your Code" and "How To Review Your Codeand Test For Security Bugs", and the chalk talk, which was a lot of fun, was simply answering numerous developer questions.
It's interesting to gauge overall security awareness from our customers, and there is no doubt that over the years, the level of security knowledge and maturity has risen. I think it's possible to evaluate overall security maturity by the questions posed. Some years ago, security was never really a topic of discussion other than those that relate to security technologies, such as how to use and manage X.509 certificates. About four years ago the tide really changed and people started asking more questions about "secure" application deployment and management, and developers wanted to learn more about securing their code; especially C and C++ code. Even then there was still a reliance on exterior defenses like firewalls. All too often I would hear people claim that they don't need to focus on securing their apps because a firewall was in the way. Heck, David and I documented this excuse in the original version of Writing Secure Code (Appendix D, "Lame Excuses We've Heard, #6, ‘We're Secure-we use a Firewall'") way back in 2002.
Fast forward to 2008.
Things have obviously changed. I don't know if finally the security message is getting through because many people asked me highly specific questions about securing their apps and how best to use the defenses we offer in Windows Vista and Windows Server 2008.
I still hear the firewall excuse a little, but not too much!
Perhaps the most telling trend I saw this year was a great deal of interest in the SDL. Not cursory, "that looks interesting" interest, but, "how can I implement this in my company" interest. After answering specific questions, I pointed most folks to Jeremy's "Crawling Toward SDL" post on the subject.
In my opinion, getting to a point where you want to change your development process shows you really understand there's an issue that needs fixing.
Bryan here. A couple of weeks ago, I posted a blog entry with links to SQL injection defense guidelines. The SDL requires guidance and education for end-users, and tools to verify security settings are highly recommended, as defined in "Stage 5: Implementation Phase: Creating Documentation and Tools for Users that Address Security and Privacy". Today, Microsoft is releasing two new SQL injection defense and detection tools, URLScan 3.0 and Microsoft Source Code Analyzer for SQL Injection (MSCASI). We are also excited to announce the release of HP Scrawlr, a SQL injection detection tool developed by HP Web Security Research Group in conjunction with Microsoft.
Each of these tools works differently and each attacks the SQL injection problem from a different angle, and in combination they complement each other well. MSCASI analyzes classic ASP source code to find potential SQL injection vulnerabilities. It can detect both first- and second-order SQL injection bugs and will point you to the exact line of source code where the error occurs.
However, sometimes you don’t have access to the complete source code of your application; for example, you might use third-party libraries or services in your code. This is where Scrawlr comes in. Scrawlr is a black-box analysis tool that doesn’t require access to source code. You just give Scrawlr the URL of your web application and it crawls and analyzes that application for SQL injection vulnerabilities. One downside is that Scrawlr can’t point you to the exact line of vulnerable code the way that Microsoft Source Code Analyzer for SQL Injection can, but this is why the two tools work so well together. In general, source-code analysis tools and black-box analysis tools often work better in conjunction with each other, but this is definitely a larger topic for another blog post.
Finally, URLScan 3.0 is an update to the existing URLScan IIS request filter tool. URLScan 3.0 blocks HTTP requests that contain suspicious text like SQL keywords. URLScan 3.0 is a good defense-in-depth measure, but it’s important to find and fix vulnerabilities at the source. Never rely solely on URLScan or any type of application firewall as your only defense. (I’ve talked on my blog about some potential dangers of substituting firewalls for secure development practices.)
If you’d like more information, the Security Vulnerability Research and Defense blog has posted a more in-depth analysis of each of these tools. I recommend that you download both of the detection tools and test your applications against them. If either tool reports a vulnerability, I also recommend that you use URLScan 3.0 to block attacks while you fix the problems in the source code.
Adam Shostack here.
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.
In a previous post I explained how to use HeapSetInformation correctly. In short there's an option when calling this function that will terminate your application if the heap manager detects some form of heap corruption, or the potential to cause heap corruption.
I would recommend you read the previous post before continuing.
You guessed it, the number one email I got after this post was, "So, what sort of corruption will terminate my app?"
So for all those who emailed me, here's a list:
But there is one huge and critically important caveat to using the defense: it only works if you use the Windows heap manager. You might be surprised to learn that many applications actually implement their own heap functionality for various reasons, often legacy reasons based on historically poor performance of operating system heap managers. A great deal of performance work was performed on the Windows Vista and Windows Server 2008 heap managers, but the work performed is way beyond the scope of this document. Another common scenario is to allocate a huge block of memory from the operating system and then perform custom allocation within that heap block. Again, if you do this, you will not get benefit from using the heap corruption termination capability and you will still be subject to repeatable heap based attacks.
Another down side of not using the native Windows heap manager (or if you use your own sub-allocation mechanism) is you cannot take advantage of Windows leak-detection tools because you are not using the Windows heap in the way it's meant to be used, or you're not using the Windows heap at all.
With all this said, I realize that moving off a custom heap to another heap is never an easy task, but if you want to take advantage of this defense, you should add "Move off our custom heap" to the list of development tasks.