Cannot set string condition for RawArtifactType on Artifact Object
david74552 opened this issue · comments
I have seen usage of condition="Contains" for the RawArtifactType on an Artifact Object in the wild and would like to replicate this effect using the cybox artifact_object.
As far as I can tell, there does not appear to be a method to set the condition until after it has been exported to xml.
Even in the object form which is attached to the STIX object as "observable._object._properties", it still only has the "_data" and "_packed_data" objects exposed.
Am I missing something (#200)? or was the package I saw in the wild edited by hand and this part of the schema not added to the code-base?
The Artifact object inherits from ObjectProperties - which enables you to set the condition:
Try this:
a = Artifact()
a.condition = "Contains"
I don't think it's as easy as that, @rpiazza . You want to set the @condition on the raw_artifact property of the Artifact object, not the Artifact itself. Due to the complexity of what we do with data and packed_data (which is what #200 is meant to document), we don't let the user explicitly create a Raw_Artifact, and do it ourselves in to_obj.
@certau-davidg, I think it's likely that XML you've seen in the wild was not created with python-cybox, but you may be able to work around the issue by calling to_obj(), then modifying the "binding object" before exporting as XML. See the mixbox code for what to_xml() does. The key is the gds_obj.export() call.
I'm not sure the best way to fix this in python-cybox. We could have an explicit raw_artifact_condition attribute that we use in to_obj and to_dict (and set in from_obj and from_dict), but that doesn't address any of the other XML attributes possible on ObjectProperty objects.
Thanks @gtback, that pretty much confirms all of our testing and object probes.
Not sure we really want to be messing with the binding object though, because we want to be able to import the STIX object from xml and make additional changes later.
It is a shame, but we understand why parts of the schema like this would go unimplemented with the code for 2.0 in active development.
At this point we will treat the Raw_Artifact as if it has an implicit condition="Contains" and avoid using condition="FitsPattern".
Chances are if we need to use FitsPattern we will make a yara rule and attach that instead.
You might be able to create a RawArtifact property yourself (handling any encoding/compression/etc. of the bytes stream manually), and attach that to the Artifact object explicitly. If python-cybox doesn't pick it up, that's something it should be straightforward for us to fix.
Hmm, that is a fair point. Will discuss internally.
Any updates on this, @certau-davidg ? I'm hoping to release a new version of python-cybox in the next week or so. If there's anything we need to do to fix this, please let me know.
Sorry @gtback like all great github dev moments I forgot to come back and leave a comment.
No solutions from the team here.
The object itself has had very limited use so I doubt resources will be allocated to researching any patches over here. Happy to wait and see where this object goes with CybOXProject devs.
Thanks for the update, @certau-davidg . We'll see if there's a good way for us to support this in the "API" (non-"binding") classes, without requiring the workaround I suggested above.