oasis-tcs / cti-stix2 Goto Github PK

The addition of capabilities to STIX 2.0 to capture text in multiple languages.

Work area: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4

Scope

Capabilities required to capture multiple languages for content in STIX. Translatable content includes text strings (name, description) and potentially open vocabularies.

Examples

1. Content provided in a single language
2. Providing content in multiple languages at the time of creation
3. Providing a single object with different fields in different languages
4. Third-party translations (one publisher creates the original content, another publisher creates a translation).
5. Field in cyber observable is supposed to be in one language, but includes characters from another language by mistake.

Open Questions

• Approach to representing additional language content
• Approach to marking an object with several languages (granular markings)
• Approach to capturing the concept of multiple official languages

We should add a new parent_directory_ref property to the Directory Object, for specifying the parent directory of a directory. We already have a very similar parent_directory_ref property on the File Object.

The src_ref and dst_ref properties in Network Traffic have descriptions that refer to a list, but the property itself is a single value. The description should be corrected.

In part 4, section 2.7.6.3: all properties of windows-pe-optional-header-type are optional. We should add a normative statement that says at least one property should be populated.

https://lists.oasis-open.org/archives/cti-comment/201705/msg00005.html

Dictionary keys in the hashes property on the File Object MUST come from the hash-algorithm-ov. Clarifying text added to 2.1, Part 4 in suggestion mode.

The development of one or more SDOs to capture incident and event information.

Work area: Working Concepts

Scope

The capture of information related to internal security events, internal security incidents, and external security-relevant events.

Examples

• A malware infection on an internal laptop
• Tracking an incident response to an APT intrusion
• A threat actor changes a C2 domain
• Reporting an incident to a third-party, such as US-CERT or DC3
• Public incident repositories, such as VERIS

Open Questions

• Is there a single SDO to capture both incident and event information?
• If so, how is the status "incident" captured?
• Do you need to distinguish between internal, security-relevant events and external information?
• How do you track workflow/timestamps?
• How do you track POCs?
• How is it related to observed data?

The service_name property in the Windows Service Extension of the Process Object (Part 4, §2.13.3) is currently required. To support additional use cases, such as capturing malware configuration parameters (without the service name), we should make it optional.

Jason pointed out that we're missing a way of describing Windows named pipes, so we likely need to add a new Windows Named Pipe Observable Object to do so.

Currently, the user_id property is required in the User Account Object (Part 4, §2.16). To support use cases such as capturing a password used by malware (embedded as a configuration parameter) without a corresponding user ID, we should consider making this property optional.

Jason brought up some questions around network shares and patterning:

• How to match on network shares
• How to match on if said share is hidden or not

I think the main implication here is that we'd need a new Network Share Cyber Observable Object.

Enhanced malware capabilities will create enhancements to STIX (new objects, new properties on existing objects) to capture more in-depth malware analysis information. The intent is to capture much or all of the information that is currently expressable in MAEC directly in STIX.

Work area: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.s5l7katgbp09

Scope

• High-level characterization of malware used primarily for threat intel
• Low-level characterization of malware behavior used for malware analysis (e.g. sandbox output)
• Malware instances
• Malware families

Examples

• DarkEnergy (family)
• Poison Ivy Instance w/ Hash XYZ (instance)

Open Questions

Still being determined.

The Infrastructure object would capture information about adversary infrastructure, such as command and control servers, download sites, e-mail delivery, etc.

Work area: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.maky5z1n51ds

Scope

Still being determined.

Examples

• C2 servers for a particular campaign
• E-mail delivery typically used by an intrusion set

Open Questions

Still being determined.

Jason pointed out that we currently can't characterize whether some network traffic was denied/blocked access or allowed in the Network Traffic Cyber Observable Object.

Allan has suggested adding first_seen and last_seen fields (both optional, presumably) to the relationship object. This would let you track, for example, the time period when a malware object was used-by an intrusion-set.

Many relationships are only valid for some time period...for example, malware may only be used by a threat actor for some period of time. Optional valid_from and valid_to properties would let you capture that, when relevant.

Per CSDPR02#6 (https://docs.google.com/spreadsheets/d/1YOPONeKzc6Uu1A1MS3WkICG26LKLQOWdr-KBDzM8K6Y/edit#gid=5055878), the TC should define further normative rules for referencing external IDs (e.g., CAPEC, LMCO kill chain phase names).

TODO:

• Develop list of external sources we need defined names for
• Implement in text

The following sectors are not mentioned in the industry-sector-ov:

• Chemical Sector
• Commercial Facilities Sector
• Dams Sector
• Nuclear Reactors, Materials, and Waste Sector
• Water and Wastewater Systems Sector

the term Sector could be omitted

There are a few missing entries in the current Malware Label Vocabulary, so I propose that we expand the current vocabulary with the following:

Oh, and the 'unknown' value is necessary because the labels property is required and there are cases when you may not know the "type" of malware being characterized.

