How to represent MISP categories in STIX 2 (contextual categories)?

kill_chain_phases can be used to represent MISP categories. As this can be used in conjunction with existing ones like lockheed-martin-cyber-kill-chain.

"kill_chain_phases": [
{
        "kill_chain_name": "misp-category",
        "phase_name": "Network activity"
},
{
        "kill_chain_name": "lockheed-martin-cyber-kill-chain",
        "phase_name": "reconnaissance"
}
],

Attribute level taxonomies like the lockheed-martin-cyber-kill-chain can be derived from the attribute-level or event tagging where Lockheed Martin Cyber Kill Chain is used. This allows a bidirectional mapping of MISP events with STIX 2 format.

MISP extended the interpretation of the kill chain phase to allow a versatile definition which allows to map existing MISP taxonomy into a kill_chain_phases vocabulary as is (e.g. kill-chain misp taxonomy). As the STIX 2 standard requires the use of lockheed-martin-cyber-kill-chain, a mapping of the misp taxonomy name should be defined in the STIX 2 generation library.

OASIS CTI should reference a public repository of all known and existing kill_chain_phases to ensure common good practices.

How are the taxonomy/tag translated in STIX 2?

If the label is common property available on all SDO, MISP tags should be translated as full expanded value in STIX 2 label. This can fully support STIX 2 import/export in MISP but other STIX implementation would need to fully support MISP taxonomies to benefit from all descriptions. OASIS CTI should at least propose in the standard to support machine tags within the label property.

{
    "created": "2017-04-19T08:27:20.295887Z",
    "description": "Some contextual information",
    "id": "indicator--790465fd-c380-4c3d-a1d7-16dd4240637b",
    "labels": [
        "osint:source-type=\"blog-post\"",
        "tlp:amber"
    ],
    "modified": "2017-04-19T08:27:20.295887Z",
    "name": "File hash for malware variant",
    "pattern": "file:hashes.md5 = \"d41d8cd98f00b204e9800998ecf8427e\"",
    "type": "indicator",
    "valid_from": "2017-04-19T08:27:20.295887Z"
}

How to represent MISP IDS/Machine (to_ids) processing in STIX 2?

No concrete idea until now... but we cannot afford to loose this information in STIX from MISP.

There is some mention in the SIX 2.0 standard about the use of CoA in machine automatable courses of action.

course-of-action object could be used but which relationship to use? In the "Specification - Defined Relationships Summary", course-of-action relationship is only mitigates (no detection relationships) which is the default meaning of the to_ids in MISP.

Another easy option would be to use the label with the misp taxonomy prefix. It would be the fastest way and it could be even bidirectional. "labels": ["misp:to_ids:true"]

How to represent MISP deleted state of an attribute in STIX 2?

"STIX Objects are versioned using the version, revoked, created, and modified properties."

The revoked state could be used to set the revocation part (revoked with a timestamp) and use it at a deletion state in MISP. Versioning as is doesn't need to be supported as MISP relies on merging strategy for updates but the fields ( version, revoked, created, and modified) can be used to trigger within MISP but STIX 2 doesn't impose how the updates are done internally.

How to represent a MISP event in STIX 2?

The first idea was to use a Bundle to aggregate all the STIX objects into a meaningful MISP event. The issue is that the standard states that the bundle as 'A Bundle does not have any semantic meaning and objects in the same Bundle are not necessarily related'. So the Bundle definition is not MISP event as it has a semantic meaning.

In STIX 1.1, we used a package with incidents, as recommended by MITRE. Nowadays, it doesn't make more sense due to the dynamic of events in MISP and how people use and share the information.

In STIX 2, an option is to use report as the properties are matching the MISP event format. It makes sense but the main issue from a MISP perspective is that an event is dynamic and can be updated by any organisations. At the end, it's just a matter of interpretation of what a report is. Maybe the Report Label (report-label-ov) can include a misp type in addition. Multiple report-labels could be set and should not be an issue for tools importing MISP STIX import without knowing the MISP event label. Another issue is the vague interpretation of the labels field. Maybe a custom misp:type="event" could help? Especially to ensure importing back the STIX export into MISP?

Get our forked STIX 2 python library

If the standard submodule update command fails fetching the latest cti-python-stix2 library version, it is probably because the original library is installed.

The solution for this kind of issue is simply to set the cti-python-stix2 submodule url to our forked repository one:

cd ${your_path_to_misp}/cti-python-stix2

git remote set-url origin https://github.com/MISP/cti-python-stix2

git pull origin master

Then do not forget to update the python library:

${your_path_to_misp}/venv/bin/pip install -I . (or alternatively if it fails: pip3 install -I .)

Open Discussions with OASIS CTI

Proposals (SDO) made to OASIS CTI

Event proposal for STIX 2 (REJECTED)
Following a discussion with OASIS CTI (moving event to existing report) Report updates proposal (REJECTED)
Generic event proposal for STIX 2.1
Updated indicator SDO to extend with a pattern_language and pattern_version
Generic patterning for indicator (REJECTED)

Mapping

'to_ids' flag set to "True" => Indicator
Observed Data otherwise
Vulnerability type matching with the Vulnerability SDO
Some galaxy objects are also matching with STIX Objects

Discussions about events, attributes, classification, and so on

Confidence levels should be included in STIX 2.1
Some Galaxies types are tricky to classify with the existing SDOs

Things to handle

Attribute types "text", "comment" and "other" (=> waiting for the SDO 'Note' to be added)
Related events
Some Galaxy types ("microsoft-activity-group" for instance)

Osint feed export issues

(MISP events)

1128, 1813, 2202, 4625: Attributes duplicated (--> rejected by PyMISP)
7844: Attribute Tag duplicated (--> rejected by PyMISP)
9084, 9229, 9230, 9257, 9314, 9369: 'object_relation' field missing in Objects in Osint Feed events (--> rejected by PyMISP)
9301, 9375, 9387, 9391, 9499: 'object_relation' missing in Objects & Attributes duplicated (same as previous issues)
4956, 4957, 4964, 4965, 4966, 4973, 4975, 4976, 4983, 4984, 4990, 4996: No attribute in MISP (--> not accepted by STIX2)
5885: Error related to the Stix2 requirement regarding email address display-names that cannot be defined without email address values
6245: Stix2 registry keys should be of type WindowsRegistryValueType (--> STIX2 does not accept keys beside WindowsRegistryValueType)

Visualize directly all the objects id:

cat {filename} | grep "id\"" | grep "\-" | grep -v "CVE" | cut -f2 -d: | sed -e "s/\"//g" | grep -v "CAPEC" | grep -v "CWE" | sed -e "s/,//g" | sed -e "s/ //g"