Some of the Object names currently used within STIX and CybOX have certain connotations associated with them which color the way that those Objects are viewed, and therefore used. Some comments we’ve heard from people when discussing with them are that ‘but that’s what the Object is called’.
The objects that have been pointed out to us are:
Incidents
Within Incident Response circles the SOC Analyst performs an Investigation, and then calls an Incident when he/she has confirmed that malicious activity is occurring. This contrasts with the STIX Incident, which was developed for use at all stages of the Incident Response lifecycle.
Test_Mechanism
Most people when told of the Test_Mechanism idea say ‘oh like Signatures?’, which indicates that we’re probably using the wrong word. The complicating factor is that there are also OVAL and OpenIOC test mechanisms in there which have quite a different purpose to the rule focused snort and yara test mechanisms.
ExploitTarget
Most people I’ve spoken to have no idea what this is, and have to have the concept explained to them. Maybe this Object is actually conflating vulnerability, weakness and misconfiguration together?
Observable Instances and Observable Patterns
As mentioned in section 5 “Observable Patterns and Observable Instances differences aren’t easily discerned” many people find Observable Instances and Observable Patterns extremely confusing, and often interchange their use – especially in Indicators.
POTENTIAL ANSWER
To make STIX more approachable, we should survey the community to find out if there are any other names that they find confusing, and attempt to come up with replacements that make more sense to the STIX and CybOX populace. Some suggestions for alternative names are listed below:
Incidents
If we decide to create a new Investigation Object (see section 19) then this object can retain its current name. But if we do decide to keep the Incident Object an expand its functionality then its name should likely be changed to reflect that its scope covers the Investigation and Security Incident phases of the Incident Response process.
Test_Mechanism
I’ve only ever seen Snort rules used in a test mechanism. My personal preference would be to change the name of test mechanism to one of the following:
Rule
Signature
ExploitTarget
It could be worth separating the ExploitTarget information into 3 different sections:
Vulnerabilities
Weaknesses
Configurations
This would enable
Observable Instances
As mentioned in section 5 “Observable Patterns and Observable Instances differences aren’t easily discerned” many people find Observable Instances and Observable Patterns extremely confusing, and often interchange their use – especially in Indicators.
Some suggested alternative names:
Observation
Observable Patterns
As mentioned in section 5 “Observable Patterns and Observable Instances differences aren’t easily discerned” many people find Observable Instances and Observable Patterns extremely confusing, and often interchange their use – especially in Indicators.
PROBLEM
Some of the Object names currently used within STIX and CybOX have certain connotations associated with them which color the way that those Objects are viewed, and therefore used. Some comments we’ve heard from people when discussing with them are that ‘but that’s what the Object is called’.
The objects that have been pointed out to us are:
Incidents
Within Incident Response circles the SOC Analyst performs an Investigation, and then calls an Incident when he/she has confirmed that malicious activity is occurring. This contrasts with the STIX Incident, which was developed for use at all stages of the Incident Response lifecycle.
Test_Mechanism
Most people when told of the Test_Mechanism idea say ‘oh like Signatures?’, which indicates that we’re probably using the wrong word. The complicating factor is that there are also OVAL and OpenIOC test mechanisms in there which have quite a different purpose to the rule focused snort and yara test mechanisms.
ExploitTarget
Most people I’ve spoken to have no idea what this is, and have to have the concept explained to them. Maybe this Object is actually conflating vulnerability, weakness and misconfiguration together?
Observable Instances and Observable Patterns
As mentioned in section 5 “Observable Patterns and Observable Instances differences aren’t easily discerned” many people find Observable Instances and Observable Patterns extremely confusing, and often interchange their use – especially in Indicators.
POTENTIAL ANSWER
To make STIX more approachable, we should survey the community to find out if there are any other names that they find confusing, and attempt to come up with replacements that make more sense to the STIX and CybOX populace. Some suggestions for alternative names are listed below:
Incidents
If we decide to create a new Investigation Object (see section 19) then this object can retain its current name. But if we do decide to keep the Incident Object an expand its functionality then its name should likely be changed to reflect that its scope covers the Investigation and Security Incident phases of the Incident Response process.
Test_Mechanism
I’ve only ever seen Snort rules used in a test mechanism. My personal preference would be to change the name of test mechanism to one of the following:
ExploitTarget
It could be worth separating the ExploitTarget information into 3 different sections:
Observable Instances
As mentioned in section 5 “Observable Patterns and Observable Instances differences aren’t easily discerned” many people find Observable Instances and Observable Patterns extremely confusing, and often interchange their use – especially in Indicators.
Some suggested alternative names:
Observable Patterns
As mentioned in section 5 “Observable Patterns and Observable Instances differences aren’t easily discerned” many people find Observable Instances and Observable Patterns extremely confusing, and often interchange their use – especially in Indicators.
Some suggested alternative names: