Incident Management and Response
Abstract
Incident response is a key component of an enterprise business continuity and resilience program. The increasing number and diversity of information security threats can disrupt enterprise business activities and damage enterprise information assets. A sound risk management program can help reduce the number of incidents, but there are some incidents that can neither be anticipated nor avoided. Therefore, the enterprise needs to have an incident response capability to detect incidents quickly, contain them, mitigate impact, and restore and reconstitute services in a trusted manner. This white paper examines incident response from security, risk, privacy and assurance perspectives; identifies some key issues to be considered in an incident response program; and outlines where the COBIT® 4.1 framework can be applied to the development of an effective incident response capability.
ISACA®
With 95,000 constituents in 160 countries, ISACA (www.isaca.org) is a leading global provider of knowledge, certifications, community, advocacy and education on information systems (IS) assurance and security, enterprise governance and
management of IT, and IT-related risk and compliance. Founded in 1969, the nonprofit, independent ISACA hosts
international conferences, publishes the ISACA® Journal, and develops international IS auditing and control standards, which help its constituents ensure trust in, and value from, information systems. It also advances and attests IT skills and knowledge through the globally respected Certified Information Systems Auditor® (CISA®), Certified Information Security Manager® (CISM®), Certified in the Governance of Enterprise IT® (CGEIT®) and Certified in Risk and Information Systems Control™
(CRISCTM) designations. ISACA continually updates COBIT®, which helps IT professionals and enterprise leaders fulfill their IT governance and management responsibilities, particularly in the areas of assurance, security, risk and control, and deliver value to the business.
Disclaimer
ISACA has designed and created Incident Management and Response (the “Work”) primarily as an educational resource for security, risk, privacy and assurance professionals. ISACA makes no claim that use of any of the Work will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same results. In determining the propriety of any specific information, procedure or test, security, risk, privacy and assurance professionals should apply their own professional judgment to the specific circumstances presented by the particular systems or information technology environment.
Reservation of Rights
© 2012 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical, photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of all or portions of this publication are permitted solely for academic, internal and noncommercial use and for consulting/advisory engagements, and must include full attribution of the material’s source. No other right or permission is granted with respect to this work.
ISACA
3701 Algonquin Road, Suite 1010 Rolling Meadows, IL 60008 USA Phone: +1.847.253.1545
Fax: +1.847.253.1443 Email: [email protected] Web site: www.isaca.org
Incident Management and Response
Acknowledgments
ISACA wishes to recognize:
Project Development Team
Salomon Rico, CISA, CISM, CGEIT, Deloitte LLP, Mexico, Chair Francis Kaitano, CISA, CISM, CISSP, MCSD, New Zealand Munyaradzi Mufambisi, CISA, CISM, Ernst &Young LLP, Australia Miguel Villegas, CISA, CISSP, GSEC, Newegg Inc., USA
Expert Reviewers
Jeremy McKissack, Ministry of Justice, New Zealand Graeme McLellan, CISSP, ANZ Bank, New Zealand Jim Shaw, CISA, CISM, Axenic Consulting, New Zealand Ability Takuva, CISA, Ernst &Young LLP, South Africa ISACA Board of Directors
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, International President Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Vice President Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Vice President
Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia, Vice President Niraj Kapasi, CISA, Kapasi Bangad Tech Consulting Pvt. Ltd. India, Vice President
Jeff Spivey, CRISC, CPP, PSP, Security Risk Management, USA, Vice President
Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, RSM Bird Cameron, Australia, Vice President Emil D’Angelo, CISA, CISM, Bank of Tokyo-Mitsubishi UFJ Ltd. (retired), USA, Past International President
Lynn C. Lawton, CISA, CRISC, FBCS CITP, FCA, FIIA, KPMG Ltd., Russian Federation, Past International President Allan Neville Boardman, CISA, CISM, CGEIT, CRISC, CA (SA), CISSP, Morgan Stanley, UK, Director
Marc Vael, Ph.D., CISA, CISM, CGEIT, CISSP, Valuendo, Belgium, Director Guidance and Practices Committee
Phillip J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman
Ramses Gallego, CISM, CGEIT, CCSK, CISSO, CISSP, SCPM, 6 Sigma, Quest Software, Spain Meenu Gupta, CISA, CISM, CBP, CIPP, CISSP, Mittal Technologies, USA
Yongdeok Kim, CISA, IBM Korea Inc., Korea Perry Menezes, CISM, CRISC, Deutsche Bank, USA
Mario Micallef, CGEIT, CPAA, FIA, Advisory in GRC, Malta Salomon Rico, CISA, CISM, CGEIT, Deloitte LLP, Mexico Nikolaos Zacharopoulos, CISA, CISSP, Geniki Bank, Greece
Acknowledgments (cont.)
ISACA and IT Governance Institute® (ITGI®) Affiliates and Sponsors American Institute of Certified Public Accountants
Commonwealth Association for Corporate Governance Inc.
FIDA Inform
Information Security Forum
Institute of Management Accountants Inc.
ISACA chapters ITGI France ITGI Japan Norwich University
Solvay Brussels School of Economics and Management
Strategic Technology Management Institute (STMI) of the National University of Singapore University of Antwerp Management School
Enterprise GRC Solutions Inc.
Hewlett-Packard IBM
Symantec Corp.
Introduction
Significant evolution in technology has enabled businesses to change the way that they handle and manage information.
Whether it is advancement of mobile devices, leveraging cloud services or virtualization, it is important for information professionals to also remember to take care of the basics. Recent events have demonstrated that while it is important for enterprises to have preventive measures in place to avoid security incidents, it is equally important that there be a robust, practiced response should an incident occur. An enterprise’s ability to detect, react and respond to security incidents in a fast, planned and coordinated fashion is important to the resilience and success of the enterprise.
What Is Incident Management and Response?
Incident management is defined as the “capability to effectively manage unexpected disruptive events with the objective of minimizing impacts and maintaining or restoring normal operations within defined time limits.”1 A viable incident management capability requires the allocation of human and material resources to support business operations to assure continuity of the minimum of enterprise operations and contain security breaches in accordance with the enterprise risk strategy.
Incident management involves all of the actions taken prior to (including testing and planning), during, and after an information security incident occurs.
The actions taken should be designed to mitigate the impact of an incident with the following goals in mind:
• Provide an effective means of addressing the situation in such a way that it minimizes the impact to the enterprise.
• Provide management with sufficient information to decide on appropriate courses of action.
• Maintain or restore continuity of enterprise services.
• Provide a defense against subsequent attacks.
• Provide additional deterrence through the use of technology, investigation and prosecution.
Incident response is a subset of incident management and is defined as “the operational capability of incident management that identifies, prepares for and responds to incidents to control and limit damage; provide forensic and investigative capabilities; and maintain, recover, and restore normal operations as defined in service level agreements (SLAs).”2
Not unlike other business functions, incident management should follow a life cycle approach. Incident management from a life cycle perspective is composed of a spectrum of activities including:
• Planning and preparation
• Detection, triage and investigation
• Containment, analysis, tracking and recovery
• Postincident assessment
• Incident closure
Figure 1 summarizes the incident response life cycle phases and activities involved in each.
Incident management is defined as the “capability to effectively manage
unexpected disruptive events with the objective of minimizing impacts and maintaining or restoring normal operations within defined time limits.”
1 ISACA, Certified Information Security Manager® (CISM®) Review Manual 2012, USA, 2011
2 Ibid.
Figure 1—Incident Management Life Cycle Phases
Phase Activities
Planning and preparation • Creating policies, acquiring management support, developing user awareness, building a response capability
• Conducting research and development
• Building checklists and acquiring necessary tools
• Developing a communication plan and awareness training Detection, triage and
investigation • Defining events vs. incidents and notification process
• Detecting and validating incidents
• Prioritizing and rating incidents
• Implementing intrusion detection systems (IDSs), intrusion prevention systems (IPSs) and security information events monitoring (SIEM)
• Utilizing anti-malware and vulnerability management systems
• Conducting and participating in global incident awareness, e.g., CERT
• Conducting log and audit analysis Containment, analysis,
tracking and recovery • Executing containment strategy for various incidents
• Performing forensic analysis according to evidence-handling processes
• Executing recovery procedures in line with the enterprise business continuity plans (BCPs) and disaster recovery plans (DRPs)
• Determining the source of the incident Postincident assessment • Conducting postmortem:
– Exactly what happened, and at what times?
– How well did staff and management perform in dealing with the incident? Were the documented procedures followed?
Were they adequate?
– What corrective actions can prevent similar incidents in the future?
• Reporting on incident management related metrics, e.g., mean-time-to-incident-discovery, cost of recovery
• Providing feedback of lessons learned
Incident closure • Conducting incident response postmortem analysis
• Submitting reports to management and stakeholders
Incident Management Response and the Enterprise—Impacts
Incident management is a central component of an enterprise strategy for viability and resiliency as reflected in its BCPs. Incident management is a positive enabler with beneficial impacts to the enterprise both in dealing with risk associated with internal and external threats as well as responding to critical business drivers involving regulatory compliance.
Threats
Threats to information are myriad. Enterprises must be prepared for incidents that may occur from a variety of sources, including those within the
enterprise due to maliciously planned attacks from trusted insiders as well as nonmalicious acts from insiders that result in damage.
In addition to internal threats, cybercriminals are now using more sophisticated attacks to steal assets ranging from intellectual property to the sensitive personal and financial information of an enterprise’s customers, partners and employees. Enterprises are often at a disadvantage in situations involving cybercrime because the criminals are increasingly well funded and have the time and the tools to devise complex, focused attack strategies.
Given the time and money involved, an enterprise cannot anticipate or stop every security incident. However, key stakeholders, clients and other observers do expect an enterprise to take reasonable measures to respond appropriately.
A poorly executed response has the potential to cause an enterprise significant financial losses, ruin its reputation, and perhaps even drive it out of business altogether.
Enterprises must be prepared for incidents that may occur from a variety
of sources, including those within the enterprise due to maliciously planned attacks from trusted insiders as well as
nonmalicious acts from insiders
that result in damage.
Compliance
External and internal business stakeholders are demanding more transparency into system and application access activities. These include regulators who monitor and report access activities pertaining to key financial data and consumer personal information along with internal and external auditors who assess the effectiveness of security and financial controls and processes within the enterprise. In addition, risk management activities may require the collection of security event and incident information as part of status and scorecard reporting to enterprise management. Operational considerations require the consolidation of disparate event and incident monitoring capabilities and improvement of operational efficiency.
The implementation of a successful incident management program can improve the efficiency and effectiveness of the enterprise’s logging, monitoring
and reporting capabilities, and thus help address the overall enterprise IT compliance and risk management objectives.
Business Benefits of an Effective Incident Management and Response Capability
Incident management is tied to the principal enterprise goals for information security: preserving the confidentiality, integrity and availability of enterprise information assets. Employing a systematic incident management program that utilizes a formal methodology offers several benefits to the enterprise such as:
• Providing a structured, logical approach to use in situations that are usually chaotic
• Increasing the efficiency of dealing with an incident, which reduces the impact to the enterprise from both financial and human resources (HR) perspectives
• Breaking down an incident into smaller, more manageable phases or stages that can be addressed in a logical manner
• Providing evidence of due diligence and forethought that may become significant should legal and liability issues arise following an incident. This is particularly true when dealing with disclosure regulations and compliance with laws.
An effective incident management program provides a means of dealing with unexpected circumstances in such a way as to minimize impact to the enterprise. It also provides management with sufficient information on which to base an appropriate course of action. Creating an interdisciplinary incident response team that is drawn from all parts of the enterprise and is educated and prepared to respond to events such as social engineering attacks is a key component of a comprehensive incident management program.
Especially significant is the fact that a robust incident management program as a stand-alone component3 of the overall BCP can enhance the enterprise’s competitive position through greater security awareness, improved
defenses and effective resilient responses to events with negative impacts to the enterprise.
A robust incident management program as a stand-alone component of the overall BCP can enhance the enterprise’s
competitive position through greater security awareness, improved defenses and effective resilient responses to events with negative
impacts to the enterprise.
The implementation of a successful incident management program can improve the efficiency and effectiveness
of the enterprise’s logging, monitoring and reporting capabilities,
and thus help address the overall enterprise IT compliance and risk
management objectives.
3 It should be noted that the incident response plan, though part of the overall BCP, is a separate and distinct document and is not restricted to use only during times when the BCP is executed.
Risk, Security and Privacy-related Aspects of Incident Management and Response
Recent attacks on enterprise information assets have become quite sophisticated, with the adversaries seeking significant financial gains through the use of more advanced and persistent techniques to target and attack reputable enterprises.
The attacks and threats are continuing to evolve at a fast pace, according to a recent information security survey,4 putting more enterprises at risk of being compromised. These attacks from either internal or external sources can take a multitude of forms for varying reasons, each of which can have risk, security and privacy implications:
• Intrusion attempts for financial gain
• Obtaining intellectual property for competitive advantage or national security reasons
• Creating business disruptions
• Obtaining private information for exploitation
There are many types of risk that the enterprise can be exposed to as a result of such attacks, each of which needs to be addressed from both the risk planning and incident response planning perspectives. These types of risk include:
• Reputational risk (public relations or legal issues with customers or the public)
• Regulatory risk (inability to satisfy regulatory processing requirements due to outages or violation of a regulation)
• Operational risk (inability to process critical business functions, including those that are security-relevant)
• Internal human relations issues (relating to payroll and employee privacy)
• Financial risk (stock price dropping, the loss of physical assets or costs to remediate other risks)
It is evident that effective incident management is conducive to a positive security posture for the enterprise and that a structured and tested incident response and management methodology is a key component. It is important to note that by using a formal approach to incident management in the context of an overall business continuity optimization and risk mitigation strategy, the probability of the response itself contributing inadvertently to risk exposure is minimized. In this regard, the COBIT 4.1 framework and process methodology can be used to structure an effective incident management function and
response capability within the enterprise.
Strategies for Addressing Risk Associated With Incident Response
For an enterprise to ensure that its risk level remains low should an event occur, it is imperative that a robust incident response plan exists. It is important that the program:
• Is endorsed by management
• Contains a well-trained interdisciplinary group comprising the incident response team
• Has proven operations and execution plans and processes
• Provides metrics for evaluating overall response effectiveness and gaps in the operational plan
Although incident response programs may differ for each enterprise, based on industry sector, available staff, expertise, budget resources, and other business drivers, there are some key elements or practices that should be consistently applied. These include:
• A charter outlining the mission, scope and objectives of the incident response program, which is consistent with and supports the enterprise BCPs and DRPs.
• An operational plan that includes declaration and escalation procedures
• A well-defined and structured communication plan
By using a formal approach to incident management in the context of an overall business continuity optimization and risk mitigation strategy, the probability of the response itself contributing inadvertently
to risk exposure is minimized.
4 The 2012 Global State of Information Security Survey®, a worldwide study by PricewaterhouseCoopers, CIO magazine and CSO magazine, was conducted online
• An interdisciplinary team comprising technical incident handlers, along with operational and administrative support from IT, legal, HR, public relations and management
• Tools and resources to meet the incident response objectives
• A postincident assessment
Having a demonstrated incident response program in place as part of the incident management program is critical to minimizing impact to the enterprise and its stakeholders should an event occur. The risk categories described previously can all be addressed by mindful planning to address not only prevention, but response as well. A well-executed response in the midst of chaos will minimize financial impact while helping to restore stakeholder confidence.
Governance and Change Considerations Relating to Incident Management and Response
Developing and implementing an effective and successful security incident response program is a comprehensive endeavor, which requires substantial enterprisewide planning, investment and resources. The program should be dynamic and able to adapt to changing business requirements and the ever-shifting threat landscape. Thus, the program should be treated as an evolving entity of the business that follows an outlined life cycle.
The incident management program defines the incident response program, which provides guidance and documentation on security incident response
handling and communication efforts. The incident response program is activated whenever an incident occurs, and guides the responses for all events severe enough to affect the enterprise’s ability to do business or undermine its reputation.
When developing an incident response program, enterprises need to reflect on how they will drive the ability to continuously monitor threats (IPSs, SIEMs, etc.) and establish clear procedures for assessing:
• Current and potential business impacts
• Effective methods of collecting, analyzing and reporting data
• Continuous improvement
• Building of relationships
• Establishing a suitable means of communication with internal and external business stakeholders
Incident Response Governance
The principal governance components of an enterprise incident response plan consist of the following:
• Statement of senior management buy-in/commitment to incident response strategy
• Incident response and management policy
• Incident response team charter and constituency
• Goals and mission statement and how the program fits into the overall enterprise
• Road map for maturing the incident response capability
• Plan for aligning the incident response program with national, regional and global standards (National Institute of Standards and Technology [NIST] SP 800-61, Regulation [EC] No. 460/2004 of the European Parliament, Information Technology Infrastructure Library [ITIL], International Organization for Standardization [ISO]/International
Electrotechnical Commission [IEC] 27035)
Developing and implementing an effective and successful security incident response program is a comprehensive endeavor, which requires substantial enterprisewide
planning, investment and resources.
Assurance Considerations Relating to Incident Response
The establishment of an incident response function requires a corresponding assurance function to ensure that the incident response function:
• Meets the needs of the enterprise
• Provides sought-after outcomes
Management needs to be able to evaluate independently the incident response process on a regular basis to gain assurance on the effectiveness of controls within the process. Some essential assurance considerations to be taken into account when evaluating an incident response capability include:
• Policies and procedures:
– Does the enterprise have appropriate policies and procedures that govern the incident response process?
– Does the incident response/handling policy set clear direction with executive management support? Are roles and responsibilities clearly established within the policy?
– Do the incident response policy and procedures address the priority of assets that can be compromised? Is prioritization of assets and services determined based on risk?
– Is the policy appropriately communicated and enforced? Are employees aware of their responsibilities in the incident response process?
• People:
– Have roles and responsibilities for incident response been assigned to a formal team with a formal structure of authority for decision making?
– Does the incident response team include individuals from pertinent areas within the business?
– Is incident handling managed using good practices, with management oversight?
– Is staff adequately trained to enable an effective response to incidents? Does staff knowledge of threat-related legislation remain current through the use of training and journals?
• Technology:
– Are incident response workstations and software configured for maximum security?
– Are incident response data adequately protected to facilitate investigation?
– Do incident response software and equipment have strong logical access controls to ensure integrity and confidentiality of data captured?
– Is incident response equipment assessed for vulnerabilities and are identified vulnerabilities remediated?
– Are scripts/tools used in the incident response process appropriately tested?
As noted earlier, the use of the COBIT framework and methodology can be an effective tool for structuring effective incident response processes. As an illustration, figure 2 provides a sample mapping of some COBIT 4.1 domain, process and control objectives to a number of assurance considerations relating to incident response.
Management needs to be able to evaluate independently the incident response process on a regular basis to gain assurance on the effectiveness of
controls within the process.
The COBIT framework and methodology
can be an effective tool for structuring
effective incident response processes.
Figure 2—Application of COBIT 4.1 to Assurance for Incident Response
Deliver and Support Domain Control Objectives5 Relation to Incident Response 5.5 Security testing, surveillance and monitoring—Test and monitor the IT
security implementation in a proactive way. IT security should be reaccredited in a timely manner to ensure that the approved enterprise’s information security baseline is maintained. A logging and monitoring function will enable the early prevention and/or detection and subsequent timely reporting of unusual and/or abnormal activities that may need to be addressed
Proactive monitoring and surveillance of security events enable the detection of security anomalies, which may be subsequently classified as incidents. This is the first step of the incident response process.
5.6 Security incident definition—Clearly define and communicate the characteristics of potential security incidents so they can be properly classified and treated by the incident and problem management process.
This control objective addresses the need for proper classification of events to enable the incident response team to prioritize competing activities requiring attention. This classification may be based on the incident’s potential business impact.
8.1 Service desk—Establish a service desk function, which is the user interface with IT, to register, communicate, dispatch and analyse all calls, reported incidents, service requests and information demands. There should be monitoring and escalation procedures based on agreed-upon service levels relative to the appropriate service level agreement (SLA) that allow classification and prioritisation of any reported issue as an incident, service request or information request. Measure end users’ satisfaction with the quality of the service desk and IT services.
Setting up a service desk provides internal participants the ability to report events. Many incidents are observed and reported by employees. Therefore, an enterprise should have a platform for receiving, categorizing, analyzing and reacting to the reports. The service desk should have internal operational level agreements (OLAs) as to the response times for particular classification of incidents. The OLA sets a level against which the service desk function can be measured, and more important, provides a measure of performance for improvement.
8.2 Registration of customer queries—Establish a function and system to allow logging and tracking of calls, incidents, service requests and information needs. It should work closely with such processes as incident management, problem management, change management, capacity management and availability management. Incidents should be classified according to a business and service priority and routed to the appropriate problem management team, where necessary. Customers should be kept informed of the status of their queries.
The recording of incidents through the service desk and monitoring provides input into the incident management process. The subsequent classification of incidents allows resources, time and effort to be applied most effectively to remediate the anomaly.
8.3 Incident escalation—Establish service desk procedures, so incidents that cannot be resolved immediately are appropriately escalated according to limits defined in the SLA and, if appropriate, workarounds are provided.
Ensure that incident ownership and life cycle monitoring remain with the service desk for user-based incidents, regardless which IT group is working on resolution activities.
Effective incident management should encompass defined SLAs to manage the escalation of incidents. Well-articulated SLAs and escalation allow all incidents to be appropriately remediated within defined times. SLAs may also be used as a performance metric against which the incident response function is measured.
8.4 Incident closure—Establish procedures for the timely monitoring of clearance of customer queries. When the incident has been resolved, ensure that the service desk records the resolution steps, and confirm that the action taken has been agreed to by the customer. Also record and report unresolved incidents (known errors and workarounds) to provide information for proper problem management.
Upon successful remediation of an incident, all resolution steps should be recorded and the incident should be closed. This will allow the response team to focus on other open, current issues.
5 See, for example, ISACA, Security Incident Management Audit and Assurance Program, USA, 2009. This document is available to ISACA members free of charge and can be found at www.isaca.org/siem-AP
Conclusion
Even with the best of controls, there is no guarantee that an enterprise can prevent disruptive and possibly damaging information security incidents arising from either internal or external sources. Incident response management and incident response processes can enable an enterprise to respond effectively when an incident occurs, to continue operations and, if necessary, perform critical forensic assessments in the event of attack or disruption. Developing and executing an effective incident response plan require the commitment and participation of a wide range of stakeholders; it is not an undertaking that should be confined to just the IT or security organizations.
Some suggestions to consider in addressing incident response events from a risk control and assurance perspective include:
• Be prepared for incident response. Tools and techniques must be ready, and team members must be trained, before a response is made to the computer incident. Also, corporate policies, procedures and guidelines for response need to be in place. Top management from all business units and external parties (e.g., managed service providers) should be required to participate in incident response exercises.
• Properly identify the incident. Is the event simply an unusual activity, or can it be identified as suspicious? If so, what are the surrounding activities? Are there multiple reports of issues on the network, or is it confined to one machine or location? Some of the areas to check include suspicious entries in system or work accounting, unexplained new user accounts and unexplained new files.
• Contain the incident and its effects. Change passwords for elevated privilege accounts and review computer trust relationships as quickly as possible when an incident is identified. Protect and, where possible, keep the critical information regarding sources available to the primary users.
• Remove the issue as soon as it is realistically possible. Possibly verify and utilize enterprise anti-virus and anti-malware programs. Review and potentially rebuild the operating system software. Utilizing approved validated software, remove any infected software.
• Return the infected system to operational use as soon as feasible. Remember there are two areas of focus for incident response: recovery and, potentially, prosecution.
• Follow up with responders for improvements to the process. Check with the operational staff in areas where information or data were compromised.
In keeping with these suggestions and by insisting that incident response be a critical part of the enterprise’s overall risk management and security program, assurance professionals can help ensure that incidents do not become problems that can escalate into disasters.
Additional Resources and Feedback
Visit www.isaca.org/incident-response for additional resources and use the feedback function to provide your comments and suggestions on this document. Your feedback is a very important element in the development of ISACA guidance for its constituents and is greatly appreciated.
Developing and executing an effective
incident response plan require the
commitment and participation of a
wide range of stakeholders; it is not an
undertaking that should be confined to
just the IT or security organizations.
References
Endorf, Carl; Eugene Schultz; Jim Mellander; Intrusion Detection and Prevention, McGraw-Hill, USA, 2004
Grance, T.; K. Kent; B. Kim; Computer Security Incident Handling Guide: Recommendations of the National Institute of Standards and Technology, NIST Publication 800-61 rev. 1, USA, 2008
ISACA, COBIT 4.1, USA, 2007, www.isaca.org/cobit
ISACA, Certified Information Security Manager (CISM) Review Manual 2012, Chapter 4, Information Security Incident Management, USA, 2011
ISACA, Cybercrime: Incident Response and Digital Forensics (out of print November 2011)
ISACA, Security Incident Management Audit/Assurance Program, USA, 2009, www.isaca.org/siem-AP Kabay, M.E.; CSIRT Management, USA, 2009, p. 15, www.mekabay.com/infosecmgmt/csirtm.pdf
Kent, K.; S. Chevalier; T. Grance; H. Dang; Guide to Integrating Forensic Techniques Into Incident Response, NIST SP800-86, USA, 2006, http://csrc.nist.gov/publications/PubsSPs.html
Schultz, E.; R. Shumway; Incident Response: A Strategic Guide to Handling System and Network Security Breaches, New Riders, USA, 2002
Software Engineering Institute, CERT® Coordination Center (CERT/CC), Carnegie Mellon University, USA, www.cert.org/certcc.html
Software Engineering Institute, CERT Coordination Center, Creating a Computer Security Incident Response Team:
A Process for Getting Started, Carnegie Mellon University, USA, 2006, www.cert.org/csirts/Creating-A-CSIRT.html Software Engineering Institute, Defining Incident Management Processes for CSIRTs: A Work in Progress, Carnegie Mellon University, USA, 2007, www.sei.cmu.edu/publications/documents/04.reports/04tr015.html
Sterneckert, Alan B.; Critical Incident Management, Auerbach, USA, 2004 Symantec, Managing Security Incidents in the Enterprise, USA, 2003, www.symantec.com/avcenter/reference/incident.manager.pdf
United States Computer Emergency Readiness Team (US-CERT), www.us-cert.gov
Vacca, John; K. Rudolph; System Forensics, Investigation and Response, Jones and Bartlett, USA, 2010, www.isaca.org/bookstore/extras/Pages/System-Forensics-Investigation-and-Response-review.aspx
West-Brown, Moira J.; Don Stikvoort; Klaus-Peter Kossakowski; Georgia Killcrece; Robin Ruefle; Mark Zajicek;
Handbook for Computer Security Incident Response Teams, US-CERT: 2003-04-01, Carnegie Mellon University, USA, 2003, www.cert.org/archive/pdf/csirt-handbook.pdf
