Episode 107: A Risky Business

Speaker 1: You're listening to Your Practice Made Perfect. Support, Protection and Advice for Practicing Medical Professionals, brought to you by SVMIC.

J. Baugh: Hello everyone, and welcome to this episode of Your Practice Made Perfect. My name is J. Baugh, and I will be your host for today's podcast. We have back with us today Robbie Morris. Robbie, welcome.

Robbie: Thanks so much, Jay. Good to be back.

J. Baugh: Well, it's good to have you back. We'll be talking about privacy and security risk assessments and cyber incident responses. We had Robbie for a previous podcast, in which we talked about some of these issues on a more general level, and so if you haven't listened to that podcast, you might want to go back and listen to that one first. And we're going to put references to that podcast in the show notes for this podcast. This one is going to be a deeper dive into a few cybersecurity topics, and so let's begin with talking about privacy and security risk assessments.

Could you start maybe by just explaining what those terms mean?

Robbie: You bet. In the HIPAA law, there are several components, the privacy rule and the security rule, when you think about clinical operations, patient data. I'm not referring to personally identifiable information because that's a whole ‘nother conversation. Again, this is protected data. The privacy portion of the rule established administrative controls, so definitions around the data and what classification is, the organizations. And a privacy risk is obviously then the potential loss of control of that personal information. During a risk audit and the review of the controls that are in place. The people, the process, the technology controls that you have that maintain that privacy right, you would uncover risks or gaps - if you will - around people, process or technology that could allow for unauthorized access to private data.

HHS, Health and Human Services, they are the ones that are in control of this world. They have defined that there are seven elements that should be addressed and in place in order to comply with the privacy rule. A lot of organizations, as you're going down whatever your lens is from where you're sitting, so you're creating the data or just in control of data, all of the requirements are the same. And one covered entity can obviously be responsible for a business associate and their actions of that same information.

When thinking about the data, notice of privacy rights, that's a very important component. The rights to request for PHI, access to data, administrative requirements, use and disclosures, amending and accounting for disclosure. There's a lot of risk. When you think about a privacy audit, there's a framework that you should follow that helps guide the privacy control. And in a privacy audit, you would look at the data, again, how you're managing that.

A security risk assessment, on the other hand, the security rule established technical controls. In both the privacy rule and security rule, there are required elements and addressable components. Security rule, that's your technical controls, activity log, access log, and classification of the data that you are protecting, so you're establishing the control of that. And within that definition of the security risk assessment, some of the things that come into that discussion is the organization size and complexity and what they do. You define all of these in policies and procedures that you have in a company, right? And that's the boundaries that you operate under, and it's not a destination. It's an ongoing process that shows a pattern of behavior about patient data and the controls and what the government has the right to ask of you to do.

Robbie: Technical, hardware controls, software controls, infrastructure, cost of security components of managing firewall logs and logging. The security assessment is the likelihood and potential impact and risk to protecting that data. Conducting a security risk assessment is a key component to an organization's risk management process, and they help identify potential security measures, again, in policies, and gaps or flaws in their process and identifying, addressing those weaknesses early.

J. Baugh: Where would a company begin if they wanted to do, or when they need to do, I should say, a privacy and security risk assessment, where would a company begin to do this?

Robbie: Depending on the size of organization, you can complete it yourself. Health and Human Services, they've been very specific around what they're asking, right? It's the law. There's no ambiguity in the law and there's no optional laws. Anybody can go to the internet and search for audit and assessment protocol and HHS, and it will pull up literally the questions that they will ask you and things to consider when marking your compliance checkbox of that particular component. Then they've also published a software tool that you can download and it'll manage that process for you. It gives you the ability to mark whether your documentation process has satisfied the requirement and assign the risk level if something goes wrong.

But if you can't do it yourself, that doesn't relieve the obligation. You must hire someone, and so it got to be done. It's the law. And risk assessments, again, in HIPAA have been, that's not new, but it keeps popping back up through the Affordable Care Act and meaningful use. I mean, it was required there. A lot of insurance companies that require claims to be paid, if you're going to file an insurance claim, you will - must have - done some reasonable due diligence and efforts, and putting a firewall in is one of those examples. You've got to follow a process, and the government has published that framework. So you can literally know what they're going to ask you.

J. Baugh: So let's change gears just a little bit here, and let's step over now into discussing cyber incident responses. Can you shed a little bit of light on the topic of cyber incident responses?

Robbie: When you think of incident response, another component in the HIPAA law is the breach notification rule. The requirement is to provide notification of those individuals that are affected following a breach. A breach is classified as the data has been accessed. An unauthorized situation has occurred. An incident is, something has occurred in the operation, but might not have constituted access to protected information. HHS defined the breach as impermissible use or disclosure under the privacy rule, that compromises security and privacy of PHI. So following a breach, a covered entity or business associate must provide notification to the affected people, perhaps the secretary of HHS. You have to notify the government that something occurred-

