RE: [Non-DoD Source] Re: [cti-stix] STIX Indicator Proposal

["Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>]

Couple of comments.

First, I believe that I may have not explained what I was proposing well.  To Jason's comment, I am not proposing that the indicator object have the ability to reference observed data directly.  I am stating that properties within observed data that have an 'i_' prefix are indicators.  There is no need for an indicator object because they are denoted as being atomic indicators.  The indicator object would be used to represent complex pattern objects.  

Terry, from an architecture standpoint I agree with you.  When defining the model we purposefully broke apart the indicator and the observed data, but from a practicality standpoint of how a user would like to interact with any system built upon the STIX model, I believe they would not want to see links between every piece of observed data and the associated indicator.  

I'm trying to look at the original issue, which is an analyst having to see every atomic indicator represented twice, once as the data the indicator is based upon and again as the indicator itself.  Definitely open to better and cleaner options but I do have some concerns with not addressing this issue.

-----Original Message-----
From: Terry MacDonald [mailto:terry.macdonald@cosive.com] 
Sent: Thursday, June 08, 2017 3:52 PM
To: Jason Keirstead
Cc: cti-stix@lists.oasis-open.org; Katz, Gary CTR DC3\DCCI
Subject: [Non-DoD Source] Re: [cti-stix] STIX Indicator Proposal

I'm not really a fan of this approach. We spent a long time separating the observed data or so that it recorded what has happened, and the indicator, which recorded what to look for.

I still think this is the delineation that should apply, even with the malware object discussion. Malware object should record some basic 'structured' information about what's been seen (whatever helps an analyst to pivot), with the malware detail going in the observed data to record the detail of what's been seen, and the indicator should show how to look for the malware in the future.

Attempting to use malware as an observed data object seems to go against the general overall structure of STIX 2.x.

Cheers
Terry MacDonald
Cosive


On 9/06/2017 05:30, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:


	Hi Gary - if I understand  your proposal correctly - you are proposing that the indicator object have the ability to reference an observed_data directly, in lieu of a pattern?
	
	I am not totally sure how this would help with the issue of keeping the malware and/or infrastructure objects in-sync with the corresponding indicator object, as malware has embedded SCO information, it is not a relationship to an observed_data (this was brought up by myself in the past but folks felt that because this information was not "observed" it was not appropriate).
	
	If we change malware to be a reference to an observed_data, and allow the indicator to point at the same observed_data, then I think your proposal would definitely help the situation. I would take it further as well and say the indicator should be able to point at *a list* of observed_data. This would allow you to reference a list of atomic data in your indicator..
	
	-
	Jason Keirstead
	STSM, Product Architect, Security Intelligence, IBM Security Systems
	www.ibm.com/security <http://www.ibm.com/security> 
	
	Without data, all you are is just another person with an opinion - Unknown 
	
	
	
	
	From:        "Katz, Gary CTR DC3\\DCCI" <Gary.Katz.ctr@dc3.mil>
	To:        "'cti-stix@lists.oasis-open.org <mailto:cti-stix@lists.oasis-open.org> '" <cti-stix@lists.oasis-open.org>
	Date:        06/08/2017 12:49 PM
	Subject:        [cti-stix] STIX Indicator Proposal
	Sent by:        <cti-stix@lists.oasis-open.org <mailto:cti-stix@lists.oasis-open.org> >
	
________________________________




	
	I would like to provide another alternative to cover the issues associated
	with analysts creating indicators and the objects they are based upon.
	There are definitely some cons to this approach, but I believe it does meet
	the core issue and at the least it should hopefully start some new
	discussion on the topic.
	
	Problem:
	Currently analysts need to capture an IP address, email address or other
	atomic indicators in two ways, first as part of observed data or
	infrastructure and then again as an indicator within a pattern.  Not all
	IPs, FQDNs, email addresses, etc. are indicators but a large majority are
	and large volumes of these types of indicators are captured on a daily
	basis.  While individual products can be built to alleviate the extra work
	required to maintain this information in two locations (the indicator object
	and in the analysis (i.e. observed data, infrastructure, etc.), STIX should
	be designed to encourage good practices and minimize the need for systems to
	hide inefficiencies in the standard.
	
	Proposed Solution:
	This solution does leave the opportunity for indicators to be included
	within a document in two ways, but encourages atomic indicators to be
	represented in one way, while complex indicators to be represented in
	another way.  Many properties within objects can also be atomic indicators.
	This proposal suggests that any properties that are also an atomic indicator
	have an 'i_' in front of the property name, while if that property was not
	an indicator it would not have an 'i_'.  The Indicator object would be used
	to store complex indicators (i.e. patterns), although atomic indicators
	could still also be stored using this approach (hence the two ways to
	represent an indicator).
	
	For example:
	{
	 "type": "observed-data",
	 "id": "observed-data--b67d30ff-02ac-498a-92f9-32f845f448cf",
	 "created_by_ref": "identity--f431f809-377b-45e0-aa1c-6a4751cae5ff",
	 "created": "2016-04-06T19:58:16.000Z",
	 "modified": "2016-04-06T19:58:16.000Z",
	 "first_observed": "2015-12-21T19:00:00Z",
	 "last_observed": "2015-12-21T19:00:00Z",
	 "number_observed": 50,
	 "objects": {
	                  "0": {
	                    "type": "email-addr",
	                    "i_value": "badguy@harpoons.com",
	                    "display_name": "Bad Guy"
	                  },
	                  "1": {
	                    "type": "email-addr",
	                    "value": "victim@clicksonanything.com",
	                    "display_name": "Vic"
	                  },
	 }
	}
	
	Two email addresses are represented within the objects.  badguy@harpoons.com
	is an indicator, while victim@clicksonanything.com is not an indicator.
	This allows users (or implementers) to easily create atomic indicators
	without having to represent the email address within the context of the
	event and then separately create an indicator object with the same email
	address, linking the two together.
	
	In order for this approach to work, we would need to define how each data
	type (including complex datatypes, such as windows-registry-value-type)
	would be used as an indicator.  In most cases this would be simple, but in
	complex datatypes such as windows-registry-value-type, we would need to
	specify how the key and values are used to create an indicator.  
	
	I do not believe this functionality would need to go in the 2.0 release of
	STIX.  In my view, this does not break backwards compatibility, although it
	is a fairly significant change that would break forwards compatibility.  
	It also is a little be it of a hack, which I'm not a fan of and puts extra 
	work onto the developer to support the capability.  Truthfully, I'd rather 
	put more work on the developer to make things easier on the users 
	rather than making it easier on the developer to implement something 
	that puts the burden onto the user.  
	
	Interested in everyone's thoughts,
	   -Gary
	
	---------------------------------------------------------------------
	To unsubscribe from this mail list, you must leave the OASIS TC that 
	generates this mail.  Follow this link to all your TCs in OASIS at:
	https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php <https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>