Repository navigation
Cannot set string condition for RawArtifactType on Artifact Object #296
Description
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?
Activity
[-]Cannot set @condition for RawArtifactType on Artifact Object[/-][+]Cannot set string condition for RawArtifactType on Artifact Object[/+]rpiazza commentedon Aug 15, 2017
The Artifact object inherits from ObjectProperties - which enables you to set the condition:
Try this:
a = Artifact()
a.condition = "Contains"
gtback commentedon Aug 16, 2017
I don't think it's as easy as that, @rpiazza . You want to set the
@conditionon theraw_artifactproperty of the Artifact object, not the Artifact itself. Due to the complexity of what we do withdataandpacked_data(which is what #200 is meant to document), we don't let the user explicitly create aRaw_Artifact, and do it ourselves into_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 thegds_obj.export()call.I'm not sure the best way to fix this in python-cybox. We could have an explicit
raw_artifact_conditionattribute 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.david74552 commentedon Aug 20, 2017
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.
gtback commentedon Aug 21, 2017
You might be able to create a
RawArtifactproperty 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.david74552 commentedon Aug 21, 2017
Hmm, that is a fair point. Will discuss internally.
gtback commentedon Oct 16, 2017
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.
david74552 commentedon Oct 16, 2017
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.
gtback commentedon Oct 17, 2017
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.
Fix RawArtifact attribute settings. Some general improvements. Added …