enisaeu / reference-security-incident-taxonomy-task-force Goto Github PK

Please fix "Portugese" typo in the last Malaga meeting minutes. Should be "Portuguese".

From this code and below (defining 1st category, in JSON called "predicates" information is not exposed in human readable format).

In particular, let's take following predicates - some of them do not have bigger descriptions, but some have:
The ones which do not have (example):

"value": "abusive-content"
"description": "Abusive Content.",

"value": "information-gathering"
"description": "Information Gathering.",

While some predicates (1st classification category) has longer texts, which are not exposed in the human readable table):
"value": "malicious-code"
"description": "Software that is intentionally included or inserted in a system for a harmful purpose. A user interaction is normally necessary to activate the code.",

Suggestion - to modify https://github.com/enisaeu/Reference-Security-Incident-Taxonomy-Task-Force/blob/master/working_copy/humanv1.md - probably provide additional table for only predicates, or provide extra lines for each 1st category.

It seems that last changes of working copy human readable version file did not change the version from 1002 to 1003. While machine reading version is already at 1003.

Should working copy Human readable version should be updated to 1003?

Vilius Benetis

title should be changed for clarity:
current "# REFERENCE TAXONOMY INCIDENT Taxonomy (human readable version)"

suggestion to change to "# Reference Security Incident Classification Taxonomy (human readable version)"

Child Porn and Child pornography are not terms used nowadays. Time ago specialists and authorities started using instead Child Sexual Exploitation (CSE) and/or Child Sexual Abuse (CSA) as more appropriated terms to refer these crimes.
I guess it makes sense to update the taxonomy to reflect current denominations.

One of the purposes of using an incident taxonomy, next to many, is to have a view on trending of security incidents for your organisation and then map this to the 'public' threats. The reference material to use is the Threat Landscape Report from ENISA.

Current taxonomy misses a link with the threat taxonomy used in the TLR.

see subject

ransomware/backdoor is missing

There are two values with upper case letters:

Is this by intention? All others are lower case only

As discussed in the meeting in Paphos 9/19, it would be great to have a script that pulls the latest version of the machine readable file and may install it as custom fields into RTIR.
(possibly the same is doable for OTRS?)

Future versions of RTIR could hopefully include the taxonomy as custom fields by default

Could be

• Information Content Security > Unauthorised modification of information (like defacement) or
• Abusive Content or
• Fraud (tricking users and search engines)

The taxonomy uses the term Information Content Security. but it's not clear why it contains 'Content' instead of simply being Information security.

This is just a reminder to discuss how dropzones can be classified in the RSIT, as discussed on the mailing list to reach a consensus and document that.

We mentioned a couple of times that the taxonomy says nothing about the situation of multiple values.
One could imagine a situation where multiple values make sense (for example assigning "Vulnerable"/"Weak crypto" as well as "Vulnerable/"DDoS Amplifier" to a web server which also hosts a (open) DNS server).

I guess it's ok to use the taxonomy tags differently in different contexts. But some text describing how the taxonomy should be used in different contexts might make sense.

At the meeting in Hamburg we discussed that there are multiple use-cases for the taxonomy. Maybe listing the known use-cases brings in clarity to this topic.

But the question of multiple values really should be addressed before we even start comparing stats which follow the reference security incident taxonomy.

Unauthorised access to information and Unauthorised modification of information

vs.

Unauthorized use of resources

Even if as a CSIRT you usually don't have to deal with illegal content (e.g. "child exploitation") per se. It happens that we receive materials or information which need to be acted upon and forwarded to the appropriated organisation (e.g. INHOPE or national stop line). I would recommend to add an "illegal content" classification to properly label such information for manual or/and automatic processing.

To not forget what we wanted to change in an upcoming major version, we collect some non-urgent, but major changes here:

• convert all names to singular (#114)
• rename information-content-security to information-security (#113)

The RSIT is described as a reference taxonomy for "security incidents" - is this term currently formally defined in the RSIT, and if not, should it be?

For example, I note that the current version of RSIT includes things that might be thought of as physical security issues (e.g., "Burglary" or "Sabotage") and safety or business continuity issues (e.g., "Outage"). Does the RSIT therefore cover these as well as cyber security incidents, and is this worth explicitly stating (via a definition)?

As a starter, NIST has a range of definitions, as does the UK's NCSC. ENISA has a glossary but this doesn't include anything to do with incidents.

Some RSIT use Plural in the (sub)classification names:

• Intrusion Attempts
• Intrusions
• Login Attempts
• Potentially Unwanted Accessible Services

However, most of them are in singular:

• Denial of Service
• {Account,Application,System} Compromise
• Unauthorised Modification of Information
• Misconfiguration
• Vulnerable
• Burglary
• Vulnerable System
• Phishing
• etc.

Use of singular seems better suited. If you suffer an incident it is an intrusion, not intrusions.

Expected action: rename the plural names to singular form

The machine readable version currently includes several additional values not included in the human readable version, e.g. under "malicious-code" or "intrusions".

Running convert-rsit-to-attck.py creates new uuids on clusters/rsit.json and galaxies/rsit.json (in addition of reordering the output), resulting in semantically different files.

I would propose the addition of a predicate called "exercise" to tag information if this is part of an exercise.

rsit:exercise="cyber-europe-2018"
rsit:exercise="locked-shields-2019"

This helps for automation and filtering to avoid polluting production sharing communities.