Reacting to a Security Incident

When something does go wrong, the first thing to do is identify what happened. Essentially you’re figuring out whether or not it’s actually a security incident. Some situations are obvious, like a natural disaster or a defaced website, while others aren’t so clear and should be investigated by technical personnel (security professionals, system administrators, etc.) to determine if there was a security incident. Some of the possibilities are physical damage (fire, flood, etc.), human error, an insider attack or an external cyber attack leading to data theft, destruction, etc. Proper responses will naturally vary considerably depending on the type of crisis you’re facing.

Upon discovering a security incident, the next step is to mitigate the potential damage, effectively stopping the bleeding as quickly as possible. This may involve taking systems offline and/or contacting the authorities. Preset written responses like Incident Response Procedures, Business Continuity Plans and Disaster Recovery Plans kick in here. Then the problem needs to be fixed – this is typically a technical solution that will have to be addressed by security personnel. Finally, it’s important to understand what happened so your office can be better prepared next time.

But we’re getting ahead of ourselves…

Whether you have one office or twenty, the proper first steps in reacting to any security incident happen well before the incident itself. That’s because the plans and procedures essential to responding to a security incident need to be ready to go as soon as something is discovered. Otherwise, you’re effectively just starting to pick your team while the opposition is already on the field and charging towards your goal. This sort of delay is absolutely unnecessary and can result in bad PR, lost business and compromised information (and perhaps even a spot on HHS’ lovely Wall of Shame).19

A written procedure to refer to in case of an attack is critical. An Incident Response Procedure (or Plan – IRP) defines how an organization reacts to a security incident. Each incident is different, so the most important aspects of an IRP are who has the authority to act and what needs to be done (though not necessarily how). Once an incident has been discovered, the IRP should specify actions to address different levels of incidents, as well as who is on the incident response team. The IRP should clearly state:

  • Who responds to the incident
  • The timeframe in which to respond
  • How the response team members get in touch with each other
  • What resources they will need
  • Who do they contact (and when)

The IRP should specify one or more incident handling objectives. These can include: protecting organizational systems or data, restoring operations and limiting bad PR/brand damage. With HIPAA in mind, protecting data should be paramount. The response to the incident will flow directly from the handling objectives. It’s also important to specify who has the authority to take action (like the taking systems offline, contacting authorities, etc., as noted above). There are numerous IRP templates and detailed information available. HHS recommends a few resources to get started, including NIST’s comprehensive Computer Security Incident Handling Guide.20,21 The IRP should be created – and regularly updated – well in advance and tested periodically. As with anything designed for an emergency, if it doesn’t work, you’ll find out at the worst possible moment if you don’t test it first.

The plans mentioned above are a Business Continuity Plan (BCP) and a Disaster Recovery Plan (DRP). While they are often grouped together, they’re not the same thing. A BCP is for keeping things running in the short-term and a DRP is directed at recovering office assets and systems within a reasonable amount of time after an incident (it’s often IT-centric). One other important consideration: be sure that any plans (or procedures) meant to be used while responding to an emergency are written in language that can be understood by the people who will actually be using them. The easier to read, the better. As you can imagine, these plans are typically needed with little or no advance warning.

Start the ball rolling with a Business Impact Analysis (BIA). A BIA determines what needs to be recovered and how quickly. In effect, you’re identifying the processes or functions performed by each part of your office. With respect to each function, look at:

  1. Financial risk of not performing that function
  2. Regulatory risk of not performing that function
  3. Customer or reputational risk of not performing that function

In essence, what needs to be back up and running in what time frame to minimize the impact on the practice?

  1. What will the impact be if a given process or function isn’t restored right away (i.e., what’s really needed day-to-day and what can wait)?
  2. How soon until that impact will be felt?
  3. How significant will the impact be?

For example, if you’re a bank, marketing isn’t as critical in the short-term as payment processing, etc.

This is a slow and involved process, but well-worth doing correctly. Numerous samples and step-by-step resources are available.22

A Business Continuity Plan (BCP) is a plan to maintain (or rapidly restore) business functions in the event of a major disruption. This can include anything from a security incident to a flood or power outage. A BCP ensures critical business functions continue during a crisis and outlines the immediate steps to take in response to one.23 Specific steps will obviously depend upon the circumstances, though a BCP will cover business processes, your people, assets, business partners, etc. This will include considerations like communicating with patients and/or vendors, and where and how will staff continue working, if possible. Details vary, depending on the size and nature of your practice, though basic free templates are available. You can also use a BCP published by an organization similar to yours and modify it as necessary.

A Disaster Recovery Plan (DRP) covers the steps needed to recover and replace infrastructure, etc., within a reasonable amount of time after a disruptive event. “Reasonable” may depend on how critical the system in question is. A DRP should contemplate various types of disasters, ranging from a single system or device to your entire network. An office’s technological “environment” should be examined to determine the impact of any single system or device failure. The BIA and risk assessments should offer guidance with respect to the effect and importance of specific systems, functions and processes.

A DRP specifies what must be done to keep your office running without the affected system or systems. The DRP should also include the “how” of getting replacement equipment if it’s needed. Given what’s at stake, DRPs should be tested and kept up-to-date. It’s rare the first draft of a DRP is perfect, so it’s extremely risky to make the first run through a live one.

Resources to help in the preparation of a DRP are available online and elsewhere.24