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:
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.