Missing Properties about cti-stix-elevator HOT 13 CLOSED

may be connected to #6, but because of the wording used I'm not completely sure

from cti-stix-elevator.

Some target_refs are not possible to create. Most of the time it is because a STIX 1.x TTP doesn't contain enough information to convert it to one of the supported types in STIX 2.0 (victim identity, malware, attack pattern, tool). Is this the case? If so - you should see a message to that effect.
Otherwise, please send me a STIX 1.x document that exhibits this.

bundles that are missing spec_version seems strange, since it is hard-coded for all bundles created by the elevator. Sending a document that has this behavior would also be useful.

#6 pertains to STIX 1.x properties not directly representable in STIX 2.0 - so it is unrelated

from cti-stix-elevator.

That would be the case for the relationships
here is the file that is missing the spec_version after being passed through. I got it from polling hailataxii.com
test.xml.zip

from cti-stix-elevator.

Here is what was produced when I ran the elevator locally. The bundle's spec_version is in bold.

{
"id": "bundle--26f03880-1338-4768-91e7-68861b5a2e4b",
"identities": [
{
"created": "2016-11-29T12:40:17.306071Z",
"id": "identity--5d74c958-1704-4281-a9f2-7d858fd033de",
"identity_class": "unknown",
"modified": "2016-11-29T12:40:17.306071Z",
"name": "www.malwaredomainlist.com",
"type": "identity",
"version": 1
}
],
"indicators": [
{
"created": "2015-04-23T02:07:02.758292Z",
"created_by_ref": "identity--5d74c958-1704-4281-a9f2-7d858fd033de",
"description": "This domain aminev.com (69.89.22.122) located in US (United States), has been identified as Malious [Script.Exploit] by www.malwaredomainlist.com. For more detailed infomation about this indicator go to [CAUTION!!Read-URL-Before-Click] [http://www.malwaredomainlist.com/mdl.php?search=aminev.com].",
"id": "indicator--00055363-d2e5-4f2d-891e-54bc543b8d5c",
"labels": [
"benign",
"benign",
"benign"
],
"modified": "2015-04-23T02:07:02.758292Z",
"name": "Compromised Site: : aminev.com/HSBC_BANK-STORAGE.DATA/new_payment-document.html",
"pattern": "PLACEHOLDER:opensource:Observable-be80298d-913a-4071-9c05-4b8ca988e856",
"type": "indicator",
"valid_from": "2015-04-23T02:07:02.758292Z",
"version": 1
}
],
"relationships": [
{
"created": "2016-11-29T12:40:17.306149Z",
"created_by_ref": "identity--5d74c958-1704-4281-a9f2-7d858fd033de",
"id": "relationship--957a16c5-7d47-4f5f-9efa-718c872a4a14",
"modified": "2016-11-29T12:40:17.306149Z",
"relationship_type": "indicates",
"source_ref": "indicator--00055363-d2e5-4f2d-891e-54bc543b8d5c",
"type": "relationship",
"version": 1
}
],
"spec_version": "2.0",
"type": "bundle"
}

On the other hand - this STIX is "missing" a lot of object, that are only referred to via an idref

from cti-stix-elevator.

wait that was the wrong file
STIX_data.xml.zip

from cti-stix-elevator.

and here is the result I get out of it
STIX_data.json.zip

from cti-stix-elevator.

Hmmm - the second xml file you sent was output from taxii, with many STIX package objects - the elevator only takes one STIX package at a time. Was one of the STIX packages in that file related to the json file you generated??

Also, that json file is malformed - the top level object should always be a bundle... I'm not sure how the elevator could have generated it.

from cti-stix-elevator.

I see the problem now it's the system I have parsing the parts of the bundle

from cti-stix-elevator.

@rpiazza Hey Rich, in reference to your first comment, surely even if the elevator can not uplift some STIX 1.x constructs, it should not result in outputting an invalid document? It should either abort outright, or skip the unsupported objects.

from cti-stix-elevator.

The elevator will (soon) have command line options to decide how serious the users thinks a particular warning is - so you will be able to decide how you want the elevator to handle them.

Sometimes you want to see the "invalid" output from the elevator. Looking at it can help you determine how to "fix" the original XML document. Whether to output invalid documents could be one of the command line options.

The elevator is designed to put any "unsupported" objects in the description fields. That will also be controlled via options.

from cti-stix-elevator.

from @JasonKeirstead:

@rpiazza OK - from my understanding conversing with @IanmacIBM , what happens right now is it is not putting unsupported objects in the description fields - it is outputting an invalid document because it is creating relationships with no valid targets. I would suggest that if the target of a relationship is not created, then the relationship should also not be created.

from cti-stix-elevator.

If you look at the first example that @IanmacIBM gave me (see above comment), the reason why the relationship has no target ref is not because the target is unsupported, but it is a "dangling" idref, and there is no target object, which is a slightly different case. In general, in cases like this we could just put in the converted ref, however, since this idref is to a ttp, we can't create the appropriate 2.0 ref because we have no idea what object type it will be in 2.0. Perhaps we could put in the 1.x idref - but that would also be invalid.

As I said above, soon you will be able to control what to do, for instance, when your document contains a dangling idref. It seems like you would want it to produce no output. OTOH, just leaving out the relationship object would be a problem for different reasons.

from cti-stix-elevator.

See #34

from cti-stix-elevator.