In August, the National Institute for Standards and Technology (NIST) released an update to its Computer Security...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Incident Handling Guide (SP 800-61) [PDF]. This third revision offers guidance on issues that have arisen since the last release in March 2008 with an emphasis on addressing new technologies and attack vectors, changing the prioritization criteria for incident response and facilitating information sharing.
In this tip, we examine these major changes and discuss how to integrate them into a security and compliance program.
From categories to attack vectors
One of the major shifts in the newly revised NIST incident response guide is a move away from assigning security incidents to black-and-white categories. Previous editions of the manual set forth five specific categories for incidents: denial of service, malicious code, unauthorized access, inappropriate usage and the catchall "multiple component." In practice, it was difficult to assign real-world incidents to these categories, as almost every incident wound up in the multiple component bucket.
The new manual abolishes these categories and replaces them with the concept of attack vectors -- a list of methods an attacker might use to carry out an attack. The important difference is that a single incident may include attacks that leverage more than one vector. These are the new vectors:
- External/removable media
- Attrition (denial-of-service and brute-force attacks)
- Improper usage
- Loss or theft of equipment
Federal government agencies and appropriate contractors will likely use these attack vectors when reporting security incidents to the federal government. However, even companies outside of government control can use these standardized attack vectors to form the basis of their categorization scheme and compare benchmark data with other organizations.
In addition to replacing categories with attack vectors, the updated manual recognizes that many organizations face hundreds or thousands of attacks on a daily basis and require a mechanism to identify the significant attacks that require thoughtful handling. It introduces three impact-based criteria to use when assessing the priority of an incident.
- Functional impact describes how the business functions are affected by the system and is categorized as none, low, medium or high. Incidents with a high functional impact result in a situation where the organization is unable to provide one or more critical services to all users.
- Information impact describes the sensitivity of the information breached during the incident and may be categorized as none (if no data was breached), privacy breach (if sensitive personal identifying information is lost), proprietary breach (if trade secrets may have been compromised) or integrity loss (if data may have been altered).
- Recoverability impact describes the resources needed to recover from the incident. If no additional resources are needed, the recoverability impact is "regular." If the company can predict the time to recover but needs additional resources, the incident is categorized as "supplemented." In cases where the company cannot predict recovery time, the "extended" category applies. Finally, the most serious incidents may be "not recoverable."
This three-tiered approach to prioritizing incidents is a remarkably flexible model that is easily adaptable to an organization's needs in a particular incident response. I particularly like the way that it leaves the decisions about weighting these criteria in the hands of the organization. For example, an organization that deals with massive amounts of personal identifying information (PII) might weight information impact more heavily than recoverability impact, while an emergency response agency might prioritize functional impact to ensure the continued delivery of emergency services.
Deciding what to share
With the recent hullabaloo in Washington D.C. over legislation that will require private organizations to share details of computer security incidents with government regulators if it passes, some expect that this government guide would advocate just such an approach. In reality, the guide offers a balanced look at the issue and dedicates an entire chapter to "Coordination and Information Sharing."
The bottom line presented by the NIST incident response guide is a reasonable one: Companies should share information with "trusted partners" (the definition is left up to you) in an effort to both help quickly resolve the incident at hand and spread the word among a closed, trusted community of security professionals. This type of reasoned, limited collaboration is likely to not only protect each organization, but also provide benefits to the broader community.
As companies build this component of their incident handling program, it's important to remember to plan for the disclosures they are required to make under the laws and regulations governing their respective industry. For example:
- PCI DSS imposes reporting requirements on organizations that store, process or transmit cardholder information.
- HIPAA requires that organizations suffering a security breach notify the affected individuals as well as the secretary of health and human services.
- State breach notification laws may require the notification of individuals as well as the state government.
The precise set of information-sharing requirements facing each organization varies based upon the types of information that are handled and the jurisdiction(s) in which the organization operates; consult your legal staff for more guidance on this issue.
Overall, the NIST Computer Security Incident Handling Guide offers an excellent roadmap to organizations that are either building a response process for the first time or are evaluating the effectiveness of their current response process. It's definitely worth a read.
About the author:
Mike Chapple, Ph. D., CISA, CISSP, is an IT security manager with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Chapple is a frequent contributor to SearchSecurity.com, and serves as its resident expert on network security for its Ask the Experts panel. He is a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated.