SBN

Zero Trust Architecture for Healthcare – 7 Common Pitfalls to Avoid

The wealth of sensitive personal and financial data managed by hospitals and health systems, coupled with known cybersecurity vulnerabilities, makes the healthcare sector an inviting target for cyberattacks. In the last three years, 93% of healthcare organizations have experienced a data breach, and 57% have had more than five breaches.

Digital transformation has led to explosive growth of interconnected IT, IoT, OT and, for healthcare organizations, IoMT and medical devices designed to improve patient care and outcomes. Along with these innovations comes an ever-increasing attack surface. IoMT and medical devices in particular share information and communicate with diverse endpoints, making them powerful vectors for damage. They are also subject to supply chain vulnerabilities such as those revealed in our recent Access:7 disclosure, which could enable hackers to remotely execute malicious code on imaging and lab machines, for example. Cyberattacks on medical devices can lead to misdiagnosis or mistreatment, resulting in serious injury or loss of life at worst and significant loss of business and reputational damage at best.

No wonder zero trust architecture (ZTA) is gaining momentum in healthcare. In this post, based on my recent Healthcare Cyber Security Summit talk, I’m going to share some tips, best practices and pitfalls to avoid on your journey to zero trust. It’s based on over 100 conversations I’ve had with cybersecurity leaders in healthcare and other industries.

The NIST SP 800-207 standards for zero trust architecture

The core concept behind zero trust is to “never trust, always verify.” It’s been more than a decade since this architecture was introduced, so there are many guidebooks out there, but today the primary source of truth across the public and private sector is NIST SP 800-207.  It outlines seven steps for introducing ZTA to a perimeter-based architected network:

  1. Identify actors on the enterprise
  2. Identify assets owned by the enterprise
  3. Identify key processes and evaluate risk associated with executing them
  4. Formulate policies for the ZTA candidate policy enforcement point (PEP)
  5. Identify candidate PEP solutions
  6. Begin deployment monitoring
  7. Expand the ZTA

ZTA is a security design approach, not a single solution or technology that can be purchased through a single vendor. A major advantage of NIST SP 800-207 is that it lays out a multi-vendor, vendor-agnostic approach – and more help is on the way. Implementing a Zero Trust Architecture is a forthcoming project from the NIST National Cybersecurity Center of Excellence (NCCoE) that enlists multiple vendors to demonstrate practical approaches to zero trust using the tenets in SP 800-207. Forescout is one of just a few vendors selected by NCCoE to collaborate on the project.

Now then, onto the pitfalls to avoid.

Pitfall #1: Undercounting the reality of your digital terrain

Zero trust begins with a user and device that must be verified before they can access sensitive data. Already, this is where the first major pitfall arises in many organizations: Their use case for ZTA assumes there is a human and a managed device. In a hospital network, most devices communicating across the network, data center and cloud are non-human entities. Managed workstations used by humans typically comprise 30-50% of a network.

In addition to administrative and clinical IT, think about all the connected devices in a typical hospital ecosystem across nurses stations, patient rooms, surgery centers, laboratories and pharmacies, most of which manage sensitive personal health information (PHI):

  • IoMT connecting major surgical and imaging equipment, infusions pumps and pharmacy dispensers
  • IoT/OT that manage building automation systems (BASs), including security cameras, badge readers and HVACs, as well as Zebra printers and RFID readers
  • Wireless access required to host guest, patient, visitor and contractor devices
  • Unmanageable vendors requiring access to medical devices for support and maintenance

This snapshot only represents on-prem connectivity. It doesn’t include requirements for telehealth and remote workers. Already you can intuit that without accounting for your entire digital terrain upfront, you almost certainly will have to redesign and potentially fork your ZTA to account for them later.

Pitfall #2: Starting with the PEP

Under zero trust, each device must go through the same verification process every time it tries to connect to your network: First, a PDP, or policy decision point, must determine its trust level, and second a PEP, or policy enforcement point, must either deny or grant it least-privileged access based on the specified trust level.

Too often organizations jump directly to PEP vendor evaluation, which is Step 5 in the NIST guidance. If you start more than halfway through the process, you’ll be talking only to PEP vendors, who may try to convince you they’re all you need for zero trust. There are four policy enforcement approaches to consider and dozens of vendors within each one. Do you want to use an agent centric, perimeter centric, network access centric or application centric approach? Based on the above reality check, it’s clear zero trust is going to require a mix of these options, and you don’t have enough information to evaluate them yet.

Steps 1-3 require you to identify and classify everything traversing various boundaries across your network and to understand the communication flows among them. Only then can you tackle step 4: creating the policies for what should be communicating with what. Your policy design will dictate step 5: which candidate PEP solutions you need in each case.

Pitfall #3: Not using all available compliance and threat intelligence in your PDP

PDPs have their own set of issues. A smart PDP relies on continuous compliance and threat intelligence coming in from multiple sources. The more context, the smarter the decision point. Most organizations have many sources of this information, but it’s not being tapped continuously and corralled to inform every access decision.

The PDP has a policy engine that should reflect input from security agents and subscriptions, the CDM system and SIEM system, activity logs and security tools used for vulnerability assessment (VA), endpoint protection, data loss protection and so on. You also want to incorporate intel on compliance with standards and policies such as NIST CMF,  identify management and data access. This collective intel, coming in from multiple vendors, tools and sources, should manifest in various policies as specific checks to be passed. For example, before a nurse can access the EMR/EHR on a workstation, identity checks for both the user and machine must be passed, as well as VA checks for exploited critical vulnerabilities and EDR checks for threats or IoCs.

