Don't Get Caught Between a Rock and a Hard Place: Regulatory Compliance and Security Updates
"I need to deploy the security update MS06-001 to protect my systems, but I can’t because that would invalidate our HIPAA compliant configurations. What should I do?"
This quote above is one of many that I have heard from customers in recent years. It typifies the current, irresolvable situation in which many system administrators find themselves because of the need to both comply with regulations and install security updates to protect their systems.
On This Page
In 1996, the Health Insurance Portability and Accountability Act (HIPAA) passed; in 2002, Sarbanes-Oxley Act (SOX) was passed. While there are a number of other regulations that apply to information technology (IT) management practices in the U.S. and abroad, these two have had the most profound impact. It is only in the past couple of years that these new regulations have had a real effect on the day-to-day operations of the IT world. As regulations evolve from abstract ideas into concrete compliance requirements for the real world of operations, we are seeing an area where regulations are having an unexpected and negative impactthe realm of security updates.
Many of the principles and goals of these regulations are good; they often force organizations that had been reluctant to do so in the past to adopt industry best practices. In some cases, the need for regulatory compliance has helped network administrators successfully make the business case for the tools and resources needed to implement best practices where they had been unable to do so before. As a result, SOX and HIPAA have been strong drivers for practices like configuration management and change control.
Most people in security would agree that these are clear benefits: that the ability to secure your environment is always directly related to your degree of management and control over your environment. However, during the period of time that regulatory compliance has become an increasingly important and pervasive requirement, another change has been underway elsewhere that also affects IT management. In the past few years, the computer security threat environment has evolved and changed to become very fast moving. In some unusual instances, such as the Zotob attacks in 2005, active attacks have emerged within days after the release of security updates. For organizations to effectively mitigate the risk posed by this increasingly fluid threat environment, they need to be able to deploy security updates to their systems very quickly.
A Look at the Current Situation
Generally speaking, the types of best practices that regulatory compliance has imposed on the industry are practices that can help an organization to protect itself against existing and potential threats. Strong management controls and configuration management such as those recommended in the NIST Special Publication Series 800 and ISO 17799 provide a means to quickly change and update the operational configuration of production systems. One would expect that organizations that have implemented practices in support of HIPAA, SOX, or other regulations would be in a strong position to meet this threat environment through the timely application of security updates. Unfortunately, that is turning out to not always be the case.
What we see increasingly in a number of organizations is an environment where regulatory compliance has not fostered and facilitated the timely application of security updates, but has instead actively hindered the application of security updates altogether, let alone in a timely manner. System administrators are increasingly finding themselves between a proverbial rock, leaving systems potentially vulnerable to attack, and a hard place, making changes that can negatively impact the regulatory compliance of their systems.
In most cases, the root of the problem lies in how an organization has chosen to implement its compliance with regulations. Specifically, some organizations have implemented configuration management and change control systems that only meet the requirements of regulatory compliance without accounting for the requirements of ongoing security maintenance. Consequently, in environments where the goals of configuration management and change control systems are focused on a single set of requirements, there is little flexibility for change. From the standpoint of regulatory compliance, changes to systems incur cost and represent overhead. This problem is further compounded by the reality that, in many cases, the policies and procedures that are developed in support of regulatory compliance are made by staff members who are detached from the operational tasks, such as applying security updates, that their work governs. Finally, much of the literature and information around regulatory compliance fails to speak to the importance of maintaining the flexibility to update the environment to meet security threats. For example, NIST Special Publication 800-66 "An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule" is a guide to help with HIPAA compliance and makes only a single, passing reference to security updates.
While it is not necessarily obvious, the requirements for ongoing security maintenance ultimately support rather than hinder regulatory compliance efforts. Attacks that compromise systems because those systems do not have relevant security updates are a direct threat to an organization's regulatory compliance. Because of this, a regulatory compliance regimen that doesn't address requirements for ongoing security maintenance isn't a thorough or complete regimen. To be thorough and complete, a regulatory compliance regimen must include requirements for ongoing security maintenance and do so in a way that realistically accounts for the threat environment in which systems are operating.
An important point to note is that while regulations like HIPAA, and SOX and management frameworks such as CoBIT, don't specifically call out the importance of ongoing security maintenance, they also do not impose requirements that prohibit it. One thing that makes regulatory compliance challenging is the need for each organization to implement its own policies and procedures to meet the requirements imposed by applicable regulations. However, this also gives organizations the flexibility to be able to tailor their policies and proceduresincluding how security updates are managedin such a way their security strategies are both supported and enhanced. In other words, the freedom that regulations leave in the hands of the implementers can and should enable you to develop a regulatory compliance regimen that enables and facilitates ongoing security maintenance.
In many ways, implementing regulatory compliance is still a new practice and, as a new practice, it is expected that there will be a learning curve. The important thing with any learning curve is to be able to recognize the lessons that need to be learned and incorporate those learnings into future practices. In the past couple of years, one key lesson that has emerged around regulatory compliance is the need to ensure that it accounts for the requirements of ongoing security maintenance.
Organizations that are just now starting their work to implement solutions that comply with SOX, HIPAA, or other regulations are in a position to learn from those who have gone before them. These organizations can and should bring their security and management teams into the process of building policies and procedures to support their regulatory compliance. Organizations that have policies and procedures in place should take the time to reevaluate them with their security and management teams with the goal of ensuring that those policies and procedures are successfully accounting for the threat environment and providing system administrators with the flexibility necessary to be able to meet threats as they arise. In so doing, you will improve your overall security and thus improve your regulatory compliance.