cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-stix] STIX Indicator Proposal
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Jerome Athias <jerome.athias@protonmail.com>
- Date: Fri, 9 Jun 2017 08:46:35 -0300
This is indeed a very apt analogy to the
problem we're trying to solve here...
Now that Gary has explained his proposal
more... I agree with @jmg that I am not a fan of this approach, namely
because it would require continuously modifying the observed_data which
doesn't make much sense, unless we want to totally re-define what observed_data
is.
I could get behind a set of relationships
from an indicator object to pre-existing observed_data like I described
though (the relationship becomes the "highlighter pen")
-
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:
Jerome Athias <jerome.athias@protonmail.com>
To:
"Katz, Gary CTR
DC3\\\\DCCI" <Gary.Katz.ctr@dc3.mil>
Cc:
"'cti-stix@lists.oasis-open.org'"
<cti-stix@lists.oasis-open.org>
Date:
06/09/2017 02:05 AM
Subject:
Re: [cti-stix]
STIX Indicator Proposal
Sent by:
<cti-stix@lists.oasis-open.org>
My 2c
I do like the idea behind that.
Sounds like you have a large piece of writing, and want
to avoid writing a stand-alone summary by using an highlighter pen.
That would be worth exploring a solution imho.
-------- Original Message --------
Subject: [cti-stix] STIX Indicator Proposal
Local Time: June 8, 2017 6:49 PM
UTC Time: June 8, 2017 3:49 PM
From: Gary.Katz.ctr@dc3.mil
To: 'cti-stix@lists.oasis-open.org' <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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]