Cybersecurity Incident Response Plans Go Begging

Posted on by Robert Ackerman

In recent years, we would be hard-pressed to make the case that huge investments in cybersecurity haven’t made things better. Consider, for example, the advent of big data analytics, which takes the crucial step of aggressively addressing potential hacker attacks before they occur. It is now widely accepted that defensive measures alone—historically, the key approach to stopping or mitigating attacks—are no longer sufficient.

But it’s also true, unfortunately, that breaches continue at a relentless pace. More than a quarter of Fortune 500 companies, which typically spend heavily on cybersecurity, have been breached, and most companies of any size continue to worry that they will be the next victim—and frequently not for the first time. Last year, a survey of 273 security pros by Black Hat USA found that 70 percent believe their organizations will have a major cybersecurity breach over the next 12 months.

Fact is, surprisingly astute hackers keep evolving, just as cybersecurity does, and no organization is invulnerable to a breach.

So it’s unfortunate at this juncture that relatively few companies have embraced incident response plans (IRPs). This needs to change. IRPs are designed to expedite the response to an organizational breach as expeditiously as possible to mitigate reputational damage, customer distrust, regulatory and legal fees, and cleanup costs.

Yet even though a well-crafted IRP is essential, creating a formal plan may not be a priority for many companies. Last year, an IBM security report found that a whopping 74 percent of 3,400 security and IT pros surveyed in 11 global markets didn’t have a formal incident response plan applied consistently across their organization.

As already suggested, it’s not that cybersecurity pros are laying low across the board.

For example, big data analytics, a $193 billion market in 2019, is projected to grow at a robust 11 percent annual clip to a $421 billion market in 2027, according to Allied Market Research. Big data analytics, also known as data science, takes a proactive approach to cybersecurity using data collection, aggregation and analysis capabilities to perform vital security functions that detect, analyze and mitigate cyberthreats. In simple terms, it analyzes network data from a blizzard of sources to spot potential trouble spots early. Combining and correlating this data gives organizations one primary data set to work with, enabling security pros to apply appropriate algorithms and create rapid searches to identify early indicators of an attack.

More is needed, however. What can companies do to mitigate breaches besides purchase this technology? Other steps include the adoption of more automation to monitor intrusion detection systems, pressuring Internet of Things (IoT) manufacturers to improve device security and better cybersecurity training of employees. In addition, companies should adopt more creative hiring practices of cybersecurity professionals to address a huge and growing talent shortfall.

First, however, companies should cover all their fundamental bases, bringing us back to the gaping need to create or improve formal incident response plans. With this in mind, below are the key steps of a strong IRP, applicable to big and small companies alike.

+ Assemble your team. The right people have to be positioned in the right places. Once doing so, appoint a team leader with overall responsibility for responding to the incident. This person should have a direct line of communication with management. This way, key decisions—such as taking key systems offline if necessary—can be made quickly. Technical skills are not all that is required. Also needed are cross-functional members to handle non-technical tasks, such as talking to the media and responding to legal issues.

+ Stop the breach. Systems that the attacker might access must be isolated to prevent further spread. Breached accounts must also be disconnected, and targeted departments shut down. In addition, IP addresses belonging to the origin of the attack must be blacklisted.

+ Contain and recover. Containing a breach is not unlike containing a forest fire. Once detected, the incident needs to be roped in. This may involve disabling network access for computers known to be infected and installing security patches to resolve malware issues or network vulnerabilities. Passwords for users with breached accounts may also need to be reset. In addition, affected systems should be backed up, preserving their current state for later forensics.

+ Assess the damage. This can take time. Did the breach, for instance, result from an external attack on servers that could shut down critical components of a business, such as e-commerce or reservation systems? Or, for example, did a web application layer intrusion potentially use a web server as a pathway to steal data from a back-end system?

+ Begin the notification process. A data breach is a security incident in which sensitive, confidential data is copied, stolen or transmitted. Privacy laws such as Europe’s General Data Protection Regulation or California’s Consumer Privacy Act require public notification of a breach. Impacted parties should also be notified to help protect them from identity theft or other fallout.

Wise companies will do two other things as well. Once a security incident is stabilized, they analyze lessons learned to try to prevent the recurrence of similar incidents. This may include patching server vulnerabilities or training employees on how to avoid phishing scams. Companies should also create thorough documentation. This, coupled with defined procedures, helps ensure that key players, including those new on the job, understand the concrete steps needed to combat a potential breach down the road.

Robert Ackerman

Founder/Managing Director, AllegisCyber, AllegisCyber Capital

Analytics Intelligence & Response

data security incident response

Blogs posted to the website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community

Related Blogs