Software Flaws: Why Is Patching So Hard?

Federal regulators are reminding organizations about the importance of identifying and patching software vulnerabilities. But why are these seemingly basic security steps so challenging for so many, and what can be done to improve these practices?

The Department of Health and Human Services' Office for Civil Rights' latest monthly newsletter spotlights the risks posed to healthcare organizations by unpatched software flaws and the difficulties often involved with patching. But many of the insights apply to organizations in other sectors as well.

Challenges range from difficulty in keeping up with vulnerabilities and quickly applying patching - if and when flaws are identified by vendors - to the complexity of applying patches on clinical systems that cannot easily be taken offline because of patient care demands or their interconnectivity with other critical systems and devices.

"Identifying software bugs and managing patches can be challenging in healthcare," says Keith Fricke, principle consultant at tw-Security. "Hospital networks that are 'flat' mean that computer workstations may be co-mingled on the same network as biomedical devices. Care must be taken to ensure vulnerability scans do not adversely affect biomed devices, especially ones connected to patients."

Additionally, maintenance windows can be challenging to establish, "given that hospitals operate 7x24x365," Fricke notes. "In some cases, workstations, servers, and/or applications may be owned and managed by a vendor. The vendor may require managing patches, putting the healthcare organization at the mercy of the vendor's schedule. Additionally, patch testing is necessary to ensure applying patches to production systems does not cause problems."

Widespread Risks

Spectre and Meltdown, identified by researchers in 2017, were prime examples of widespread vulnerabilities impacting healthcare and other organizations, OCR notes.

"The security flaw was present in nearly all processors produced in the last 10 years and affected millions of devices. After the discovery of these defects, vendors scrambled to release patches that addressed this problem. However, testing indicated that a side effect of the patches could be decreased performance in certain computer uses," OCR writes.

"Testing and understanding the impact of patches can be critical to mitigating the risks patches are designed to address while avoiding or minimizing risks that patches may introduce."

Difficult Work?

Identifying vulnerabilities in software is a significant challenge for many organizations in healthcare and other sectors.

"As OCR states, identifying all vulnerabilities in software is not an easy process, particularly for the end user or consumer," says Mac McMillan, CEO of security consultancy CynergisTek.

Among the most difficult vulnerabilities to identify and patch in healthcare environments "are those associated with software or devices of a clinical nature being used directly with patients," he says.

"There are many issues that make this a challenge, including operational factors like having to take the system off line or out of production long enough to address security. Hospitals don't typically stop operations because a patch comes out. The more difficult problems are ones associated with the vulnerability in the software code itself, where a patch will not work, but a rewrite is necessary. When that occurs, the consumer is usually at a disadvantage."

Fricke says applications that a vendor has not bothered to keep current are the trickiest to patch.

"Some vendors may require the use of outdated operating systems or web browsers because their software has not been updated to be compatible with newer versions of operating systems or web browsers," he says. "At some point, the operating system vendor or web browser vendor may stop issuing patches, leaving the healthcare organization between a rock and a hard place."

Room for Improvement

So where is there the most room for improvement?

"The most room currently is in the tactical management of vulnerabilities to systems and software," McMillan says.

"Many organizations still lack well defined and executed processes for identifying, researching, patching and testing systems in the environment," he says. "However, if vendors were required to certify that their software has undergone appropriate code review for security prior to it being sold, much of the risk healthcare entities face would be mitigated."

But some software vendors put up barriers to mitigating their products' flaws, he contends.

"There are many software vendors who are reluctant to address security flaws in their software for a myriad of reasons; but usually it comes down to dollars and cents," he says. "Without a hard requirement to address the issue, it often takes market pressure to get something addressed; that is not easily accomplished."

Buyers need to be aware, in particular, that smaller software developers and entrepreneurs sometimes do not have sophisticated software development practices or the resources to afford secure code testing, McMillan says.

Steps to Take

How can healthcare organizations and their business associates improve their practices for identifying and mitigating software vulnerabilities?

To help keep abreast of reported vulnerabilities, organizations should tap into resources made available by such organizations as the Department of Homeland Security's U.S. Computer Emergency Readiness Team, OCR notes.

McMillan points out, however, that "the problem is that not all vendors put their software through rigorous security testing, and some don't test for security at all. So consumers will not know about flaws in their products until the bad guys show it to them, like Spectre and Meltdown. Secure code testing is not a requirement for vendors, but it should be."

Fricke suggests organizations ensure there allocate enough time and resources early in a new system implementation to test and apply patches. "At times, organizations implement a new system without applying appropriate patches due to the go-live schedule. Well-intended people plan to go back and patch after go-live, but they either do not, or they delay completing that task," he says.

"Such a mindset gets system patching off on the wrong foot. Also, it is worth looking into leveraging technology that can act as a compensating control until a patch can be applied. For example, an intrusion prevention system may have the capability to block an attack on a vulnerability until the patch can be applied to the system susceptible to attack."

Useful Tools

OCR also notes that a variety of tools can help organizations keep their software updated with the latest patches.

"Vulnerability scanners are software tools used to test systems and networks for known vulnerabilities, including identifying outdated or unsupported software," OCR writes. "Oftentimes, when threat and vulnerability data is available publicly, malicious actors specifically seek out unpatched vulnerabilities on a system to exploit. This means that the timely implementation of patches is an important part of the risk management process."

Installing vendor recommended patches is typically a routine process, OCR notes in its alert. "However, organizations should be prepared in the event that issues arise as a result of applying patches. Computer programs are often interconnected and dependent on the functionality and output of other programs.

"When certain changes are made, including the installation of a patch, programs dependent on the changed application may not perform as expected because settings or data are affected. This is why in complex environments, patch management plays a crucial role in the safe and correct implementation of these changes. Each organization is different and has unique systems, challenges and needs for this process."

Due to the complexity of some systems, installing a patch or collection of patches can be a major undertaking, OCR acknowledges. "System modifications that affect the security of electronic protected health information may trigger an entity's HIPAA obligation to conduct an evaluation to ensure that ePHI remains protected following environmental or operational changes," OCR writes.

"An evaluation can help identify new vulnerabilities that may have resulted from these changes. Undiscovered bugs or vulnerabilities are unpleasant surprises that could be exploited and may lead to beaches of PHI."

About the Author

McGee is executive editor of Information Security Media Group's HealthcareInfoSecurity.com media site. She has about 30 years of IT journalism experience, with a focus on healthcare information technology issues for more than 15 years. Before joining ISMG in 2012, she was a reporter at InformationWeek magazine and news site, and played a lead role in the launch of InformationWeek's healthcare IT media site.

Operation Success!

Risk Management Framework: Learn from NIST

From heightened risks to increased regulations, senior leaders at all levels are pressured to
improve their organizations' risk management capabilities. But no one is showing them how -
until now.

Learn the fundamentals of developing a risk management program from the man who wrote the book
on the topic: Ron Ross, computer scientist for the National Institute of Standards and
Technology. In an exclusive presentation, Ross, lead author of NIST Special Publication 800-37
- the bible of risk assessment and management - will share his unique insights on how to:

Understand the current cyber threats to all public and private sector organizations;

Develop a multi-tiered risk management approach built upon governance, processes and
information systems;