Do You Have an Effective Security Incident Response Plan? – Assess your Readiness

The Ponemon Institute has found that the survival rate for businesses without a security incident response plan is just 10%. Enterprises will often focus on creating a strong security posture to detect and thwart attackers, but fail to detail what to do if and when a breach actually occurs. That’s not unusual; it can feel defeatist to prepare for the worst. However, with new attacks being discovered all the time, and increasingly connected networks putting us all at risk, an incident response plan is essential.

1. Understanding the Consequences of Ignoring a Security Incident Response Plan

The first stage in your security incident response strategy needs to be recognizing the ramifications of an attack. From the obvious problems, such as asset and data breach, to reputational damage, compliance failures and public image breakdown, it’s in your company’s best interests to be fully prepared. Detailing these threats in writing can help your staff focus on maintaining a strong security posture to prevent attacks, and encourage everyone to work together with a mutual understanding of what’s at risk if the worst happens.

2. Assigning Roles Before an Emergency

Especially in large organizations, it can be hard to keep everyone in the loop when there is a crisis. Identifying the core stakeholders for a security incident before a breach occurs is therefore essential. Here are some key personnel who need to be detailed in your security incident response plan. In some cases they may be obvious, while in others you might need to choose staff to take on responsibilities for some of these roles in your cyber-security incident response team.

  • Incident response managers . It’s worth having at least two members of staff on hand who can oversee and prioritize the incident response plan, communicating information and tasks throughout the business.
  • Security analysts. Maintain the investigation, support the managers in following the plan, and filter out false positives. They may also alert others to potential attacks. It’s essential to ensure that they are given the right tools to be able to manage their role effectively.
  • Threat researchers. These personnel will be the port of call for contextual information around a threat. Using the web, as well as other threat intelligence, they can build and maintain a database of intelligence internally.
  • Key internal stakeholders. Who needs to be kept in the loop when a threat occurs? From board level personnel who may need to sign off on your actions or give the go-ahead for your response plan, to your CISO or human resources representative if human error is involved.
  • Third-party organizations, such as legal counsel, law enforcement, forensics experts or breach remediation companies.

3. Create a High-Level Document Outlining the Security Incident Response Procedure

Many organizations have multiple playbooks with granular detail on the technical side of an attack, in order to help IT manage and contain a breach. However, if you’ve ever experienced a security incident, you know that IT are far from the only department affected by an attack. Your incident response plan needs to be easily communicated and understood by C-suite employees, Human Resources, Vendor Management and all other lines of business stakeholders including global offices or teams in the field. As regulation increasingly dictates that customers are kept informed when their data is at risk, you may even need customer experience managers to be able to relay your position.

Some of the best security incident response plans are one or two pages, and give a high-level overview of how to manage the consequences of an incident. While playbooks might hold specific information for targeting a type of attack, such as Ransomware, your incident response plan should be written so that it can be read by anyone and understood easily in a moment of crisis.

4. Outline Response Priorities

Not every key stakeholder is going to have the same priorities when an attack hits, and not all priorities can be taken into consideration. For example, your board might want to get your operations up and running as quickly as possible, while legal counsel may suggest staying offline until vendors have been notified or customers contacted. Without a clear outline of whose priorities take precedence, existing relationships can dictate what procedure is followed after a breach, following tribal knowledge rather than smart decision making.

Assessing the scale of an attack and making quick decisions about revenue over security for example should not be done in the moment, or by whomever has the ear of the CISO that day. While you’re building your incident response plan, think about who should have autonomy over decisions that manage risk, and engage them in creating priorities based on levels of threat.

Detailed performance objectives can help here. In the event of a customer data breach, your security team might be tasked with finding out what has been exposed and how many customers are affected within a given amount of time. Making smart decisions about the action needed before a problem becomes a reality means all relevant teams can hit the ground running.

5. Simulate Breaches to Troubleshoot in a Safe Environment

Having an incident response plan is not enough in and of itself. Without testing and simulation, there is no way to recognize gaps in protocol or resources, or to uncover changes in third-party procedure. Regular simulations can ensure that your security incident response strategy remains up to date and nothing falls through the cracks. This can include finding replacements for staff who took on security roles and have now left the company, or for external vendors with lapsed service agreements. It can also help you keep up with changes in regulation, and keep new staff informed of the process in case of a breach.

