Compliant or Secure?
In today's challenging healthcare IT world, there's increased focus on regulatory compliance and information security. For some outside of IT (executives, Board of Directors members, for example), being compliant and being secure are synonymous. They are not at all the same thing, though both are required in HIT today.
I recall an image in a security conference presentation that really drove home the concept of being compliant but not secure. It was a picture of a bicycle locked to a bike rack with both tires missing. It was "compliant" but not secure.
From an HIT information security standpoint, it can be challenging to be both compliant and secure. Here's a good example. Let's say you have a really diligent server team. They have a process they always use when commissioning a new server so that it is done the same way every time and the process includes server hardening (secure configuration). However, it's not documented as a policy ("Server and System Hardening Policy") nor is it documented as a standard process or procedure. Periodic auditing of server builds indicate the team does build servers the same way every time and they are using the secure configuration. Compliant? Secure?
Here's another scenario to consider. You have a policy in place ("Server and System Hardening Policy") and it has an associated procedure that documents and defines the required steps to be taken each time a new server is commissioned. The systems team members are required to read and agree to IT policies on an annual basis or at hiring. However, the team is comprised of individuals from different backgrounds and each approaches system hardening in their own way. From their perspective, they are compliant with the requirement to harden systems. Compliant? Secure?
Variability is the enemy of security.
Most regulatory requirements (HIPAA, Joint Commission, PCI, etc.) say you must have a policy in place to address certain controls and you must have procedures and practices in place that conform to your policy. So, is it better to have a team that follows a standardized, but undocumented process or a team that loosely follows the spirit of a written policy and procedure? Or are they equally bad?
I guess that depends. Certainly neither is good. From a compliance standpoint, you're perhaps slightly better off not having anything written (policy, procedure) and performing the work vs. having policies and procedures that are not being followed. So, in both cases (but for different reasons), you might be secure, but not compliant. However, let's be clear. Neither scenario is the place you want to be, so don't spend cycles trying to rationalize one stance or the other. Though I've heard colleagues refer to "locking the doors before papering the place" (i.e. do the work to secure your systems vs. sitting around writing high level charters and policies that no one adheres to), it simply is meant to indicate the order of priority. Always ensure systems are secure, then work on documentation.
Regardless of which scenario your team faces (no formal policies/procedures or no adherence to formal policies/procedures), in both cases, you are relying on informal, peer-to-peer knowledge to ensure the security of your systems. If you do not have documented processes and procedures that all engineers are required to follow, you will have variation. Variability is the enemy of security. In both of these examples, you are really relying on luck.
When patient safety is on the line,
luck is a four letter word.
Of course, when regulatory compliance, information security and your job are on the line, luck is still a four letter word. Relying on people to do work the same way every time is a challenge. Most sophisticated IT departments automate repetitive processes so that they are done the same way every time and the configuration is audited to ensure it continues to meet standards. However, not everything can be automated and those tasks that require humans to complete them are subject to error. No one is perfect, even our super star performers make mistakes. So, how do we reduce our risk of error?
Automate whenever possible
Document processes and procedures
Train staff on the procedures and the reason for these procedures (context is everything)
Audit the standard
Compliant and secure are not the same thing. However, you can walk your way into compliance by documenting your security activities more easily than you can walk yourself into security by writing documents. You have to get there either way, it's just a matter of the path you choose.
As always, please feel free to borrow from this blog, just be sure to include attribution information. Thanks.
