Alex,
What is there isn't the best way to do it and I think a bunch of us are aware of that. I've shown some folks the current thinking around patterns and they like it so much better. Hopefully we're getting close enough that I can update
the report with the latest proposal
Paul
Sent from my iPhone
On Mar 28, 2016, at 5:48 PM, Foley, Alexander - GIS <> wrote:
Actually I’m sorry but I can’t leave the indicators portion alone for now…. question #7… are we sure that the best way to include a hashed file in a STIX package is to have it as part of an indicator _expression_,
with three separate properties, requiring a condition to figure out which hash is which type and which file name it belongs to? For those following along, I’m talking about the code below. Please correct me if the suggested observable or patterning syntax
has already changed.
"indicators": [
{
…
"indicator_expression": {
"pattern": {
"properties": {
"$prop3": {
"operator": "equals",
"value": "SHA1",
"key": "file-object:hashes/hash_type"
},
"$prop2": {
"operator": "equals",
"value": "MD5",
"key": "file-object:hashes/hash_type"
},
"$prop1": {
"operator": "equals",
"value": "facture-97620236.doc",
"key": "file-object:file_system_properties/file_name"
},
"$prop7": {
"operator": "equals",
"value": "c1a3f0aa7df620b20edffb483203d661bdb7994f22baa3a443832acf3ecedfad",
"key": "file-object:hashes/hash_value"
},
"$prop6": {
"operator": "equals",
"value": "1744dfd6a08e6a6606a1143880f0a3280d89e126",
"key": "file-object:hashes/hash_value"
},
"$prop5": {
"operator": "equals",
"value": "0483a670833dbaddb3a310225485b66f",
"key": "file-object:hashes/hash_value"
},
"$prop4": {
"operator": "equals",
"value": "SHA256",
"key": "file-object:hashes/hash_type"
},
"$prop9": {
"operator": "equals",
"value": "7ef4316439c03814d8d2b0329a6538e4",
"key": "file-object:hashes/hash_value"
},
"$prop8": {
"operator": "equals",
"value": "28e2d98623771f2176f672e61ee3f423",
"key": "file-object:hashes/hash_value"
},
"$prop13": {
"operator": "equals",
"value": "$var2",
"key": "file-object:id"
},
"$prop12": {
"operator": "equals",
"value": "$var1",
"key": "email-message-object:id"
},
"$prop11": {
"operator": "equals",
"value": "81c321493c91e5413538ad90f44f1740",
"key": "file-object:hashes/hash_value"
},
"$prop10": {
"operator": "equals",
"value": "098ad1f5ddd71633f7385022f374a8d0",
"key": "file-object:hashes/hash_value"
},
"$prop17": {
"operator": "equals",
"value": "Facturation Octobre 2015 et Rachat",
"key": "email-message-object:header/subject"
},
"$prop16": {
"operator": "equals",
"value": "has-attachment",
"key": "relationship-object:kind_of_relationship"
},
"$prop15": {
"operator": "equals",
"value": "$_var2",
"key": "relationship-object:target_ref"
},
"$prop14": {
"operator": "equals",
"value": "$_var1",
"key": "relationship-object:source_ref"
}
},
"condition": "AND(ConjunctiveAND($prop12, $prop17),ConjunctiveAND($prop14,$prop15,$prop16),ConjunctiveAND($prop13,$prop1,OR(ConjunctiveAND($prop2,$prop5),ConjunctiveAND($prop3,$prop6),ConjunctiveAND($prop4,$prop7),ConjunctiveAND($prop2,$prop8),ConjunctiveAND($prop2,$prop9),ConjunctiveAND($prop2,$prop10),ConjunctiveAND($prop2,$prop11))))"
}
Thanks,
Alex Foley
From:
[mailto:]
On Behalf Of Foley, Alexander - GIS
Sent: Monday, March 28, 2016 5:29 PM
To:
Subject: [cti] Questions based on iSIGHT Sample
Dear CTI,
I’m not sure how many of you have taken the chance, but I really enjoyed going through the iSIGHT sample and I thank Paul Patrick, Sean Barnum and others who contributed to its development. Forgive me as I express some undecided thoughts
here instead of trying to type this in Slack.
1.
Why are we placing a spec_version in every object? I was thinking this would be defined at the package level (with some sort of default assumed if it’s not even there)
2.
Same goes for created_by_ref… it seems like this is the same value for almost every top level object in the package, and might be duplicative? If the idea is that it’s required if the object wasn’t created by the package originator,
would it be easier to have a top-level created_by_ref (if it’s even required at all) and then allow for overrides in the package when needed?
3.
Is created_at required for all top level objects in STIX at the moment? Is it optional?
4.
Is there a reason why some relationships are in observations versus being included in the relationships top level grouping? Is this a CybOX / STIX separation?
5.
The identities object seems so wonky… why establish a Financial Sector object, with its own ID, if we already have it defined by NAICS with a specific code? Are we planning on other generally accepted forms of code authorities that
I haven’t thought about? I can only imagine the hell when trying to dedupe many different financial sector objects created by different threat intel providers.
6.
Am I the only one to just now figure out there’s an infrastructure object, separate from observables now? For the actual compromised IP of the server in iSIGHT’s example, it seems like I have to go through infrastructure[‘infrastructure_expression’][‘pattern’][‘properties’][‘$prop1’][‘value’]
to find the actual IP address. Slightly easier to regex it from observations[][‘uri_value’][‘value’] I guess, but still, nested quite a bit.
I wondered if anyone else had these same questions – working from this version of the document:
http://taxii2-demo.soltra.com/taxii/mygroup/collections/mycollection/packages/package--3b3441de-8bf2-409e-a7e8-8f296f385057
I’m just going to leave the entire indicators portion alone for now. I assume there’s much smarter people than I figuring out how these conditions and property IDs (with a dollar sign for some reason that I assume is related to shell scripting
or PHP) will work in the end… especially when we will inevitably extract observables and not follow conditions.
Alex
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important
terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at
http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
