It’s 4:45 p.m. on a Friday. You’ve had a great week. You’re busy shutting down all your equipment and are ready to head home when a colleague peeks into your office.
There’s a problem with one of your core systems.
None of the end-of-week patient billing statements will go out. As a matter of fact, there’s a weird message on the main computer that hosts that data. It popped up a few hours earlier after a co-worker got that email from you to update the system password. The team member has spent the last few hours trying to work around it, with no luck. Frustrated and wanting to go home for the weekend, someone finally reaches out to you.
“All of your files are encrypted. The only way you can regain access is to purchase your unique key.”
The problem? No one from your team sent an email about password resets. And, you’ve been diligent explaining to all your staff that you’ll never send email messages like that and what they need to do to vet if a message is real.
But all the education and training was for naught. It’s going to take a while to evaluate, triage, and recover. Where do you begin?
- Is your incident response plan ready?
- Do you know which team members you need to rally?
- Are they still in the office or connected remotely?
- Is there a clear plan of action?
- Do you have updated contact information for everyone needed for response?
- Do they know their roles and responsibilities?
- Do you have a solution to help you manage the incident?
Increasing Attacks
The healthcare industry continues to be hard hit by data breaches.
There have been over 700 breaches and 74 million records breached to date in 2023.
And for the 13th year running, healthcare has the highest average cost of a breach, which is now nearly $11 million.
While healthcare remains in the crosshairs, these types of attacks are happening with increasing frequency across all industries. Unfortunately, incidents such as cyberattacks, natural disasters, or other disasters or disruptions don’t just happen during normal business hours.
Are You Prepared?
Incident response, even with effective planning, can be stressful. That stress is heightened with attacks that happen outside of normal operating hours. And even for those that may originate during the business day, response and recovery can rack up hundreds—or more—hours, late nights, weekends, and holidays. Not to mention the financial expenses that can quickly add up during incident response, often exceeding hundreds of thousands of dollars for a single entity.
So, how can you help reduce some of this stress and be prepared for incidents no matter when or where a disruption occurs?
It’s all about incident response planning, where it’s probably a good idea to go ahead and adjust your approach from what might happen “if” a breach or disruption occurs to “when.”
Incident response goes well beyond cyberattacks, expanding into other disruptions like severe weather disruptions or other natural disasters, which are increasing in frequency alongside breaches and ransomware attacks. Establishing robust, well-thought-out incident response plans that encapsulate a variety of these disruption types, for example, an unexpected pandemic—may be the lifeline that ensures your organization survives the next incident.
While it’s not possible to plan for every scenario, having an incident response plan developed, tested, and ready can help you set the stage for what you need to do to respond to an incident in the future.
Here are 7 tips to ensure your incident response plan is always incident-ready:
- Establish an incident response framework you can build upon or improve over time
Your incident response framework should include the complete lifecycle of an incident. Based on NIST SP 800, here are a few areas you’ll want to ensure are included in your framework:
- Prepare
- Detect and analyze
- Contain, eradicate, and recover
- Post-incident activities
It’s important to point out that this is not merely a linear process. After developing your plans, once you detect an incident, you’ll need to analyze it and enact your containment, eradication, and recovery protocols. However, before you can move to your post-incident activity phase, you’ll need to loop through the detection and analysis phase again until you’re sure your incident has been resolved.
Even then, once you make it to the post-incident phase, you’re not finished. You should review and apply knowledge from that post-incident review to your plans, meaning you may need to make adjustments or improvements identified within that review.
Remember, your incident response plan is not “set it and forget it.” It should be treated as a living document that undergoes continuous review, testing, and updates to ensure success.
- Understand common occurrences and build them into your policies and procedures
Before building your incident response plan, especially for cyber response, you may find it beneficial to develop an understanding of some common occurrence types so you can plan for them.
By understanding some of the common categories your organization may encounter, you can plan for scenarios that could come into play as part of your incident response strategies. This list can also help you mature and scale your existing response strategies.
Here’s a quick overview, which is not comprehensive but will give you a good starting point:
- Unauthorized Access: This is when an individual or entity gains logical or physical access without permission to your network, system, application, data, or another resource.
- Denial of Service (DoS): An attack that prevents authorized network, application, or system functionality by intentionally disrupting services.
- Malicious Code: Successful installation of malicious software (e.g., a virus, worm, trojan horse, or other code-based malicious entity) that infects an operating system or application, excluding malware that has been successfully quarantined by antivirus software.
- Improper or Inappropriate Usage: When an individual violates acceptable computing policies.
- Suspected PHI Breach: If an occurrence involves PHI, it must be reported, even if just suspected.
- Suspected Loss of Sensitive Information: An occurrence that involves a suspected loss of sensitive information (not personally identifiable information) that occurred as a result of unauthorized access, malicious code, or improper (or inappropriate) use, where the cause or extent is not known.
- Know your environment
When establishing effective incident response plans, it’s important to know your environment, not just within your organization (and your various locations and vendors), but also what’s happening within your industry.
Be sure to keep apprised of alerts and read relevant (and trustworthy) industry news about potential incidents and disruptions.
While your incident response lifecycle can help you learn more about maturing your plans based on what you learn within your organization, you can also build stronger plans by reviewing what other organizations have experienced, how they responded, what worked, and what didn’t.
- Don’t silo incident response
When it comes to incident response, plans often reside with information security or cybersecurity teams. That means, in many cases, those team members bear response responsibility, even if the incident goes well beyond their areas of expertise or requirements.
That’s why it’s important to not silo your incident response within a single team or department. Instead, establish a cross-functional incident response team (IRT) to ensure core areas of responsibility and ownership are represented.
And don’t limit your IRT exclusively to your internal team members. For some response types, you may also need input and support from external stakeholders, for example, board members or your third-party vendors. A cross-functional team can ensure an integrated strategy for your incident response plans.
Here are some members to consider for your IRT:
- Privacy officer and security officer
- Human resources manager
- Legal counsel
- Senior management
- Board of directors
- Internal investigator(s)
- Affected system or operations representative(s)
- Marketing
- Public relations
- Finance/accounting representative(s)
- Call center operations
- Other departments/people deemed appropriate
Once you’ve determined the right representation for your IRT, here are some key responsibilities to tackle:
- What happens when the incident rises to the level of a breach?
- Who conducts the breach risk assessment?
- Who notifies affected individuals?
- Who notifies HHS OCR?
- Who notifies the media, if applicable?
- Who notifies state agencies, if required?
- What happens when OCR investigates?
- Understand the core components of an effective incident response plan
Earlier, I shared the importance of your incident response plan aligning with NIST’s incident response lifecycle. Now, let’s take a closer look at each of these and how they might apply to your organization:
- Preparation: Maintain and improve incident response capabilities to minimize the likelihood of occurrences through effective management of third-party hosting services, systems, networks, applications, and processes that ensure the confidentiality, integrity, and availability of data
- Detection: Once you’ve determined an incident has occurred, what steps will you take to confirm, classify, and prioritize the response? Here are a few common ways incidents may be detected:
- Reporting by a workforce member
- Intrusion detection system/intrusion prevention system
- Monitoring, such as a security information and event management (SIEM) system
- Endpoint protection, for example, the ability to lock down laptops, smartphones, tablets, and other devices once you discover an incident
- Triage: Your initial triage stage will determine the incident severity and response level and help you establish priorities for the next steps.
- Incident Analysis: Seek out indicators of compromise to determine the root cause and establish appropriate actions for resolution
- Containment, Eradication, and Recovery
- Containment: Isolate or mitigate the affected system to contain what is occurring or prevent it from flowing outward. The goal is to limit the degree to which the incident can harm your organization and systems. Don’t forget about evidence gathering here. Evidence gathering is critical in preserving the chain of custody, which may be required as part of self-reporting or external investigation into your incident.
- Eradication: Remove threats. This is where you identify and mitigate vulnerabilities or other security issues, including removing latent threats such as malware, identifying and mitigating potential vulnerabilities or misconfigurations, and identifying other hosts that may be affected.
- Recovery: Incident analysis for procedural and policy implications. Gather metrics and incorporate lessons learned into future response activities and training.
- Remediation: Post-occurrence repair of affected systems, communication, and instructions to affected parties, including analysis that confirms you’ve contained the threat. Also, monitor and/or audit systems to ensure mitigation and remediation plans are in place, are working, and are effective. Be sure to detail related disciplinary actions for team members and document all needed changes for your existing policies and procedures with a plan to make those changes.
- Post-Incident Activity and Review: This happens after detection, analysis, containment, eradication, and recovery. Your goal is to review your response to determine what you can do to better respond to similar situations in the future.
- Dust off your shelf
Incident response is not a “one-and-done” process. To remain resilient, you’ll need to continually review, adapt, and improve your incident response protocols. One way to do that is to routinely unpack your plan, pull it off the shelf, and put it to the test.
Here are a few ways you can test your incident response plans:
- Paper test: A detailed walk-through includes validating your vendor call and notification lists and reviewing end-user procedures.
- Tabletop exercises: Review your response plan to determine how effective your plan is for responding to various scenarios.
- Technical restoration activities (including alternate site activities): For example, can your team access previous backups to restore systems if you experience a data loss? You could also test your team’s ability to switch specific operations from your primary site to an alternative site and back again to determine if you can effectively respond and maintain operations for critical systems and services.
- Supplier facility and or service tests: Conduct tests in conjunction with vendors to ensure both you and your vendor respond as you’ve determined in your vendor agreements, BAAs, SLAs, etc.
- Come full circle and do it again
I mentioned a few times how important it is to align your plans with the incident response lifecycle. That’s because effective incident response is an ongoing process and to remain resilient, you must come full circle with continuous planning, reviews, testing, and updates.
Those post-incident activity reviews we’ve talked about are key to driving your plan success and adopt improvements. You can also use those results to also help improve your strategies for employee training and both internal and external communication strategies. By reviewing your lessons learned, you can continuously mature your incident response strategies to decrease disruptions and downtime and improve operational resiliency.
Do you need help developing a framework to implement an incident response plan or mature your existing practices? Connect with a Clearwater advisor or visit our resource library for more information.
