Forwarded from: Elizabeth Lennon <elizabeth.lennon (at) nist.gov> ITL BULLETIN FOR MARCH 2008 HANDLING COMPUTER SECURITY INCIDENTS: NIST ISSUES UPDATED GUIDELINES Shirley Radack, Editor Computer Security Division Information Technology Laboratory National Institute of Standards and Technology U.S. Department of Commerce Today, organizations that operate and manage information technology (IT) systems are spending more time than ever before in responding to security incidents. New incidents and threats that arise daily have the potential to seriously damage and disrupt the security of the organizationÂs information and IT systems. Security incidents are violations or threats of violation of the organizationÂs computer security policies, acceptable use policies, or standard computer security practices. Organizations should consider carefully their ability to handle these security incidents and threats effectively when they plan, develop, and implement their IT security programs. Applying risk management procedures, organizations should identify and assess the risks of security incidents and identify effective ways to deal with them. The first approach is to prevent security incidents whenever possible. But since not all incidents can be prevented, organizations should take steps to establish an incident response capability for rapidly detecting incidents, minimizing loss and destruction, identifying any weaknesses in their systems that may have been exploited, and restoring IT services. This is a complex undertaking, requiring considerable planning and the commitment of resources to carry out the plans. Intrusion detection and prevention systems (IDPSs) and other mechanisms can be used to monitor threats. Clear procedures are needed to assess the current and potential impact of incidents and to implement effective methods for collecting, analyzing, and reporting data. Specific communication channels should be established with internal groups, such as human resources and legal staffs, and with external groups, such as law enforcement, the media, and other incident response teams. Security Threats to IT Systems The many security-related threats that organizations must address include: - Denial of Service (DoS)Âan attack that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources. - Malicious CodeÂa virus, worm, Trojan horse, or other code-based malicious entity that successfully infects a host. - Unauthorized AccessÂa person gains logical or physical access without permission to a network, system, application, data, or other IT resource. - Inappropriate UsageÂa person violates acceptable use of any network or computer policies. - Multiple ComponentÂa single incident that encompasses two or more incidents; for example, a malicious code infection leads to unauthorized access to a host, which is then used to gain unauthorized access to additional hosts. Updated Guide on Handling Security Incidents NISTÂs Information Technology Laboratory recently issued NIST Special Publication (SP) 800-61 Revision 1, Computer Security Incident Handling Guide: Recommendations of the National Institute of Standards and Technology. Written by Karen Scarfone and Tim Grance of NIST and by Kelly Masone of Booz Allen Hamilton, NIST SP 800-61 Revision 1 provides practical guidance to help organizations establish an effective incident response program, analyze and respond to information security incidents, and reduce the risks of future incidents. The recommendations in the guide are useful for those organizations that are just setting up their incident handling teams, as well as those that have already done so. The updated guide, which replaces NIST SP 800-61, Computer Security Incident Handling Guide, focuses primarily on the procedures and solutions for detecting, analyzing, prioritizing, and handling incidents. The guidelines and recommended solutions can be used on many different hardware platforms, operating systems, protocols, or applications and can be tailored to meet the specific security and mission requirements of different organizations. NIST SP 800-61 Revision 1 provides in-depth information on the need for incident response capabilities. It covers the structures of incident response teams and discusses the other groups within an organization that might participate in incident handling activities. The basic steps of handling incidents effectively, including incident detection, analysis, containment, eradication, and recovery, are presented. Separate sections in the guide provide specific recommendations for handling the five types of incidents: denial of service (DoS), malicious code, unauthorized access, inappropriate usage, and multiple component incidents. All of these incidents are defined, and examples of each are given. The preparation, detection, analysis, containment, eradication, and recovery steps for each type of incident are detailed. Checklists for handling each of the five types of incidents are included. The appendices bring together useful information sources that assist organizations in their incident handling programs. Included are a consolidated list of the recommendations that are discussed in the guide, incident response scenarios, and questions for use in incident response exercises. Also provided are suggested items of information to be collected about each incident, a glossary, an acronym list, lists of in-print resources, online tools, and other resources that help organizations in planning and performing incident response activities. In addition, the appendices present frequently asked questions about incident response activities and the steps to be followed in incident handling. The final section of the appendices contains incident reporting guidelines for federal agencies from the United States Computer Emergency Readiness Team (US-CERT) in the Department of Homeland Security. This ITL bulletin summarizes the updated guide, which is available at: http://csrc.nist.gov/publications/PubsSPs.html. Basics of Incident Handling Organizations face major decisions and actions when they develop their computer security incident response capabilities (CSIRC). One of the first considerations should be to create an organization-specific definition of the term Âincident so that the scope of the term is clear. The organization should decide what services the incident response team should provide, consider which team structures and models can provide those services, and select and implement one or more incident response teams. An incident response plan, and associated policies and procedures, should be developed when a team is established so that the incident response process is performed effectively, efficiently, and consistently. The plan, policies, and procedures should identify the teamÂs interactions with other teams within the organization as well as with external parties. The incident response process is composed of several phases. The initial phase involves establishing and training an incident response team, and acquiring the necessary tools and resources to enable the team to carry out its responsibilities. During this preparation activity, the organization also attempts to limit the number of incidents that will occur by selecting and implementing a set of controls based on the results of risk assessments. However, residual risk will inevitably persist after controls are implemented, and no control is foolproof. The next phase is detection and analysis of security breaches, which alerts the organization whenever incidents occur. A containment/eradication/recovery phase follows. Depending upon the severity of the incident, the organization can act to mitigate the impact of the incident by containing it and ultimately recovering from it. After the incident is adequately handled, the organization issues a report that details the cause and cost of the incident and the steps the organization should take to prevent future incidents. This last phase is post-incident activity. The organizationÂs incident response team should be available for contact by anyone who discovers or suspects that an incident involving the organization has occurred. One or more team members, depending on the magnitude of the incident and availability of personnel, should handle the incident. The incident handlers analyze the incident data, determine the impact of the incident, and act appropriately to limit the damage to the organization and restore normal services. Although the incident response team may have only a few members, the teamÂs success depends on the participation and cooperation of individuals throughout the organization. NIST Recommendations for Handling Security Incidents NIST advises that organizations implement the following recommendations in planning and developing their incident response capabilities: Establish and operate a formal incident response capability. Federal agencies and departments are specifically directed to establish incident response capabilities under the Federal Information Security Management Act (FISMA) of 2002. Federal organizations are required to develop and implement procedures for detecting, reporting, and responding to security incidents. Federal civilian agencies are responsible for designating a primary and secondary point of contact (POC) to report all incidents to the United States Computer Emergency Readiness Team (US-CERT) and for documenting corrective actions that have been taken and their impact. Each agency is responsible for determining specific ways in which these requirements are to be met. Also, policy guidance issued by the Office of Management and Budget (OMB) requires that agencies have a capability to provide help to users when security incidents occur in their systems and to share information concerning common vulnerabilities and threats (OMB Circular No. A-130, Appendix III). OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information, provides guidance on reporting security incidents that involve personally identifiable information. Federal Information Processing Standard (FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems, specifies minimum security requirements for federal information and information systems, including incident response. The specific requirements for the implementation of security controls are defined in NIST SP 800-53, Recommended Security Controls for Federal Information Systems. Organizations should take the following steps in establishing an incident response capability: - Create an incident response policy and plan; - Develop procedures for performing incident handling and reporting, based on the incident response policy; - Set guidelines for communicating with outside parties regarding incidents. - Select a team structure and staffing model; - Establish relationships between the incident response team and other groups, both internal to and external to the organization; - Determine the services that the incident response team should provide; and - Staff the incident response team and provide staff members with appropriate training. Reduce the frequency of incidents by effectively securing networks, systems, and applications. It is less costly and more effective to prevent incidents than to try to fix the problems that occur when security controls are inadequate. Many security incidents can overwhelm the resources and capacity of the organization to respond, and can result in delayed or incomplete recovery. Extensive damage may occur, and systems and information may not be available for long periods. When the security of networks, systems, and applications is effectively protected and maintained, the incident response team can focus on handling serious problems. Document the organizationÂs guidelines for interactions with other organizations regarding incidents. Clear procedures should be established to guide incident handling team members who may need to communicate with outside parties, including other incident response teams, law enforcement, the media, vendors, and external victims. These communications often must occur quickly, and guidelines are needed so that only the appropriate information is shared with the right parties. The inappropriate release of sensitive information can lead to greater disruption and financial loss than the incident itself. Creating and maintaining a list of internal and external POCs, along with backups for each contact, can help organizations to make the communications among the involved parties easier and faster. Emphasize the importance of incident detection and analysis throughout the organization. Organizations might experience thousands or millions of possible indications of security incidents each day. These incidents are recorded mainly by logging and computer security software. Centralized logging and event correlation software can be effective in automating the initial analysis of the voluminous data that is collected and in selecting the events of interest that require human review. To assure the quality of the data collected, organizations should establish logging standards and procedures that facilitate the collection of adequate information by logs and security software. This data should be reviewed regularly by the appropriate staff members. Develop written guidelines for prioritizing incidents. Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Incidents should be prioritized based on the following: - Criticality of the affected resources and data, such as whether a public Web server or a user workstation is affected; and - Current and potential technical effect of the incident, such as root compromise or destruction of data. Combining the criticality of the affected resources and the current and potential technical effect of the incident determines the impact of the incident to the organization. For example, data destruction on a user workstation might result in a minor loss of productivity; however, root compromise of a public Web server might result in a major loss of revenue, productivity, access to services, and reputation, as well as the release of sensitive data. The latter breach could result in the release of credit card numbers, Social Security numbers, and other forms of personally identifiable information. Since incident handlers may be under great stress during incidents, it is important to make the prioritization process clear. Organizations should decide how the incident response team should react under various circumstances and then create a Service-Level Agreement (SLA) that documents the appropriate actions and maximum response times. This documentation is particularly valuable for organizations that outsource components of their incident response programs. Documenting the guidelines should facilitate faster and more consistent decision making. Review the lessons learned from security incidents to improve the organizationÂs security incident handling processes. After a major incident has been handled, the organization should hold a meeting to review the lessons learned from the incident and the effectiveness of the incident handling process. Then it is possible to identify necessary improvements to existing security controls and practices. Meetings to review lessons learned should also be held periodically for lesser incidents. The information accumulated from all of the meetings to review the lessons learned should be used to identify systemic security weaknesses and deficiencies in policies and procedures. Follow-up reports generated for each resolved incident can be important not only for evidentiary purposes but also for reference in handling future incidents and in training new members of the incident response team. An incident database, with detailed information on each incident that occurs, can be another valuable source of information for incident handlers. Seek to maintain situational awareness during large-scale incidents. Organizations often are challenged to maintain situational awareness for handling of large-scale incidents because these incidents are very complex. Many people within the organization may play a role in the incident response, and the organization may need to communicate rapidly and efficiently with various external groups. Collecting, organizing, and analyzing all the pieces of information, so that the right decisions can be made and executed, are not easy tasks. The key to maintaining situational awareness is to prepare to handle large-scale incidents by: - Establishing, documenting, maintaining, and exercising on-hours and off-hours contact and notification mechanisms for various individuals and groups within the organization, such as the chief information officer (CIO), head of information security, IT support staff, and business continuity planning staff. Mechanisms are also needed for contacts outside the organization, such as US-CERT, incident response organizations, and counterparts at other organizations; - Planning and documenting guidelines for the prioritization of incident response actions based on business impact; - Preparing one or more individuals to act as security incident leads with responsibility for gathering information from the incident handlers and other parties, and distributing relevant information to the parties that need it; and - Practicing the handling of large-scale incidents through exercises and simulations on a regular basis. Since these incidents happen rarely, incident response teams often lack experience in handling them effectively. More Information See Appendix J of SP 800-61 Revision 1 for information about federal incident reporting guidelines, including definitions and reporting time frames. The US-CERT Web page can be found at: http://www.us-cert.gov/federal/reportingRequirements.html. OMB directives and guidelines are available at: http://www.whitehouse.gov/omb/. NIST publications assist organizations in planning and implementing a comprehensive approach to information security. See NISTÂs Web page for information about NIST standards and guidelines that are referenced in the Computer Security Incident Handling Guide and other security-related publications, covering related topics, such as security planning, risk management procedures, security controls, intrusion detection systems, and firewalls. http://csrc.nist.gov/publications/index.html Disclaimer Any mention of commercial products or reference to commercial organizations is for information only; it does not imply recommendation or endorsement by NIST nor does it imply that the products mentioned are necessarily the best available for the purpose. Elizabeth B. Lennon Writer/Editor Information Technology Laboratory National Institute of Standards and Technology 100 Bureau Drive, Stop 8900 Gaithersburg, MD 20899-8900 Telephone (301) 975-2832 Fax (301) 975-2378 ___________________________________________________ Subscribe to InfoSec News http://www.infosecnews.org/mailman/listinfo/isn
This archive was generated by hypermail 2.1.3 : Sun Mar 30 2008 - 22:32:10 PST