Re: [cti] Questions based on iSIGHT Sample

[Paul Patrick <ppatrick@isightpartners.com>]

Sent from my iPhone

On Mar 28, 2016, at 5:29 PM, Foley, Alexander - GIS <alexander.foley@bankofamerica.com> wrote:

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?

This is being fixed 

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.

This was a first cut at specifying identity beyond the basic form that is lacking all the necessary info for victim targeting. Clearly this can be made better. 

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.