These checks must be continuous, automatic and happen at machine speed to ensure they don’t disrupt workflows and, more importantly, to cut off network access if a check fails.

Pitfall #4: Formulating policies without discovery, classification and grouping

Visibility is the foundation for zero trust. You can’t secure what you can’t see. Before you start creating policies, you want to know, with high fidelity, what devices are connected to your network, who the users are, what they communicate with and what processes and risks exist.

The discovery process produces a raw list of IP addresses that’s of little use for humans creating policies. They must be translated into your business logic; that is, classified by device and user type, then grouped by business function. For example, X-ray machines and PACS servers might be grouped under medical imaging, while badge scanners and electronic door locks may belong under BAS. These steps pave the way for writing the group-level policies needed to assess trust and least privileged access – the heart of zero trust. It may sound like a huge undertaking, but the entire process can be automated to include continuous and passive discovery, classification and assessment across campus, data center, cloud, IoT, IoMT, medical devices and OT environments.

Pitfall #5 Causing business disruption during policy implementation

Next, it’s time to visualize and analyze the traffic flows. Which types of users, devices and machines are communicating with what other types of users, devices and machines? Are any of these permissions inappropriate? How can you optimize communications? With this understanding, you can define exactly how you want these humans to communicate with those non-human entities, this workstation to communicate with that imaging device, and so on.

A sure-fire way to kill your zero trust project is to cause business disruption. This typically occurs while you’re rolling out new zero trust policies that impact communications and cause anything from inconvenience to harm. For example, you may create a policy for how a radiologist’s imaging machine communicates with a PACS server based on documented port and protocol configurations. Often, however, undocumented but valid communication also occurs.

The best way to avoid disruption is to simulate policies and monitor traffic flows before rolling out new controls. NIST SP 800-207 doesn’t expressly reference simulation, but look for it in key security tools used for zero trust. For example, Forescout can be run in simulation mode to flag policy violations that could have unexpected consequences across the network. This allows you to fine-tune and validate your policies before go-live.

Pitfall #6: Not separating PDP in the control plane from PEP in the data plane

At last, you’re ready for Step 5: evaluating different vendors and PEPs. Imagine starting here, without understanding the types of users, devices and traffic patterns in your environment. By proceeding sequentially from Step 1, when you reach this point, you will know, “This needs to be a firewall, that requires software-defined access, I need an agent over here.” Many of the right enforcement points are likely already on your network; they just need to be tied  together with a macro policy engine. Don’t rely on siloed PEP policy engines – they won’t consider your macro-ecosystem, which includes many other cybersecurity tools.

Another major concept in the NIST ZTA is physically extrapolating the control plane from the data plane. You’re already familiar with this practice for identity management. Remember when it was a nightmare? Every application, server and thing had its own identity for every single user. Now, best practice is to manage identities from a central location in the control plane and map them to the applications in the data plane. The same practice applies to zero trust policies. A single PDP sitting in the control plane can write all the necessary policies and enforce them across the different PEPs in the data plane.

Pitfall #7: Deploying small and thinking small

With everything in place, you’re ready for initial ZTA deployment and monitoring. People will warn you not to eat the whole elephant in one bite. True, you don’t want to turn on everything at once, but you do want to plan for your whole implementation upfront to avoid the need to redesign or, worse, have a stalled deployment.

It’s wise to start your implementation in smaller sections of your ecosystem and expand little by little. However, if you focus on one small area without seeing the big picture, you may accomplish zero trust for that area but need to reboot to accomplish the rest – or never complete it.

Ready, set go!

In closing, let’s reframe my pitfalls to avoid as imperatives to follow. I called out seven, although they don’t necessarily directly align with the seven tenets of NIST SP 800-207:

  1. Understand the reality of your entire digital terrain.
  2. Don’t start with the PEP. Start with visibility and asset inventory, the foundation of zero trust.
  3. Incorporate all available compliance and threat intelligence into your PDP.
  4. Discover, classify and group everything connected to your network before designing policies.
  5. Simulate all new zero trust policies and monitor their impact before going live.
  6. Put the PDP in the control plane and the PEPs in the data plane.
  7. Deploy incrementally but consider the whole picture upfront.

If you adhere to these rules and pay special attention to considerations for the healthcare environment, you’ll be well on your way to zero trust.

Planning your zero trust architecture for healthcare doesn’t stop at managed users and workstations. Here’s how to get started and avoid pitfalls.

Watch Webinar

About the author

Tamer Baker enjoys helping customers build strategies and regulatory compliance policies, improve cybersecurity posture and position their organizations as a best-in-class provider based on NIST, CIS, zero trust and other frameworks. He has specialized in compliance automation strategies in CDM, C2C, healthcare, finance/banking and more.

The post Zero Trust Architecture for Healthcare – 7 Common Pitfalls to Avoid appeared first on Forescout.

*** This is a Security Bloggers Network syndicated blog from Forescout authored by Tamer Baker. Read the original post at: https://www.forescout.com/blog/zero-trust-architecture-for-healthcare-7-common-pitfalls-to-avoid/