How a software approach could boost security

Enabling patient-doctor trust goes a long way in furthering a provider’s ability to provide care; trust is also critical for enabling network connections that are safe, to help secure health networks.

As the healthcare industry is scrambling to shore up defenses as cyberattacks and breaches increase, the rapid adoption of electronic health records (EHR) has created an attractive opportunity for cyber criminals. Each healthcare record that is breached could cost as much as $363 on average, the highest cost across all vertical markets, according to the Ponemon Institute.

Healthcare organizations are tasked with the difficult job of protecting both the core HIS network and departmental systems. This is particularly true in multidisciplinary practices, which are comprised of clinics and multi-location healthcare facilities. Typically, healthcare cybersecurity builds walls around the perimeter to keep the bad guys out, with critical connections enabled by Transmission Control Protocol/Internet Protocol (TCP/IP).

TCP/IP connectivity starts with a DNS lookup so Endpoint A can determine Endpoint B’s IP address to establish a connection. Endpoint B must respond to the connection request to establish a TCP connection, despite knowing nothing about Endpoint A. Only then can Endpoint B seek more information from Endpoint A to try to establish its identity, authorization and trust.

This basic architecture has fueled scalable TCP/IP networking in healthcare. The problem is, it requires:

• Servers with protected health information (PHI) to be heavily advertised (DNS).
• Continual connectivity of the health network.
• Servers to expose themselves to unknown users and devices by responding to TCP requests.

This is the perfect formula for any health organization that wants to be susceptible to network-based attacks and fooled by anyone who has stolen credentials from an authorized user.

Healthcare organizations have tried to limit authorization as a defense mechanism, usually by mapping users into Active Directory Groups that define the applications they are allowed to access. The problems, from the standpoint of protection against network-based attacks, are:

• Stolen credentials can still fool the system if based simply on using a username and password.
• Servers must engage with the prospective user – establish a TCP connection and probably then a TLS connection – before enough information can be obtained to determine whether the user is authorized or not.

A lot of bad things can happen in that time frame, including SQL injection, connection hijacking and OS or server vulnerability exploitation.

In less complex times, most applications were run from within the health network and accessed by users who were either local or backhauled over the corporate WAN to access the applications. Today, many apps have moved to Software as a Service (SaaS) or to Cloud Service Providers. Health IT is challenged with protecting networks and patient data while providing secure connectivity for those authorized to access this private information.

Software Defined Perimeters (SDP) has been created to address the issues cited above, and is gaining traction in healthcare. SDP does not attempt to regulate traffic at the network level. It operates at the TCP level, which means it can be deployed anywhere and is transparent to network-level issues such as addressing, ownership and changing topologies. Because data can’t be accessed unless a TCP connection is established, SDP enables a medical system to completely control who gets to connect over their entire extended health network. It can allow only trusted connections.

In SDP, applications, services and servers are isolated from users, which create a zero-trust network by an SDP Gateway – a dynamically configured TCP Gateway. The gateway rejects all traffic sent to protected servers unless users and endpoints are “pre-approved” as trusted by a third-party arbitrator, performed by the SDP controller. Endpoints desiring connectivity to a destination protected by an SDP gateway don’t bother to send a connection request to that destination. Instead they “apply” for connectivity to the SDP controller, which determines if they are trusted or not.

Trust verification involves device authentication, user authentication and context-based information that will continue to expand over time; this can include location, BYOD vs. managed device, software posture and software integrity. The goal is to evaluate overall trust as much as possible before allowing connectivity. If satisfied, the SDP gateway dynamically configures the TCP gateways to allow connectivity. The systems that are isolated and protected by the SDP gateways in this zero-trust scenario are then never exposed to:

• Attackers who have stolen credentials.
• Unauthorized systems that might intend to exploit server or application vulnerabilities.

Successful spear phishers trying to move laterally in a persistent search for access to sensitive data, or bad guys who, failing everything else, just want to deny service to others via bandwidth or resource starvation attacks.

SDP controllers and gateways are software entities that can be deployed with no topological restriction. As a result, SDP provides a powerful tool for health organizations to completely control access based on trust, whether the application is located internally or on the cloud, if the user is an employee or a non-employee, or if the device is managed or BYOD.