The classification of incidents is part of the incident response policy. The classification approach can be documented as an incident response policy or a standard. In the case of a security breach, that naturally means some vulnerability in your systems or security has been exploited. By classifying the incident, you can better understand the threat and the weakness. Knowing the type of attack can help you determine how to respond to stop the damage. It can also help you analyze the control weaknesses in your environment. This helps reduce the risk of future attacks. There’s no one standard approach to follow in classifying incidents; however, an industry often adopts similar approaches among companies. The key point is to select an approach that meets your legal and regulatory obligations. This should be an approach that provides enough detail to analyze an incident. This analysis will help you improve weaknesses that lead to incidents.

As an example, the Payment Card Industry Data Security Standard (PCI DSS) requires merchants who accept credit cards to report security incidents involving cardholder data. This report should be issued whenever a breach is detected that violates the PCI DSS. One method of classifying a breach is by attack method. The PCI Security Standards Council publishes lists of common security issues. Some of these are attack types; some of them are vulnerabilities. The following are examples of the sorts of things that the PCI Security Standards Council identifies as methods to gain unauthorized access to systems and sensitive information:

• SQL injection—A technique that introduces modified Structured Query Language (SQL) into a website. This attack depends on the website allowing unfiltered input.
• Improperly segmented network environment—Related attacks rely on the lack of partitioning or on isolating high-risk assets on their own network segments. For example, in a flat network, all portions of the network are accessible from anywhere on the network. A breach in one part of the network exposes the entire network to potential access.
• Malicious code or malware—Programs (such as viruses, worms, Trojan applications, and spyware) added to the platform without a user’s knowledge. These programs can damage systems, delete files, encrypt files and demand ransom, or exfiltrate confidential data.
• Insecure remote access—Attacks gaining access through remote services such as point-of-sale (POS) devices, vendor networks, and employee remote access tools.
• Insecure wireless—Attacks accessing the network through wireless points of entry. The wide variety of networked devices that are now wireless ready has increased the risk in recent years. Such devices include copiers, fax machines, inventory systems, POS terminals, web cameras, and more.

Another example is the federal government. Under the Federal Information Security Management Act (FISMA), the government uses the National Institute of Standards and Technology (NIST) Special Publication 800-61. This publication classifies incidents into the following events on a system or network:

• Malicious code—This is a broad category for all code that causes some harm, including computer viruses, Trojan horses, and spyware.
• Denial of service—An attacker crafting packets to cause networks and/or computers to crash.
• Unauthorized access—An exploit to gain access.
• Inappropriate usage—Any use of the computer that violates company policies. This can also facilitate other attacks. For example, visiting websites that are not allowed or inserting portable USB storage that is not approved can lead to malware.

It’s important to use a classification that has meaning to both internal and external stakeholders. In both the PCI DSS and FISMA approaches, incidents must be reported. These breaches are classified within categories that help assess the threat level. Also, they use a taxonomy, or classification system, that is easily understood by external stakeholders. It’s not uncommon to find similarities among many incident-classification approaches. They all share the goal of providing a common language to describe security incidents.

The incident classification is also used to assess the severity of the incident; that is, is an incident minor or major? On this basis, you determine whether the IRT should be activated. What is considered a major incident versus a minor one depends on the organization’s view of risk. Major incidents are generally viewed as incidents that have significant impact on the organization. The impact can be measured in several ways. It might be financial. It may be measured based on disruption of service or legal liability. From a practical standpoint, many major incidents are easier than minor incidents to identify. They might cause effects such as a significant number of users unable to process transactions or unauthorized access to millions of customers’ personal data. Any incident related to the protection of human life is considered a major incident. What is considered a minor incident depends on how much risk the organization is willing to accept.