Skip to content

IDMEFv2 : Format comments

Jump to bottom
Gilles Lehmann edited this page Jan 18, 2023 · 17 revisions

This page details global choices made for the IDMEFv2 classes and attributes.

Purpose and coverage of the format

IDMEFv2 is planned to be a standard format that all Incident Detection Systems could use for reporting what they have deemed to be suspicious or of interest.

Few precisions :

  • IDMEFv1 was cyber-security oriented, IDMEFv2 still covers cyber incidents but also includes physical incidents
  • The I of IDMEFv1 was for Intrusion, IDMEFv2 is larger and covers Incident (which includes Intrusion)
  • IDMEFv2 is not a universal log or event format, IDMEFv2 is restricted to event suspicious or "of interest". Definition of suspicious or of interest events depends partially on the Security Policy of the organisation but it's not "all" the events.
  • In IDMEFv2, security is considered globally, this includes the triad Confidentiality Integrity and Availability

Event vs Incident

An event is something that triggered a notice. Any incident starts off as an event or a combination of events, but not all events result in an incident. Although IDMEFv2 is made for incident detection system, it can describe an event "of interest" but not yet considered as an incident.

Example : A successful authentication should usually be considered as a "normal" event. But there are some situation when it can become an incident :

  • authentication successful in the middle of the night,
  • authentication successful after hundreds of failure,
  • authentication successful with the account of someone who has left the company,
  • ...

To identify such scenarios incident detection system needs to correlate "event of interest", which are not yet incident, with external information (e.g. business hour, HR information, etc.) to verify if those "event of interest" are or not incidents.

Defining which events are considered "of interest" is closely dependant of the organisation security policy.

Alert Class name choice

An alert is a notification/message that a particular event/incident (or series of events/incidents) has occurred.

The Alert Class could have been named "Message Class" or even "Event Class".

We have kept the name Alert which is already used in IDMEFv1. Alert implies that IDMEFv2 should not be used for all events description (IDMEFv2 is not a log format) but only events of interest.

"Event" could lead to a misunderstanding on the goal of IDMEFv2. IDMEFv2 goal is Incident detection, not Event logging.

"Message" could be used but it doesn't implies the "specificity" of the events being described, it's not a plain event, it's an event that need to be notified and potentially further analysed. Operator needs to be "alerted".

Last choice could have been "Notification", but then again it's a little weaker than Alert in terms of potential threat.

In physical incident detection systems, the term "Alarm" is often preferred. But the two terms Alert and Alarm are close enough for no misinterpretation.

Severity, Priority, Impact, Urgency

Draft V00 includes a severity attribute in Alert Class. It may not be satisfactory.

Severity is a global term related to other criteria as urgency, priority impact.

Impact

Impact defines the enormity of the situation and mostly deals with “How Many” question. It can be in terms of people, finances, systems, etc. How many people and/or systems impacted, how badly are they impacted (is there potential physical impact ?) , how much financial loss, severity of legal liabilities,... Impact could be considered equivalent to "Severity".

Impact essentially depends of :

  • target : how large is it , how critical is it
  • vector : how dangerous/destructive is it
  • classification : what is the dangerousness of this category on this target

Urgency

Urgency is associated with time. The time it takes to have the perceived Impact. For example, a high impact incident may have low urgency if the impact will not affect the business until the end of the financial year.

Urgency essentially depends of :

  • vector : how fast is this vector
  • classification : how fast is this kind of incident on this target

Priority

Priority is usually determined by assessing its impact and urgency.

Priority is often defined through the use of a matrix combining Impact and Urgency.

Basic matrix

Questions

  • Should there be three attributes : impact, urgency, priority or only one (maybe priority instead of severity)
  • Is it possible to set values to those attributes before further analysis ?
  • If it is possible maybe those values can change when analysis progress
  • Where is the information ? Is it possible to set it automatically in the analysers ? in the manager ? from the operator ?
  • If we keep only one attribute should we replace severity by priority ?

Locations

Three location attributes are available :

  • Geolocation : GPS Coordinates (e.g. "48.858370, 2.174081, +330") Used for distance calculation or object display on a 2D or 3D map, this information is not easily readable for the operator
  • Unlocation : United Nations Economic Commission for Europe (UNECE) Codes for Trade (e.g. "FR PAR") Used to differentiate origin of the alert in case of muti-sites, multi-countries organisations or if the alert is meant to be sent to an external centralized security center for example.
  • Location : String (e.g. "Buiding A, Room 506" "Room Archimede") This is a local description of a location in the organisation. This should be the term used by the organisation people to designated the place so the operator can identify the location very easily.

Depending on your organisation and your incident detection system architecture one may use or not each location attribute. A small business, located in a single place deploying only cyber detection system (no physical detection) might not need geolocation and unlocation. Location might still be useful to rapidly spot where a server is physically located in the building for example.

Comments :

  • In theory, the location attributes of the analyser or the target could have been stored else where in the organisation internal data (e.g. CMDB) and IDMEFv2 would only contains an ID pointing toward those information, but it seems to be more effective for them to be directly stored in the alert for better analysis/computing in the detection system and information to the operator.
  • Before deploying a new IDMEFv2 architecture, if the location attribute is needed one has to define a location dictionary/taxonomy for every place where incident can be detected. This taxonomy has to be inspired from the day-to-day language in the organisation.

Category

Defining Incident Category enumeration is a challenging task.

First choice is to leave a free string attribute. Everyone can define his own category taxonomy in relation with his private needs and security policy. It sounds easier but it's the opposite choice of a standard. Without using a closed list of choice it is very difficult to compare, analyse, correlate alerts together with generic rules and algorithms. The same category incident will have a different signification depending on the team deploying the system, etc. This was the choice in IDMEFv1 and experimentation showed it's not a good choice.

Thus, there is obviously a need for a closed list (enumeration) of categories.

Incident categories can be very numerous, the best choice is to build a hierarchic tree of categories with classes, sub-classes and so on.

Then comes a second difficulty. There are so many categories of incident that it is complicated to define a closed list without hundreds of elements. It's even more difficult if you want to have the same single list for all types of cyber and physical incidents. A mistake would then to be too exhaustive with a very complex category tree with different and limitless depth on each branches. Trying to be too exhaustive could even lead to misinterpretation as the category tree would be very difficult to learn and master.

Due to this analysis, we ended with four "consensus" limits :

  • No more than two levels of depth for the classification tree
  • Approximately no more than 20 to 30 "master classes"
  • Approximately no more than 100 sub classes.
  • optional : If possible some balance between the sub-classes (i.e. not one master class with 80 sub classes and one with only three)
  • TBD : Keeping an optional third level class for "private" use ?

Finally, to avoid the "NIH" syndrome we tried to find existing categories classification we could re-use. Here is a short summary of this analysis :

Conclusion

  • The RFC will included an incident taxonomy based on ENISA and CRED taxonomies to cover all the needs.
  • This taxonomy will be tuned during the standardisation process (TBD) attributes, subclasses, etc.
  • The AltCategory attributes offers the possibility to use an external category based on alternate taxonomy (e.g. MITRE, MISP, etc.)

Alert Immutability ?

During the lifetime of an alert some complementary informations can be added or modified in the original alert object. This could be the result of correlation, external enrichment, operator analysis, etc.

Two choices are possible :

  • Alerts are immutable : If an alert needs to be completed/modified a new alert will to be generated (with a new UUID)
    • The new alert might contains only the modified/information with a pointer toward the original alert or a complete copy of the original alert. This choice might lead to complex recursivity cases of "chained" alerts.
    • The new alert completely obsoletes the old alert.
  • Alerts are mutable : Alerts can be modified without generating new alerts and new UUID. The new alert has the same UUID and contains a pointer to the original alert, indicating it obsoletes it.

The two option have pros and cons (TBC):

  • Multiplication of alerts
  • Storage of obsoletes alerts
  • Related alerts (through UUID)
  • Etc.

TBD : Leave the choice to the integrators ?

Confidence : Attribute vs Class

Some incident analysis format implements confidence as a class that can be linked to different attributes. One can indicate confidence in the detection, confidence in the category, confidence in the severity, etc. There are some pros as the confidence might not be the same for all the alert attribute, but this choice would go against the principle of IDMEFv2 of limitation as much as possible of complexity and classes number. It's also rarer in detection, before analysis stage, to have such details about each attributes.

Confidence attribute in IDMEFv2 is a global attributes, sort of "average value" of all attributes confidence values.

Future events

IDMEFv2 can be used to alert organisation of possible future threats.

Typical examples of future threats are natural hazards forecast :

  • Heatwave for the next three days on all department, possible wild fire in the close forest
  • Snow storm and extreme cold on the city starting tonight around midnight and probably finishing in two days

Future threats can also be linked to human activities :

  • New covid pandemic wave in the country which might for example induce the wear of the mask and no face detection possible or a significant absence of contaminated security employees
  • Possible power shortage due to energy restriction (because of war) next Monday between 10h and 15h.
  • Crowd of people passing close to the building on Saturday afternoon between 14h and 22h due to protest against inflation (possible burglary and/or sabotage)
Clone this wiki locally