Jeremy Dallman here to talk about aligning SDL practices with Health Insurance Portability and Accountability Act (HIPAA) regulatory activities when developing or integrating healthcare applications. Today, I would like to announce the release of a new whitepaper:
SDL and HIPAA: Aligning Microsoft SDL Security Practices with the HIPAA Security Rule.
We are all acutely aware that our lives are becoming more and more digitized. New technology and services are storing, aggregating, and sharing our personal information in new ways every day. With these innovations come inherent risks; and with these risks come new regulations designed to ensure technology is protecting our personal information. Along with the development of new technology and implementation of regulations is a rapidly-growing awareness that securing applications is a critical component of securing data. It is no longer enough to only rely on perimeter or infrastructure-based protections. The critical process of creating more secure applications is what the Microsoft SDL is designed to address.
Recent studies have shown that organizations are spending on compliance tasks in lieu of security – however compliance and security don’t have to be at odds. For organizations already tasked with ensuring their software meets the demands of regulatory compliance, adopting the Microsoft SDL process alongside these activities may seem both time consuming and costly. Yet, their customers are (or soon will be) demanding evidence of security best practices for how applications are written or integrated.
In recent months, the U.S. Department of Health and Human Services (HHS) has set a 2015 deadline to increase use of electronic health records (EHRs) by 60%, largely spurred by $19 billion in incentives for health care organizations to adopt EHRs. This push for EHR adoption and the billions of dollars in incentives are all part of the Health Information Technology for Economic and Clinical Health (HITECH) Act approved by Congress in 2009.
As we became aware of this convergence of new technology, regulatory compliance, demands for more secure software, and the inherent costs of these activities; it became apparent that we needed to evaluate the application of the Microsoft SDL alongside some of these regulatory activities.
This paper shows how the Microsoft SDL can help meet some of the requirements of HIPAA. It addresses two primary scenarios—the development of new healthcare software and the integration of healthcare software into an EHR solution. Both of these scenarios represent common intersections between software security and HIPAA requirements. Our goal is to show where software security can both assist in attaining regulatory compliance with HIPAA and ensure that the software created for the healthcare industry is written and deployed with security as a priority, using the Microsoft SDL as a guide. Additionally, this paper highlights some HIPAA security requirements (called safeguards) and demonstrates how SDL practices can be used to support those safeguards.
The expected audiences for this paper are business decision-makers, compliance managers, software developers, IT consultants, and systems integrators who are working within or on behalf of organizations that must meet HIPAA compliance requirements. This paper is not intended to advise organizations of their legal requirements and responsibilities. It is assumed that the reader understands the laws and regulations mentioned in this paper and how those laws and regulations apply to their organization.
The paper is broken into easy-to-digest sections that we hope are both readable and practical in application:
1. Overviews of the Microsoft SDL and the HIPAA Security Rule
2. A scenario-based review of SDL applicability to the HIPAA Security Rule
3. A “rip-out” mapping of SDL Practices to the HIPAA Security Rule Safeguards in the Appendix
We realize that aligning security practices with compliance activities will vary across organizations, but we hope this paper will help you think through how your organization may be able to adopt the Microsoft SDL to write more secure software and realize redundancies or improve efficiencies between those security practices and your HIPAA regulatory activities.
As always, we welcome your questions and feedback.
Jeremy Dallman here to introduce a new paper we released earlier this week that introduces you to the Windows Live team’s implementation of the SDL in their web application scenario. The paper will join our other internal SDL case studies and white papers in the Publications section of our SDL web portal and can also be downloaded directly:
Applying the SDL at Windows Live.
The Windows Live™ team adopted many of the newer Web-focused requirements of the SDL. This paper summarizes these new requirements, describes the process that the Windows Live team followed in integrating the SDL starting with Wave 2, and captures some of the lessons that they learned along the way. This paper also describes how the use of SDL by the Windows Live team has evolved, starting with Windows Live Wave 2, through Windows Live Wave 3, and on to the upcoming release, Windows Live Wave 4.
This paper focuses on two classes of Windows Live products:
· Web applications, such as Windows Live Hotmail®, running on Web servers hosted for Microsoft.
· Client applications, such as Windows Live Messenger, running on users' desktops.
The security threats and mitigations for these two classes of products are very different. The most common vulnerabilities observed in the Web applications are cross-site scripting (XSS), cross-site request forgery (XSRF), open redirects (XSRs), and JavaScript object notation (JSON) hijacking. In the client applications, past vulnerabilities are often due to buffer overflows and integer overflows. Some other common security vulnerabilities, such as Structured Query Language (SQL) injection attacks, are not as prevalent in Windows Live products because of their limited use of SQL.
This paper walks you through a phase-by-phase description of how the Windows Live team mitigated these threats by implementing the SDL while giving you a good view of how the SDL is applied by web application development organizations inside Microsoft.
Hi, Michael here.
It gives me great pleasure to introduce Tim Burrell from our team based in Cheltenham, England. Amongst other things, Tim works on static analysis and compiler security improvements, but more on that work in a later post!
As I have mentioned many times, I’m a huge fan of anything that reduces friction for software developers; anything that makes it easier to design, build and test code that’s more secure is a huge win in my book.
Now, over to Tim to see how a tool he created can help reduce coding friction and help you be more SDL-compliant!
In a previous post we mentioned that our team had worked with the Visual C/C++ compiler team to make significant enhancements to /GS buffer overrun detection in Visual Studio 2010.
While working on /GS – and navigating the unfamiliar corridors of the Visual Studio buildings – I got talking to Boris Jabes, Program Manager Lead in the Visual Studio IDE team. He told me how they were making the IDE easier to extend in Visual Studio 2010.
This piqued my interest because one of the challenges we face when enforcing compiler warnings is that teams write their code, and then get notified of the errors and warnings later on. There are some downsides to this process:
1. By the time the developer gets notified of the error or warning that needs fixing, the context is lost: i.e. the developer has to remind himself of what the line of code in question was doing.
2. Typically there may be multiple errors or warnings to resolve: the approach is naturally to go and fix all of them as quickly as possible to avoid any further delays to development. This can lead to errors.
3. The code that immediately follows the fixed code may also need updating as a result of the fix, and this can be time-consuming.
By flagging an issue in the editor itself, as the code is being written, the developer can immediately correct the issue knowing the code’s context.
With all the benefits of flagging coding issues early in mind, I decided to create an SDL Banned API extension for Visual Studio.
The extension is very simple: at the moment a developer types the name of a banned function, such as strcpy Visual Studio highlights the offending code using a squiggly line, much like a spelling error in Microsoft Word:
Visual Studio extensions can also differentiate between C and C++ language elements. For instance, we can ensure that we don’t underline occurrences of banned API function names that occur in comments or string literals:
We can also add tooltip information pointing to the SDL required coding practice.
Let us know what you think or how you extend this extension to your own purposes.
Thanks to Boris Jabes and Noah Richards in the Visual Studio IDE team for coding this up!
The code for the SDL Banned API IDE Visual Studio extension is available in SDLBanned.zip.
There are two folders in the ZIP file: src and bin. The source code folder includes the necessary C# code and VS2010 project to tweak the code. The binary code folder includes a single file: BannedAPIextension.vsix.
Double-clicking this file will install it into Visual Studio 2010. You can enable, disable and uninstall extensions from the Visual Studio Tools | Extension Manager menu.
Finally, if you want to tweak the code you need to install the Visual Studio 2010 SDK, the link is below.
Security Development Lifecycle (SDL) Banned Function Calls, MSDN, May 2007.
MSF Agile + SDL process template for Visual Studio Team System
Microsoft SDL process template for Visual Studio Team System
Visual Studio 2010 SDK
Visual Studio on MSDN
Extending the editor, MSDN.
VSX home on code gallery, samples, documentation and more, MSDN.
Noah Richards’ blog, lots of examples and discussion from Noah Richards on the IDE team.
IErrorTag Interface
Hi Michael here.
Over the last few months, a small cross-group team within Microsoft, including the SDL team, has written a paper that explains how to use the security defenses in Windows Azure as well as how to apply practices from the SDL to build more secure Windows Azure solutions.
We wrote this paper because no matter how many defenses we add to Windows Azure, it is important that people building software or hosting services in “The Cloud” understand that they must also build software with security in mind from the start.
The paper also discusses some common threat scenarios, and provides mitigation guidance.
Below is a short video introducing the paper and a link to the paper.
The paper is here.
Read the paper if you’re building solutions for Windows Azure so you know the threats your application might face and you know the practices you should use to defend against those threats. Let us know what you think.
On a similar note, Warwick Ashford, a UK reporter, interviewed Steve Lipner for a podcast about the paper and Microsoft’s cloud security practices. In the podcast, Steve touches on the roles of assurance and the SDL, operational security, and certifications in providing a secure environment for hosting applications in the cloud.