For such a widely used and accepted term, it’s surprising to find so many different definitions for “incident” in cybersecurity. There are a great many ways we can define the term, and that can have a big impact—not just on how we count our own incidents, but in how we apply resources to them as well. This piece explains the importance of prioritizing what matters most to you, while recognizing the definitional inconsistencies when comparing numbers across the industry.
Industry Definitions of a Security Incident
Lord Kelvin told us, “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind: it may be the beginning of knowledge, but you have scarcely, in your thoughts, advanced to the stage of science.”
From that, we can gather the importance of being able to count the number of incidents we handle in building our incident response program. Let’s consider a few common definitions and see how that might impact our thinking.
The Financial Services Information Sharing and Analysis Center (FS-ISAC) says incidents should be classified by the nature of the severity, and it defines incidents as:
- Cybersecurity breaches or incidents experienced of a new evolving nature that clearly go beyond daily norms or appear to have broad consequences, correlate to incidents reported by others or correlate to specific threat information received.
- Cybersecurity breaches or incidents having a significant impact on operations (e.g., denial-of-service attacks, attacks on integrity) or are of a recurring or persistent and insidious nature.
- Security breaches or incidents related to criminal activities (e.g., fraud, extortion or espionage).
By contrast, NIST defines an incident as “a violation or imminent threat of violation of computer security policies, acceptable use policies or standard security practices.”
The Federal Deposit Insurance Corp. defines “notification incidents” as:
A computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, a banking organization’s:
- (Ability to carry out banking operations, activities or processes, or deliver banking products and services to a material portion of its customer base, in the ordinary course of business;
- Business line(s), including associated operations, services, functions and support, that upon failure would result in a material loss of revenue, profit or franchise value; or
- Operations, including associated services, functions and support, as applicable, the failure or discontinuance of which would pose a threat to the financial stability of the U.S.
And lastly, the Verizon Data Breach Investigations Report (DBIR) defines an incident as “a security event that compromises the integrity, confidentiality or availability of an information asset.” It defines a breach as “an incident that results in the confirmed disclosure—not just potential exposure—of data to an unauthorized party.”
We note that there are a lot of choices! Why can’t or hasn’t the industry settled on a single definition to rule them all? Well, it turns out different organizations value attributes differently, so they end up counting things differently.
For example, FS-ISAC and FDIC both refer directly or indirectly to disruption (or potential disruption) of business services in their definitions. NIST and Verizon, on the other hand, regard an incident to be an event that compromises or violates something (a policy or the confidentiality, integrity or availability of an asset).
These represent very different schools of thought. Both FS-ISAC and FDIC represent financial businesses, while NIST and the Verizon DBIR (arguably) represent businesses in general. What matters in the world of finance may well be different than what matters to other businesses.
READ: New SEC Cyber Rules: What to do Next
How to Build an Incident Response Program
When building your own incident response program, you should use a definition that matters to your industry and your business in particular. Why? Because you’re going to count incidents based on that definition, and you’re also likely to allocate resources for your incident response operation and the resulting remediation based on the incidents you encounter.
Let’s consider a hypothetical: Company X encounters an incident involving a particular ransomware profile. The attack and the ransomware software are of a specific nature. A week goes by and Company X experiences more ransomware, but this time it is at a subsidiary, Business Unit Y. As the investigation continues, Company X determines Business Unit Y was likely affected by the same adversary using the same tools and techniques, and even entering from the same location (in a network sense).
Should that be counted as one incident or two? The scientist might argue it was two. The businessperson will argue it doesn’t matter; the business data that was affected matters far more! If our investigation focuses on analyzing the attack, techniques, tools, etc., we may well be missing the point that matters most to the business.
Consider those differences in thinking over the period of a year or more. It seems reasonable to conclude that Company X is going to report statistics to its leadership differently, depending on how it defined “incident.” That could have a long-term impact on resources, tools, staffing and so on.
READ: How to Prepare for SEC’s Cyber Disclosure Rules
Reporting Consistency Matters
Irrespective of how you decide to define an incident, it is imperative to apply your definition consistently. What is the best way to proceed? Use these tips to improve your chances of success:
- Know your business: Determine what matters most to you and your specific business.
- Look for an industry definition: Research within your industry sector. What does the ISAC that serves your industry use for a definition? That’s a good place to start.
- Adapt and adopt: Don’t be afraid to tweak that industry definition, if need be, to apply specifically to your business.
- Go forth: Apply that definition into every aspect of your incident response plan. Your incident tracking, counting and response operations should all be using that same definition consistently.
Keep in mind that there is no “one size fits all” definition - know your organization and risk potentials.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.