Breaking Down The Critical Security Controls: CSC 19 – Incident Response
4 min read
There are two controls left in this series, Breaking Down The Critical Security Controls. The last two are the metaphorical bows on the package that is your security program. Number nineteen is all about your plans of action. What do you do when you have a security event or discover a violation? What are the steps you and your teams need to take in order to protect the employees, the business and the data? That’s why CSC 19 is Incident Response and Management.
Here what the control says –
Protect the organization’s information, as well as its reputation, by developing and implementing an incident response infrastructure (e.g., plans, defined roles, training, communications, management oversight) for quickly discovering an attack and then effectively containing the damage, eradicating the attacker’s presence, and restoring the integrity of the network and systems.
Incident response is much more than tactical actions to resolve a problem. This is goes into the legal world of information security. The incident response plans, your proof of actions, are your defense to post-event fallout. Your plans are your ability to defend your business and teams to show you have in place the best efforts to defend, protect and respond. As an example, if you have a SIEM collecting all your logs, sending alerts to the team on DDOS attacks, administration accounts being used improperly, systems logged into by rogue accounts, etc… and you do not have a documented plan on how to respond to them. The alerts pile up and are ignored. WHEN a breach or security events happens and data is lost, you are not naive or unaware but in the eyes of the law you are negligent. Therefore you are liable as you had the information but failed to act.
Solution Approach
Many years ago I was told the most important rule when it comes to managing a security department. NEVER implement a policy, buy a product, rollout new features unless you and your team is fully prepared to RESPOND to what the tools do or if policies are violated. If you are not prepared to handle the alerts from an IDS, don’t put it in first. You will be buried by alerts, scrambling to handle the information that you do not know how to respond to. A mountain of data you will never dig yourself out of. That’s incident response and building your plans should be done side by side with security operation you are advancing.
In large organizations there is a dedicated department for incident response. They receive all the alerts from a lost laptop to a firewall attack and manage the response to resolution. Those teams are not necessarily doing the work, they are not the experts of every technology, but they manage the business units experts to resolve an event.
The best approach to strengthen your incident response is to integrate it into every project. Have a section in the project plan for a response. What happens when this fails? When a vulnerability scan detects a gap? What is the communication chain for support? All those details should be standard for all projects big and small. If it’s the help desk managing incidents or a dedicated team, it doesn’t matter as long as the plan is documented and available to all.
How It Can Be Exploited
Incident response is not a technology that is in place to defend or detect. It’s the integrity and organization of the security team that determines the effectiveness of any plan. There are two main ways hackers will exploit good and bad teams. The first is to be as stealthy, quiet, unique and as hidden as possible. If they can’t be detected or can fall through the cracks of anomaly detection that’s best. Being as unique as possible will also confuse the best teams. Hard to respond when you don’t know what you are looking at.
The other side of this is the exact opposite. Flood a network with traffic. Generate false positives or true positives. Send the teams scrambling to consume the alerts and data flowing. In the middle of the noise the attacker can do what they want and get out without getting stopped.
You wont be able to detect or plan for everything. A mature incident response plan never is stagnant. It’s always evolving from within and from feedback from the outside. There are new security bulletins regularly, new patches, new software installed in the environment and each element requires a plan for the ‘What If’ moments.
If you don’t know how to respond, why are you doing it in the first place? Checkbox security will fail you in the end.
End of line.
Binary Blogger has spent 20 years in the Information Security space currently providing security solutions and evangelism to clients. From early web application programming, system administration, senior management to enterprise consulting I provide practical security analysis and solutions to help companies and individuals figure out HOW to be secure every day.
Subscribe
Facebook Page
Follow Me On Twitter
contactme@binaryblogger.com
