Our client, a large hospital system was seriously underperforming in its assessment of 3rd Party security risk. As with most large health care entities, it has a massive volume and velocity of data flows of electronic protected health information (ePHI) between care providers, payers, and vendors used to providing services to patients. This, obviously, engenders significant security and privacy risks. While Business Associate Agreements (BAAs) are standard and required, they do not accurately reflect the security posture of an organization. Increasingly Corporate boards are very sensitive to data loss caused by 3rd party inadequacies. The large Target breach of 2017 was directly attributable to poor 3rd party oversight. .
The IT infrastructure required to serve over 20 hospitals and over 300 clinics is necessarily very complex, distributed and large. Over 1000 applications in use and 70,000 network endpoints offers a simple indication of the size of the problem and the difficulty in securing information adequately. In addition, any comprehensive effort to shore up security and its execution would have to consider two fundamental aspects of delivering security to health care providers:
· To never harm patients
· To not interrupt, if possible, any clinical processes
Biomedical devices are a major cause for concern in hospital environments because:
They are connected to the hospital or care-provider’s network thus vastly increasing the attack surface area for evil-doers.
Patient safety is at considerable risk as demonstrated by recent remote wireless hacks of insulin pumps and other patient monitors.
Many devices have not had their operating systems patched or migrated to newer versions for years. These devices are especially vulnerable to known and widespread attacks of unpatched software. A virus infecting an “old” OS on an infusion pump can propagate and infect every other device, crippling the entire hospital network in minutes.
The mobile revolution has resulted in many new consumer oriented apps or devices that perform patient monitoring which then send information upstream or downstream for additional diagnostic actions. Tainting of this upstream or downstream data is very possible and adds to patient safety concerns.
Disaster recovery planning is like flossing – ignored until the pain becomes too great. The topic is large, the effort poorly-defined, and the payoff for planning is distant, and in the future. Disaster recovery (DR) planning is a task that is often scheduled for “someday”, when priorities and money will somehow become available. Yes it is in the nature of computer systems to fail, so DR planning is not for an “if” but for a “when”.
If a “health system” is defined as a provider organization having more than one hospital location, we will inevitably discover that security concerns are far greater than if securing a single facility.
In any “system” the different hospitals will have unique IT environments with different network designs, application profiles, biomedical devices, and unique customer bases. Security products and services will likely have been purchased on a “best-of-breed” basis over time. This results in varying approaches to maintain an adequate security posture across the system.