The foundation has been laid for enterprise incident response; only running through mock scenarios and real incidents will find the faults and areas that need to be modified for a more effective and fault-tolerant process. The incident process requires information to be gathered at the identification phase of the incident and throughout the resolution process. There are several pieces of information that should be captured at the time of incident identification and throughout, so that the incident team will know where to focus their efforts, and as the investigation continues and possible scope changes occur, detailed documentation can be developed to be used during and after the incident resolution.
The sources of incident reporting are many; security tools, analyst observation, and employee awareness. The initial report of an incident may not have all the details, as it may be unknown if there is an incident or not and the scope.
Critical information to capture includes but is not limited to:
- Date and time of report
- Name, title, and contact information of who reported the incident
- Date and time of incident, if known
- Type of incident
- Intrusion, DoS, virus, system misuse, website defacement, and so on
- Affected systems if known (IP address, hostname, OS, applications, and so on)
- If sensitive data is involved
- Scope of the incident, number of systems, and so on
- Any other details on source
This information can be captured in a form or in an incident management system and is updated as the investigation continues. A sample reporting form is included in Appendix E, Security Incident Response Resources.
Once an incident has been reported and the process is initiated for incident response as per the plan, the documentation on response must be generated. There may be a significant amount of data and information generated during the response and it must all be logged to the forms or the incident management tool used by the enterprise. Not only is this necessary for active investigations, but it should be retained for future incident response. Additionally, this information can be used for lessons learned to either improve incident response or to tweak other areas of the process to better reflect the real world scenarios observed through continued use of the process.
Information that should be captured will include information from the initial reporting of the incident and also includes all details of the incident learned through the investigation.
Additional information includes but is not limited to:
- Case number assigned
- Case owner and contact information
- Incident summary
- Steps taken during investigation
- Additional parties involved
- Incident handler comments
- Next steps (to be updated by each member working on the incident)
- Incident detail (should be more accurate and detailed versus a report)
- Real date and time of incident
- Detailed description of incident
- Detailed source information
- Impact information
- Evidence collected
- Resolution information
The incident tracking documentation will be more valuable with more detailed information that may also help improve procedures previously defined. The more information that can be gathered, the more effective the mitigation could be for future incidents. The last important aspect of incident resolution is that it should be approved with a sign-off from an IT executive. This will more than likely follow a full briefing of how the incident was detected, all the actions taken, impact analysis, and steps to mitigate the same type of incident in the future. Another outcome of incident response may be the determination to further invest in the in-house forensic capability or contract the entire process to a third party.
There should be some level of in-house incident response capability, but to what level must be determined by the IT management. For the enterprise that will have a full capability, training and expertise development cannot be stressed enough. Improper handling of an incident can cost the enterprise additional money, increase incident impact, and increase liability to the enterprise. With this understood, it is an investment that can be very beneficial in reducing the day-to-day impact of incidents when the process can be handled properly in-house. Depending on the size of the enterprise, more resources may be required to maintain all facets of securing the enterprise, while gaining the additional responsibility of incident response.
If management decides that due to resource limitations, it will not proceed with building a full capability, the team should still exist and a well documented process must be executed for when the in-house team hands off to a contracted third party.
For enterprises that have made the decision to contract incident response to a third party, a small amount of incident response work will still need to occur in-house for maximum effectiveness in reducing further impact on the business. There can be significant benefits to contracting out incident response to a third party. First, leveraging for the most impactful incidents ensures that a dedicated team will be assigned to resolve the incident and second, the liability of improper incident handling is no longer an enterprise concern, as it is owned by the contracted third party. The caution with a completely contracted out incident response is that the incident resolution time frame is extended while waiting on the third party to respond and there is significant cost in this approach. In enterprises with no in-house capability, this may be the only option and all non-critical incidents may be handled by a more generic process. The more generic process may seem effective initially, but repeating the process and not investigating incidents or documenting thoroughly may prove to be more costly in the long run.
The decision to contract incident response is one that must be well thought out with benefits and caveats clearly understood by the enterprise.