Re: [cti] RE: Questions based on iSIGHT Sample

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

This is, I believe how you would represent the below, except using our current in-process patterning proposal that Paul is referring to - presuming I copy / pasted it accurately.

As you can see, in my opinion it is much more compact, and easier to read / comprehend, while being easily parseable through usage of a grammar.

Note that the fact that you are looking for a file *within* the email is implicit through usage of the WITH keyword as opposed to the AND keyboard.

"indicators": [
{
"pattern":"
(
email-message-object:header/subject = 'Facturation Octobre 2015 et Rachat'
)
WITH
(
file-object:file_system_properties/file_name = 'facture-97620236.doc' AND
(
( file-object:hashes/hash_type = 'MD5' AND file-object:hashes/hash_value = '28e2d98623771f2176f672e61ee3f423' ) OR
( file-object:hashes/hash_type = 'MD5' AND file-object:hashes/hash_value = '81c321493c91e5413538ad90f44f1740' ) OR
( file-object:hashes/hash_type = 'MD5' AND file-object:hashes/hash_value = '7ef4316439c03814d8d2b0329a6538e4' ) OR
( file-object:hashes/hash_type = 'MD5' AND file-object:hashes/hash_value = '098ad1f5ddd71633f7385022f374a8d0' ) OR
( file-object:hashes/hash_type = 'MD5' AND file-object:hashes/hash_value = '0483a670833dbaddb3a310225485b66f' ) OR
( file-object:hashes/hash_type = 'SHA1' AND file-object:hashes/hash_value = '1744dfd6a08e6a6606a1143880f0a3280d89e126' ) OR
( file-object:hashes/hash_type = 'SHA256' AND file-object:hashes/hash_value = 'c1a3f0aa7df620b20edffb483203d661bdb7994f22baa3a443832acf3ecedfad' )
)
)
"
}
]

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Paul Patrick ---03/28/2016 07:18:44 PM---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 sh

From: Paul Patrick <ppatrick@isightpartners.com>
To: "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 03/28/2016 07:18 PM
Subject: Re: [cti] RE: Questions based on iSIGHT Sample
Sent by: <cti@lists.oasis-open.org>

---

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 <alexander.foley@bankofamerica.com> 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: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Foley, Alexander - GIS
Sent: Monday, March 28, 2016 5:29 PM
To: cti@lists.oasis-open.org
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.