J. Baugh: That's right.

Robbie: ... and perhaps have to take an advertisement out, a media thing.

J. Baugh: Sometimes you do have to do that, yes.

Robbie: Right. And the notification requirements, all that's governed by the number of records that are exposed, and breaches of 500 or more people require an immediate response. That, then in itself, becomes a difficult challenge. Going back to your question now.

Under the law, HHS specified the definition of a breach. But in IT, an event is anything of significance that could impact a system or hardware processes or disrupts operation. Security incidents are usually distinguished by the degree of severity and the associated risk or compromise that the organization had. So, an incident could be just merely an attempt to gain access, so security incident. Somebody clicked on something. They went to a website. They filled out something, opened the file that was attached, fell prey to something that then caused another reaction. That is an incident, and the incident was, an email came in and you clicked it. Right? So going through the incident response, you define what those variables are.

J. Baugh: So you have to have some sort of a plan in place, when it comes to cyber incident responses?

Robbie: Yeah, that's right, and it should be, there's a number of steps in the plan and that's preparing for it. So, we've installed antivirus because we're preparing to get viruses. Preparing for the incident, what that may be, identifying what the potentials are. Maybe it's an operational, we lost power. Maybe, it's, the sprinkler went off in the server room. Maybe it's somebody spilled Coke on the server. All of those things are important. Oh, well, now somebody put a USB drive in the computer. Oh, well, somebody clicked the email. The list goes on and on and on. The potential things that could go wrong and documenting that is the plan. So preparing, identifying, containing, resolving the situation, eradicating whatever. Maybe it's a malicious virus or a file or ransomware, God forbid, and then the recovery after the fact. The last part that people don't do, what was the lesson we learned? So that we don't make the mistake again.

J. Baugh: You don't want it to happen a second time.

Robbie: Right.

J. Baugh: Yeah, exactly.

Robbie: One of the common huge problems that I see in every environment that I go into, and it doesn't matter whether it's a small clinic or a large hospital, a lot of organizations don't archive the access logs. Let's just say a small clinic, there's 30 devices. So there's 15 PCs, a couple of servers, a couple of access points, a firewall, and a couple of switches. On one year, those devices would generate roughly about five terabytes of activity logs.

J. Baugh: Wow.

Robbie: ... of just plain text.

J. Baugh: That is so much information.

Robbie: It is ridiculous, and that's just the way it works, because everything reads and writes to a log. A lot of organizations don't manage that process correct. So, in talking about incident response plan, well, if you lost power, that's one thing. You know when the power gets turned back on. If you launched a ransomware attack, you got the key back, but are they out of your environment? And you hope they are, but hope is not a strategy.

J. Baugh: Yeah. You got to have a plan, got to have some processes in place before the fact to know what you're going to do if something like that happens.

Robbie: That's right. In all of those kinds of controls, as an example, you can't just set it and forget it. There's some degree of administration that you got to do. There's also your documentation proof of compliance.

J. Baugh: So that you can show someone, if you get audited, "This is what we did."

Robbie: Yeah. It's a pattern of behavior for sure, and organizational assets then become Word Documents that are very important and very valuable. A lot of money and time has been spent to create those documents. There's not one person doing all of that by themselves. So who does what when that happens? Who do we call? If it's our EMR company, and the server gets hit that then corrupts our database on that server, what do we do? Who do we call? There's a data archive that organizations use to backup data appliances, a little thing that just plugs into the network, and the servers write to it each night, and that thing pumps the data up into a cloud and archive.

Robbie: Again, just tons of information just flying all over the place. So it's important to know that you're not moving bad data, backing it up, which is a whole ‘nother conversation in cybersecurity, because now we're talking about cloud operations and public cloud, private cloud, physical environments and architecture, monitoring your costs, all that is a challenge. But it has to be there and there's not one that's safe on its own. So cyber incident response, it's not a matter of if, it's whe,n that these things can go wrong.

J. Baugh: For our listeners who are interested in trying to find some additional resources about how they could begin self-assessments or look at some sites to help them review the information that they need to for cybersecurity incidents, we're going to put that information in the show notes. If any of our listeners finds themself in a situation in which they feel like that there might be some sort of a HIPAA privacy breach, ransomware, anything along those lines, feel free to give us a call.

Robbie, we want to thank you for being here today.

Robbie: Thanks so much, Jay. I sincerely appreciate it.

Speaker 1: Thank you for listening to this episode of Your Practice Made Perfect with your host, J. Baugh. Listen to more episodes, subscribe to the podcast and find show notes at svmic.com/podcast. 

The contents of this podcast are intended for informational purposes only and do not constitute legal advice. Policyholders are urged to consult with their personal attorney for legal advice, as specific legal requirements may vary from state to state and change over time.