In the previous post in this series I introduced the healthcare dilemma from the CISO perspective, then attacked the Build vs. Buy issue in a 2-part series so today we get into the serious topic of risk classifications ...as the quote from Princess Bride goes "...when death is on the line."
Importance of Risk Classifications
Before you tell me that risk classifications are important, and water is wet, the sun is hot, and ice is cold ... I'd like to remind you how many large, small, and everything-in-between enterprises still do it poorly. I almost wish it was a simple as data telling you it's critical or not, but let's face it the game is very rarely that simple.
When I managed an IT organization at a start-up financial a number of years ago "everything" was critical. Our customer database, their financial and personal information, our feeds, people's payroll information, and everything in between. No one was willing to say "this data over here, isn't that important" ... heck even the call center manager classified his data stores at "Tier 1" (meaning - company critical).
Now fast-forward to working as a consultant through several medical and healthcare organizations over the past decade and as I go through my notes through my notebooks over the years looking at network diagrams and designs, hacking and recovery exercises, and data protection initiatives I realize that it's still difficult to classify anything as non-critical... but if you're a healthcare provider like a hospital or medicinal dispensary or similar, there's critical and then there's critical. The former will get you fined or in trouble with the FDA or worse ... the latter will potentially kill someone if you screw it up. The difference is huge.
When we're defining data classification levels in healthcare providers, we have to think about the absolute worst-case scenario: loss of life. My recommendation is that when you're doing risk assessments you do this for yourself... draw a small circle in the middle of a page and call it "Human Life" and then draw several concentric rings radiating out from the center... in the immediate circle that contains the "Human Life" circle you should have systems and data that are directly responsible for life support, maintenance. Things like that heart monitor that lives on the network and provides real-time feedback to the central nurse's station, and the application that manages case records and medicinal formulations/dispensations... things like that. In the next outer circle write in all the things that are one step removed from these life-critical systems such as the application infrastructure that allows doctors to seek a second opinion on an x-ray from a doctor in another hemisphere. Keep drawing and filling circles out and out until you're at that point where you've filled in every system, application, and data asset in your organization. Now you've got your risk classifications... based on the thing you care about most - human life.
Once you've gone through this exercise within IT, it's time to have the same kind of exercise with people like heads of the different departments within your organization, and basically everyone in the management chain in the organization outside IT. Nothing against IT people, but we're really not necessarily the best judges of what a doctor may need to re-start someone's heart... but over time and with enough of these exercises we'll get much better at the task!
Learning from the Circles
One thing that quickly becomes apparent is that you have a lot of critical systems, and you're going to need to pare them down further in order to get a starting point. In most healthcare organizations the sprawl of 'critical systems' is swift and difficult to contain. There are always new technologies that pop up to give doctors an edge when it comes to saving lives and improving people's healthcare - which means that we need to keep track of those systems ever-more carefully lest we lose track of what really matters.
For me, the point where I learned the most is not the first iteration of the concentric circle exercise within IT, but when I sat down with various department heads. At a hospital I sat down with the head of radiology, the head nurse, the head of the ER and various others and each of them had a slightly different perspective on things. To the head of nursing dispensary and support systems were the most crucial as her team needed to manage multiple patients at the same time across a floor, or "pod"... but for the head of the Emergency Room it was all the devices and information systems that his staff required to get that edge over someone's critical ailment. While they rarely had the exact same things in the 'critical' ring, what I realized is that the things that multiple department heads (and my IT team) had in the critical circle meant they were super-duper critical, and I based my overall analysis based on the frequency of overlapping in certain rings of criticality.
There was a good bit of science to the exercise, and if you've done one of these yourself, or are thinking about it - remember that it's not anything exact. Each facility, each organization, and each person thinks and depends on different components to make them effective. It will depend on your facility and how you provide care.
As a final analysis, identifying critical systems is absolutely ...well ...critical, as is classifying them in the real rings of criticality so that you can understand how things are inter-connected and what makes your organization tick and operate effectively.
I'd love to hear from someone that's led either this type of exercise, or something similar... just to get your experiences and ideas that perhaps others can work with.
If you're leaving a comment below, please leave your Twitter handle, and don't forget to tell us that you've left a comment on this topic to the #SecBiz Twitter hashtag. Healthcare is a very interesting, and often slightly unique, animal when it comes to risk, critical systems and getting a grasp on securing these things... thanks for sharing your experiences!