There is no such thing as perfect cybersecurity, so as business and information security professionals, we accept that mistakes will occur, and risks will exist. Your business is on a journey to scale, and in turn your security program will continue to evolve. But, and it’s a big BUT, that doesn’t mean we shouldn’t develop robust strategies, harden your defenses and prepare for emergency incident response situations. It’s your responsibility to take proactive steps to ensure your team, and entire organization are prepared to address a serious security breach or incident.
While you’re considering your emergency preparedness plans, keep in mind the top 5 mistakes to avoid in digital forensics and incident response (IR) that every IT leader should know…
1 . Having incomplete preventative measures in place
A comprehensive cybersecurity and incident response plan requires specialized expertise, organizational commitment, disciplined personnel and layers of modern tools to provide defense in depth. But even sophisticated organizations can make mistakes when creating an incident response plan like failing to consider and cover the entire threat surface, intentionally or inadvertently maintaining out-of-scope devices, keeping services externally exposed, treating insecure behavior from executives as necessary exceptions or simply introducing defense solutions too slowly.
Incomplete implementations of tools and allowing exceptions without compensating controls lead to issues within environments.
When developing your incident response plan, ask yourself:
- How are we monitoring the health and hygiene of our security stack?
- Have we made compromises when it comes to multi-signal coverage?
- Do we have any key cyber projects or implementations on hold? Why?
2. Thinking a cybersecurity incident won’t happen
The unfortunate reality is that at some point you’ll have to deal with a malicious event or full-blown cybersecurity incident. Maybe configuration or patching issues will leave gaps, a laptop will be misplaced, a phishing attempt will succeed, or a sophisticated attack will break through.
The prudent approach to risk management is to accept this unwelcome truth and prepare your organization, because with the right processes and systems in place you can at least limit the frequency, reduce the magnitude and be aware of cybersecurity incidents. (What you don’t know most definitely can hurt you.)
Ask yourself:
- Have we identified gaps with penetration tests or undergone a red team operation recently?
- Do I have 24/7 eyes on glass across my environment to identify cybersecurity threats?
- What is our capability in terms of digital forensics and incident response, should an incident occur?
3. Moving too slowly after a security breach
Time is of the essence when a cybersecurity incident occurs. Delays negatively impact containment and recovery activities and can give threat actors time to destroy evidence. Failing to have an incident response provider at the ready and decision paralysis are two major causes of delays that impact an organization’s ability to respond to a cybersecurity incident.
Not having an Incident Response Provider on Retainer
Having an Incident Response provider, on retainer, ensures you have someone to call when an incident occurs, and you have an incident response playbook in place that you can follow.
The alternative requires you to pick up the phone, reach out to different providers, initiate conversations and negotiate contracts and legal terms during a period of time characterized by chaos and panic.
Decision paralysis (and failure to execute the incident response plan)
It is crucial during incident response to designate someone within your organization with sufficient decision-making authority to enable and enforce timely responses. Avoid committees, as they create dangerous delays and lead to very conservative, least-objectionable thinking at a time when decisiveness is paramount.
Additionally, ensure the designated person is willing to make potentially tough decisions (for instance, taking customer services offline to contain an incident) and has real authority within the organization. An incident is not the time to debate power dynamics and to get pulled into political discussions, nor is it the time to discover that people feel empowered to disobey the instructions because they came from the “wrong” person.
Ask yourself:
- Does your organization have the internal capability to address the full scope of a security breach and if not, have you engaged a third party on retainer for Digital Forensics and Incident Response support?
- Does your organization have an up-to-date emergency preparedness and incident response
plan?
- Who is your internal lead based on your incident response policy should an incident occur?
4. Not knowing your regulatory and contractual obligations
Industry and regional regulations as well as contractual notification requirements impose specific obligations upon your organization, and it’s crucial you understand them.
Automatically or incorrectly labeling an incident as a “breach”
In any relevant agreement, or piece of regulation, a “breach” should be defined with legal and contractual meaning, as well as implications. An incident should not be labeled as such until the specific conditions are met. Again, it’s important to understand the regulatory and contractual requirements you must abide by, and be consistent in your approach, so you can reserve the term “breach” for incidents that meet the criteria, thereby avoiding unnecessary notifications and consequences.
Furthermore, your Incident Response plan should clearly identify who within your organization has the authority to label an incident a breach.
Not knowing your notification requirements
Failing to properly understand your notification requirements can lead to two follow-on mistakes:
- Failing to send a notification when you were obligated to do so
- Sending a notification when you were not obligated to do so
Both mistakes can cause significant damage. To avoid such errors, your organization needs to be keenly familiar with two sets of notification requirements relating to cybersecurity incidents:
- Regulatory body and government regulations: Bloc-, federal-, state- or provincial-level laws and statutes (for example, GDPR and PIPEDA) governing notification requirements and timelines, including when you are required to notify or involve law enforcement agencies
- Contractual obligations: Upstream and downstream commitments to notify suppliers and customers
While many security breach notification regulations and requirements contain similar components, there can be important differences. Keep in mind, as security breaches rise in frequency and prominence, regulations and contractual obligations are changing, which requires organizations to stay up to date.
Ask yourself:
- Do you know which regulatory requirements you need to adhere to based on your industry and region?
- What are your notification requirements?
- In the event of a breach are your contractual obligations with customers and suppliers consistent and how are they documented?
5. Mishandling evidence
Digital forensics evidence is vital to many aspects of Incident Response and litigation support. Inadvertent destruction of evidence and preventing the incident responder from accessing evidence are two common challenges that hamper incident response.
Destroying the evidence
In the rush to contain and clean up a cybersecurity incident, it’s common for well-intentioned personnel to destroy the digital forensics evidence (for instance by rebuilding compromised assets). Unfortunately, doing so eliminates crucial information that the incident reponse team needs to perform digital forensic analysis, to determine the full incident scope and to complete their end-to-end incident management.
Make sure the division of responsibilities between your internal team and your IR provider is clear, and unambiguously identify who has the authority to make decisions that can impact evidence. That way, you won’t accidentally destroy information your incident responder needs to fulfill their role.
Blocking access to evidence
During the course of IR, it’s entirely possible that your Incident Response provider will need access to sensitive systems and information. For example, in the case of a business email compromise an Incident Responder may require complete access to your email systems (Office/Outlook, Gmail, etc.).
To prevent confusion during a cybersecurity incident, it’s important the Incident Response procedures clearly explain which systems the IR provider can access and to ensure that all personnel involved (for instance, the email administrator) are aware.
Ask yourself:
- If you have an Incident Response provider on retainer, have you set clear roles and responsibilities in the event of a breach?
- Does your team understand what NOT to do in the event an incident occurs, so they don’t inadvertently destroy digital forensic evidence or slow an investigation?
- Who are the internal stakeholders that will need to provide administrative support or permissions in the event an incident occurs?
—
Cybersecurity incidents can compromise personal and business data, severely impact operations and lead to legal consequences. When an incident occurs, it’s not the time to start planning. Or panicking. It’s imperative your organization plan ahead and establish a comprehensive Emergency Preparedness plan, outlining your Incident Response playbooks.
Both Managed Detection and Response (MDR) and Incident Response (IR) services are vital parts of an overall cybersecurity program, augmenting your response capability, and ensuring your organization can detect, respond to and recover from incidents.
To learn more about how eSentire’s Managed Risk Program and Managed Detection and Response services can better prepare you for a cybersecurity incident, contact us https://www.esentire.com/get-started.
