I hear patches and the first thought that comes into my mind is me as a kid falling, tearing my pants and my Mom fixing them with patches. I also remember, using patches to repair the tires on my bicycle. Of course, there were also the patches I used in martial arts and the military. These patches main purpose was to identify the organization at large. However, there are other patches that I have been using for many years but, truly never think about them. I am referring to the system patches that I created, or those my own network identified and installed on my behalf.
Merriam-Webster Dictionary defines a patch as:
Based on the above definition, it is easy to summarize the function of a patch as, an item or device that is used to repair or correct errors. Even more important, while all patches are significant, patches used for our networks and software are critical and failure to deal with them in a timely basis could expose you and your organization to catastrophic results.
Consider the following:
In its June 2018 newsletter, The Department of Health and Human Services, Office of Civil Rights (OCR) explained that:
“Most software that we use contains “bugs” – mistakes in the software code that negatively affects how the software works. Some of these bugs may introduce security vulnerabilities that, if exploited, could permit hackers unauthorized access to a user’s computer or an organization’s computer network. Patches are fixes to these bugs to correct how the software operates including closing security vulnerabilities. Patches play an essential role in the software lifecycle as vulnerabilities are regularly discovered in software that can create risks to the confidentiality, integrity, and availability of data. Without patches, such vulnerabilities could not be fixed.”
Just considering the issue of bugs within our software and systems, merits we pay close attention to system patches. If we add cybercrime to the equation, then paying close attention is not enough as we must ensure that our systems are secured, and that we not only protect the information but the operational side of the same.
In the healthcare arena, it is even more important as we are becoming dependent on our systems for day to day operation. However, there are other things to consider as explained by the OCR:
“Under the HIPAA Security Rule, Covered Entities (CEs) and Business Associates (BAs) are required to protect their ePHI, which includes identifying and mitigating vulnerabilities of computer programs and systems that could affect the security of ePHI. Identifying software vulnerabilities and mitigating the associated risks are important activities for CEs and BAs to conduct as part of their security management process and technical evaluations.”
As part of the mitigating process the OCR added:
“HIPAA covered entities (CEs) and business associates (BAs) are required to conduct a risk analysis ‐an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) they hold. Following a risk analysis, CEs and BAs must implement measures that reduce these risks and vulnerabilities to a reasonable and appropriate level. The scope of the risk analysis and risk management processes encompasses the potential risks and vulnerabilities to all ePHI that an organization creates, receives, maintains, or transmits.
This includes identifying and mitigating risks and vulnerabilities that unpatched software poses to an organization’s ePHI. Mitigation activities could include installing patches if patches are available and patching is reasonable and appropriate. In situations where patches are not available (e.g., obsolete or unsupported software) or testing or other concerns weigh against patching as a mitigation solution, entities should implement reasonable compensating controls to reduce the risk of identified vulnerabilities to a reasonable and appropriate level (e.g., restricting network access or disabling network services to reduce vulnerabilities that could be exploited via network access).”
The bottomline, even if the actions of patch management may not be evident, the act of identifying and installing the same are covered under:
|1||45 C.F.R. § 164.308(a)(1)(i)(A)||BAs an CEs must conduct risk analyses to identify vulnerabilities|
|2||45 C.F.R. § 164.308(a)(5)(ii)(B)||BA’s and CEs must have policies and procedures for guarding against, detecting, and reporting malicious software*|
|3||45 C.F.R. § 164.308(a)(8)||CE’s and Bas must conduct periodic technical and nontechnical evaluations*|
* Indirectly includes patch management as part of these standards
Going back to my military days, I remembered that for every task we had a checklist and a process to ensure that tasks at hand were taken care of. In this case, the OCR simplified our process by recommending CE’s and BA’s complete the following steps:
45 C.F.R. § 164.308(a)(1)(ii)(A).