Free Privileged Account Discovery Tool: Identify & secure credentials to stop lateral movement. Download Free

BeyondTrust
  • Products
    Privileged Password Management
    Discover, manage, audit, and monitor privileged accounts
    Password Safe DevOps Secrets Safe
    Endpoint Privilege Management
    Manage privileges on Windows, Mac, Linux, and Unix endpoints
    Windows and Mac Unix and Linux Active Directory Bridge
    Secure Remote Access
    Centrally manage and secure remote access for service desks and vendors
    Remote Support Privileged Remote Access
    BeyondInsight Analytics
    See All Solutions
  • Resources

    Universal Privilege Management

    Our innovative Universal Privilege Management approach secures every user, asset, and session across your entire enterprise.

    Watch Video

    Learn

    Case Studies
    Competitor Comparisons
    Datasheets
    Glossary
    Product Demos
    Whitepapers

    Attend

    Events
    Go Beyond
    Training
    Webinars

    Support

    Changelog
    Professional Services
    Technical Documentation
  • Blog
  • Partners
  • Contact
  • Support
  • Services
  • Training
  • Events
  • Company

Is Your Incident Response Plan Actually Effective?

August 29, 2017

  • Blog
  • Archive

Incident Response Plan

As a security professional, I have seen a wide variety of best practices for incident response. The methodologies vary greatly based on the sensitivity of the data, requirements to notify law enforcement. Plus, the incident plan can differ dependent on where the services are located — with third parties, on premise, technologies or to hosted in the cloud.

Best practices recommendations exist everywhere from non-profit security organizations through regulatory compliance initiatives, but all suffer from the same problem — they are too painfully high-level to actually execute.

Every one of the standards will recommend having an incident response plan, assign roles and responsibilities, preserve critical log information, notify law enforcement, and prioritize restoration of services. Sounds great…but how?

This may sound innocuous, but creating an incident response plan is one thing, while actually using it effectively without a fire drill is a completely different enigma.

This is the focus of this blog: how do you take your incident response plan, regardless of its maturity, and actually make it effective? The answer? Periodic role playing and practice much as with regular vulnerable assessments and penetration testing.

To get started, first ask yourself how often you have fire drills at your office or even at home. You probably have the former at least once a quarter, but rarely do you ever practice fire safety at home — let alone tell your children what to do if there is a fire. This is the first step in exercising an incident response plan.

Typically, these plans require you to call out the roles and responsibilities for all the team members involved, but do they actually know what to do? Do they know what to do when the incident happens while someone is on vacation, in the middle of the night, or during a holiday? Who are their backups?

This may sound like a procedure maturity issue, but all too often these procedures call out executives and various team members, while they themselves are unaware of their roles or what their tasks and responsibilities are.

This is why when practicing an incident response plan, it is so important to reference their participation, including any context aware variables that may affect the plan outside of business hours. The results, good and bad, should obviously be re-rolled back into the plan. But…that’s a different problem we will discuss later.

A second problem is controversial and revolves around transparency. How much information should you disclose internally, to team members, and to the press or law enforcement?

During practice exercises, hypothetical scenarios should always include some form of catastrophic use case. This could include access to crown jewels, or data leakage that could be a game over event for the business, and include aspects that may have human liability, such as illicit photos or behavior.

Why? Teams need to learn how to communicate this information between each other in order to successfully navigate an incident response plan. The team also needs to understand what information not to share, duplicate, or make available outside of a secure and trusted inner circle.

For example, if you are building a component for a government contract, and there is a suspicion that designs have been inappropriately accessed, sharing the blueprints with incident team members is inappropriate.

The data may have been privileged before the incident and the policy for its control must continue to be monitored and adhered to during an incident response. Just because it may have been leaked does not remove existing security procedures, and teams need to learn how and what to communicate.

The same would be true for credit card or other personally identifiable information. Just because it may be leaked does not mean the files should be treated with any less security moving forward, including putting the data on an insecure share for preservation.

Teams need talk about... what can and what can’t be said? What can be share and what can’t be shared? Data transparency during an incident needs to be considered during the social aspects of any response plan.

One of the primary goals after any incident is to return to a normal operating steady state. The criteria may include remediating systems, restoring backups, and preserving logs and files suspected of having been manipulated during an incident.

The human factor for role-playing is time-dependent. Based on a catastrophic incident as the worst-case scenario, teams need to consider how long the restoration times of services may take, including collecting cyber forensic information.

Without an effective role-playing implementation, an hour-long meeting in a conference room to review an incident response plan will never reveal the true pain of an outage that could last days if domain controllers, virtual instances, and infrastructure need to be restored.

The business may want to leverage disaster recovery procedures or high availability options as a method to mitigate lost revenue during an incident. This exercise obviously touches more team members outside of the core incident response team and only emphasizes the first concern in this blog: roles and responsibilities.

Incidents may have associated outages and then again, they may not. Planning, role-playing, and practice exercises should consider the worst case, assuming an environment may need to be completely rebuilt. If you think that is never possible; ask someone who has ever had a domain controller compromised or been a victim of ransomware.

The final piece of any incident response plan and practicing it is self-improvement. Creating a plan, never testing it, and filing it away so you can check the box on a regulatory compliance form is just pathetic.

We have fire drills for a reason. We need to learn how to survive when a life-threatening event occurs and cyber security incidents can be life-threatening to the business, your job, and depending on your line of work, the country or well-being of others.

Please do not misunderstand my message. I am not suggesting war games. I am suggesting actually following your incident response plan in a mock scenario and on a periodic basis to ensure that people know what to do, how to do it, and what to say. Then, anything that works, fails, or needs clarification gets baked back into the plan until the next scheduled practice.

This scheduled practice should match up to existing policies for penetration testing, cyber security awareness training, and may involve red and blue teams for the sake of realism.

Incident response plans need to evolve past being a documented procedure. They need to be a working part of any business and the success of the plan measures with appropriate metrics for response time to loss of services and revenue.

While this might not always be the case, and the incident may be trivial, the potential for a catastrophic incident can happen to any organization.

Reading a manual for the first time when it happens is never a good way to manage the crisis. This is why we have fire drills.

Other Suggested Reading:

Security Emergency Preparedness: Planning for the Next (Inevitable) Cyber Attack (on-demand webinar)

How to Access Privileged Passwords in ‘Break Glass’ Scenarios (white paper)

Break Glass Theory: Designing a Break Glass Process to Provide Security for Privileged Accounts (on-demand webinar)

Morey J. Haber

Chief Technology Officer and Chief Information Security Officer at BeyondTrust

Morey J. Haber is Chief Technology Officer and Chief Information Security Officer at BeyondTrust. He has more than 25 years of IT industry experience and has authored four Apress books: Privileged Attack Vectors (2 Editions), Asset Attack Vectors, and Identity Attack Vectors. In 2018, Bomgar acquired BeyondTrust and retained the BeyondTrust name. He originally joined BeyondTrust in 2012 as a part of the eEye Digital Security acquisition. Morey currently oversees BeyondTrust strategy for privileged access management and remote access solutions. In 2004, he joined eEye as Director of Security Engineering and was responsible for strategic business discussions and vulnerability management architectures in Fortune 500 clients. Prior to eEye, he was Development Manager for Computer Associates, Inc. (CA), responsible for new product beta cycles and named customer accounts. He began his career as Reliability and Maintainability Engineer for a government contractor building flight and training simulators. He earned a Bachelor of Science degree in Electrical Engineering from the State University of New York at Stony Brook.

Stay Up To Date

Get the latest news, ideas, and tactics from BeyondTrust. You may unsubscribe at any time.

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

You May Also Be Interested In:

Webcasts | February 25, 2021

Customer Tips & Tricks: Remote Support for Android

Webcasts | February 09, 2021

Customer Webinar: Remote Support 21.1 Released!

Webcasts | February 24, 2021

Your PAM 2021 Blueprint: Securing Privileged Accounts for On-Premises and Cloud Assets

BeyondTrust Logo
  • Facebook
  • Twitter
  • LinkedIn

Keep up with BeyondTrust

I agree to receive product related communications from BeyondTrust as detailed in the Privacy Policy, and I may manage my preferences or withdraw my consent at any time.

Customer Support
Contact Sales

Products

  • Endpoint Privilege Management
  • Password Management
  • Privileged Remote Access
  • DevOps Secrets Safe
  • Remote Support

Resources

  • Blog
  • Case Studies
  • Competitor Comparisons
  • Datasheets
  • Glossary
  • Videos
  • Webcasts
  • Whitepapers

About

  • Company
  • Careers
  • Contact
  • Events
  • Leadership Team
  • Partner Program
  • Press

Languages

  • English
  • German
  • French
  • Spanish
  • Korean
  • Portuguese
  • Japanese
  • Privacy
  • Security
  • Manage Cookies
  • WEEE Compliance

Copyright © 1999 — 2020 BeyondTrust Corporation. All rights reserved. Other trademarks identified on this page are owned by their respective owners. BeyondTrust Corporation is not a chartered bank or trust company, or depository institution. It is not authorized to accept deposits or trust accounts and is not licensed or regulated by any state or federal banking authority.