Wednesday30 November 2022

Vendors - once again - rule the security world, especially in Health Care Featured

Reading time is around minutes.

It seems that is the time once again to talk about the relationship between software vendors and the security posture of different business verticals. Why are we beating this particular dead horse? Well with the Covid-19 Pandemic, the rush to shift to remote work force and an increase in attacker activity aimed at the remote workforce and healthcare you would think that there would be an increase level of effort to fix vulnerabilities in remote access and healthcare services software. If you thought that, you would be wrong. Instead during this time, we are seeing more software vendors pushing FDA as law and healthcare organizations even refusing opportunities to patch critical software. This on top of an extremely slow response to threat to the remote workplace.

In March of 2020 as the common response to Covid-19 was to isolate and move from an on-site workplace to a heavy remote one we saw far too many companies making this move without the proper safeguards in place. BYOD policies were suddenly implemented, and corporate assets were opened to the outside world. Threat actors went into overdrive as they went on the hunt for not only truly insecure companies, but also ways to leverage existing vulnerabilities that are commonly left on the table. We have talked about this problem before, so we will not belabor it too much here. The big issue is that once the normal routine was established far too many organizations did little to nothing to improve their security posture and remained open to attack. This was even more prevalent in the healthcare industry.

In healthcare, almost more than any other industry, the idea of 100% up-time drives the security posture. I often hear comments like; “we can’t take that down”, “our vendor does not support that”, “we can’t have anti-malware on that”, along with a host of other excuses when it comes to security tools and prevention measures. Let me give you a very concrete example of this.

A healthcare organization runs a clinical application (it does not matter what the application is). The organization is looking to patch a key subsystem (.net, esxi, etc.), they reach out to the vendor and are told they cannot update as their clinical application is not supported on the updated version. Now the host system is vulnerable to attack all because of pressure by the vendor. We can see the same logic being applied to clinical applications when it comes to security tools. An organization my want to install an advanced EDR/XDR solution on all systems to help prevent Ransomware but are unable to due to dependencies of the EDR/XDR solution that cannot be upgraded. Conversely, if they do have the proper dependencies, the EDR/XDR must have too many exceptions and blind spots to make it of any real value on the device.

Although these examples are seen in many other business verticals, we see them more clearly in Healthcare. Vendors throw around FDA protections to prevent any real security in their apps and have no interest in taking ownership for the vulnerabilities their introduce. This has left healthcare very exposed at a time when they need to be able to provide services to people. The attackers know this and have doubled (or in in some cases, tripled) their efforts. The are very aware of the fertile hunting ground they have and know they are very likely to get the money they ask for. New and improved ransomware as a service models mean that we can expect to see a continued rise in these types of attacks. That is unless some significant changes are made.

To change this trend both software vendors and healthcare organizations need to step up and take more ownership of this issue. On the healthcare organization side, they need to invest in better and more consistent security tools, redundancies, backup systems, proper network segmentation, as well as requiring vendors to be responsible for the failings of their software. There must be a fundamental top-down shift in perspective as well. Security needs to be a priority instead of it being driven by the needs of the application. This does not mean you put lives in danger, but it does mean you allow for proper testing, patching, down time and security tools to be put in place to prevent the use of those tools as an attack vector. Failing being allowed to do those things then the application needs to be a locked off as possible. Believe me when I say that attackers do not care if they disrupt a hospital’s efforts. In fact, they are counting on the impact to force the payment of the ransom.

In the future we need to see more healthcare organizations spend on securing and stabilizing their own systems and infrastructure and less on purchasing bitcoin “in case” of an incident. If we cannot make this shift the trend of attacks aimed at healthcare organizations will not only continue, it will expand.

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.