Reacting to a Security Incident

So reacting to a security incident properly is actually pretty critical. I mean a lot of things can go wrong. This can include things like straight up data destruction. This can be physical damage from a fire or flood, interstellar invasion, whatever it is. This could happen as a result of different kinds of malware. Wiper malware just destroys things. Ransomware will encrypt your data and then theoretically you can pay to get it back, although a lot of the time they don't give it back. So these underscore the critical importance of backups, preferably offsite and not always connected to your system. Because again with ransomware, if it gets in your system it tries to infect everything and if your backups are directly attached, it will infect those, too. That's can also mean something like just a straight up successful attack, a data breach, hackers stealing data from your system, including most likely PHI. As I mentioned before, a malware infection can damage the data and your system. Either one of these is considered a data breach by Health and Human Services under HIPAA. Now you can also obviously bring in afterwards computer forensics experts and security experts to assess the damage, patch whatever vulnerabilities were exploited in the attack to prevent similar attacks in the future, but... Before something goes wrong, you want to look at a few specific plans. In particular, a business continuity plan, disaster recovery plan, and what's called an incident response procedure, sometimes called an incident response plan. First a business continuity plan covers steps needed to recover and replace your business functions within a reasonable amount of time after a disruptive event. Basically you want to be able to get back up and running. It's just a question of what to do and what will reasonably get you back up and running.


The thing underlying this is something called a business impact analysis, sometimes referred to as a BIA. This determines what needs to be recovered and how quickly. In a larger organization they'd literally have reports from each department on what needs to be running, in what order. In a dental office, you will have some idea of what needs to get back up and running, how quickly. Just make sure you're actually committing it to paper. That's what the business impact analysis does. And from that you can build this business continuity plan to look at what needs to come back and what order to get you back up and running as quick as possible. A related concept, is called a DRP or disaster recovery plan. That's a plan to maintain or rapidly restore your IT infrastructure, basically your systems, etc. in the case of a major problem. Whatever it is that takes you off, you want to make sure you can get back up and running quickly.


So the disaster recovery plan, the DRP that's quickly getting your systems back up, the business continuity plan, or BCP, is getting you back to normal in a reasonable amount of time. The related concept, the incident response procedure or plan or the IRP, that defines what constitutes a security incident in the first place and then lays out your organization or office's steps, step by step, in terms of how you respond to it, who's responsible for what, how everyone's going to stay in touch with each other. Basically all the steps for something that can go wrong before it happens. It's really important to do this early. The reason for this is if you're trying to figure this out and something has already gone wrong, this is sort of like you're on the field for a game and the other team has the ball, they're charging towards your goal and you're literally on the sidelines going, "all right, Tommy, why don't you play halfback. Julie, why don't you get in net." While you're busy figuring out the details, they're going to run it and punch it in the goal. Unfortunately it's not as bad as a soccer game gone foul. This is your network and if you're not ready, whatever it is is going to be a lot worse because you're not prepared to respond to it. And there are obviously a lot of sources for this information. The business continuity planning, disaster recovery plan, the incident response procedure, a lot of it, there's a lot of access here in terms of resources for getting it for free. You can see them online for similar organizations and you can literally download them and just tweak them a bit to fit your organization. I will put multiple links in here so that you can have each of these handy because it's very, very important to have these ready well before there's a problem.


Now, one last concept with this is: testing. It's really, really important to do some tests on these because if there's a problem and when you start off, there's always a problem of some sort. You're going to find out the worst possible time if you don't test it first. Basically when you really, really need it, it won't work. And oh, one last thing to mention, make sure these are written for the people who'll be using it. If, let's say it's a technical plan written by technical people, but the people using it are not technical people, they're not going to understand what to do. So always make sure it's addressed to who's going to use it so they can do the most helpful thing to protect your office and get you back up and running as soon as possible.

It’s essential to prepare for a security incident (or any other type of issue that can threaten your office) before something goes wrong.

Business Continuity Plan (BCP)

  • Covers steps needed to recover and replace business functions, within a reasonable amount of time after a disruptive event
  • Business Impact Analysis – determines what needs to be recovered and how quickly

Disaster Recovery Plan (DRP)

  • A plan to maintain (or rapidly restore) IT infrastructure, systems, etc. in the event of a major disruption

Incident Response Procedure (IRP)

  • Defines what constitutes a security incident and lays out an organization’s step-by-step response to the incident

Testing for each of these is critical