Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
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.
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:
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:
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
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
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:
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.
November 30, 2023
By IANS Research
CISOs, find guidance on what to focus on within the first 30 days, 6 months and first year of your tenure to ensure a fast, successful start.
November 28, 2023
Use this checklist of best practices, designed to help CISOs and cybersecurity leaders protect their organizations and avoid SEC compliance missteps.
November 21, 2023
Access key data sets from the 2023 edition of IANS and Artico Search’s Security Organization and Compensation Benchmark Report. Gain valuable insights on functional leadership compensation to hire and retain top security talent.