Blog post

Is That An Incident In Your Pocket – Or Are You Just Happy to See Me?

By Anton Chuvakin | July 08, 2013 | 2 Comments

securitypolicyincident response

Here are some real-world examples of what some organizations consider to be a security incident (most of these are taken off Universities’ publicly posted security incident plans – these are great bedtime reading, if you are into that sort of thing):

  • “An IT Security Incident (“Incident”) is any activity that harms or represents a serious threat to the whole or part of […] computer, telephone and network-based resources such that there is an absence of service, inhibition of functioning systems, including unauthorized changes to hardware, firmware, software or data, unauthorized exposure, change or deletion of PHI, or a crime or natural disaster that destroys access to or control of these resources.” (source)
  • “A security incident can have the following definitions: Violation of an explicit or implied security policy, Attempts to gain unauthorized access, Unwanted denial of resources, Unauthorized use of electronic resources, Modification without the owner’s knowledge, instruction, or consent, Theft or displaced University IT property” (source)
  • “An information systems security incident is any event, suspected event, or discovery of a vulnerability that could pose a threat to the confidentiality, integrity, or availability of supporting systems, applications, or information.” (source)
  • “An incident is the act of violating an explicit or implied security policy.” (source)
  • “An information security situation that potentially poses a significant risk or could cause significant impact to University systems, assets or personnel would be classified as an incident” (source)
  • “The term “incident” refers to an adverse event in an information system and/or network or the threat of the occurrence of such an event.” (source)

BTW, I really like a clear definition reportedly used by the Verizon team in VERIS: “violation of one or more of the Parkerian hexad attributes.” On the other hand, “for many enterprises, the perception is that “[we] know an incident when [we] see it” (source: “Acting on Security Monitoring: Incident Response and Forensics”).

What do we learn here? RELATIVITY RULES!

What else do we learn? Based on one definition, you may have an incident every day! Based on another one, you have an incident once a year!

P.S. A bonus question: if 2-3% of your systems (that’d be 200-600 systems out of a pool of 10,000 machines) are always compromised and running malware (viruses, RATs, PUPs, etc), is that really an incident today? Can your daily norm ALSO be an incident at the same time? Or maybe it is an incident with an action plan of “nothing”…

Posts related to the same research project:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Mark Kedgley says:

    We try and explain this all the time to our clients when installing FIM and SIEM technology – in our book, if it happens all the time then either fix it at source to stop it happening, or change your definitions/alerts. We advocate a philosophy that the aim of security monitoring is to learn what normal/regular looks like. That way you can then spot the unusual/irregular – security incursions are not meant to be detected so you need to be tuned in to spot subtle irregularities.

  • @mark Thanks for the comment! Indeed, “irregular/abnormal + actionable = incident” at many places where a formal definition is lacking