Hi, Matt Miller from Microsoft’s Security Science team here to talk about exploitation & mitigation.
Over the past decade exploitation techniques have been developed and refined to the point that very little expertise has been needed to successfully exploit software vulnerabilities. These refinements have lowered the bar for attackers and drastically increased the probability that an attack will be successful. This has led to the need for mitigation techniques that can prevent or otherwise reduce the reliability of a given exploitation technique. In relation to one another, we can think about exploitation techniques as attempting to drive the probability of successful exploitation to 100%, whereas mitigation techniques attempt to drive the same probability to zero. While probability gives us a nice measure for the effectiveness of a mitigation technique, it doesn't give us immediate insight into the specific problems being solved by mitigations or the techniques that are being used to solve those problems.
Understanding the problems that are solved by mitigations is what provided the motivation for the presentation I will be giving at BlueHat. Many of the materials in this presentation were taken from my work with Leviathan Security Group and have been repurposed to focus on taking attendees on a journey through the technical evolution of the mitigation techniques developed by Microsoft. This evolution is illustrated in terms of the problems each mitigation technique is attempting to solve, the methods used to solve them, and how well each mitigation has stood the test of time thus far. The journey itself starts first with /GS and ends with a glimpse of the mitigation techniques we might expect to see in the future.
It is my hope that this presentation will illustrate that mitigations, when working in concert with one another, can be an effective method of helping to keep users secure by reducing the probability of a successful exploitation attempt for the majority of known exploitation techniques.
Bryan here. Last January, I wrote a post on this blog bemoaning the difficulty of making security interesting and “sexy” to developers. Applied research conferences generally place a much greater emphasis on revealing new vulnerabilities and new attack techniques, and much less emphasis on educating people on how to actually fix those vulnerabilities. I was at RSA Conference last April, and I attended a session by a very well-regarded, high-profile security researcher. He gave an eloquent and educational presentation on the dangers of a significant new attack vector, but all the prescriptive guidance he gave for dealing with the threat amounted to something like, “If you’re worried about this kind of thing, talk to your browser manufacturer.” No offense to this presenter, but if I’m going to listen to 70 minutes of discussion of a dangerous threat, I want to leave the room with a clear understanding of what I can do to solve the problem! It’s not enough just to know that the problem exists.
So, in conjunction with the BlueHat team, I am pleased to announce that the SDL team will be organizing the sessions for the second day of the fall BlueHat conference. The BlueHat SDL sessions will be laser-focused on not just describing vulnerabilities but also solving them. Every attendee should leave every presentation with a clear idea of exactly what he or she needs to do to protect themselves from the threat that was discussed during the session.
The sessions will begin, appropriately, with the topic of secure design. Danny Dhillon of EMC and the SDL team’s own Adam Shostack will each present their organization’s approach to threat modeling. As a bonus, Adam will also be demonstrating the new SDL Threat Modeling tool that you might have heard about last week.
Next up is Matt Miller, a recent and very welcome addition to the Microsoft Security Science team. Matt has a fantastic presentation on the evolution of buffer overflow attacks and on the corresponding development of overflow mitigations. From there we will switch gears to look at some managed code implementation issues: iSEC Partners’ Scott Stender and Alex Vidergar will demonstrate coding techniques to mitigate elusive concurrency vulnerabilities in web applications.
At this point we will have covered the Design and Implementation phases of the SDL; where better to go from here than Verification? One of the most important activities in the Verification phase is fuzzing, and we have a trio of security experts from the Microsoft Security Science team to talk about it. Jason Shirk, Lars Opstad, and Dave Weinstein will answer three of the most common fuzzing questions: How should I fuzz? When have I fuzzed enough? And what do I do now that I’ve fuzzed?
Finally, we will wrap up the Verification phase talks with a return appearance to BlueHat by Stach & Liu’s Vinnie Liu. Vinnie will compare different approaches to security verification – static code analysis, blackbox analysis, and manual code review – and make recommendations as to when each approach is best used.
Even if you can’t make it in to BlueHat in person, you can still watch the sessions via streaming media on TechNet. Additionally, webcast interviews with the speakers – condensed “Cliff’s Notes” versions of their full presentations – will be posted on Channel 9. And we’ll be continuing the BlueHat tradition of inviting speakers and other industry notables to guest blog about their topics and the latest security trends. More information on all of these resources will be posted here when it becomes available.
I expect that a number of you have seen the announcement and various press articles or Steve Lipner's Tuesday post about our launch of the SDL Threat Modeling Tool 3.0, the SDL Optimization Model and the SDL Pro Network. Since I was intimately involved with the creation of the SDL Pro Network, I thought I'd write a few words about our objectives and chat a bit about the thinking behind our partner choices for the pilot phase.
So, what are we hoping to gain by creating a network of security consulting and training experts to work with customers who want to implement the SDL? Generally speaking, this question has a two-part answer: First, Microsoft is, and always will be a partner-driven company - we rely on the skills and capabilities of our partners to provide specialized services and broad geographic coverage for Microsoft products and services. Second, even though there are talented folks in the Microsoft Services organization, it's clear that we will need help from our partners to scale to meet the demand. I can't tell you how many times the folks on the SDL team have been approached by people - after an executive briefing, or a session at TechEd - asking for guidance in implementing SDL in their own organizations. When we look at the demand and pair it with the geographic diversity of our customer base, it's clear that a partner approach is the right answer.
Now a few words about the partners who will be participating in the pilot phase...
After the decision was made to work with partners on SDL delivery, we had two primary criteria that we had to address; partner quality, and manageability of the SDL Pro Network pilot. We have all seen instances where individuals or consulting organizations have represented themselves to the IT community as having security expertise when in reality the "experts for hire" were simply reading a page or two ahead of the customer in whatever security tome was "in vogue" at the time.
Based on those observations, it was clear that partner "quality" was a critical criterion. Fortunately for us, we didn't have to look far to satisfy our quality bar - many of the companies in the SDL Pro Network pilot have direct experience with executing portions of the SDL on our products, or have delivered services to Microsoft in a security context. Design reviews, code reviews, penetration testing, training and other tasks critical to SDL implementation were (and are) common fare for these folks.
Despite the customer demand for SDL that I alluded to above, starting with a small pilot was the right thing to do; a small group of trusted consultancies supports our imperative for quality and it allows us to pragmatically grow the SDL Pro Network as the market matures. As we continue to evolve and innovate with the SDL, we'll have a strong core of partners to help drive the software security message.
Will we grow the SDL Pro Network? The qualified answer is: "When the market demands it..." - there are a number of talented potential partners who meet the quality bar - and clearly, the need for security in software development will grow to demand additional talented specialists. However, it's our plan to begin with a small set of partners of known expertise, and then respond to growing demand as it materializes.
So there you have it - the nuanced beginning and bright future of the SDL Pro Network... I invite your comments, and encourage you to check in at the SDL Portal as we continue to build out the program
Steve Lipner here.
Last week I participated in a “press tour” talking to press and analysts about the evolution of the SDL. Most of our past discussions with press and analysts have centered on folks who follow security, but this time we also spoke with publications and analysts who write for software development organizations. I was struck by the extent to which the folks who focus on development have been grappling with many of the issues about developing secure software that we’ve focused on here at Microsoft.
Security beat reporters, whom we have been working with for years, have been exposed to a regular stream of news on the latest bugs, worms and viruses, and Microsoft’s ability to react quickly to customers affected by those attacks with patches has been the industry story for many years. Last week, I had an opportunity to get out and tell the other side of the story – what we are doing proactively as a major software vendor and platform provider to help eliminate vulnerabilities during the development process. Based on feedback from reporters and analysts who know this space, our work to take Microsoft’s SDL best practices and share them externally has clearly been a need in the industry for a long time.
The specific occasion that motivated me to spend a week in conference rooms, airplanes and hotel rooms was today’s announcement of new initiatives in sharing aspects of the SDL with the development community. These initiatives don’t make secure development a “cut and dried” process, but I believe they will take things one step further toward enabling developers to build more secure software. I’d encourage you to look at our announcements. I’m really excited that we’re taking these new steps to share more of our secure development practices and tools with developers who need them.
As always, we’d welcome your feedback about these new programs and what we should do next.
Hey all – Dave here…
Wanted to drop a quick note to introduce the latest member of the SDL team - Katie Moussouris!
Many of you may already know Katie from her past work on the MSRC Ecosystem Strategy Team or her tenure at Symantec and @Stake.
Katie has joined the SDL team to help drive crucial elements of our SDL outreach effort; her primary responsibility will be managing our relationships with security consulting and training partners. She’ll additionally be tasked with ongoing analysis of the SDL – with a goal of assisting industry verticals that are looking to apply the SDL in critical computing scenarios.
It goes without saying that she will be a regular contributor on the SDL Blog – but given her expertise, it’s likely she’ll continue to blog on an occasional basis over on Ecostrat...
Anyway – here’s Katie in her own words!
Katie Moussouris is a Senior Security Program Manager in the Security Development Lifecycle (SDL) Outreach Team, working to bring Microsoft’s SDL to partners, vendors and customers in order to improve the security of the Internet as a whole. Katie began her nerdy life programming her C64 in grade school, writing her own Zork-like text-based adventure – which was of limited use, since she had no friends and she knew all the puzzles in her own game. Good thing she eventually left her room and found some like-minded people at a local 2600 meeting.
Katie’s professional background is application security, having come from Symantec by way of the @stake acquisition. Katie founded the Microsoft Vulnerability Research Program (MSVR), extending the focus of Microsoft’s security vulnerability research to third party software. Katie also founded and ran the Symantec Vulnerability Research Program, the first program of its kind in Symantec's history to allow the publication through Responsible Disclosure of original vulnerability advisories discovered by Symantec researchers. In addition to performing security research, Katie has been an application penetration tester for Fortune 500 companies across numerous industries. She has uncovered serious vulnerabilities during the course of her work before they could be widely exploited by hooligans and criminals for either fun or profit, respectively.
Bryan here. Since Steve called me out in his post on the XSS Filter last week, I feel obligated to clarify my position. ☺ I believe that the SDL blog is mainly for development teams; after all, development is the D in SDL. Now, development teams are made up of more than just developers. Development teams include everyone involved in the development process from management on down. But development teams don’t include end users. While XSS Filter is a great, innovative XSS defense technology, there’s really nothing that development teams can do to take advantage of it. Users alone make the decision as to whether they’re going to take advantage of XSS Filter: they either use IE8 and get it, or they use another browser and don’t get it.
That being said, there are some interesting implications that XSS Filter and other user-specified defenses have for the SDL. Given that XSS Filter is effective in stopping many types of reflected XSS attacks, should we relax the SDL coding and testing requirements around server-side XSS defense? Of course not. For one reason, the SDL requirements are effective in preventing forms of XSS that XSS Filter does not address, like persistent XSS. For another, not everyone uses IE 8. If we were to relax server-side requirements now, we would jeopardize IE 7 users, as well as Firefox, Safari, Opera, Chrome, and all the other browsers’ users.
But what if these conditions change? What if David and others on the security science team develop a new version of XSS Filter that’s effective against all forms of XSS? And what if all the browser manufacturers develop similar technology and implement it in their browsers? (Or alternatively, what if every user on the planet switches to IE 8? ☺) Then would we relax the server-side XSS defense requirements? Yes, we probably would.
I’ve always been more of a security pragmatist than a security purist. While the security purist in me would want to keep the requirements around to prevent developers from falling back into bad habits, the security pragmatist in me would recognize that development teams have a limited amount of bandwidth, and making them defend against rare, obscure vulnerabilities is a poor use of their time. Unfortunately, we’re not likely to face this scenario any time in the near future, so the SDL will continue to require server-side input validation and output encoding to prevent XSS attacks.
We now return you to your regularly scheduled development-focused blog.
Steve Lipner here. When the Internet Explorer team posted the announcement about the XSS Filter feature in IE8 I asked some other members of the SDL blog team “why aren’t we talking about the new XSS Filter feature on the SDL blog?” Bryan and Jeremy said something like “that’s a mitigation that only applies to specific clients and a subset of attacks”. So we didn’t cross-reference IE’s XSS Filter post on the SDL blog at the time. Instead, I agreed to write a subsequent post about the relationship of XSS Filter to the SDL and to the ways that our SDL and security science teams think about improving product security.
For those of you who aren’t familiar with XSS Filter, a brief summary is that it is a client-side defense against reflected cross-site scripting (XSS) attacks. It works by recognizing that reflected XSS attacks inject script into the string that the browser sends to the targeted web server. If the server doesn’t neuter or strip out the injected script, it gets sent back to the browser and executed in the context of the target web page. Bad things then happen. At a high level, XSS Filter remembers the string that the browser sent to the server, and looks at the server’s response to see if any of the script was actually in that string. If it was, then XSS Filter decides that it got there because it was injected by an XSS attack and blocks the script from executing. The rest of the web page renders as usual. This is a vastly oversimplified sketch of XSS Filter – for details, see the post by David Ross, inventor of XSS Filter on the Security Vulnerability Research and Defense blog.
So what does XSS Filter have to do with the SDL? Well, for almost nine years, since XSS was first discovered at Microsoft, we’ve been trying to figure out effective ways to reduce vulnerability to XSS attacks. Our focus has been on improving the ways that web page developers code their pages, and we’ve developed a lot of tools and techniques for making web content safer from XSS attacks and for detecting XSS vulnerabilities in live pages. The SDL requires the use of many of these tools and techniques, and we’re sure we’ve prevented a lot of XSS vulnerabilities from being introduced into Microsoft web pages as a result.
But while we identify (and the SDL requires) measures that allow developers to avoid classes of vulnerabilities, we also look to identify more sweeping solutions that can either 1) eliminate classes of vulnerabilities, 2) reduce their severity, or 3) reduce the likelihood of attacks being successful. The process usually starts from deep understanding of a class of vulnerabilities and attacks, and then we broaden defenses from there. In the case of XSS Filter, David’s years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today. The solution is compatible with existing web pages (doesn’t “break the web”) and thus we were able to enable it by default for users of Internet Explorer 8. Because it’s a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS.
Our work on buffer overrun defenses follows a somewhat similar pattern – we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns. As we gained a deeper understanding of how buffer overruns can be exploited, we enhanced the /GS compiler flag and added ASLR in a quest to cause classes of exploits to fail even if a buffer overrun remains. We’re not yet close to eliminating the SDL requirements for use of tools and coding techniques, but the SDL also requires the use of the mitigations to reduce the severity of vulnerabilities that slip past. Will we ever get to the point where the mitigating technologies are so strong that we can relax the coding requirements? Maybe not, but we will continue to introduce technologies that reduce the chances of a successful attack.
Similarly, in the case of XSS, even after IE8 ships, the SDL will continue to require the use of safe web site coding practices and tools such as the Anti-XSS library both to protect users of browsers other than IE8 and to provide protection in recognition of the fact that XSS Filter is a mitigation or defense in depth rather than a complete solution. But we’ll also be keeping our eyes open (and doing active research) in the quest for an even more effective defense – whether client or server side – that eliminates XSS for good.
This post is a little far afield from the normal content of the SDL blog, but I thought it was important to provide a picture of the role of security science and security research in defining SDL requirements and in making major improvements in software security. You can read more about our work in security science in the Security Vulnerability Research and Defense blog.
I’ve been catching up on various security-related articles that I’ve been meaning to read, and the following article was on the list http://www.itnews.com.au/News/73635,google-shares-its-security-secrets.aspx about Google’s “security secrets.”
Quoting from the article:
“In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers."
I think it is great that Google has a security program they are willing to talk about and I could not agree more with the ‘security as a cultural value’ philosophy. But isn’t there something really fundamental missing here? Design? There is a lot more to software engineering other than coding and testing.
The SDL has a very large set of implementation-related requirements, but there are many design-related requirements also.
Computer security experts have known since the early 1970s that you have to get the design right; and our experiences with the SDL over the last 5 years have taught us that you need to consider security and privacy (but remember, you have to ship too!) very early in the design phase and have a consistent end-to-end process if you truly hope to reduce vulnerabilities and create more secure software. This is how the SDL is helping to create ‘security as a cultural value’ at Microsoft.
We’ve seen a general trend downward in security vulnerabilities in Microsoft products, and the IBM X-Force 2008 mid-year report backs the assertion that we’re making progress; according to the report Microsoft’s share of total vulnerabilities decreased from 3.7% in 2007 (1st place) to 2.5% (that’s 2.5% for all Microsoft products; a more appropriate comparison might be Windows vs Linux vs Mac OSX, or SQL Server vs Oracle vs DB2) in the first 6 months of 2008 (3rd place.) This is an encouraging signal that the SDL is working on a large scale… of course, it might also show that vulnerability researchers are moving to easier targets, which, to me shows the SDL is working too.
What do you think?
A group of MIT students made news last week with their discovery of insecurities in Boston's "Charlie" transit fare payment system [pdf]. The three students, Zack Anderson, R.J. Ryan and Alessandro Chiesa, were working on an undergraduate research project for Ron Rivest. They had planned to present their findings at the DEFCON conference last weekend, but were prevented from doing so after the transit authority obtained a restraining order against them in federal court.
The court sets a dangerous standard here, with implications well beyond MIT and Boston. It suggests that advances in security research can be suppressed for the convenience of vendors and users of flawed systems. It will, of course, backfire, with the details of the weaknesses (and their exploitation) inevitably leaking into the underground. Worse, the incident sends an insidious message to the research community: warning vendors or users before publishing a security problem is risky and invites a gag order from a court. The ironic -- and terribly unfortunate -- effect will be to discourage precisely the responsible behavior that the court and the MBTA seek to promote. The lesson seems to be that the students would have been better off had they simply gone ahaed without warning, effectively blindsiding the very people they were trying to help.
The Electronic Frontier Foundation is representing the students, and as part of their case I (along with a number of other academic researchers) signed a letter [pdf] urging the judge to reverse his order.
Update 8/13/08: Steve Bellovin blogs about the case here.
Adam Shostack here. I'm working on a paper about "Experiences Threat Modeling at Microsoft" for an academic workshop on security modeling. I have some content that I think is pretty good, but I realize that I don't know all the questions that readers might have.
So, what questions should I try to answer in such a paper? What would you like to know about? No promises that I'll have anything intelligent to say, but I'd love to know the questions you're asking. So please. Ask away!
I got a lot of interesting comments from my TechEd 2008 presentation entitled, "How To Review Your Code And Test For Security Bugs," but the most comments and questions were reserved for fuzz testing; I was blown away by the number of people who thought fuzz testing was hard, or that you only left fuzz testing to ‘leet hackers.
During the presentation I mentioned in some depth how to perform fuzz testing, and what parts of an application should be fuzz testing targets. I also introduced an idea (that's not new) to help people who have never performed fuzz testing begin fuzz testing with very little cost and friction. The idea is to add a small layer of code to an application to automatically mutate untrusted data as it comes into an application; I called that code layer "a layer of hurt."
Before I continue, I want to point out that fuzzing is an SDL requirement, but the idea in this blog post is not an SDL requirement, it's just another way to help meet SDL fuzzing requirements.
Adding a layer of hurt, as shown in the picture below, is pretty simple as it involves adding code to an application to tweak data as it comes into an application. You can work out where to place the fuzzing code by looking at your threat models to see where data crosses trust boundaries. You could also simply grep the code looking for APIs that read data, for example:
You get the picture.
The fuzzing code should appear right after the API that reads that data.
For example, C or C++ code that reads from a UDP socket and then fuzzes the data before it's consumed by the rest of the application might look like this:
char RecvBuf[1024];
int BufLen = sizeof(RecvBuf);
int result = recvfrom(
RecvSocket,
RecvBuf,
BufLen,
0,
(SOCKADDR *)&SenderAddr,
&SenderAddrSize);
#ifdef _FUZZ
Fuzz(RecvBuf,&BufLen);
#endif
Or, in C#, code that reads from an untrusted file:
FileStream fileStream = new FileStream(filename, FileMode.Open, FileAccess.Read);
uint len = (uint)(fileStream.Length);
byte[] fileData = new byte[fileStream.Length];
fileStream.Read(fileData, 0, (int)len);
fileStream.Close();
#if _FUZZ_
Malform pain = new Malform();
fileData = pain.Fuzz(fileData);
#endif
In both code examples, Fuzz() mutates the incoming data. In the C++ case, the fuzzing code looks like this:
void Fuzz(_Inout_bytecap_(*pcbBuf) char *pBuf,
_Inout_ size_t *pcbBuf) {
if (!pcbBuf || !pBuf || !*pcbBuff || *pBuf) return;
if ((rand() % 100) > 5) return; // fuzz about 5% of Buffers
size_t cLoop = 1 + (rand() % 4);
for (size_t j = 0; j < cLoop; j++) {
size_t i=0,
iLow = rand() % *pcbBuf,
iHigh = 1+rand() % *pcbBuf,
iIter = 1+rand() % 8;
if (iLow > iHigh)
{size_t t=iHigh; iHigh=iLow; iLow=t;}
char ch=0;
switch(rand() % 9) {
case 0 : // reset upper bits
for (i=iLow; i < iHigh; i++)
pBuf[i] &= 0x7F;
break;
case 1 : // set upper bits
for (i=iLow; i < iHigh; i++)
pBuf[i] |= 0x80;
break;
case 2 : // toggle all bits
for (i=iLow; i < iHigh; i++)
pBuf[i] ^= 0xFF;
break;
case 3 : // set to random chars
for (i=iLow; i < iHigh; i++)
pBuf[i] = (char)(rand() % 256);
break;
case 4 : // set NULL chars to (possibly) non-NULL
for (i=iLow; i < iHigh; i++)
if (!pBuf[i])
pBuf[i] = (char)(rand() % 256);
break;
case 5 : // swap adjacent bytes
for (i=iLow; i < __max(iHigh-1,iLow); i+= iIter)
{char t=pBuf[i]; pBuf[i] = pBuf[i+1]; pBuf[i+1]=t;}
break;
case 6 : // set to random chars every n-bytes
for (i=iLow; i < __max(iHigh-1,iLow); i+= iIter)
pBuf[i] = (char)(rand()%256);
break;
case 7 : // set bytes to one random char
ch=(char)(rand() % 256);
for (i=iLow; i < iHigh; i++)
pBuf[i] = ch;
break;
default: // truncate stream
*pcbBuf = iHigh;
break;
}
}
}
The sample C# and C++ fuzzing code is available as a ZIP file at the end of this post.
This code is an example of dumb-fuzzing, which is fuzzing with little or no regard for the data structure being manipulated. If you've never performed any kind of fuzz testing in the past, then you will probably find bugs with this simple fuzzing technique. Once you have weeded out the low-hanging bugs, you may need to turn your attention to smarter fuzzers. For example, in theory, this code would find few if any bugs in a PNG parser, because PNG files have a built in check-sum, so if you fuzz a PNG file, you'd have to recalculate the checksum to get decent code coverage.
When I showed this code during my presentation, I urged people to add it to their applications today if they currently don't do fuzz testing, and simply run their applications through their normal testing processes. Within three days of my presentation I received emails from people saying they had found bugs. I have no doubt others did too.
One of the comments I made during the session was,"If you can't spend the time on great fuzzing, fuzz anyway" and adding a "layer of hurt" is a reasonable start.
Please feel free to sound off if you have ideas to help improve the code and let us know what you think, either through email or comments to this post.
Jeremy Dallman here. Before we move on with our regularly-scheduled programming here at the SDL blog, I wanted to pull all of the “Walking with the SDL” blog posts into a single document to put it all together in another format. You can find that document here.
Hopefully the “Walking with the SDL” series provided some valuable guidance that will help you formalize your own Security Development Lifecycle. As always, we welcome your thoughts or questions in the COMMENT section of this blog. If you have specific questions that you would like to discuss with our team, you can use the EMAIL link at the top of the blog and we’ll be sure to reply.
Jeremy Dallman here with the final piece of my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2, Part 3]. So far I have discussed getting management approval, expanding security training, formalizing security requirements and effective ways to reuse your threat model or attack surface review data. In this post, I will wrap up with a look into setting up final security reviews and managing post-release documentation.
Formalize your Final Security Review (FSR) Process
A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.
Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.
What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.
What does an FSR team do?
How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.
Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.
Document security work for reference
After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:
· All final threat models for future reference.
· Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.
· All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.
· The final symbols that reflect the product shipped should be archived.
· The Final Security Report and project signoffs to validate your security audit activity
· Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.
Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.
In closing…
I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.
I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.
Over-engineered surveillance gadgetry has always held a special (if somewhat perverse, given my professional interests) fascination for me. As a child, I understood that the best job in the world belonged to Harry Caul (and as an adult, it was a thrill to finally meet his real-life counterpart, countermeasures expert Marty Kaiser, last week).
So perhaps it was inevitable when recently, facing a low-grade but severely geeky midlife crisis, I recaptured my youth with the Maserati of 70's spy gear: the Nagra SNST (see photo at right). For decades, this miniature reel-to-reel audio recorder, specially optimized for eavesdropping, was the standard surveillance device, used by just about every law enforcement and intelligence agency that could afford the money-is-no-object price tag. Slightly larger than two iPods, the SNST runs virtually silently for over six hours on two AA batteries, and can record about two hours of voice-grade stereo audio on a 2.75 inch reel of 1/8 inch wide tape. Now largely made obsolete by soulless digital models, the Nagras are built more like Swiss watches than tape recorders. And trust me, now that I own one, I feel twenty years younger.
I bought mine on the surplus market and ended up with a unit from the Missouri State Highway Patrol, where it had been used in drug and other investigations until at least 1996. Why do I know so much about its history?
Because my new surveillance recorder came with a tape.
I had assumed the tape would be blank or erased, but before recording over it a few days ago, I decided to give it a listen just to be sure. Much to my surprise, it wasn't blank at all, but contained a message from the past: "February 8, 1996, I'm Trooper Blunt, Missouri State Highway Patrol..."
The tape, it turns out, was an old evidence recording of a confidential informant being sent out to try to purchase some methamphetamine. But the informant's identity isn't so "confidential" after all: his name, and the name of the guy he was to buy the drugs from, was given right there at the beginning of the tape. The tape they'd eventually sell me a dozen years later.
I made an MP3 of the recording; it's about 42 minutes long and, I must admit, as crime drama goes it's a letdown. It consists almost entirely of the sound of the informant driving to and from the buy location, with no actual transaction captured on tape. No intricate criminal negotiations or high-speed car chases here, I'm afraid. So, although the recording is fairly long, all the actual talking is in the first few minutes, where the officer gives last-minute instructions to the informant. But just in case someone involved still harbors a grudge after 12 years, I've muted out the names of the informant and the suspect from the audio stream. You can listen to the audio here [.mp3 format].
Unfortunately, this isn't the first time that confidential police data has leaked out in this and other ways, and it no doubt won't be the last. Law enforcement agencies routinely do a bad job redacting names and other sensitive information from electronic documents; in May, I discovered deleted figures hidden in the PDF of a Justice Department report on wiretapping. And a few years ago, when my lab was acquiring surplus telephone interception devices for our work on wiretapping countermeasures, some of the equipment we purchased (on eBay) contained old intercept recordings and logs or was configured with suspects' telephone numbers.
None of this should be terribly surprising. It's becoming harder and harder to destroy data, even when it's as carefully controlled as confidential legal evidence. Aside from copies and backups made in the normal course of business, there's the problem of obsolete media in obsolete equipment; there may be no telling what information is on that old PC being sent to the dump, where it might end up, or who might eventually read it. More secure storage practices -- particularly transparent encryption -- can help here, but they won't make the problem go away entirely.
Once sensitive or personal data is captured, it stays around forever, and the longer it does, the more likely it is that it will end up somewhere unexpected. This is one reason why everyone should be concerned about large-scale surveillance by law enforcement and other government agencies; it's simply unrealistic to expect that the personal information collected can remain confidential for very long.
And whatever you do, should you find yourself becoming an informant for the Missouri Highway Patrol, you might want to consider using an alias.
MP3 audio here.
Photo: My new Nagra SNST; hi-res version available on Flickr.
Jeremy Dallman here. This is Part Three in my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2]. So far I have discussed getting management approval and expanding security training. In this post I will discuss formalizing requirements and effective ways to reuse your threat model and attack surface review data. I’ll wrap up with a look into final security reviews and managing post-release documentation.
Formalize Requirements for long-term use
Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.
At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies. Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.
Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version. Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.
I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.
Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.
Reference & Reuse Threat Modeling results & Attack Surface Reviews
Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:
· Think about component-level architecture
· List common pitfalls in writing code, or begin defining and building test cases.
· Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.
· Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.
· Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.
Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.
I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.
Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.
In the meantime, we’d like to hear from you:
? How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?
? What challenges have you faced in enforcing requirements across your teams?
? How have you implemented threat models or attack surface reviews?
Jeremy Dallman here with Part Two in my series on “Walking” with the SDL. In Part One, I provided a snapshot of “Crawling” and discussed getting management approval. In Part Two, I will cover a couple more “Walk” components: expanding security training and formalizing requirements.
This blog gives us a place to talk about our experiences from using the SDL here at Microsoft and hopefully provide useful information that will help you implement it more effectively at your company. So, I would encourage you to use the Comments section at the bottom of each post to ask questions, give us feedback, or request other topics for us to cover.
Some quick definitions before we dive in. I’ve been using the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing the Security Development Lifecycle (SDL). “Walking” is the point where your security development practices become a lifecycle – a repeatable, reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll continue to talk about walking – or adding the “L” in SDL.
Let’s jump into another component for adopting the Microsoft SDL to expand your own Security Development Lifecycle.
Expand Security Training
Once you have management approval, it is necessary to gain grassroots acceptance of the changes – at the developer, QA/test, and PM levels. If you have been “crawling”, you have probably already implemented some sort of discipline-specific training around things like threat modeling, using compiler defenses, and fuzz testing. Now that you are building a lifecycle, your goal for security training should expand. Security training should be about creating an environment where writing secure software is everyone’s mission. While security training should be undertaken with the goal of understanding security issues and how to address them, good training (and instructors) will also explain why solving security problems is in their best interests and create an environment where they know voicing security concerns is encouraged.
Training has been one of the earliest and most important elements of the SDL at Microsoft. From our experience, we learned that the most effective approach is to divide your training into two tracks: general security principles and role-specific security practices. Before I jump into the details, I want to encourage you to also read Shawn Hernan’s very good post about SDL training that highlights some of the ways to make security training effective.
The general security principles should explain why security is important, how you define security requirements, the process you will use for writing and validating secure code, and how security relates to each phase of the lifecycle or unique roles contributing to the development process. A key factor for building a development lifecycle is educating your individual contributors on the value of investing in security. Of course changing culture takes time, but using the opportunity of structured training to explain your principles will be one of your most effective platforms for influencing change.
At this point in your organizational maturity, you are also beginning to expand your security thinking by focusing on each role in the development process. Discipline-specific security training is where you dig into the details of implementing a Security Development Lifecycle.
· The developer needs to understand the practical details of how to write code securely, how to set compiler flags, what a security code review means, how to avoid using banned APIs, and what tools are available for them to perform security analysis before checking in their code.
· The QA/tester needs to know how to set security rules in test tools, how to perform penetration testing, and what the security quality criteria is for your product, or how to file a security bug.
· The PM needs to understand how to define measurable goals or how security policies can be factored into feature design.
· The business decision maker of your organization should understand how to track security metrics alongside other product measurements or how security policy plays a critical role in the overall quality and value of your product.
· Finally, it is critical for the employees occupying all job roles to understand the value of threat modeling – both as a tool for understanding threats early in the design phase and throughout the development process as a key barometer to the security pulse of your product.
Discipline-specific training will be the place to address these issues for your organization. In case you were wondering, all job roles should be required to attend both types of security training before working on your product.
Our new SDL website [http://www.microsoft.com/sdl] will be a very good place to watch for future training materials. The SDL Training and Resources page has some useful material up now and more will be coming in the future.
That’s Part Two. In Part Three, I will discuss the important “walk” components of formalizing security requirements and reusing threat models and attack surface reviews. Then we will close with the discussions on conducting final security reviews, and managing post-release documentation.
I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.
? Do you provide security training to your employees today?
? Do these additional training topics make sense in your organization?
? What would you add to this that is unique to your application or company?
Jeremy Dallman here. Back in March I wrote a post about “Crawling” Toward SDL. I used the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing a version of Microsoft’s Security Development Lifecycle (SDL).
In this series I am going to talk about “Walking” with the SDL. Walking is the point where your security development practices become a lifecycle – a repeatable, mostly reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll talk about walking – or adding the “L” in SDL.
I will be covering quite a bit on this topic, so I intend to split it up in to a multi-part series over a few days. I’ll condense it all into one big doc at the end. In Part One, I will review “crawling” and the foundation you need to have in place as well as discuss getting management approval. In Part Two we’ll cover the topic of expanding your security training. In the additional posts, we’ll discuss formalizing requirements, reusing threat modeling and attack surface review data, the importance of final security reviews, and managing post-release documentation. All of these are components to “walking” with the SDL.
Before I jump into detailing what you can do to “walk” with the SDL, let’s look back at a snapshot of what you should already have in place from learning to “crawl.” At a high level, crawling involved three components. Each of these components requires specific activities or tools that your team must implement to begin developing secure code:
1. Detailed awareness of your architecture and its attack surface.
a. Threat Modeling
2. Tools that will perform security analysis on your application.
a. Strengthen compiler defenses
b. Use code analysis or static analysis tools such as PREfast, FxCop, AppVerif
c. Build a strong fuzz testing capability
3. Results that show how the analysis resulted in improved security
a. Response planning and response process in place
b. Use bugs to gather evidence and show that your work improved security
Think of these pieces as the “gross motor skills” you need to start walking. You should already be using these components and have reached a conscious decision to start building a lifecycle around your secure development practices. As you start figuring out how to “walk”, I want to point out that each of the concepts I discuss in this post is a critical component of the Microsoft Security Development Lifecycle. Adopting the SDL in your company involves a combination of integrating the existing SDL principles and the creating of unique requirements and components specific to your environment to build your own Security Development Lifecycle.
With that in place, let’s start talking about what it means to “Walk with SDL.”
Obtain Management Approval/Endorsement
Creating a Security Development Lifecycle will cost time and money. In addition, it will likely require some process changes. In most organizations, this change will not happen unless you obtain the management approval and endorsement necessary to compel the organization to act.
The key to successfully pitching SDL to your management can be found in the data you have been accumulating during the “crawl” phase. As you may recall from my crawling post, the simplest way to create evidence that clearly illustrates improved application security is to “mine” the data from your bug database. Connecting those bugs to known security vulnerabilities or to what would have been bad security issues that were avoided by fixing them in development is a powerful story. Of course your pitch should include other necessary components like anticipated costs, new software acquisition, possible vendor and consulting contracts and anticipated return on investment.
However, the heart of your argument will be the story you tell. The story is quite simply “If we hadn’t done this basic work in security, here is what we would have missed and how much it would have hurt…” followed by “if we continue to expand our security practices and make them a part of our process, we can better predict measurable security improvements that reduce the likelihood of future risks.”
The new SDL website [http://www.microsoft.com/sdl] provides some valuable reference material on the Business Case for SDL. I would recommend that looking through that information for some good supporting material. In Part Two, I will discuss expanding your security training as another component of “walking” with SDL.
I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.
? What unique challenges are you facing as you try to push for SDL adoption?
? What have you used to successfully communicate the importance of security to your management?
Hi all, Dave here…
I’m pleased to announce the availability of new resources for the Microsoft Security Development Lifecycle (SDL).
We have recently launched a dedicated SDL website at www.microsoft.com/sdl. This website will serve as the main online presence for all SDL related communications and resources from Microsoft.
For several years now the SDL has been at the heart of Microsoft’s strategy for making security and privacy an integral part of the software development culture at Microsoft. As a result of the SDL, we have seen significant security improvements across many flagship Microsoft products including Windows, SQL Server and others. These security improvements have been widely recognized by security analysts, researchers and other experts. However, despite the significant improvements and recognition, we believe that our connections to our broad technical audiences (developers and IT Pros) are not equating the SDL to the progress we have made with our technologies and services.
Given that, our goal is to help illustrate SDL processes and tooling in a structured and consistent manner – by providing actionable guidance for the different job roles within a development organization.
We welcome your feedback – on the site, and on other information you’d find useful in evaluating the SDL.
