Jeremy Dallman here to let you know we have released our annual update to the Microsoft Security Development Lifecycle Process Guidance – version 5.2 (SDL 5.2). SDL 5.2 is now available for download (.docx format) as well as updated online in the MSDN library.
The changes in SDL 5.2 demonstrate how the Microsoft SDL evolves internally to address new attack vectors, provides guidance that leads to implementation of new protections, and improves the security of Microsoft products throughout our software development lifecycle. This public update of Microsoft’s SDL Process Guidance documentation is intended to provide transparency into how we implement the SDL at Microsoft.
The SDL 5.2 guidance may be a useful reference resource for organizations whose processes align with Microsoft’s processes or are looking for detailed information on how Microsoft implements SDL practices. However, if you are just beginning your investigation or implementation of the SDL, we encourage you to first read the Simplified Implementation of the SDL paper and some of the additional resources we make available on the Microsoft SDL website to begin building your own SDL framework.
Since this is a smaller “dot” release, we simply tagged each change within the paper so they can easily discovered searching in document for one of the following phrases: “New for SDL 5.2”, “Promoted for SDL 5.2” or “Updated for SDL 5.2”. The updated content in the MSDN library includes all updates automatically.
If you have any questions about the Microsoft SDL 5.2 Process Guidance, feel free to comment on this post or send us an email. We always enjoy hearing how the guidance and tools we provide help your organization adopt SDL practices.
Doug Cavit here, blogging from the Security Development Conference 2012 in Washington, D.C.
I am excited to announce a new set of important SDL Chronicles case studies detailing the efforts of two organizations to enhance their overall security posture using the SDL. The Government of India and Itron, Inc. represent two very different but uniquely important components of the global critical infrastructure upon which we all depend daily. Both face the similar issues of trying to balance how they can privately combat cyber threats to their infrastructure while transparently talking about the processes they use to secure those assets.
The first case study being released today is from the Government of India. The government believes the issue of proactive application security is so vital that it has incorporated the concept into the next draft five year economic plan for the country. The government organizations CERT-in and National Informatics Centre have also adopted the use of secure application principles, as embodied in the Microsoft SDL. The case study gives a fascinating story of how the highest levels of government view the subject of application security as a key economic and national security issue which extends to government operations, public-private partnerships and regulatory requirements. The Government of India has made a public policy decision on application security and they are using process transparency to help communicate that commitment to all the government’s various constituents. There is often a discussion of how to measure the return on security investments and how hard that is to do accurately. When we talk about ROI, efficiency and scalability are key metrics. One key element of the case study is how they use the SDL to deliver repeatable and scalable training to over 10,000 cyber forensic investigators. As evidenced in this case study and the one below, there is now more direct evidence for organizations considering the adoption of secure application development to leverage the impact of the SDL and the return on investment it provides. You can read more about the steps the Government of India is taking to secure its environment in the case study available for download.
The second case study is from Itron, Inc. and discusses their use of the SDL. Itron realized early on that the Smart Grid, with all of its promise, also represents a potential for harm to the electrical network through external threats. Their evaluation of proactive security practices led them to look to the Simplified Microsoft SDL as the best process to incorporate into their own secure development program. Particularly interesting is the fact that they have also extended the SDL principles into looking not just at software applications but also the entire system including the firmware and the hardware. Itron is already benefiting from their adoption of the SDL, as the process has given them a mechanism to communicate with customers who have been asking for proof of security in the products they buy. By showing conformity to a well-established and transparent process they can demonstrate the considerations and features they are building into their products to decrease vulnerabilities and to limit the severity of attacks. Itron has also seen some immediate ROI from this process. Rather than spending large sums on outside vendors for testing, they have brought security tools and process in-house to resolve issues more rapidly with lower overall expense. This has also resulted in measurable productivity gains from a streamlined engineering process. You can read more about the process Itron is using to secure its systems through a case study we have published for download here.
I also wanted to call attention to an important paper that Good Harbor Consulting LLC released during Richard A. Clarke‘s keynote yesterday at the conference – titled Confronting Cyber Risk in Critical Infrastructure: The National and Economic Benefits of Security Development Processes. The key tenet of the paper is that secure application development processes are core to securing critical infrastructure and that solid evidence of economic benefit coming from the use of these methods exists. The paper includes information from many different providers and regulators of critical infrastructure and talks about the importance of SDL practices in achieving those results. It is a comprehensive overview I would recommend for anyone interested in the critical infrastructure sector. You can download a copy of the Good Harbor Consulting paper from here.
These three papers provide documented experience and direct evidence on the use of the SDL spanning a broad spectrum of critical infrastructure. Each of these papers discuss a common process and set of principles represented by the Microsoft SDL as well as tangible returns on investment when adopting these security practices. This common approach is also being seen at the Security Development Conference 2012 where representatives from all of these critical infrastructure providers as well as leaders from over 100 other companies who have come together to share many of the best practices described in these papers and discuss their own experiences. We are both humbled and excited about the adoption the SDL has gained in this important area and the value it has provided to others. Our hope is that more companies will benefit from reading case studies like these and will use that information to help accelerate their own unique adoption of SDL practices.
.
Jeremy Dallman here with a quick reminder about a big event next week.
Next Tuesday, May 15, the doors will open to the inaugural Security Development Conference 2012 (SDC2012) at The Fairmont in downtown Washington D.C. This two-day security industry event is being hosted by Microsoft to bring together organizations from a variety of industries to learn from each other, build professional networks, and expand the growth of a security ecosystem around security development practices.
Speakers and panelists have been selected from over 25 companies to provide a breadth of perspective. Attendees will hear from security professionals from 25 different organizations including Adobe, RedHat, IBM, Itron, Salesforce.com, Microsoft, Cisco, NIST, NSA, Intel, Lockheed Martin, BlackBerry, and more. These practitioners will share their own experiences with the goal of helping other companies accelerate their own adoption of security development lifecycle practices. There will be plenty of technical content for the security engineers, but we will also include content for business decision makers (development directors, IT managers, and CSOs) and security program managers (project managers, policy makers, compliance teams).
If you are local to Washington D.C. or can be there by Tuesday of next week, we would encourage you to take advantage of the low $400 registration fee and join us.
We look forward to seeing you at SDC 2012!
Hello all - Dave here...
Tim Burrell of the TwC Security Science team presents the fifth blog installment describing /sdl: functionality in Visual Studio 11.
-----------------------------------------------------------------------------------------------------------------------------
In the last few posts we described some additional security features that are enabled by the new /sdl compiler switch. Previous comments to posts in this series have highlighted the balance that we have to strike when introducing new security features: some developers/readers welcome new security features in the toolchain and suggest further enhancements; for others conformance and standards compliance takes precedence.
This post describes another feature included under /sdl: in limited circumstances the compiler will instrument C++ operator::delete calls to sanitize the pointer reference. In particular it illustrates a case where we have sought to carefully balance the desire for improved security with that of conformance and avoiding unnecessarily breaking a developer’s valid C++ code.
The Security Development Lifecycle (SDL) as implemented at Microsoft recommends (see pages 42-43 of SDL Process Guidance 5.1):
“NULL out freed memory pointers in new code. This helps reduce the severity of double-free bugs and bugs that overwrite "dangling" pointers. For example:
Add this statement after the delete operator:
A common approach that we’ve seen developers take is to define macros such as
and use these in their code in preference to calling the deallocating function directly.
In light of the SDL recommendation above – and a number of real bugs related to reuse of stale references to deleted C++ objects – it is natural to look at whether we could add compiler support to do this kind of instrumentation automatically:
The obvious choice of sanitization value is NULL. However there are downsides to that: we know that a large number of application crashes are due to NULL pointer dereferences. Choosing NULL as a sanitization value would mean that new crashes introduced by this feature may be less likely to stand out to a developer as needing a proper solution – i.e. proper management of C++ object lifetimes – rather than just a NULL check that suppresses the immediate symptom.
Also checks for NULL are a common code construct meaning that an existing check for NULL combined with using NULL as a sanitization value could fortuitously hide a genuine memory safety issue whose root cause really does needs addressing.
For this reason we have chosen 0x8123 as a sanitization value – from an operating system perspective this is in the same memory page as the zero address (NULL), but an access violation at 0x8123 will better stand out to the developer as needing more detailed attention.
Finally note that if a developer actively sanitizes a pointer by writing:
and we insert an automatic sanitization instruction to some INVALID_ADDRESS:
then the optimizer would typically identify it as dead code and eliminate it, reducing it back to:
Indeed if ‘p’ is not used after deletion then the optimizer may also eliminate the “p = NULL;” instruction too! So carrying out pointer sanitization should not typically lead to performance issues.
It is certainly valid for a developer to choose to define and use macros such as SAFE_DELETE and SAFE_ARRAYDELETE above where appropriate. However getting the compiler to do this automatically is not: what if ‘p’ were to change between the “delete p;” and the “p = INVALID_ADDRESS;” instructions? Here are a couple of examples of code that would be broken by such an “always-on” sanitization.
In this example we have a class used to maintain a linked list of objects. The static class member m_head is used to keep track of the first element in the list.
This is valid code and the expected behaviour is that
would delete the memory associated with the m_head object, and update the (static) m_head class member to point to the next object in the list (m_next) which has now become the first list entry.
However the automatic pointer sanitization would break this because we would effectively have:
But m_head is no longer the object that was just deleted, as the value of Node::m_head was updated during the destructor call to point to the (presumably valid) object m_next!
2. Expressions involving a dereference: “delete p->q”
This example shows an analogous problem that can arise even without static members – the setup here is that of two objects of type CChild and CParent, each with a pointer to the other.
In this example we have two interrelated class types with a CParent object containing a pointer to its child and vice versa. Now consider the instruction:
If we applied automatic pointer sanitization, then this would be equivalent to:
However the destructor call also deletes the child member m_Child. This means that the instruction actually deletes both pChild->m_Parent and pChild itself! The memory associated with pChild is therefore freed as part of this single delete instruction and the sanitization instruction is illegal, accessing the now freed memory at pChild – as such the sanitization instruction itself could even trigger an access violation!
Thinking through the two examples above makes clear that there are many cases where the destructor call could alter or invalidate part of the expression being passed into the operator::delete call, making inserting a sanitization instruction incorrect or illegal.
If the impact of this security feature were limited to areas described in the standards as “undefined” or “implementation-dependent” then always applying pointer sanitization might be a consideration. However incompatibility with valid code constructs as described above precludes that.
Visual Studio 11 provides initial support for pointer sanitization in the following cases:
The /sdl switch is specified by the user.
The expression passed into the delete call does not involve a dereference.
No non-trivial destructor is defined.
The global operator::delete is being used (rather than any class-specific override).
Protection therefore applies to simple examples such as:
This ensures that valid code constructs such as the ones described previously are not broken (as the pointers are not sanitized in these cases)!
Automated pointer sanitization is one example where we need to take particular care in order to avoid breaking conformant C++ code.
We want to see improved software security and the tooling support that goes with that – however to be effective then that tooling must be usable on real code! The pointer sanitization support in Visual Studio 11 seeks to strike that balance. In future one might consider additional analysis to support identifying additional cases where it would be safe to sanitize.
We encourage you to try out the new /sdl compiler switch (along with other Security Development Lifecycle tools such as BinScope Binary Analyzer and Attack Surface Analyzer) and provide feedback on your experience!
Tim Burrell, MSEC Security Science team.
Hello all – Dave here…
Now that RSA is over and things are somewhat back to normal, we can get back to the business of talking about Visual Studio features as they relate to the SDL. Here we present the fourth installment of the series by Thomas Garnier of the Security Science team talking about Visual Studio and proper C++ class initialization…
----------------------------------------------------------------------------------------------
In previous posts we introduced the /sdl compiler switch and described our approach when designing and implementing additional security features in Visual Studio 2011.
This post describes another feature enabled by the /sdl compiler switch: in specific cases it will initialize all member pointers of a class. This feature addresses a common mistake made by developers when creating C++ classes.
Creating C++ classes requires the developer to handle the class initialization correctly. A classic mistake is forgetting or failing to initialize a member pointer that will be used or freed in the destructor.
The following example highlights how a class initialization might fail leaving a member pointer uninitialized. This problem was seen in multiple MSRC cases such as MS10-071, MS10-053 and MS09-051.
This code assumes that the allocation will succeed and initialize the p variable. An attacker might influence the size or state of the process forcing a particular failure path to be taken. In this example it would free an uninitialized pointer which can lead to code execution.
We have seen different approaches to make this initialization process easier. For example, a developer might use a custom operator “new" to allocate and initialize memory. However the custom operator is not called if the variable is declared locally, as a member of another class (not being a pointer) or if the class is inherited.
Ensuring a class is always properly initialized can be a challenge, especially for large and complex code bases.
In reviewing MSRC cases involving uninitialized class members, we noted that uninitialized pointers are the most common issue that could lead to code execution.
The following examples highlight how the compiler generates class creation code into assembly and how the /sdl compiler switch can change the generated code to initialize class pointers avoiding the common mistake described earlier.
Creating an object for the previous example via the following code:
Generates this assembly by default (without /sdl) on x86:
With the /sdl compiler switch enabled, when creating a class the Visual Studio 11 Developer Preview compiler will generate a new function called A::__autoclassinit(). This function is responsible for the initialization of class member pointers. It will also call the compiler-generated class initialization functions of any base classes or member variable of a class type. For our example the A::__autoclassinit() function is called before the call to the constructor:
In this example the A::__autoclassinit() function would initialize the variable p, call B::__autoclassinit() for the variable o and not touch n:
The compiler-generated class initialization function is called as long as:
- The object is not allocated using a custom (user defined) operator new
- The object is not allocated as part of an array (for example “new A[x]”)
- The class is not managed or imported
To be initialized by the compiler-generated class initialization function, a member has to respect the following rules:
- The member is a pointer
- The member is not a property or constant
Automated initialization of class member pointers demonstrates the capabilities offered by the compiler to mitigate complex security problems.
We hope you will find this functionality of the /sdl compiler switch useful and encourage you to try it. You can find more information about the Security Development Lifecycle (SDL), including articles, tools and more on this website.
Thomas Garnier, MSEC Security Science.
Jeremy Dallman here to introduce four new companies that have joined our SDL Pro Network.
Today, Accuvant Labs, Conviso Application Security, Lockheed Martin, and Verizon Business EMEA joined this network of security consultants, training companies, and tool providers that specialize in application security and have substantial experience with the methodology and tools of the SDL. Each of these companies have established service offerings that are designed to span the entire lifecycle and make security and privacy an integral part of how software is developed.
Lockheed Martin is a global security and information technology company. The majority of Lockheed Martin's business is with the U.S. Department of Defense and the U.S. federal government agencies. In fact, Lockheed Martin is the largest provider of IT services, systems integration, and training to the U.S. Government. “We are pleased to join the Security Development Lifecycle (SDL) Pro Network. Lockheed Martin and the SDL Pro Network share similar principles and practices for application security. Our membership with this network of security consultants, training companies, and tool providers that also specialize in application security expands our reach in advancing software assurance awareness, skills, and solutions” says Steve Adegbite, Lockheed Martin’s Director of Cyber Security, and Commercial Strategies.
The SDL Pro Network continues its global expansion by welcoming Verizon Business EMEA providing SDL services throughout Europe. Thierry Zoller, Practice Lead EMEA for Threat and Vulnerability Management says “Verizon EMEA is proud to have joined the Microsoft SDL Pro Network. The Microsoft SDL is a leading SDLC concept backed up by years of real-life, large enterprise experience in the fields of business alignment, cost effectiveness and technical expertise. Verizon is delivering Microsoft SDL and overall SDL consulting across the EMEA region. We offer leading threat and vulnerability consulting expertise, including on-site SDL evangelists, SDL consultancy, SDL pilot programs, secure coding guidelines and developer trainings, that help enterprises develop secure and robust applications.”
Conviso Application Security expands the SDL Pro Network into South America. Conviso is a security consulting company based in Curitiba, Brazil specializing in network and application security services and in application security research. Their values are based on the allocation of the adequate competencies on the field, collaboration and partnership with customers and business partners and constant investments on methodology and research improvement. “It is an honor for Conviso to join this distinct group of companies that comprise the Microsoft SDL Pro Network. We hope to bring to the Latin American market the best practices in SDL by combining our efforts together with experienced and qualified professionals”, says Wagner Elias, CTO at Conviso Application Security.
We also welcome Accuvant Labs to the SDL Pro Network. Accuvant, with offices in Denver, Atlanta, and Chicago is a consulting member providing comprehensive analysis of mission-critical software, ensuring security threats are identified, an effective application security risk management program is put into place and ultimately, all risks are mitigated. “Microsoft has done more to advance secure development than any other company, we are honored to be included in the SDL Pro Network. Accuvant LABS looks forward to enhancing our SDL offerings with the research and tools provided by Microsoft, ensuring that we can continue to deliver the highest quality of service to our customers” says John Bock, Director Application Security at Accuvant LABS.
We encourage you to review each company’s services and consider contacting them or other SDL Pro Network companies to help you with your own organization’s Security Development Lifecycle program.
Jeremy Dallman here with some exciting news to kick off the week!
We are pleased to announce that registration is now LIVE for the inaugural Security Development Conference 2012 (SDC 2012) taking place in Washington D.C. on May 15-16, 2012. REGISTER today and take advantage of early bird pricing!
This event, hosted by Microsoft will bring together professionals from a variety of organizations to learn from security experts, build networks and learn how to evolve their own Security Development Lifecycle (SDL) principles into practices. SDC 2012 will include information for leaders in security engineering, business decision makers, and management who are responsible for accelerating the adoption and effectiveness of SDL practices within their own organizations.
KEYNOTE SPEAKERS
3 TRACKS & 24 SESSIONS
The session tracks for this industry event will target three important roles for any security organization: security engineers, business decision makers, and lifecycle process managers. The sessions in these tracks will include experts representing over 30 organizations from a variety of industries. Visit the event website to see our current list of speakers and regularly check back as new speakers are added. We hope you will visit the website, spread the word and register early to join us at the Security Development Conference on May 15th & 16th!
WHY YOU SHOULD ATTEND
PRICING
Early Bird (February 20 - March 15) $300Discount (March 16 - April 13) $400Standard (April 14 - May 11) $500Onsite Rate (May 12-May 16) $700
SPONSORSHIP OPPORTUNITIES
If your organization or company is interested in being a sponsor for the SDC 2012, we have a few open sponsorship opportunities left at both the Gold and Silver levels. Please contact SDC2012@microsoft.com for more information.
More and more enterprises are realizing the importance of proactive security practices and those involved in critical infrastructure are no exception. One of the most effective ways to drive security improvements in critical infrastructure is through industry consensus. Microsoft has been deeply involved in collaborating with several critical infrastructure sectors to better understand their needs and to help improve their secure software development practices. A critical sector is financial services where Microsoft has had long term collaboration with BITS, a part of the Financial Services Roundtable, made up of major US financial institutions that are responsible for almost 93 trillion in managed assets.
Today, BITS announced the release of their Software Assurance Framework. The purpose of this framework is to document the importance of secure development and to provide guidelines that financial services organizations can use to implement these practices more fully. The framework is rooted in education, integration of security in design using standards and threat modeling, best practices for coding, focused and comprehensive testing and followed with important implementation and response practices. This type of holistic, prescriptive, risk-based approach has been a hallmark of Microsoft’s SDL since inception back in 2004. The BITS Framework goes on to further cite the Forrester Consulting study which details the compelling economic (ROI) reasons to invest in a SDL program.
The framework was also designed to provide guidelines to software suppliers of the financial services industry in writing better, more secure software. BITS recognized the importance of making this an industry-wide effort which is why we are extremely pleased to see it was made available to the public. Microsoft has been a strong advocate for improving secure development practices with free information and tools for many years now. The BITS framework is another great example on the importance of prescriptive security versus descriptive security practices such as checklists.
Of note, this Framework was a collaborative effort that involved several financial services companies in conjunction with Microsoft. The BITS group contains some of the most experienced security people in the financial services industry working together to define clear guidance on the most critical software development best practices for financial services.
We encourage you to take a look at this important document and see how practices from Microsoft’s SDL have helped to make a difference in improving software security within the financial services industry
- Doug Cavit
Steve Lipner here…
Over the past few weeks, Microsoft has been reflecting on the ten year anniversary of the Trustworthy Computing initiative; thinking about the things that have led us to this point in our history and speculating about the future.
Obviously a big part of our work has been the creation and evolution of the Microsoft Security Development Lifecycle (SDL). In our case, security has evolved in large part because of the issues that we faced early on. As referenced in my previous post, the uphill battle we fought in the early years put a negative spotlight on our products and our ability to keep customers safe.
By learning from our weaknesses and from close observation of the evolving threat landscape, we were able to make progress against the challenges by employing an effective approach to developing more secure software. The most prominent and arguably the most important attribute of our evolution lies in our commitment to the SDL – a comprehensive approach for writing more secure code. Under the Microsoft Trustworthy Computing umbrella, the SDL is considered the most battle-tested and effective software security assurance process in the industry.
Clearly Microsoft products are not the only ones being targeted by cybercriminals. Today there is an industry dedicated to finding security vulnerabilities; motivated security researchers are in a race to discover the next big vulnerability in hopes of selling them on the open market. So how does Microsoft work with the industry to help build a safer, more trusted computing ecosystem? One way is by freely sharing our prescriptive guidance around the SDL methodology and tools so that other organizations can build more secure software.
We’ve noticed that IT dependent organizations are no longer satisfied with the latest “Top n list” of security practices; instead they are demanding prescriptive practices like the SDL that make deliberate value judgments on security practices based on real world effectiveness. We’re proud of our efforts here – no other software vendor shares their tools and resources to the extent that we have. We feel strongly that by sharing our best practices and tools, we can help organizations implement a version of the SDL that makes sense for them – regardless of what platform they use.
This insistence on effective security development processes can be found in the recent release of the BITS Software Assurance Framework. For those readers unfamiliar with BITS, it is the technology arm of the Financial Services Roundtable – an organization that includes members from major US financial services organizations. BITS is chartered with finding collaborative solutions to challenges in cybersecurity, fraud reduction and critical infrastructure protection for its member companies. Today, BITS will publicly announce that they have successfully incorporated many of the key elements contained within Microsoft’s SDL into the guidance they provide to their member institutions and their software vendors. Their recommendation of many of our security development practices is gratifying and a strong testament to how far we have come with software development security.
We’re also pleased to see a growing community of individuals and enterprises that are implementing secure development best practices; we feel there should be a venue where those ideas and methodologies can be shared. In an effort to make that venue a reality and sustain the momentum behind secure development processes, we are pleased to announce the first annual Security Development Conference in Washington D.C., May 15th – 16th, 2012.
This event will bring together experts from a variety of industries to Washington, D.C. for a two day conference that centers on the theme “Evolving from Principles to Practices” and will serve as a focal point for education and collaboration for security development professionals. By holding this conference we intend to emphasize the importance of more secure code as the critical first step to protecting against criminal activity. The conference will provide in-depth sessions, panel discussions, and professional networking opportunities that will help organizations develop and accelerate their own security development lifecycle processes.
For more information and registration details, I’d strongly encourage a visit to the conference website at www.securitydevelopmentconference.com
As mentioned in previous posts, there are some interesting changes afoot regarding security in Visual Studio 11. Here is the next installment of the series by Tim Burrell outlining more of the work done by Security Science and the talented folks on the Visual Studio team…
-----------------------------------------------------------------------------------------------------------------------
Microsoft is actively developing Visual Studio 11 and continually looking for ways to improve security-related functionality in the software. We previously noted that we are updating the on-by-default /GS compiler switch, which provides protection against some memory safety bugs such as buffer overflows. This post will provide additional information on those changes.
You may recall that /GS buffer overrun protection places a cookie on the stack between local variables and critical security-critical metadata such as the return address.
The integrity of the GS cookie is checked at the end of the function, prior to the return address being used to return to the caller; if the cookie has been corrupted then execution is terminated rather than carrying on and transferring control to a now suspect return address in memory.
Note that this kind of protection is designed to catch the traditional overflow scenario – i.e. modification of consecutive bytes – and this is indeed by far the most common type of stack corruption bug. However it does not protect a scenario such as:
If the attacker can control the value of ‘n’ above then he can corrupt a single TCHAR character, leaving any GS cookie untouched:
In reviewing those Microsoft Security Response Center (MSRC) cases due to stack-based corruption that were not covered by the existing /GS mechanism, we noted one error that stood out as being more common than others: misplaced null terminators. A typical code sequence might be something like:
The ManipulateString() function correctly writes data within the bounds of the string ‘buf’– but fails to keep track of the final length ‘cch’ of the resulting string. The instruction that null-terminates the string could therefore write outside the bounds of the string buffer without corrupting the GS cookie.
Compile the code above using the Visual Studio 11 Developer Preview tools and you will see that the generated code includes an extra check:
The compiler has inserted range validation code for the null-terminating instruction to guard against an out-of-bounds write to memory, roughly equivalent to:
A couple of questions arising from this are:
1. “What is the __report_rangecheckfailure() function?”
2. “When/how often does this range validation happen?”
The __report_rangecheckfailure() is similar to the existing __report_gsfailure() function; it just terminates the program to prevent further execution in a state that we know is about to become untrustworthy. We will come back to this in more detail in a later post.
With respect to how often such range validation happens, it is targeted precisely at the code pattern for which there is historical data indicating the highest risk of a bug being present, namely an assignment to a single array element where:
- The array element size is 1 or 2 bytes, i.e. typically a string.
- The value being written is zero, i.e. to catch the null terminator case.
- The array is declared to be of fixed known size (note that this could be a local or global array so not restricted to the stack).
In addition, for the compiler to be able to insert the instruction guarding against a range violation, it needs to know the size of the array. So an additional requirement in Visual Studio 11 Developer Preview is that the array assignment instruction involves an array of locally and statically declared size. By means of illustration, the following would not lead to a range check being inserted:
As always this is a trade-off. By targeting these extra checks as described above, Visual Studio 11 by default provides extra protection for a limited set of bugs that history tells us are the most common kind of stack-corruption bugs not covered previously by /GS, while minimizing performance and codesize impact by keeping the number of such checks low overall.
And of course /GS continues to provide the familiar cookie-based protection against traditional stack overflows.
The /GS compiler switch is one of many security enhancements being looked at for Visual Studio 11 and is but one small part of the Security Development Lifecycle (SDL) process and methodology for developing secure software, which includes much more than just using specific compiler switches – read more and find additional resources related to SDL here.
Tim Burrell, MSEC Security Science.
Pop security quiz: What’s the most secure way to store a secret?
a) Encrypt it with a strong symmetric cryptographic algorithm such as AES, using a 256-bit key.
b) Encrypt it with a strong asymmetric cryptographic algorithm such as RSA, using a 4096-bit key.
c) Encrypt it using a cryptographic system built into your platform, like the Data Protection API (DPAPI) for Windows.
Have you made your choice? The correct answer is actually:
d) Don’t store the secret at all!
Ok, it was a trick question. But the answer is valid: thieves can’t steal what you don’t store. Let’s apply this principle to the action of authentication – that is, logging into a web site. If a site never stores its users’ passwords, then even if the site is breached, those passwords can’t be stolen. But how can a site authenticate users without storing their passwords? The answer is for the site to store (and subsequently compare) cryptographic hashes of the passwords instead of the plaintext passwords themselves. (If you’re unfamiliar with the concept of hashes, we recommend reading http://msdn.microsoft.com/en-us/library/92f9ye3s.aspx#hash_values before continuing.) By comparing hashes rather than plaintext, the site can still validate that the user does indeed know his or her password – otherwise, the hashes wouldn’t match – but it has no need to ever actually store that password. It’s an elegant solution, but there are a few design considerations you’ll need to implement to ensure you don’t inadvertently weaken the strength of the system.
The first design issue is that simply hashing the passwords alone isn’t enough protection: you also need to add a random salt to each password before you compute its hash value. Remember that for a given hash function, an input value will always hash to the same output value. With enough time, an attacker could compute a table of plaintext strings and their corresponding hash values. In fact, many of these tables (known as “rainbow tables”) already exist and are freely downloadable on the Internet. Armed with a rainbow table, if an attacker could manage to gain access to the list of password hashes on the web site by any means, he could use that table to easily determine the original plaintext passwords. When you salt hashes, you take this weapon out of the attackers’ hands. It’s also important to generate (and store) a unique salt for every user – don’t just use the same salt for everyone. If you did always use the same salt, an attacker could build a new rainbow table using that single salt value, and eventually extract out the passwords.
Figure 1: Comparing salted hashes
The next important design issue to take is to be sure to use a strong cryptographic hash algorithm. MD5 may be a popular choice, but cryptographers have demonstrated weaknesses in it and it’s been considered an unsafe, “broken” algorithm for years. SHA-1 is stronger, but is beginning to show cracks and now cryptographers recommend avoiding SHA-1 as well. The SHA-2 family of hash algorithms is currently considered the strongest, and is the only family of hash algorithms approved for use in Microsoft products per the Microsoft Security Development Lifecycle (SDL) cryptographic standards policy.
Instead of hardcoding your application to use SHA-2, an even better approach would be to implement a “cryptographic agility” that would allow you to change the hash algorithm even after the application has been deployed into production. After all, cryptographic algorithms go stale over time; cryptographers find weaknesses and computing power increases to the point where brute force approaches become feasible. Someday SHA-2 may be considered just as weak as MD5, so planning for this eventuality early may save you a lot of trouble down the road. An in-depth look at hashing agility is beyond the scope of this post, but you can read more about a proposed solution in the MSDN Magazine article Cryptographic Agility. And just as the SDL mandates the use of strong cryptographic algorithms in Microsoft products, it also encourages product teams to use crypto agility where feasible so that teams can more nimbly migrate to new algorithms in the event that a current strong algorithm is broken.
So far, we’ve talked about what to hash (the password and a random unique salt value) and how to hash (using a cryptographically strong hash algorithm in the SHA-2 family, and preferably configurable to allow for future change), but we haven’t talked about where to hash. You might think that performing the hashing on the client tier would be a significant improvement in security, since you’d only need to send the hash over the wire to the server and never the plaintext password itself. However, this doesn’t buy you as much benefit as you’d think. If an attacker has a means of sniffing network traffic, he could still intercept the call and pass the hash to the server himself, thus spoofing the user and taking over his session. At this point, the hash essentially becomes the plaintext password. The only real benefit to this approach is that if the victim is using the same password on multiple web sites, the attacker won’t be able to compromise the victim’s account on those other sites as well, since knowing the hash of a password tells you nothing about the password itself. A better way of defending against this attack is just to perform the hashing on the server side, but to ensure that the password and all credential tokens such as session cookies are always transmitted over SSL/TLS. We’ll explore the topic of secure credential transmission (and other aspects of password management such as password complexity and expiration) in future blog posts.
By following a few simple guidelines, you can help to ensure that your application’s users’ credentials remain secure, even if your database is compromised:
I remember the security situation at Microsoft in 2001 and 2002 like it was yesterday. Perhaps no other couple of years will be so indelibly etched into my brain as those two. 2001 was not so good, but 2002 was a heck of a lot better! Given 2001, this was not a difficult achievement for 2002! So, let me start at the beginning…
In late 1999, a small band of us formed a small security team (as in “threats,” not as in “features”) to help raise software security awareness across the company. We had no name for a long time, until the vice president in Windows at the time, Dave Thompson, decided to call us the Secure Windows Initiative (SWI). Our charter was to start reviewing Windows code in depth looking for security bugs, but having a small number of people reviewing something the size of Windows was clearly not going to work. So, we moved to a “Security Bug Bashes” model where we would deliver security education in the morning to a small development group within Windows (e.g., networking, terminal services, IIS, IE, etc.), and then for the rest of the day we would have the engineering team go look for security bugs. It was fun and we found bugs. But the most important point was raising awareness. It really didn’t matter how many bugs were found—the key was to make people aware of the security issues and reduce the chance that mistakes would be made in the future.
The downside of the bug bashes was that even though they were more effective than the original SWI charter, they still didn’t scale very well and they were very labor-intensive. Still, the security bug bashes continued for about another eighteen months.
2001 was not a good year for Microsoft security because of CodeRed and Nimda, two worms that affected Internet Information Server 4.0 and 5.0. CodeRed was the result of a one-line error in some code running by default in IIS4 and 5. In hindsight, the code should not have been installed by default. Nimda was the more sophisticated of the two worms because it used more than one vulnerability to compromise systems.
While all this was happening, David LeBlanc and I were mid-way through creating the first edition of Writing Secure Code. We had written the book because the same security-related questions were being asked time and time again and we wanted a reference we could point people to. Little did we realize that Writing Secure Code would later become a runaway bestseller.
As 2001 wound down and Writing Secure Code was finally sent to the printers, I got an email from Loren Kohnfelder, who was one of the security leads in the .NET Framework. Loren is best-known for defining what is now commonly referred to as Public Key Infrastructure (PKI). You can read his 1978 thesis on the topic here. Loren was also one of the protagonists behind the STRIDE threat modeling mnemonic.
Loren told me that the .NET Common Language Runtime (CLR) team had uncovered a small number of security bugs during the final development phase of the project, and he was really concerned. We decided to do a bigger version of a bug bash; but rather than lasting only one day, it would be done when it was done. “Done” meant the rate of incoming security bugs approached zero. This became known as the “.NET Security Standdown,” and we even had T-Shirts made with the date of the start of the event. On the day the event was to start, the Pacific Northwest got a huge snow storm and the Microsoft Redmond campus was closed, so we started the standdown a few days later.
The standdown was a great success, thanks to Brian Harry and his team, who managed the process brilliantly. We reeducated the .NET engineering team, we found and fixed bugs, but most important, in my mind, we introduced the concept of reducing attack surface (i.e., limiting the amount of code exposed to untrusted users). That’s where the concept of AllowParticallyTrustedCallersAttribute (APTCA) came from and why we flipped ASP.NET to run in much lower privilege.
December 2001 saw the release of Writing Secure Code, and Doug Bayer and I had a lengthy meeting with Bill Gates to explain security vulnerabilities in detail. Clearly he was concerned by the worms of 2001 and wanted to learn more. At the end of the meeting I gave Bill a copy of Writing Secure Code.
At the end of December 2001, the .NET Standdown was over and we had learned a great deal about rallying the troops to a common security cause. But there was much more work to do!
In light of the success of the .NET work, we decided to aim our sights at Windows .NET Server (as it was called back then). Following the .NET model, we started in February and would be done when we were done. For the most part, that ended up being late March for most teams within Windows.
This became known as the “Windows Security Push.”
As everyone knows by now, Bill sent his famous Trustworthy Computing (TwC) memo to the company in January 2002, right as we were planning the security work for Windows. His memos are rare, and this one signaled the start of something big within the company.
During the push, we had three streams of education: I handled all the Windows developers, Jason Garms worked with all the program managers and architects, and Chris Walker trained all the testers. Steve Lipner and Glenn Pittaway led much of the day-to-day process management, keeping in constant communication with upper management.
One practice we borrowed from the security bug bashes was that we always had a senior person from management kick off the training. At one of my sessions, I had Rob Short, VP of Windows Base (Kernel down to the metal) open the day. Rob’s a tall, lean Irishman with a thick Irish accent, and there’s something he said that has stuck with me forever. He said, “There is nothing special about security; it’s just part of getting the job done.” Whenever I deliver a security talk to new engineers within Microsoft or am onsite with a customer, I always recite Rob’s words, because they are so incredibly true.
The Windows Security Push begat the SQL Server Security Push, the Exchange Security Push, and the Office Security Push. Slowly but surely things started to change across the company. Engineers and managers “got it.”
A key element of all the pushes was to reduce the default attack surface of the products. That’s why Windows Server 2003 (note the name change) had a reduced functionality browser, no Web server installed by default, and much more.
One thing that is not commonly known about the pushes is that a lot of documentation was written about the security implications of various technologies. Much of that learning ended up in the second edition of Writing Secure Code; the book ballooned from 500 pages to over 800 pages, and much of that was detail we learned and fine-tuned throughout 2002. A great example is the chapter concerning the security implications of internationalization and globalization. The text in the book is derived from a whitepaper written by the globalization team within Windows after they had gone through the push process and had looked at their important corner of Windows with a fresh security perspective.
The pushes were just the start, however. Real change came only when we implemented the Security Development Lifecycle (SDL). As I have said many times, you can’t build some software and then have a security push. It just doesn’t scale and, frankly, having a push at the end is too late. We needed something that was “part of the process,” and that is how the SDL was born.
There was a wrinkle along the way, however. In 2003 we saw Slammer affect SQL Server and Blaster affect Windows. Because one of the effects of Blaster was blue-screened computers, product support saw a huge increase in support calls. Many of us manned the phones to help out. Raymond Chen, a lead developer on the Windows shell team, and I were seated next to each other, and he wrote about it in his blog.
Blaster led to a lengthy and intense effort known as “Springboard,” led by Rebecca Norlander, Matt Thomlinson, and John Lambert. The end result of the process was Windows XP SP2, in which we not only found and fixed security bugs but also added numerous critical defenses to Internet Explorer, DCOM, and RPC. We also enhanced and enabled the Windows Firewall and added data execution prevention (DEP), and we made it easier for users to enable automatic updates by prompting them right after setup.
Microsoft has come a long way in the last ten years, and I am incredibly proud to have been a part of this watershed time. Much has changed. The SDL is now seen as industry-leading and is in use by many software developers outside of Microsoft. My role has changed too: I now work with our customers and partners as part of the Microsoft Americas Services Cybersecurity team to help them adopt SDL practices as they recognize the need for an increased focus on security.
It’s been an amazing ten years. We still have much to do, however. And no one knows that more than the incredibly talented people across Microsoft helping bake security into our products and our partners’ and customers’ products every day.
Michael Howard
Principal Cybersecurity Architect
January marks the ten year milestone of Bill Gates' memo on Trustworthy Computing. When I think about “where was I when…” the email hit my inbox, several memories come to mind that I thought I’d share. Back then I was the Director of Security Assurance, a position that encompassed both the Microsoft Security Response Center (MSRC) and the Secure Windows Initiative that focused on improving the security of Microsoft’s products before they shipped. We had had our share of problems in those days as attackers had released worms – Code Red, Nimda – against our products and customers.
On January 12th 2002, Michael Howard, Jason Garms, Glenn Pittaway and I were working long days and nights preparing for the February start of the Windows Server 2003 security push. We were prioritizing component development groups, identifying tools that we’d tell groups to run, and working to finalize the four-hour security training class that we planned to present to a total of about 8500 people during the week of January 28, 2002.
One of our big concerns was how the employees would react. We knew that our managers up to senior and group vice president had approved our idea of conducting the security push, and we knew that the team commitments were on the calendar. But if the individual employees and lower-level managers weren’t on board with the idea, the process could crater badly.
Bill’s Trustworthy Computing mail appeared in the midst of this hard preparatory work. I won’t say we would have failed to get the employee engagement we needed if Bill hadn’t sent his mail – after all, we’d lived through Code Red, NIMDA, and some very embarrassing vulnerability reports against Windows XP, and developers and managers were aware of the negative customer perception. But I do know that Bill’s mail made a difference. We told developers, program managers, and testers to sit through four hours of training in a cramped (950-person) meeting room and pay attention, and they paid attention. We told them to review code and find security bugs rather than working on features, and they found and fixed security bugs. We gave them, what I know with ten years hindsight were, immature and flaky tools and processes, and they swallowed hard and used them effectively to find more security bugs. And to this day, I believe a lot of their willingness to do those things was not only because their managers said to do them, but because Bill and Craig Mundie (then Microsoft’s Chief Technology Officer and today Microsoft’s Chief Research and Strategy Officer) had said they were important to do – important for our customers and important for Microsoft.
We’ve done a lot to make our software and services more secure in the last ten years. The Security Development Lifecycle (SDL) evolved from the security push and today we’re recognized for our leadership because we share SDL process and tools with the broader software development community. But the security pushes of 2002 were the beginning. And Bill’s commitment and the way it mobilized the company were the key to that beginning.
Steve Lipner
Senior Director of Security Engineering Strategy
Trustworthy Computing
In chatting with our colleagues in the MSEC Security Science Team, there were a number of interesting topics that weren’t covered in our previous Code Analysis blog post – information that would help contribute to the understanding of security features and functionality in Visual Studio 11. So after some discussion, we have decided to release a series of posts covering this important work – everyone benefits from a better understanding of future technology offerings.
So with that, I again turn the blog over to Tim Burrell to elaborate!
_______________________________________
(Note – this blog post describes a feature in an unreleased product; this feature may be changed prior to final product release.)
Microsoft is actively developing Visual Studio 11 and continually looking for ways to improve security-related functionality. As part of this we are updating the /GS compiler switch, which is on-by-default and enables a basic level of code generation security features, with some enhancements beyond the now familiar cookie-based stack overflow protection. We’ll provide some more detail on these in a later post.
The Security Development Lifecycle (SDL) includes a number of recommendations beyond the scope of /GS where the compiler is able to assist secure software development. These range from specific code generation features such as using strict_gs_check to security-related compiler warnings and more general recommendations to initialize or sanitize pointers appropriately.
For the first time we intend to provide a central mechanism for enabling such additional security support via a new /sdl switch. The impact of /sdl is twofold:
- /sdl causes SDL mandatory compiler warnings to be treated as errors during compilation.
- /sdl enables additional code generation features such as increasing the scope of stack buffer overrun protection and initialization or sanitization of pointers in a limited set of well-defined scenarios.
This dual approach reflects our conviction that secure software is best achieved by the combination of detecting and fixing code bugs during the development process together with the deployment of security mitigations that will significantly increase the difficulty of exploiting any residual bugs.
The /sdl compiler switch is disabled by default, and can be enabled easily in the Visual Studio UI by opening the Property Pages for the current project, and accessing the Configuration Properties -> C/C++ -> General options.
The features enabled by the /sdl switch are a superset of those enabled by /GS i.e. enabling /sdl enables everything included in /GS. We will be providing more background and in-depth details of the additional /GS and /sdl features in future posts. For now we note that they include:
The following SDL mandatory compiler warnings are enabled and treated as errors:
Warning
Command line switch
Description
C4146
/we4146
A unary minus operator was applied to an unsigned type, resulting in an unsigned result
C4308
/we4308
A negative integral constant converted to unsigned type, resulting in a possibly meaningless result
C4532
/we4532
Use of “continue”, “break” or “goto” keywords in a __finally/finally block has undefined behavior during abnormal termination
C4533
/we4533
Code initializing a variable will not be executed
C4700
/we4700
Use of an uninitialized local variable
C4789
/we4789
Buffer overrun when specific C run-time (CRT) functions are used
C4995
/we4995
Use of a function marked with pragma deprecated
C4996
/we4996
Use of a function marked as deprecated
If a developer wishes to opt in to most of the /sdl functionality but exclude a given warning ID (suppose C4146 for example) then this can be achieved by using the /wd switch to disable that specific warning under C/C++ -> Command Line -> Additional Options in the Visual Studio UI:
Additional /sdl code generation features will be covered in more detail in later posts.
Microsoft strongly recommends using the /GS switch as in previous Visual Studio releases; the new /sdl switch in Visual Studio 11 presents an opportunity for greater security coverage both during and after development: stay tuned for more details on specific security benefits of using /GS and /sdl in Visual Studio 11.
Of course the Security Development Lifecycle (SDL) is an entire process and methodology for developing secure software and as such includes much more than just using specific compiler switches – read more and find additional resources related to SDL here.
Tim Burrell, MSEC security science.
We’ve talked before on this blog about SAFECode – an organization of IT vendors who have come together to share and document best practices in software security. SAFECode has published a number of papers on best practices in software and supply chain security – most recently an update to “Fundamental Practices for Secure Software Development” released earlier this year. The SAFECode web site is a great resource for vendor-independent guidance on software security.
Today, SAFECode announced that Siemens has become the eighth SAFECode member joining Adobe, EMC, Juniper, Microsoft, Nokia, SAP, and Symantec. Siemens, headquartered in Berlin and Munich Germany, is a supplier of products for use in industry, healthcare, energy and infrastructure. Software security is an important matter for Siemens, and they will bring SAFECode great expertise in control systems often used in critical infrastructure.
As the Microsoft representative to the SAFECode board and the board’s chair, I’m delighted to welcome Siemens to SAFECode. I’m looking forward to SAFECode releasing new products that take advantage of the expertise Siemens brings.
George Pulikkathara here.
Every now and then we get asked by conference attendees or someone at a company who is evaluating the SDL for adoption at their company, “How well known is the SDL within the IT industry?” or “Where can I find video summaries of your SDL tools or whitepapers?”, or my favorite, “Who else is using the Microsoft SDL?”
Well, today, Microsoft launched a new SDL “Industry Talk” wall on the Security Development Lifecycle (SDL) website. This wall was designed to publically share some of the great evidence Microsoft has generated and continues to generate surrounding awareness and adoption of the SDL.
So if you are considering adopting the Microsoft SDL or know of someone who is looking for a single resource for what the Industry is saying about the SDL, look no further.
By the way, the “Industry Talk” wall was built using HTML5 technology which gives users an exciting new way of experiencing and consuming SDL information. This means you’ll need an HTML5 compliant browser such as Internet Explorer 9 or any of the latest browsers to view the content. Enjoy.
Hello All -
As many of you already know, the SDL team at Microsoft has a strong relationship with our colleagues in the MSEC Security Science team - these guys are on the front line of tool development for the SDL, and are always looking for new ways to take the security technologies they produce and make them broadly available. With that in mind, I am quite pleased to turn over the blog to Tim Burrell to let you know about some new developments on the code analysis front.
- Dave
___________________________
At the recent BUILD Conference, the Visual Studio Code Analysis team presented some great new features of Microsoft Visual Studio 11 C++ Code Analysis. We thought we’d highlight a couple of the security aspects.
This is the first time that Code Analysis has been made available in an Express edition of Visual Studio – a reflection of Microsoft’s commitment to helping secure the software ecosystem beyond just our own software. It is also testament to the value that we believe such static analysis tools have to offer to every developer today. This value comes in many forms, mainly deriving from the fact that it’s way cheaper to fix a bug early on during development:
The Security Science team with the Microsoft Security Engineering Centre (MSEC) worked closely with the Visual Studio Code Analysis team to ensure that the Visual Studio Developer Preview includes as many of the SDL mandatory C/C++ Code Analysis warnings as possible. These are the security-related warnings that Microsoft considers critical to fix for internal C/C++ software development.
Choosing which warnings to include in Microsoft Visual Studio 11 Express is a balancing act between giving all developers access to these warnings and not overloading people with so many warnings that they just ignore them. We’ve tried to select the best combination of high severity / low noise. We are keen to hear your feedback on your experience of using Code Analysis in Express.
Of course the Security Development Lifecycle (SDL) is an entire process and methodology for developing secure software and as such includes much more than just fixing a given set of warnings – you can read more and find additional resources related to SDL here.
As we alluded to at the start, code analysis covers more than just security bugs – indeed the distinction between security and reliability can sometimes be a subtle one: the bug that manifests as a crash today (a reliability issue?) could turn out to be controllable by an attacker tomorrow (a security issue). We highly recommend running Visual Studio Code Analysis to help develop secure and reliable applications.
Tim Burrell, MSEC Security Science
Hello all,
Today we are excited to announce that some enhancements have been made to three of our free Security Development Lifecycle (SDL) tools - Threat Modeling, MiniFuzz, and RegExFuzz.
As many of you know, tools can be an invaluable asset when it comes to implementing a Security Development Lifecycle process in any organization. Over the years, Microsoft has made many of its security development tools available for free here. We hope these new enhancements will provide greater flexibility and enable you to effectively implement an SDL process in your organization.
Threat Modeling Tool v3.1.8
The Threat Modeling Tool is used in the SDL Design Phase to find security problems before coding begins. Through beta testing we obtained valuable input on what changes could be made to improve the tool. In this new version, we focused on stabilization of the Visio 2010 and Team Foundation Server (TFS) 2010 support that was provided as part of the beta release, and fixed bugs that were discovered.
Thank you to all of our beta testers who reported issues in the forum as well as through the select beta program. Your input was critical to improving the tool and customer experience.
> Learn more or download the tool
MiniFuzz Tool v1.5.5
The MinFuzz Tool provides basic file fuzzing capabilities that can be applied by developers, testers and even those with limited experience with fuzz testing as part of the SDL Verification phase. In this new version of the tool, we have included support for Team Foundation Server (TFS) 2010, fixed stability bugs and made it easier to control target application shutdown.
RegExFuzz Tool v1.1.0
The RegExFuzz Tool provides regular expression fuzzing capabilities that can be applied during the SDL Verification phase to check that regular expression evaluation times are not exponential. Regular expressions with very long evaluation times can lead to DoS attacks. In this new version, we focused on bug fixes requested from field use of the tool. A readme document has been added to the download which documents the fixes, remaining known issues, and planned future enhancements.
As the threat landscape continues to evolve, we remain committed to freely sharing our secure engineering best practices and security tools with the broader community. We hope you find our tools useful and, as always, we welcome any comments or feedback you may have.
Regards,
Monty LaRue [SDL Team]
Hi All. Doug here,
In April 2011 Forrester Research wrote a new study on Application Security. This study, titled Application Security: 2011 & Beyond led by Dr Chenxi Wang, Lead Analyst at Forrester Research, provides valuable research, insights and recommendations for security and risk professionals. We have since made this study publically available in hopes of creating greater awareness around the importance of secure application development.
The report observes that sufficient resource allocation to address application security remains a significant issue for businesses - Even though secure application development is considered a top priority by IT professionals and web application hacking continues to be the number one source of data breach incidents.
Part of the challenge is getting development organizations to undergo the culture shift required to making risk management and mitigation in application development a priority. Dr Wang’s report shows that organizations who do make the investment in secure application development are realizing positive returns. (More information about return on investment can be found in our recent blog post and in the MidAmerican case study).
There are several great recommendations in the paper which provide cost effective and incremental steps towards better application security. They include demanding better quality and security from vendors, acceptance testing for 3rd party software, disabling unused default accounts, building a secure operational environment around the application, and effective bug reporting and handling.
Additionally, one of the key recommendations identified in the paper is to implement a secure application development program, such as Microsoft’s Security Development Lifecycle. Take a look to see the latest information and tools that Microsoft makes freely available.
We encourage you to read this study and use it to think about how you can leverage the changing IT environment, such as the introduction of mobile technology and applications, to help provide the catalyst to enable change in your application development culture to improve application security.
Hi, Michael Howard here.
One very low-cost and low-friction SDL task that has high impact is removing (and not adding) banned functionality. The most common examples of banned functionality include various C runtime functions, such as strcpy(), strcat(), strncpy(), sprint(), gets() and their evil brethren; and weak crypto algorithms, such as DES, MD4 and SHA-1.
Over the years, I have shepherded the banned API requirement through the SDL, making updates along the way. One of the biggest changes in recent years (other than adding memcpy() to the list) is a separation of ‘required banned’ functions and ‘recommended banned’ functions. The reason for this change is some functions are a ‘clear and present danger’ and should never be used in any code. Ever. E.V.E.R! This is the SDL ‘required banned’ list.
Other C runtime functions pose less of a risk; but in high-risk code, or code with a very high attack surface, they should be considered for removal, and certainly not added to new code in the first place. This is the SDL ‘recommended banned’ list.
We have created an update to the original banned API and recommended replacements list. That updated text is here and the header file is here.
Feel free to leave a note if you have a question of comment
- Michael
Hello all, this is Monty LaRue posting with some SDL related tools news. Microsoft has recently released an updated version of the Web Application Configuration Analyzer (WACA). While this tool isn't intended to satisfy specific SDL requirements, it is valuable for performing best practices checks on your web application’s configuration. The checks span the Windows, IIS, ASP.NET, and SQL Server aspects of a deployment and are derived from standards that Microsoft uses to harden production servers. WACA is a good complement to the Attack Surface Analyzer tool which is applicable within the SDL Verification Phase.
You can find more details about each of these tools on the Microsoft Download Center: Web Application Configuration Analyzer and Attack Surface Analyzer Beta.
Hi All – Doug here…
Earlier this year, Microsoft worked with Forrester Consulting and Dr. Chenxi Wang, Lead Analyst on secure application development, to survey the current state of application security amongst 150 of the largest corporations in the US and Canada. I talked about it in February when we first published it on this blog. The report turned out to have a lot of very interesting data, some of which we’ve discussed previously when we published State of Application Security - A Forrester Consulting Thought Leadership Paper Commissioned by Microsoft on our website.
Microsoft is hosting a webcast on Monday, May 23 at 11 am PDT with Dr. Wang talking about the results and her recommendations based on the information in the study. I will be following her presentation with a brief presentation of my own discussing similar benefits that we’ve seen in our interactions with other organizations. The two presentations will demonstrate that the SDL, as an end to end process that engages all the relevant parties within an organization, can have a significant impact.
The current security and compliance environment is driving many organizations to look at their own secure application development practices. The results from this study and the information in the webcast can help provide key parts of the business rationale for starting a secure application development program that is about more than just compliance. The findings of this study are very clear that there is a business benefit in not only doing better application security but also in the ROI of changing the corporate culture around software development. This is a great opportunity to get your business decision makers to hear the facts and to help you make your case.
Come listen and have an opportunity to ask questions. You can sign up here, Business Insights Webcast: State of Application Security: Key Findings.
Adam Shostack here. Lately, I’ve been focused on how we bring the engineering of usable security into the SDL. When I say usable security, I mean that for those times when we need to ask a user for input on something only they know. (For example, are you connecting to a coffee shop network or your work network? Are you trying to print to a printer you’ve never used before?) We want to ensure that those questions enable users to make security decisions in accordance with their preferences and goals. So if you’re coming here to read about what’s made it into the SDL, stop now. But if you’d like some insight into how we update and improve the SDL, and some insight into something we might add, read on.
Remember that, at Microsoft, the SDL is a collection of proven practices that integrate effectively into the software engineering process. One of the key elements there is that the practices are proven to be effective without an expert in the room. We know from our Experiences Threat Modeling at Microsoft that
rolling out a mandate too early can have unfortunate consequences, and we dread the idea of doing that again.
So as we think about usable security engineering, we’ve made some great steps forward. We have guidance that’s in use in some of our product teams. We’ve surveyed the engineers who are using it and they find it effective at producing better interfaces with less debate or churn. What we don’t (yet) have is really crisp entry and exit criteria or tool support, and those are important gates to bring something into the SDL.
All of that is background and context for some work that we’d like to share for your use and feedback. It’s a pair of new mnemonics for important things to consider as you’re building security user experiences. We hope you’ll agree that user interfaces should be NEAT:
For more details, and even a second mnemonic, we suggest you look in the attached two pager by myself and my colleagues Rob Reeder and Ellen Cram Kowalczyk.
All that said, we think this is pretty NEAT, and we wanted to share it and ask for your opinion and feedback. Please give us your thoughts in the comments, or by email to tux@microsoft.com
Jeremy Dallman here with another release of free SDL documents. Today we are making available a library of templates to help you get started with the more thought-based SDL practices or activities.
One of the big questions we faced early at Microsoft and are now hearing again as more companies of all sizes start to adopt the SDL in their own organizations is “How do I [insert SDL practice or process activity].” Most frequently, these questions are specifically talking about the SDL practices that cannot be addressed with tools and are more process-oriented or thought-based.
As these questions started coming in from other companies, we started digging into some of our internal archives for the documents we used early-on at Microsoft. Most of these documents have since been incorporated into web forms or our internal SDL management dashboards. However, we discovered that they served as very useful templates for other companies. Now we want to let other SDL organizations look at them and put them to good use as well!
Today, we are releasing a small library of templates for SDL practices that can help you address:
… as well as a .ZIP that contains all of the templates in a single package.
These documents are published under the same Creative Commons license as our other SDL documents. Please put them to use in their default form (without edits), as templates to modify/customize for your unique needs, or simply as a catalyst for brainstorming and creating your own documents. The goal is to help you accelerate implementation of the SDL practices and gather valuable security information about your projects.
We are glad to share these pieces of the Microsoft SDL with the ecosystem and look forward to hearing about how they were used in your own SDL projects.
Jeremy Dallman here to let you know we have released our annual update to the Microsoft Security Development Lifecycle Process Guidance – version 5.1 (SDL 5.1). SDL 5.1 is now available for download (.docx format) as well as updated online in the MSDN library.
This public update of our internal SDL process guidance documentation is intended to provide transparency into how we implement the SDL at Microsoft. The changes in SDL 5.1 continue to demonstrate that the Microsoft SDL is continuously evolving to address new attacks, implement new protections, and improve the security of Microsoft products early in the software development lifecycle.
If you are just beginning your investigation or implementation of the SDL, we encourage you to first read the Simplified Implementation of the SDL paper and some of the additional resources we make available on the Microsoft SDL website. The SDL 5.1 guidance may be a useful resource for organizations whose processes align with Microsoft’s processes or are looking for detailed information on how Microsoft implements the SDL practices.
What is new in the SDL 5.1 documentation?
Since this is a “dot” release, the number of updates is smaller. We have tagged each change within the paper so they can be easy discovered by searching in document for “New for SDL 5.1”, “Promoted requirement for SDL 5.1”or “Updated for SDL 5.1”). The updated content in the MSDN library includes all updates automatically.
Comments or questions? You can either leave them in the Comments section below or visit the SDL Process Forum to ask questions and discuss your own implementation of SDL security practices in your organization.