A simulation can be as in-depth as you would like and can range from table top exercises to injecting your system with a known and containable malware, but a few basics to cover include:

  • Going over the lines of communication from detection to resolution
  • Understanding who is authorized to make decisions on security and risk
  • Confirming you have the third-party services in place you need to control a breach
  • Who needs to be contacted in case of a breach for continued regulatory compliance/operations?

The more you make simulation and testing part of your usual security posture, the more likely it will be second nature for the relevant stakeholders when the incident is no longer theoretical.

6. Identify the Scope of a Breach

Many companies act too quickly when they see a threat. Failing to recognize the size of a breach can cause more problems in the long run. Finding one point of entry does not mean that you’ve identified all the endpoints that have been compromised for example. Acting like you have found patient zero when it’s actually patient 10 or 15 can slow down recovery time overall. Modern day attacks are stealthy and subtle, and could have caused more damage than you might have first assumed.

The best security solutions will intercept suspicious activity on threat detection and reroute it to where it cannot do any harm using dynamic deception. The full extent of the breach can then be searched for and contained in real-time, giving your security team an accurate dynamic map of your entire data center and network. Your automatically generated report shows you the deception incidents, including integral information you need to investigate the breach. What passwords were used, and where did the attacker gain entry? Were there malicious binaries used, or suspicious C&C servers? With this level of detail, your security teams are able to start building up a clear picture of root cause.

Containment of this kind can also give you more time to understand what you’re dealing with in a safe environment. By rerouting an attacker using dynamic deception, you can isolate them safely, and monitor and learn from their activities rather than frighten them away by alerting them that you know they’ve gained entry. In this way, you can take back the upper hand, responding to the attackers behavior without going into crisis mode, calmly following your incident response plan priorities – risk free.

7. Limit Dwell Time

Having this level of granular visibility manages the next part of your incident response plan, limiting the amount of time that attackers are on your network. The SANS Institute found that a shocking 50% of organizations didn’t notice a breach for more than 48 hours, while 7% had no idea how long an attacker had breached their network for, even after the fact. The longer an attack continues for without being stopped, the more damage can be done, so having a plan for limiting this is essential.

Your security solution should be able to limit dwell time by provide application layer visibility. This uncovers and tracks process-level activity (not just at the transport layer) across applications in real-time. This can then be automatically correlated with network events and context, allowing you to access reports on suspected incidents and any anomalies detected across all workloads. With this, even new attack vectors are isolated in real-time. With nowhere for attackers to hide, dwell time is automatically minimized at a policy level.

8. Including Recovery Plans

The clearest part of your security incident response plan should outline what happens when a breach has been confirmed. Detail the processes that are automated so that all key stakeholders understand what has already been put into place.

Does your security solution allow IOCs (Indicators of Compromise) to be automatically exported to your SIEM or security gateways to speed up incident response? Can you update your micro-segmentation policies quickly and seamlessly in response to traffic violations? There might be different automated procedures needed for various environments. For example, stopping the spread of damage from VMs or Containers could involve an IOC halting or disconnecting service entirely. The best solutions will provide an integrated platform that shows the full picture from both a security and an infrastructure point of view.

Recovery plans might need their own smaller security incident response plans or playbooks. A DDoS attack is different from an injection of malware. An external bad actor is a different adversary from an insider with high level access who has compromised the network. Your company might have one set of response plans for a breach to customer data, another for artificial intelligence, and yet another for asset recovery. Make sure the right documentation is ready for any event, and the right personnel are equipped with a plan of action.

9. What Lessons Can You Add to Your Security Incident Response Plan?

By utilizing a smart incident response plan, you can use a breach to help prepare for the future. Once the attack is contained and eradicated, make sure to complete any incident documentation for regulation or internal records. You can also perform your own analysis internally to learn from the attack and your responses to it as a company. With the lessons you’ve learned, you can update your security incident response plan. What can you improve for next time, and what gaps did you uncover if any?

A strong security incident response plan is a must-have in today’s increasingly interconnected IT environment. If and when a breach occurs, your business will be asked how you prepared for an incident. This could be used to establish regulatory compliance as well as assessment of the attack and even blame. Creating a detailed analysis of how your company prepares for a threat, as well as responds in the moment and learns from the experience puts you one step ahead, and ready for anything.

0 comments

Leave a Comment

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *