One of our customers processes 1.9 billion health insurance claims every year using Iguana.
Another uses Iguana to process 120,000 real time bedside medical device results per second.
With some of the most sensitive information flowing through your integration engine on a daily basis, I shouldn’t need to convince you how important integration engine security is. No organization wants to have their information stolen or locked up with ransomware.
When we are talking about security in integration, we are referring to four pillars: encryption, networking, authentication and authorization, and isolation. So in this blog post we are going to offer some best practices on the technical aspects of integration security. These best practices will help keep your information safe from hackers. But there is another threat that I want you to think about when we talk about security: the people you work with.
I don’t mean the people you work with are bad guys. I mean it’s a good idea to think of everybody you work with as basically a curious toddler. So security, if you’re doing it right, it’s a mix of locking your doors and making sure each member of your integration team has just enough system access to do their job. Giving everyone on your team admin privileges isn’t a smart idea, for reasons we will expand upon on in this post.
One quick note: while this blog post contains some examples that are specific to Iguana, most of these best practices can, and should, be applied to your integration engine of choice.
Anyways, let’s get started with the first pillar of security, encryption.
Pillar number one: that’s encryption. Now, it’s important to talk a bit about what encryption does and what it doesn’t do. Encryption makes information look like noise. It scrambles data in a way that’s very hard to unscramble, unless you have the key. So one of the most basic and most important things you can do with your Iguana is: put its configuration and its logs on an encrypted disk partition.
What does an encrypted disk partition do? It means the information actually written onto hard drives looks like noise. When it’s mounted and unlocked, the application using it (that’s Iguana) can read and write files like normal.
So how do we do disk encryption? We just have to configure the space we’re using on that storage array (a SAN for example) so the whole partition is encrypted. Nearly all Iguanas run on either Windows or Linux, so that means either BitLocker, or it means DMCrypt and LUKS.
Setting up BitLocker is different from setting up LUKS, obviously, but the basic procedure is the same. You enable the encryption service. In Windows, this is a few clicks. You turn on BitLocker for the drive letter that maps to the partition, create a password to be used to unlock that drive, and, if you like, configure the drive to be automatically unlocked when the user logs in.
In LUKS, it’s a little more typing. You unmount the partition, you format that partition as an encrypted device, you give it a passphrase, create a filesystem on it, remount it, and then set up key mappings so, if you like, it’s mounted and unlocked for that user.
In both cases, if you have a session as the user Iguana runs under, you can see the contents of the drive. And this is important. If you can log in as the Iguana user, you have control of that Iguana. You can start and stop the process, you can see and edit its configuration files, and you can see and edit its logs. This makes sense, right? Iguana is a service.
Think about all the things it does that make it an integration engine. It reads and writes to disk. It talks over networks. It opens ports and manages connections on ports. It can do these things because the user it’s running under has those privileges and those permissions at the operating system level. So to be that user is to have all the privileges the application has, itself. So probably the most important thing you can do, once you have disk encryption in place, is have tight control over who gets to log in to that machine as that user.
Networking is our second pillar of security, and it’s an important thing to get right. Why? Because most interfaces involve network activity of some kind; they listen on ports and accept incoming connections, they open connections and push messages out to remote hosts, they send requests to web services, and so on and so forth. Interfaces involve a lot of sending and receiving of data, and not just any data, but valuable and precious data. If we don’t do networking the right way, this data becomes a prime target for hackers.
So how do we do it the right way?
We need to make sure that the lines of communication between our interfaces and the systems they connect to are secure.
Obviously things are changing, but a whole lot of activity in and around an interface engine specialized for healthcare is still basic HL7 over LLP. And that’s fine, but it’s important to remember a few things about LLP. First, it’s a low level protocol. It cares about establishing connections and framing messages, and that’s basically it. Second, LLP doesn’t have any concept of authentication or identity.
So if we are going to handle LLP traffic securely, we need to do two things: One, use an SSL, and two, use VPNs.
SSL is all about encrypting messages themselves. In Iguana, this is an easy process.
You enable the SSL feature, you point it at your certificate file and your key, and it’s turned on. If you only want to obscure messages, that one step does it. But we can also use SSL as an authentication mechanism, so we can be confident the host we’re talking to really is who they say they are. How can we accomplish this? Through the use of self-signed certificates.
So one thing we can do to really use SSL for authentication, is we become our own signing authority. The remote friends who are going to be sending us messages over LLP, we get them to generate certificate signing requests and send them to us.
Then, acting as our own signing authority, we generate signed certificates from those signing requests and send them back to the remote friends. And then in Iguana, we enable the ‘verify host’ option in the SSL configuration. And now, when we get an LLP connection request, we only accept it if it’s encrypted with the certificate we personally provided to our personal remote friend. So it obscures the traffic and it makes us confident it’s our real friend at the other end of the connection.
Step two: VPNs. A virtual private network is basically an unencrypted tunnel session to a remote host. So it’s not just messages that get encrypted, it’s everything – all the connections, all the traffic, all the handshakes. Everything. With VPNs, the basic cryptographic underpinnings are just the same as with the SSL certificates. When we open a VPN session, the same protocols are used to verify our identity and to exchange keys. And then those keys are used to encrypt all the activity between our VPN server and the remote VPN client.
The tunnel connection basically brings the remote friend into a state where you can treat them as if they were on your own network.
Authentication and Authorization
The third pillar of security is authentication and authorization. Although these are technically two separate things, we’re going to group them together because of how closely related they are. In a nutshell, authentication means knowing who is in your system while authorization is about what the people in your system are allowed to do.
As we mentioned earlier, LLP has no concept of authentication or identity. In fact, it is not uncommon for us to see Iguana users building web services without authentication either. So what is an easy way to start with authentication when working with LLP or a web service? Basic authentication. Basic authentication is when a client sends both a username and password as unencrypted base64 encoded text. Now, it’s important to know that because base64 is not a form of encryption, it should usually be used in conjunction with HTTPS or another authentication scheme.
With regards to authorization, the key point is to give your employees just enough access to perform their job. With Iguana, this means not doing things as the admin unless you need to and logging in with the least privileged account you can manage. Authorization is not about keeping out intruders so much as about limiting what legitimate users have access to.
The fourth pillar is isolation. Isolation is about keeping different pieces of your system in different places, and controlling access to those different places. Basically it’s don’t have a master key. How do we accomplish this? By thinking in layers.
You know in dumb hacker movies, where they always have a scene where the guy in sunglasses at the computer says “I’m in.”
Isolation means you don’t have one “in”. It means you have several layers, and getting into one does not get you into the others. Your operating system is a layer, as are all of the applications you might use (such as your integration engine). Then there are layers above your integration engine like web services and tools. What you don’t want is a master key, or a single password and username combination, that provides access to all of these layers.
In conclusion, it is important to think about both the technical and human elements of integration engine security. Ensuring that members of your integration team have just enough access to perform their duties is as important as putting Iguana’s configuration and logs on an encrypted disk partition. With sensitive information flowing through your integration engine such as data from real-time ICU devices, lab results, and insurance claims, you need to make sure that your integration engine is running in a very secure environment.
If you are looking for more integration best practices, click to the button below to download our free guide, “5 Ways to Speed Up Your HL7 Integration”. The guide is packed with actionable tips that will help you simplify and speed up your HL7 integration projects.