Jason pointed out that we currently can't characterize signed vs. unsigned processes and drivers in Cyber Observables. For processes, this would mean adding a new property to the Process Cyber Observable Object. For drivers, we'd have to add a new Cyber Observable Object.

I think I am looking at an incorrect link in table 2.5.1 of "STIX Version 2.1 - Part 2 - WD01". This is the property table for the Indicator object. The link is called "STIX™ Version 2.0. Part 5: STIX Patterning" but it doesn't go to the Patterning specification like I think it should.

It has been pointed out that our current encryption-algo-ov is missing some key values, so we should consider expanding it with the following (as a minimum):

AES-192, AES-256, RC4, RC5, RC6

Jason pointed out that we're missing a way of describing windows scheduled task, so we likely need to add a new Windows Scheduled Task Cyber Observable Object to do so.

The name property on the Windows Registry Value Type (Part 3, §​2.17.2) is currently required. In order to support additional use cases, such as capturing malware configuration parameters, we should make it optional.

Enhanced course of action capabilities includes things like automated COAs (OpenC2, others), extra impact statements, and playbook-type capabilities.

Note: this issue may be split in the future

Work area: https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.uilqxp59env4

Scope

Still being determined.

Examples

Still being determined.

Open Questions

Still being determined.

In the “Basic Stream Socket” socket-ext example: is_listening should be a boolean, not a string.

In STIX 2.0, marking definitions cannot be versioned.

Allan Thomson has suggested allowing versioning of them. The idea is that it would reduce network traffic and that the end result is the same.

I've heard two sets of requests:

• One of MITRE's sponsors wanted to see a description field on observable objects
• MISP wanted to see labels and description on observable objects

We should allow some marking definitions to be referenced in an external document like TOU and other Statement documents. To do this, we will also need to add a hash to make sure that nothing gets changed out from underneath the consumers.

In STIX 2.0, artifact objects are limited to 10MB. This was done to prevent parsers, which sometimes can't handle bigger files, from choking on the JSON. Discussion on Slack and the mailing list suggests that it might be fine to just remove the limit, because many parsers are able to deal with larger files. Removing the limit would then allow for the submission of larger files directly in STIX (vs. via URL).

If we don't remove the limit we should at least properly define it as either 1024 x 1024 (MiB) or the "correct" 1000 x 1000.

Jason pointed out that we're missing the ability to characterize the access level/integrity level granted to a process in the Cyber Observable Process Object. I'm not sure if this makes sense to add to the base object, or if this is something Windows-specific and would need a new extension.

Now that some of the STIX objects are using the dictionary type, we need to move the definition of it from part 3 to part 1.

During 2.0 development there was a view that we should just use labels to track the object classification data, like indicator type, report type, malware type, etc.. On the surface and at the time, this seemed like a good thing to do.

The problem I am seeing now is that I have no way of distinguishing in an automated way the content in the labels property. Meaning, are the values extra entries to the open-vocab or are they just extra user-defined tags? As such I have no way to pivot off this data because I do not know what type of data it represents.

I would propose for those few objects that we either move the object type classification out of labels, or that we make a new property called tags and change the text to say user defined "tagging" goes in tags and the object classification/type information goes in labels.

The development of capabilities in STIX to capture a producer's confidence in the data that they create.

Work area:
N/A

Slack: #confidence

Scope

Whatever is necessary to capture producer's confidence in the data that they create. It does not include expressing confidence in another producer's data or confidence in producers.

It's also scoped to only confidence at the STIX Object level - not on individual fields.

Examples

• A threat intelligence creator publishes a campaign and says they have medium confidence in the accuracy of the information.
• A threat intelligence creator publishes a relationship between a malware and a campaign, saying they have high confidence that the campaign uses that malware.

Open Questions

• How to represent the confidence value (consensus: 0-100 scale w/ normative mappings)
• Which objects have a confidence value (consensus: all of them)

While writing tests to support the LanguageContent object I found myself with a problem using the contents dictionary. I saw RFC5646 supports language tags longer than 2 characters, but the STIX specs mandate 3 or more for keys in a dictionary. The examples found in the document use language tags that are too short. Will this mean that producers need to provide a more specific language tag?

Affects: Section 2.2 Dictionary

Should there be an exception to this MUST requirement or remove the requirement completely?

The Admirality scale we used for the confidence mappings has an item called "(Not present)" for "Truth cannot be judged". The intent was that the property is omitted, but that isn't really clear.

Some of the other scales say "Not specified", which also isn't consistent. This isn't a normative change, just a clarification to text.

Per CSDPR01#20 (https://docs.google.com/spreadsheets/d/1TCNdwL9o4lbblsIlDfeV0mHsBVGMdbFgwp95dhLLfaI/edit#gid=5055878), the community should consider adding a relationship from an indicator to a vulnerability saying that the indicator "indicates" the vulnerability.

The development of capabilities in STIX to capture the location of STIX Objects.

Work area:

