Lessons Learned from Capital One’s Incident Response Plan

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.

Capital One - Responsible Disclosure

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:

  1. 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?
  2. Detection & Identification – How would we identify and detect malicious activity? How do we report an incident?
  3. 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?
  4. Remediation – Has a complete a forensic analysis performed? Can we make changes to prevent a repeat incident?
  5. Recovery – Have we securely restored the system? Do we have continuous monitoring to ensure problem is resolved?
  6. 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

Horror Stories: Timehop’s MFA Mishap

On July 4, 2018, Timehop, a self-proclaimed “daily nostalgia product,” discovered a data breach where up to 21 million users were impacted. Timehop is a memory-sharing app, enabling users to distribute posts from the past; Timehop connects to users’ social networks and photo storage apps – Twitter, Instagram, Facebook, Dropbox, Google Photos, iCloud, etc. For them, this breach was a nightmare because of the nature of their services. When users saw the headlines about Timehop’s breach, I’m guessing the first thing that went through their mind was, “Are my social media accounts compromised?” This assumption, which led to user frenzy, was Timehop’s first obstacle. The company had to overcome this false narrative by being incredibly clear about what kind of data was breached.

Timehop’s MFA Policy: What Happened?

From the security incident and technical reports published by Timehop, we actually know a lot of details about this breach and the incident response plan. Timehop came straight out and admitted that the breach was due to a lack of appropriate MFA on access credentials, which resulted in network intrusion. Obviously many details of the incident couldn’t be released for security reasons, but Timehop did provide the public with a timeline of the event.

  • December 19-21, 2017: An unauthorized user used a legitimate employee’s credentials to access Timehop’s cloud computing environment and perform cyber reconnaissance.
  • April 4, 2018: The legitimate employee migrated user data into the database, generating the data that would become the target of the attack. Until this date, no PII was accessible to the attackers.
  • June 22, 2018: The unauthorized user discovered the user data, including PII.
  • July 4, 2018: The unauthorized user logs in and the attack occurs. Timehop’s internal alerting tools reported that the service was down, and Timehop engineers worked to restart services.
  • July 5, 2018: Timehop engineers began their investigation and declared that an incident had occurred when they recognized suspicious patterns. They immediately collected evidence, implemented MFA policies, secured the cloud computing environment, and then contacted law enforcement, Timehop’s Board of Directors, and the incident response team.

Fortunately for Timehop, the connection to users’ social networks was not compromised. They reported, “No private/direct messages, financial data, or social media or photo content, or Timehop data including streaks were affected. To reiterate: none of your ‘memories’ – the social media posts & photos that Timehop stores – were accessed.” The PII breached was fairly typical from that of most breaches these days – email address, dates of birth, name, gender, etc.

Lessons Learned from Timehop

Because of Timehop’s connection to users’ social networks, the company had to be very clear about what types of information were breached. In their security incident report, Timehop goes above and beyond the norm in order to be as transparent as possible. They state, “We commit to transparency about this incident, and this document is part of our providing all our users and partners with the information they need to understand what happened, what we did, how we did it, and how we are working to ensure it never happens again.” We believe that because GDPR was in effect at the time of this breach, it greatly impacted the level of detail they provided to users.

Timehop had an exemplary incident response approach. Within 2 hours of discovering the network intrusion, Timehop engineers responded to the event. From our standpoint, their incident response plan seemed to work as intended. Their plan included providing the public with access to the following:

  • Easy-to-understand information about the incident
  • A full timeline of the attack
  • Detailed information about the types of PII that were breached, including a distinction between breached data and breached GDPR data
  • A glossary of terms used in the reports
  • Answers to frequently asked questions
  • A technical report for those interested in technical details of the incident
  • Next steps for users to take

During the weeks after the incident, you couldn’t go to Timehop’s website without learning about the breach. Their social media announced the incident, plus the company dedicated a permanent landing page to host the information listed above. Timehop’s incident response approach has been extremely transparent and accessible, one of the most thorough that we’ve seen.

If your organization was breached, what would the headlines say about your incident response plan? Does your plan provide users or clients with accessible information about their data? Would you go above and beyond to be honest about the incident?

More Resources

7 Deadly Breaches of 2018 (So Far)

Rebuilding Trust After a Data Breach

What is an Incident Response Plan?

Shark in Water: 5 Things to Avoid a Costly Data Breach

Is your organization swimming in information security concerns? Recent and startling new malicious attacks are causing organizations to re-think everything we know about our security posture – from breach prevention to response. Organizations are beginning to shift their focus on security when they have realized that sometimes, compliance isn’t enough. With this “shark in water” reality, here are 5 things your organization should be doing to avoid a data breach.

  • Perform an Annual Risk Assessment

The number one thing all organizations should be doing is performing an annual risk assessment. Without this critical component of an information security program, organizations are left in the dark about where their assets reside, and what the risks to those assets are. How can you protect your critical and sensitive assets from a malicious data breach if you don’t know what you’re protecting them from? A risk assessment will help you identify all assets and prioritize risks based on an individual threat level. A formal, risk-based approach is key to any organization’s security posture, and should be the basis of your risk management program.

  • Create a Culture of Security

Calling all management, board of directors, and stakeholders! Information security auditors can’t stress enough how important it is to create a culture of security within your organization. The best way to accomplish this is by having a solid tone from the top. What does this mean? Upper-level management must understand the importance of information security and let this understanding permeate throughout the organization, all the way down to the operations level and beyond. An important way to ensure that all employees are aware of their security obligations is to develop and maintain a policy that addresses information security for all personnel, and conduct annual security awareness training programs.

  • Update Software and Install Patches

When WannaCry, the infamous ransomware attack, hit earlier this year, organizations were left scratching their heads in disbelief that it all could have been avoided if they hadn’t ignored a Microsoft software update. Why leave a known vulnerability open to attackers? Software updates are critical for preventing a data breach and safeguarding your sensitive data.

  • Closely Manage your Vendors

Most businesses today outsource critical business functions to third-party service providers. However, it’s important to note that it’s best practice (and often required by regulation) to perform due diligence by fully vetting your vendors to ensure they, too, are implementing appropriate and effective controls to protect your assets, and will not negatively affect the security of your organization. Even after you are contractually working with a third party, organizations should issue temporary passwords to any vendor connecting to your network, monitor and log all user activity, and immediately disable temporary vendor accounts after use. Doing so can help you detect any malicious activity promptly, and respond accordingly.

  • Know your Incident Response Plan

While organizations spend so much time focusing on how to keep malicious attackers at bay, sometimes they can overlook what they should do in the event of a breach actually occurring. Incident response plans are not only important when it comes to dealing with a flood or power outage. Don’t be caught with your sails down if your organization is compromised and ensure you have a fully developed incident response plan that has been both documented and tested. Organizations should have a designated team who is available 24/7 to handle any type of security incident. These teams must be fully aware of their responsibilities in the event of a data breach and undergo regular training. Here are the six steps of an incident response plan:

      1. Preparation
      2. Detection & Identification
      3. Containment
      4. Remediation
      5. Recovery
      6. Lessons Learned

In today’s cyber threat landscape, we’re swimming with sharks. So, remember, when compliance isn’t enough, focus on hardening your systems and fully developing your information security program. It’s never too late to re-think your organization’s security posture. If you’d like help with your security program or would like to see where your security posture currently stands, contact us today.

What Is an Incident Response Plan? The Collection and Evaluation of Evidence

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.

For more insights on data security, follow @BenjaminWright on Twitter. To learn how KirkpatrickPrice can help you with your compliance objectives, contact us today!

Video Transcription

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.

3 Steps for an Effective Disaster Recovery Plan

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:
  1. Emergency notification and disaster declaration procedures
  2. Recovery team procedures
  3. Facility and business restoration procedures
  4. DRP testing and maintenance cycles
  5. 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?