The Difference Between Events, Alerts, and Incidents

If you’ve been in information security for a while you’ve probably heard people saying things like the following on many occasions:

…etc. We basically have a dumpster fire of mixed terminology.

There could be variance in these definitions due to differences in their businesses and their needs.

There is deep confusion—even among those in the field—about what constitutes an event, an alert, and an incident.

Here’s my breakdown based on analysis of many different industry definitions:

All incidents are events, but all events are not incidents.

• An event is an observed change to the normal behavior of a system, environment, process, workflow or person. Examples: router ACLs were updated, firewall policy was pushed.

• An alert is a notification that a particular event (or series of events) has occurred, which is sent to responsible parties for the purpose of spawning action. Examples: the events above sent to on-call personnel.

Many are tempted to consider attempts to be incidents as well, but if we counted those in most organizations we’d have thousands or millions of incidents per day.

• An incident is an event that negatively affects the confidentiality, integrity, and/or availability (CIA) at an organization in a way that impacts the business. Examples: attacker posts company credentials online, attacker steals customer credit card database, worm spreads through network.

Summary sentence

If you had to capture it in one sentence, I’d go with this:

NIST and CERT define incidents as policy violations, which I believe to be impractically broad. Policy violations are usually far too numerous within organizations to be elevated to this status.

Notes

1. It is possible to define incident in a number of ways based on the organization, and it’s ok for there to be some variance based on different organizational needs. But it will always be a special type of event that requires an organized and timely response.

2. NIST and CERT define an incident as a violation of explicit or implied policy, and in my opinion that’s far too common in most organizations to be practical. When deciding how broad or narrow of a definition to use, consider that all incidents should spawn an IR response. If you’re not able to do that because there are thousands or millions of them per day or week, adjust your definition accordingly.

3. Another important point on this definition of incident that I’m using is that it must impact the business. If it negatively affects CIA but there is no impact to the business, it seems strange to label that as an incident in the same way as something that does.

4. CERT uses the NIST 800-61 definition of “An incident is the act of violating an explicit or implied security policy.”

5. Many would-be incidents are either human-caused but non-malicious, or are human/malicious but don’t become an issue, but unless both are true simultaneously they aren’t often handled by the information security department. E.g., earthquake, HR update.

6. There is some debate on whether to call something an event if it was not captured. I’m in the camp that says you don’t, which is why I defined it as an *observed* change.

7. “Disruption of business” doesn’t just mean that the business is unable to function; it could also mean that those running the business have completely lost their sanity and are demanding answers.

Related posts:

1. An Information Security Glossary of Terms

2. Cybersecurity

3. Information Security