Incident Response Archives

As of 2022, 83% of organizations have had more than one data breach, costing those organizations millions of dollars in damages. In today’s cyber-landscape, companies are no longer wondering if they will ever experience a breach but when a breach will occur.

Developing an Incident Response Plan is imperative for when an organization thinks they may have experienced a data security breach or security incident. One of the most important aspects of incident response is the collection and evaluation of evidence. Just because a laptop computer seems to be missing, the organization does not have conclusive evidence that they have actually suffered a data security breach. So, when an organization believes they have experienced a security incident, the incident must be carefully evaluated, following a professional, disciplined approach to gathering and evaluating evidence, to conclude whether or not a data breach has occurred.

It’s often wise to ensure that all of the details of any investigation into a data breach are maintained as confidential. Keep in mind that your legal adversary may disagree with your own evaluation of the security incident and evidence. So, when an organization is conducting an incident response plan, ensure that all the investigators have signed an appropriate non-disclosure agreement, and to have legal counsel engaged in the investigation. Often times, if counsel is involved in the investigation, they can cloak the investigation into something known as an attorney work product. This is very similar to attorney-client privilege, and a form of confidentiality that is enforced in law.

Once you’ve conducted your incident response plan, gathered and evaluated all necessary evidence, you may then determine if a security incident has occurred, and the appropriate next steps for responding to the incident.

To learn how KirkpatrickPrice can help you with your compliance objectives, contact us today!

What is an Incident Response Plan?

An important part of the incident response when an organization thinks it might have a data security breach is the collection and evaluation of evidence. Just because a laptop computer can’t be found, for example, doesn’t necessarily mean that the organization has conclusive evidence that it has in fact suffered a data security breach for which it must give notice of under different kinds of laws. Therefore, as an organization sees that is has an incident that needs to be evaluated more carefully, the organization is wise to follow a professional, disciplined approach to gathering evidence and then evaluating that evidence to conclude whether if in fact a breach has occurred for which your organization needs to give notice.

An important factor to bear in mind as your organization conducts an incident response is that the legal adversary of the organization may disagree with the organization’s own evaluation of the incident and the evaluation of the evidence. For example, a legal adversary could be a class action plaintiff’s lawyer or it could be a government regulator. These adversaries, if they were able to gain access to the organization’s full investigative details, might say, “Wait, you had all of this information that shows that you had a breach and that you should’ve given notice, therefore, you’re bad and we should sue you or punish you.” On the other hand, from the point of view of the organization, the organization may actually review the same evidence and conclude, “No, there was not a breach under the law, therefore we should not have given notice.”

So, here’s the point: when an organization is conducting an incident response, it’s often wise to ensure that all the details of that investigation are maintained as confidential. Ways to maintain confidentiality would be 1) ensure that all of the investigators have signed an appropriate nondisclosure agreement and 2) your organization may be wise to actually reach out to legal counsel and have legal counsel engaged in the investigation. Often times, if counsel is involved in the investigation, then counsel can cloak the investigation into something that’s known as an attorney work product. An attorney work product is very similar to an attorney-client privilege. It’s a form of confidentiality that can be enforced in law, so if an attorney is substantially involved in incident response and evidence is collected, and the organization doesn’t want the results of the investigation’s evidence to go to legal adversaries, the attorney work product doctrine will help the organization achieve that goal.

There were many missteps that led to the Capital One breach, but what’s the one thing that went as planned? From our perspective, Capital One’s incident response plan seemed to function as intended. Incident response is incredibly important following a breach – that’s why having a plan and team in place is required by so many information security frameworks. The data proves the importance of incident response plans as well. IBM’s 2019 Cost of a Data Breach reports that organizations with an incident response team and extensive testing of their plans could save, on average, about $1.2 million on the typical data breach. In Capital One’s case, though, this incident will cost $100 to $150 million in 2019 alone. Is developing and testing an incident response plan worth millions to your organization?

Capital One’s Incident Response Plan

The Justice Department’s Compliant includes the report that was submitted to Capital One’s Responsible Disclosure program on July 17, 2019. By the end of that month, Capital One announced the breach to the public and explained what they knew, the mitigation work they’d already performed, and which customers were impacted.

From Capital One’s announcement, we can determine they took the following steps to validate and mitigate the reported findings:

