Skip to content

Securing the Future of Work: Agent Behavior Analytics with Google Cloud — Read the Blog

How to Quickly Deploy an Effective Incident Response Policy

  • Sep 07, 2018
  • Luke Voigt
  • 4 minutes to read

Table of Contents

    Almost every cybersecurity leader senses the urgent need to prepare for a cyberattack. If you haven’t already, most likely you’ll want to deploy an effective incident response policy soon, before an attack results in a breach or other serious consequences. Creating an effective incident response policy (which establishes processes and procedures based on best practices) helps ensure a timely, effective, and orderly response to a security event. In this blog, you’ll learn how to jumpstart the foundation of a good incident response policy that you can refine later to meet your organization’s unique needs.

    About this Explainer::

    This is part of a series of articles about Incident Response.

    Recommended Resource: Best SIEM Solutions: Top 10 SIEM systems and How to Choose.

    What is an incident response policy?

    In simplest terms, an incident response policy:

    • Defines the responsibilities of each member of your computer security incident response team (CSIRT).
    • Documents mobilization procedures for security team members across your organization. This includes:
      • “Who” should be involved (CSIRT in this case)
      • “What” responsibilities each involved party has
      • “How” you mobilize and “When” you mobilize each involved party
    • Creates a well thought out plan to avoid decisions being made in the heat of battle. It describes systematic steps to take when an incident is detected. Preventative measures such as implementing threat modeling help ensure your organization understands the likely threat scenarios. And such a plan lays out incident prioritization. This is based on relevant factors such as the critical business systems that may be impacted, or the potential for a data breach.
    • Establishes plans for the rapid recovery of systems impacted by an incident to ensure business continuity. This includes when to escalate to stakeholders such as when do you loop in IT, Corporate Security, and Legal?
    • Defines procedures for communicating the impact and status of any given incident across the organization. This includes when should you involve HR or Corporate Communication as well as when you need to disclose a breach externally.

    Jumpstarting a policy that covers the entire incident response lifecycle

    Your incident response policy helps your organization systematically handle the entire lifecycle of a security event. This includes containment and recovery, assessing the aftermath, and the subsequent incident prevention. Because every organization is different, tailor your policy to your unique business and technical situation—including how to deal with unique threat scenarios.

    Your initial policy doesn’t need to be comprehensive. The risk of not having a policy in place before a cyberattack is too great, so roll out a good foundational one as soon as possible. At a minimum, your initial policy should focus on the key phases of a security incident:

    Prepare

    Prevention is still the best weapon against cyber threats. This phase establishes procedures for understanding cybersecurity risk to your organization’s systems, personnel, assets, data, and capabilities. It regularly identifies resources that support critical business functions and cybersecurity risks that could impact them. It should also identify tools and resources that will be critical during an incident. This phase helps you prioritize your team’s efforts to align with your defined risk management strategy and business needs.

    Protect

    Next, you need to implement effective measures to ensure the delivery of critical services. This phase supports your ability to limit or contain the impact of a security incident. It includes developing guidance on isolating affected systems to contain an incident and prevent damage to other systems.



    Figure 1: Security Incident Response Policy phases with feedback and backward loops to other phases: Further detection and analysis in the Recover phase to learn if additional hosts are infected and need to be taken offline.

    Detect

    Your policy should include procedures to identify security incident occurrences. NIST states the Detect phase should provide timely discovery of anomalies and events, provide continuous security monitoring, and include detection processes.

    Respond

    Your incident response policy should detail actions your team will take when a cybersecurity incident is detected. This component covers response planning, communication, analysis, and mitigation. It should cover “which” incidents to prioritize (consider SLA time based on prioritization). It also includes the creation of a cybersecurity incident response checklist, which helps you better prepare for a security incident and ensure your response plan is both complete and up-to-date.

    Recover

    Downtime of critical systems such as a corporate website can have devastating consequences. Your policy should implement required actions to make systems resilient and to restore capabilities or services impacted by a cybersecurity incident. This includes identifying and mitigating all vulnerabilities that were exploited.

    This phase includes eradicating the incident (for example) by removing malware, inappropriate materials, and other attack components. It may also include containment such as undertaking further detection and analysis to learn if additional hosts are infected and need to be taken offline.

    The key recovery activities for your policy include how to:

    • Return affected systems to an operationally ready state.
    • Confirm that affected systems are functioning normally.
    • Implement additional monitoring (if necessary) to look for future related activity.

    Prevent

    This post-incident phase includes documenting the incident, investigating its cause, and calculating how much it cost your organization. For example, with malware—where an attack may have lasted for months and migrated laterally (e.g., an advanced persistent threat, or APT)—this could include analysis of the entire event lifecycle.

    After completing this phase, your policy should require 1) holding a “lessons learned” meeting and 2) issuing a strategy report aimed at preventing similar incidents in the future.

    For the next stage of your incident response development, the NIST Cybersecurity Framework is a great resource for  your comprehensive policy development.

    Want to learn more about Incident Response?
    Have a look at these articles:

    Luke Voigt

    Luke Voigt

    Vice President, Field Engineering | Exabeam | Luke Voight is the Vice President of Field Engineering at Exabeam. He has over fifteen years of professional experience in security architecture, analytics, intelligence, incident response, and system administration. Prior to joining Exabeam, he was a Senior Security Engineer at Anadarko Petroleum Corporation. He has a Master of Science in Information Assurance and Security from Sam Houston State University.

    More posts by Luke Voigt

    Learn More About Exabeam

    Learn about the Exabeam platform and expand your knowledge of information security with our collection of white papers, podcasts, webinars, and more.

    • White Paper

      Using MITRE ATT&CK® in Threat Hunting and Detection

    • Podcast

      Are You Relying on the Right Tools?

    • Blog

      Can You Detect Intent Without Identity? Securing AI Agents in the Enterprise 

    • Blog

      Securing the Future of Work: Agent Behavior Analytics with Google Cloud

    • Brief

      Exabeam and Google Cloud: Securing AI Agents and LLM Usage With Behavioral Analytics

    • Data Sheet

      Exabeam Success Services

    • Show More