Last fall, I took part in one of SecureWorld Seattle’s panels, “Manage the Damage – The Current Threat Landscape." The panel focused on the topic of developing, fine-tuning, and practicing incident response plans to be better prepared for a breach.
The moderator, Jean Pawluk, and the crowd in attendance, asked some thought-provoking questions about common incident response challenges that businesses face. Here are three questions that sparked an engaging and insightful discussion between the panel.
Since Successful Incident Response Depends Heavily on Preparation, What Can Organizations do to Prepare?
The panelists had many thoughts on this open-ended question, but three central priorities emerged: planning, tabletop exercises, and identifying critical assets and data.
Incident response plans keep everyone on the same page. They clearly outline who’s in charge, available resources, and detection and containment options. Having a process to follow will bring order to chaotic situations and keep everyone focused on solving the most critical problems.
Tabletop exercises allow an organization to repeat many hypothetical scenarios to test the effectiveness of the incident response plan. Stakeholders will have a better understanding of their role in the incident response process to stay prepared. In addition, exercises also identify deficiencies in the plan so that it can continue to improve.
Identifying critical assets and data helps organizations prioritize where their focus should be. Once you know what those critical items are, think through the threats against them, and what concerns you’ll have during an incident. This will determine what controls you should implement now to ensure those concerns are addressed quickly. This doesn’t always mean implementing a fancy new security product; sometimes it can be as simple as thoughtfully increasing the verbosity of your logs.
What Are the Pitfalls You’ve Seen in an Organization’s Ability to Respond to Incidents?
Most of the issues organizations run into are due to assumptions they’ve made right before an incident occurs, when it’s too late to make a correction. You can often catch assumptions in the planning and tabletop exercise phases.
For example, one assumption is that IT administrators are typically prepared to manage and conduct a security investigation and response. The skills, training, and mindset of an incident responder are different than even the most competent system administrator. If you haven’t provided your administrator with any specialized response training, your faith in his or her ability to conduct an investigation into a security incident may be misguided.
Organizations also assume that they can depend on unknown, unvetted, third-party vendors. Companies that have some form of cyber liability insurance are usually more susceptible to that mindset. They’re often in for a surprise when their insurance carrier refers them to a vendor that can’t arrive quickly, and when they do arrive, performs a sub-standard job at responding to the organization’s questions, concerns, and needs. They’re then left looking for a second opinion, often at their own expense. Organizations should develop a relationship with a vendor they trust before a crisis, as opposed to relying on a vendor they’ve never met to help them during an emergency.
Organizations May be Breached and Not Know It. What Can They Do to Find Out?
We talked about this issue in my threat hunting blog post. The first step is to be proactive. Don’t wait to find out about a breach from a third party, or stumble on it a year later. Come up with ideas of what malicious actors may be doing on your network and start hunting.
For example, systems with the Remote Desktop Protocol exposed to the Internet are prime targets for attackers. Even if you have no alarm telling you that one of these systems has been breached, take a look for common indicators of compromise. You may be surprised.
Go out and do something with the information and resources you already have, even if it’s just going to each of their critical servers to check out what’s sitting in the Windows startup folder.
Summary
Security incidents are a business problem for people to solve. While technology is an enabler, it will not investigate, scope, contain, and eradicate an incident without smart people solving tough problems.
There may be chaos, confusion, and anxiety during this process. Everyone is going to want answers. I encouraged the audience to think about who they rely on for those answers and think about the tough questions that’ll be asked. The individuals who’ll need to provide answers to those tough questions need to be prepared with the right training and resources.
More: If you’re in the initial stages of putting together an incident response plan, check out our blog, "6 Essential Steps for Creating an Actionable Incident Response Plan."
Andrew Cook is a manager for incident response services at Delta Risk. Read more Delta Risk bogs here.