• John's Proposal
• Allan's Proposal: See slack channel

Slack: #location

Scope

Any capabilities necessary to represent location information for STIX objects.

Examples

• A threat actor targets victims in some geographic area
• A sighting was seen by an organization from some geographic area
• An information source is from some area or has some address
• A threat actor is located in some area
• Malware originated from some area
• Usage in cyber observables (TBD)

Open Questions

• Separate SDO (Allan's proposal) or field on other SDOs (John's proposal)
• Format to use for geolocation (lat/lng/radius/etc)
• Format to use to capture civic address information

RFE to implement the Classification proposal as in the playground document. This proposal would allow threat intelligence vendors to indicate the "known good" as well as the bad.

Note, I do not care what the name is. I just can not come up with a good name.

https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.snfvxw2o7p1u

There are a few examples in Part 5, STIX Patterning that are missing quotes around object path components that use dashes ("-").

Here are the fixed versions:

Section 5.2
file:extensions.'windows-pebinary-ext'.sections[*].entropy > 7.0

Section 5.3
file:extensions.'raster-image-ext'.image_height

Section 6
[file:extensions.'windows-pebinary-ext'.sections[*].entropy > 7.0]

@chrisr3d (from CIRCL) proposed making the value property on the Email Address object (STIX 2.0, Part 4, §2.5) optional to accommodate cases where folks want to share information about the intended target of a spear-phishing campaign specifying the email display name but omitting the actual email address of the intended victim.

The proposal would be to make the value property optional and add normative text that at least one of value or display_name MUST be present.

Jason had some confusion with regards to the process image name vs filename vs command line on the Cyber Observable Process Object and when you'd use each, so we should try to clarify the descriptions of these properties as necessary.

Hi All,

"pattern" property of "indicator" could support STIX, YARA, Snort, OpenIOC, etc. with "pattern_lang" property in earlier draft version of STIX 2.0.
But, current draft support only STIX.

I think the former is better because it can support more wide use cases, specifically, legacy(not STIX) but commonly used nowadays such as YARA, Snort, OpenIOC.
They are almost "de facto" standard still now.
I hope STIX 2 should have comprehensiveness.

Let's re-think our earlier decision.

In STIX 2.0, there is a relationship from Malware to Vulnerability named "targets". For STIX 2.1, we recommend replacing this with a new relationship of "exploits" that is semantically clearer and less ambiguous.

As discussed on Slack, being able to mark Malware SDO objects as benign would allow the sharing of false-positive sandbox analysis results.

The Intel Note object would allow information sources to add intelligence notes to objects created both by themselves and by others. For example, a comment with more information could be added to an existing object.

Work area: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.uovlit7natfj

Scope

The intel note object will be scoped to only capture notes about STIX Objects (not fields in objects).

Examples

• Producer A adds a note to an object published by Producer B
• Producer C adds a note to an object they published themselves

Open Questions

• Does there need to be a separate field to capture the author of an intel note? If so, what does the field look like?
• How do you differentiate an intel note from an opinion? From a report?

Propose a default value (from the open vocabulary) when a label is required on a SDO.

At the very end of the 2.0 development and editorial process it was brought up that there was no way to verify the external references content that you were pointing to in the url field. The TC decided that we should try and solve that for 2.0. We noticed that we had this "hashes" type in cyber observables, so we just used that, without any real thought to the implementation.

The hashes type is a dictionary where the key is pulled from an open-vocab. As I have written a tool to handle this now, I have found it near impossible to do anything with this. The problem comes from variability in the data. There is nothing you can count on. As an implementer you will need to add library support for every known type of hashing algorithm that is in the open-vocab and then try to figure out what to do with something that is not in the open-vocab but that a user just adds.

This makes interoperability very painful and difficult. It also adds enormous unnecessary complexity on code.

I would like to propose that we make a breaking change, and change this to a "string" type and say in the description that the type for this release MUST be SHA256.

Per CSDPR02#7 (https://docs.google.com/spreadsheets/d/1YOPONeKzc6Uu1A1MS3WkICG26LKLQOWdr-KBDzM8K6Y/edit#gid=5055878), any time there's a first_* timestamp and a last_* timestamp, we should add a normative requirement saying that the first_ timestamp MUST be before the last_ timestamp.

I noticed that the examples in Part 5, Section 5 are not valid Observation Expressions, since they're missing their opening/closing brackets. We should fix this - I've already made the corresponding changes in STIX 2.1 Part 5.

The Opinion object would allow information creators to assert their opinion about objects created by other producers.

Work area: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.haeazu2sh3sq

Scope

The opinion object will be scoped to only capture opinions about STIX Objects (not fields in objects).

Examples

• Producer A expresses agreement (+1) to an indicator published by ISAC B
• Producer C expresses disagreement with a campaign characterization from ISAC D

Open Questions

• Should the Opinion object have a text description field?
• What description does the Opinion need to differentiate from the Intel Note object? Or, should they be merged?
• What scale does the object use?