bluebay2014 - Fotolia
Published: 14 Mar 2016
No one understands the internal control structure of an enterprise better than the CISO and the information security group. They deal with protection, monitoring, testing and remediation follow-up on a daily basis. So when a breach occurs and an external forensic firm is engaged to perform a post-incident investigation, it can be frustrating for the CISO to manage the internal staff and the forensic team. One critical point to understand is that, although the forensic team may have skills the internal staff doesn't, they are brought in to communicate -- to shareholders, executive management, employees and law enforcement -- that the enterprise is serious in determining the cause, containing the breach, and identifying any remediation necessary to prevent a breach from happening again.
Follow an incident response policy
Before any security incident occurs, the CISO should have developed a formal incident response plan. The IRP should be based on an industry incident response methodology, like the NIST SP 800-61 Incident Handling Guide, which involves four phases:
- Detection and analysis
- Containment, eradication and recovery
- Post-incident activity
If the incident response policy has been fully vetted and tested in different incident scenarios, the enterprise should have already managed phases one through three by the time the forensic team arrives. The post-incident activity phase addresses lessons learned from the breach, how to use collected incident data and evidence retention. The CISO needs to manage each of these and ensure all appropriate internal staff and management, including the forensic group, is provided with sufficient information to handle each activity.
Lessons learned from the breach
The IRP team should be able to handle new security threats, improved technology and lessons learned. When evaluating the lessons learned from the incident, the team should ask these questions:
- What has been lost?
- Was the information vital for the enterprise?
- How did the breach occur? Was it a human error -- social engineering or configuration error? Was the breach due to out-of-date patches? Was the breach due to a third-party vendor breach?
Using the answers to these questions, the IRP team can get a clearer picture of the security incident.
Using collected data
Once all the necessary data is collected, local or federal law enforcement agencies will need to be contacted about the breach. The agencies might include the U.S. Department of Homeland Security or the cybercrime division of INTERPOL in the EU, depending on what country the breach occurred in. Assuming the breach happened in the U.S., the FBI, Secret Service and, possibly, local or county cybercrime task forces, may also be contacted. The law enforcement agencies, including the forensic investigation group, make up the extended team, which has different responsibilities in the post-breach phase.
The IRP team should be in charge of:
1. Preparing a report for executive management to include:
- Estimated damage/impact;
- Action taken during the incident -- not technical details;
- Follow on efforts needed to eliminate or mitigate the vulnerability;
- Incident response policy or procedure that require updating; and
- Efforts taken to minimize liabilities or negative exposure.
2. Providing the chronological log and any system audit logs requested by the extended team.
3. Documenting lessons learned and modify the incident response policy accordingly.
The extended team should be in charge of making sure that:
1. Legal and finance work with the local authorities as appropriate in the case that the incident was from an external source.
2. Legal and finance work with a cybersecurity insurance provider in submitting a claim.
3. Human resources and security work with management to determine disciplinary action in the case that the incident was from an internal source.
4. Forensic investigators perform network forensics, confirm what data was exposed or stolen, and determine if the attackers have been removed from the environment.
Organizations should establish a policy for how long evidence from a security incident should be retained. Most organizations choose to retain all evidence for months or years after the incident ends. Evidence that should be kept and documented in the IRP includes evidence needed for possible prosecution and the cost of evidence storage, such as hard drives, removable media or backup tapes. A data retention or incident response policy should include a timeline for retention, such as a three-year rule.
Many meetings will be held to address the media, notify customers, handle potential legal issues and revamp the company infrastructure and security program after a security breach. Some meetings will be held several times a day for forensics update activities, while other meetings will be daily updates to management.
The CISO needs to keep an IRP calendar that will schedule meetings with system engineering, legal, media, communications, forensic investigators, auditors and executive management. They each have different concerns and are all competing for time to be heard or updated. The CISO needs to stick to the IRP process and structure so all teams know what their roles are. This allows the CISO to delegate to corresponding IRP staff without having to be present for all activities and still maintain control. This will also help the CISO to focus on the IRP process, forensic investigation and reporting to executive management without being overwhelmed with the minutiae of the post-incident activities. Lastly, the CISO needs to have a current incident response policy, fully vetted, approved by management and tested at least annually using different incident scenarios to ensure if and when a breach does occur, containment and recovery will go smoother. We all should strive to keep the IRP current and relevant in hopes that we never have to use it.
Learn about security tools that aim to automate the incident response process
Find out what questions to ask about security incident handling
Discover the best time to do a system shutdown after a security incident