Have you seen that show “The Odd Couple”? It’s something everyone can probably appreciate — two very different people with almost entirely opposite goals and incompatible habits live together by virtue of happenstance in the same cramped apartment. It’s also a pretty good metaphor for what happens in health IT (HIT) and why the Cloud Security Alliance’s (CSA) Software Defined Perimeter (SDP) could be valuable in that space.

If that surprises you, reflect for a moment on the clinical network of most health care providers. Once upon a time, you might have seen separate networks in use, with a general-purpose one used for back-office traffic and another segmented and isolated one for clinical applications. And if you talk to most providers’ security professionals, they will tell you that this is very much their preferred state. Nowadays, though, this configuration is rare. Instead, you either see a single network that carries both sets of traffic or very loosely segmented and extremely porous networks.

This means the same network pathways that transmit workaday information such as employee emails, meeting requests and even social media traffic are the same ones that quite literally keep patients healthy by transmitting things such as diagnostic information, medical images and biomedical telemetry. If you thought “The Odd Couple” had a mixed set of priorities, that’s nothing compared to this dichotomy.

However, there is work being done in the cloud technology space that could potentially change the game for HIT — namely, SDP.

What Is Software-Defined Perimeter?

In an extension of work done by the U.S. Department of Defense, SDP is a software framework designed to allow a virtual perimeter even when one does not exist at the physical level. The 1.0 version of the specification was released by the CSA in April 2014, so it is relatively new.

At a high level, the purpose of SDP is to allow a perimeter to be created in situations where physical network segmentation isn’t possible or practical. So just as a physically segmented, isolated network would prevent outside traffic from reaching a host on that network, SDP would also allow this, even when those machines co-reside with other arbitrary devices and the physical network itself is unknown or semi-trusted.

Architecturally, it consists of controllers and hosts. Initiating hosts are those that wish to communicate with accepting hosts, while controllers manage those connections. Data communications occur over a data channel, while those management interactions occur over a control channel. Authentication and authorization happens using one of several standard services (Security Assertion Markup Language, OpenID, certificates, geolocation, etc.) to ensure only those connections that are appropriately authenticated can connect and only those that are authorized to do so may contact accepting hosts.

As you might imagine, this concept is particularly appealing in a cloud use case. In the cloud, customers purposely create a layer of abstraction at some level of the stack — specifically, everything on the stack underneath the level of service you’re leasing from an internal or external service provider. So for software-as-a-service, everything underneath the application level is a black box; you lease usage of the app, but everything upon which it sits is opaque. For platform-as-a-service, it is the application services upon which applications are developed. For infrastructure-as-a-service, it’s the network and physical environment. The point is that the customer is ceding the maintenance and overhead of the underlying components to the service provider. This is valuable because the customer has less to maintain. However, it can also be disadvantageous from a security, compliance or potentially even governance perspective.

Clinical Usage?

The clinical environment has much of the same challenges as the cloud. Instead of devices existing within the domain of a service provider you don’t have direct control over, the clinical devices exist side by side with devices, applications and services that are not directly responsible for patient care. They have different requirements, roles and security properties. If, as is very often the case, the security team wants a dedicated clinical network but does not have the budget or bandwidth to accomplish that at a physical network level, SDP could potentially be an important tool. It could allow this same goal to be accomplished at a much lower cost without requiring network-level changes or a separate infrastructure.

With that said, there are a few things to keep in mind. First, SDP is new — the actual published specification is less than a year old. So, it will take a while before everything you buy off the shelf includes it by default. This is not to say that there aren’t specialized vendors out there that support SDP — to the contrary, there are already some established products in the space — but keep in mind that the clinical environment has a few challenges, some of which can affect how, when and if you deploy.

Keep in mind that there are practical and sensible reasons why you can’t just go out and do your Swedish Chef impression on the production clinical network. First, in most providers, the team that oversees the clinical equipment isn’t necessarily the same team that oversees the rest of the network. There is often a biomedical engineering group that manages clinical equipment, even IP-connected clinical equipment. Second, much of the equipment in the clinical environment is managed by external vendors, and for good reason. Direct modification of the underlying OS — even though it may be a general-purpose OS such as some version of Windows or Linux — can have health and safety issues.

With that said, even knowing about the existence of SDP can be valuable for two reasons. First, you can discuss it with the team that supports the clinical side of the house and talk about the advantages it might have in this context. There may be some clinical systems you can start to plan for usage right away, even though many obviously won’t be ready for that step yet. Second, you and the team can start to pressure vendors of clinical applications and systems to support it. They should know what SDP is, so by pressuring them, they hear loud and clear why you as a customer find it valuable that they support it.

SDP could be a game changer for the clinical ecosystem, and learning about it now and starting to plan accordingly could have significant benefits for the security team.