Re: [cti-stix] STIX Indicator Proposal

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

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

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'"
<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>

---

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