Immediately fixing the configuration vulnerability
Working with the FBI to arrest the person responsible
Determining exactly what type of information was compromised and how many individuals in the US and Canada were impacted
Performing an analysis to determine if the information was shared or used for fraud
Notifying customers
Answering FAQs like: What was the vulnerability that led to this incident? When did this occur? Was the data encrypted and/or tokenized? Did this vulnerability arise because you operate on the cloud?
Making information about the incident available on their online and easily accessible

When a household name like Capital One has a major breach, it makes headlines for years. There are major legal and regulatory ramifications for Capital One to answer to, but as far as basic incident response goes, we admit that Capital One seems to have had a thoughtful, tested incident response plan. This was vital in reassuring the public that, even though their AWS configurations had a vulnerability, Capital One knew how to handle the situation.

The key to an incident response plan is testing it in tabletop exercises, employee training, and other scenarios to determine if it will actually work. When organizations go through information security audits, their auditor will have high standards for the plan and the testing of the plan. What would’ve happened if Capital One wasn’t prepared to react to this incident? Would data have been used for fraud or compromised even further?

6 Steps to Incident Response

With today’s threat landscape, it’s not a matter of if your organization will fall victim to a cyberattack or data breach, but when it will happen. We believe basic incident response plans should have six steps:

Preparation – What are we doing to prevent an incident? How are we limiting the impact of an incident? Have we tested our policies and procedures?
Detection & Identification – How would we identify and detect malicious activity? How do we report an incident?
Containment – Has the appropriate personnel been notified? What evidence should be collected? Have we fully assessed the scope of the damage? How can we prevent further damage?
Remediation – Has a complete forensic analysis been performed? Can we make changes to prevent a repeat incident?
Recovery – Have we securely restored the system? Do we have continuous monitoring to ensure the problem is resolved?
Lessons Learned –What gaps can we now identify? Have we regained customer confidence? Have we reviewed controls and processes to prevent future attacks?

It’s not only up to IT to develop an incident response plan – many other areas of your organization will be involved, especially C-levels and boards of directors. In Capital One’s case, the CEO responded the public about the breach.

If your organization was breached, would your team know what to do? What would the headlines say about your incident response plan? Are you confident in your plan?

If you want to ensure that everyone at your organization knows their role in incident response, let’s talk today about how to train and test your incident response plan.

More Incident Response Resources

SOC 2 Academy: Incident Response Best Practices

Horror Stories: Timehop’s MFA Mishap

Breach Notification: Who, When, Why

When Disaster Strikes, Will You be Prepared?

To ensure that operations remain up and running during hurricane, tornado, or rainy seasons, businesses must have a Disaster Recovery Plan that has been developed, tested, and is in place and known to all relevant parties. Hurricanes like Matthew and Sandy have devastated businesses over the last couple of years, and without a well-developed Disaster Recovery Plan, many businesses were left inoperable, damaging their revenue and reputation.

What is a Disaster Recovery Plan?

So, what is a Disaster Recovery Plan (DRP)? Disaster Recovery Plans define an organization’s processes for protecting and recovering its business in the event of a disaster, such as a hurricane, flood, tornado, power outage, etc. These documented sets of policies and procedures can be the lifeline of an organization following a disaster, and determine loss of operations, reputation, and revenue. How will your organization stay running in the event of a disaster? Where will employees continue to carry out their work duties? How will incident response be communicated throughout your organization? These are the types of questions you should ask yourself when preparing for a potential disaster.

3 Steps for an Effective Disaster Recovery Plan

When it comes time to develop your Disaster Recovery Plan, there are three main steps to be considered, including:

Business Impact Analysis: The first thing your organization should do when preparing your DRP is to conduct a Business Impact Analysis. This process will allow you to review existing business continuity capabilities by evaluating the risk to business process failures, identify critical and necessary business functions and their resource dependencies, estimate any financial and operational impacts of disruption and the required recovery timeframe for critical business functions, and to assess the effectiveness of any existing risk reduction measures.

Strategy Selection: Once you’ve identified and prioritized critical functions for business continuity, the next step in the process is to determine which recovery strategy to move forward with. Identify a range of specific recovery strategies that address interruptions of business processes, identify the computing resources that are required to recover the various distributed processing environments, and document alternative recovery strategies.

Disaster Recovery Plan Documentation: It’s time to create your physical plan for responding to a potential disaster. This plan should include the following:

Emergency notification and disaster declaration procedures
Recovery team procedures
Facility and business restoration procedures
DRP testing and maintenance cycles
Appendices for master contact lists, equipment inventories, connectivity schematics, etc.

Once you’ve developed, tested, and disseminated your Disaster Recovery Plan, you can rest assured that you’ll be prepared if disaster strikes. For additional help on disaster recovery planning or for help with determining the effectiveness of your current Disaster Recovery Plan, contact us today.

More Disaster Recovery Resources

Business Continuity and Disaster Recovery Planning Checklist

Cloud Security: Business Continuity and Disaster Recovery Planning Checklist

What is Threat and Vulnerability?

Now, with more than 200 Phase 2 HIPAA desk audits completed, Devin McGraw, Deputy Director of the Department of Health and Human Services’ Office for Civil Rights, is encouraging healthcare organizations to take a look at lessons learned from the completed desk audits to prepare for future HIPAA audit enforcement.

Understanding and navigating HIPAA audit enforcement has been on the minds of healthcare professionals for several years. Many covered entities and business associates have struggled to know what to focus on and in which areas they are lacking safeguards. Devin McGraw made an exclusive address at HIMSS17 to share with the healthcare industry the top findings from the 2016 Phase 2 HIPAA audits.

Top 8 Lessons Learned from Phase 2 HIPAA Desk Audits

Let’s look at the top 8 lessons learned from the Phase 2 HPAA audits and make sure you have all of these things in place before you’re audited by the OCR.

Lack of Business Associate Agreements

HIPAA law mandates that you have a signed agreement in place with any contractor or subcontractor who is considered a business associate. This means any vendor or third party that has access to protected health information (PHI) is required to sign a contract pertaining to the protection and use of that PHI. This also applies to any business associates using subcontractors.

Incomplete or Inaccurate Risk Analysis

An incomplete or inaccurate risk analysis has still been a prevalent issue, mainly for organizations who are underestimating their full scope and leaving out major systems. Don’t forget that the HIPAA risk analysis is a risk-based, prescriptive approach to HIPAA compliance and should be step number one for any organization working towards HIPAA compliance. KirkpatrickPrice has published numerous resources for a step-by-step approach to performing a HIPAA risk analysis.

Failure to Manage Risk

Once your risks have been identified, it’s important to mitigate and properly manage those risks. If there are un-addressable risks, then be sure to document those and what you will be doing to manage those risks in the meantime and fully document your remediation plan. Risk management is a critical component of any information security program.

Lack of Transmission Security

Encrypt everything! Any and all electronic transmission of protected health information (PHI) MUST be encrypted. No exceptions. And as always, if there is something that for whatever reason is not addressable, then it needs to be formally documented along with ways that you are able to address and mitigate that particular risk.

No Patching of Software

We all saw the wake of WannaCrypt in the headlines this month and how not updating critical patches can lead to a devastating loss of business and operability. WannaCrypt targeted more healthcare organizations than any other kind of organization, so don’t learn this lesson twice! Patches must be up to date, as you will become an easier target with outdated software and patching. If there is a critical piece of software that you must use that comes with outdated patches, be sure you’re documenting that and what you are doing to address any associated concerns.

Insider Threat

Whether your organization is small or large, it’s always important to have employee termination policies clearly defined, in place, and to ensure that you’re following them. Do you remove employee access from terminated employees? Are you using default passwords that can be easily cracked? Don’t fall victim to insider threat.

PHI Disposal

What good are strong administrative and technical safeguards if you’re exposing the low-hanging fruit? Improper disposal of PHI was a common issue found in the Phase 2 HIPAA audits. Make sure you’re properly disposing of PHI and don’t leave anything available for dumpster divers.

Lack of Incident Response Plan

Another common finding from the Phase 2 HIPAA audits is insufficient backup and contingency planning. With the risks of ransomware, we must not only be focusing on prevention but also have an Incident Response Plan tested and ready to deploy if, and when, necessary. Regular data backups also go hand-in-hand with incident response as a way to help minimize the damage from a breach or malicious attack.

Preparing for HIPAA audit enforcement may seem like an overwhelming task. Start with a risk analysis and don’t forget these common 8 findings when developing your HIPAA compliance program. If you have any questions or would like help preparing for Phase 2 HIPAA audits, contact us today.