Best Practices: Consistent patching, meeting compliance requirements and Red Hat Satellite

Patching is a necessary part of operating system lifecycle management. It is also a requirement of functional compliance as well as regulatory compliance, as called for in the Health Insurance Portability and Accountability Act (HIPAA) and PCI DSS 2.0. But patching production systems that support critical applications like electronic medical records (EMRs) can make healthcare IT administrators a little uneasy. With a consistent patch strategy that is routinely executed on your Red Hat Enterprise Linux systems, patching can run smoothly. So what’s the best way to do this?

An automated solution like Red Hat Satellite can help healthcare organizations manage their deployments of Red Hat Enterprise Linux. Red Hat Satellite is a life-cycle management platform with tools and features to deploy, update, monitor, and manage systems, including patching.

When it comes to regulatory compliance, there are at least two regulatory frameworks that might apply to your organization. The HIPAA requires covered entities to follow a Security Management Process, which states that they must protect against any reasonably anticipated threats or hazards to the security or integrity of information, conduct a risk assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by an organization, and implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Security patches are considered part of both risk analysis and management. If an organization processes payments via cards, there are time based requirements for patching to comply with requirements, as part of PCI DSS 2.0. This requires organizations to ensure that all system components and software have the latest vendor-supplied security patches installed. Both HIPAA and PCI DSS 2.0 can be met with a regularly applied patch cycle and a review of the content within that patch set.

Healthcare organizations, by the way, must also implement EMR systems to be in compliance with federal regulations. One such solution is Epic’s EpicCare EMR software suite. Red Hat and Intel have collaborated to offer a cost-effective, efficient, and scalable foundation based on standards and open source for an Epic environment. Other EMR software suites that work with Red Hat Enterprise Linux include Cerner’s Acute Care EMR software and the suite of EMR software from Mckesson. Add in Red Hat Satellite and healthcare organizations can automate and streamline patching.

Updates to Red Hat Enterprise Linux within a major version do not change the application program interface (API) or application binary interface (ABI) of operating system components. The updates are released as a bundle of related packages, and information (called errata) about the updates is released as soon as possible for security and bug fixes. Errata and their packages are available from the Red Hat Network from what are known as channels. If you run a patch cycle on a non-production server connected directly to the Red Hat Network the released errata and packages will be available for the server. If you test these patches and then run a patch cycle on the production server also directly connected to the Red Hat Network, there could potentially be new patches that have been released which could lead to a different patch set applied than what was tested on non-production servers.

Red Hat Satellite can address the issue of time of patch determining the content of the patch set. By cloning your own channels from Red Hat Network content on your Red Hat Satellite, you can create a point-in-time snapshot so that when you patch does not determine what you patch.

Using Red Hat Satellite can provide healthcare organizations the confidence they need that patching critical production systems will run smoothly, especially since you can test a patch set in your non-production environments before applying that patch set to production.

How does your organization manage patching? Share your best practices in the comments section below.

  1. We have just migrated from satellite 5.6 to satellite 6.1. On satellite 5.6 we used action chaining to initiate a pre-patch boot , then patch the server and follow-up with a post-patch reboot. It appears that satellite 6.1 does not have the same functionality requiring us to login and run these procedures from each system which seems to undermine the promise of automation – what gives?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.