OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


The infrastructure has been there since STIX 1.0 but because the concepts of TTPs have been flattened out into separate objects it looks rather similar to an Observable.  This is because TTPs are not grouped together, but instead as separated as top-level objects; it look a bit strange and I made that comment when we were putting this together.  Perhaps the use of the pattern is lends to the confusion but that could potentially be replaced by a relationship between the Infrastructure object and the corresponding Observable.

Personally, I’d be in more favor of grouping all the TTPs back under a ‘ttps’ key instead of breaking them out as infrastructure, victim-targetings, attack-patterns, malware.

Hope this helps!

Paul Patrick

From: <cti@lists.oasis-open.org> on behalf of "Foley, Alexander - GIS" <alexander.foley@bankofamerica.com>
Date: Monday, March 28, 2016 at 5:29 PM
To: "cti@lists.oasis-open.org" <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:



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.




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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]