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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-users message

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

Subject: Re: [cti-users] Publication of another threat intelligence standard: Open Threat Partner eXchange (OpenTPX)


Comments inline

On 10/26/15, 11:06 AM, "cti-users@lists.oasis-open.org on behalf of Jason Lewis" <cti-users@lists.oasis-open.org on behalf of jlewis@lgscout.com> wrote:

One of the biggest struggles we had early on was the use of the word
"indicator".  Lots of people immediately categorize the word as
representing badness, due to the phrase "Indicators of Compromise".
We decided that a better term to describe the data we were
representing was "observable".  Observables have elements of time
included, so a decent definition is "facts about
sightings/observations".  We treat observables as immutable, so once
it's occurred, there is no modification to the event.  We modify data
about that observable, but not the element itself.  Essentially, the
data producer can tell me what risk/importance they recommend for the
data and I can modify that based on my needs.

With opentpx, I'm able to say I observed an event without confusing
the end user on if the event was good or bad.  

[sean]Just a clarifying FYI in regards to the current STIX ontology/data-model and its intent: What you describe above is the exact intent for the STIX Observable construct (which leverages CybOX) expressing an observable instance or, if you prefer, an observation. It is an immutable statement of something that was observed to have occurred either through direct observation (Event/Action) or through observation of its effects (Object). These observations very explicitly do not assert context such as good or bad. They are just the facts.
If you wish to assert and characterize a negative context for an observable you would do this using an Indicator that asserts a mapping between a particular observable pattern (derived from one or more observable instances) and a particular TTP. This is where the negative context comes in. The semantic meaning for the Indicator construct is at its root a relationship assertion saying that observation of observable pattern 1 INDICATES TTP 2.
It should be noted that the current STIX semantics automatically apply a negative denotation to any TTP and thereby to any Indicator. It has been proposed in the past that the sorts of things characterized using TTP could also be Tactics, Techniques and Procedures leveraged by defenders not just attackers and that it may be useful to abstract TTP to characterize the concept in general with specific Adverserial_TTP and Defender_TTP derivations or at least a property letting you assert the “polarity”. This would in turn allow Indicators to be leveraged to describe patterns that indicate good things in addition to bad things. This is just an idea that has not been explored in depth but should probably be on the table for consideration in STIX 2.0

There are different
levels of bad for different folks, so part of the format is allowing
the data provider to provide a score (or multiple "scores", risk,
criticality, etc).    Once the data is in our system, we are then able
to use the score provided by the data to present a computed score to
the end user.  This computed score is a combination of input from the
data itself, the user, and related observables.  The users are able to
tweak knobs that allow them to elevate or reduce the score for
multiple elements.  For example, lowering the score for a feed,
raising the score for an IP, making the score for a network neutral.
The result addresses the scenario of User A not being concerned with
attacks that target power plants, while User B can make those attacks
the highest priority.

[sean]I think this sort of approach allowing the consumer to blend context asserted by the producer with their own context to determine scoring makes sense.
It sounds like you are describing specific functionality implemented within your tools use. I think it is less clear (though not complete opaque) where the dividing line lies for what should go in STIX and what should be handled by tooling (such as yours) at the consumer end.


jas

On Mon, Oct 26, 2015 at 10:33 AM, Patrick Maroney <Pmaroney@specere.org> wrote:
Relevance, Certainty, Validity, etc. along with other highly subjective
measures like Business Impact (of mitigation/Blocking) are really not
effective shared measures for IOCs with perhaps exceptions for widely seen
common Malware/NuisanceWare/AdWare.
Point is that a majority of serious APT attacks against Sectors, Industries,
Agencies, etc. are highly targeted. In some cases the attack packages and
ephemeral TTPs are tailored uniquely to an individual organization.
I can authoritatively cite an example:  some of the most dangerous highly
targeted APT threats are typically flagged by AV as "Low"
priority/criticality/risk, which in turn leads to inadequate responses when
detected.  We've found evidence of relatively early leading APT artifact AV
detections in every APT Intrusion investigation since 2002.  When asked why
these leading indicators were ignored, without fail the response would be
something along the lines of: "Oh we don't have the resources to investigate
thousands of AV detections, we only look at Med to High Risk", or "Oh we
looked at it, it was flagged as low risk".  AV Vendors when challenged on
these rating methodologies would also respond without fail with something
like: "That RAT/Backdoor was only reported by 5 companies, it's low risk".
Tell that to the 5 companies who spent millions cleaning up entrenched
adversaries that could have been stopped early in the intrusion had the
threat not been mischaracterized and investigated.
In my view (1) we should be sharing facts about sightings/observations, (2)
analysis along with methods to "show your work" for any hypothesis for
subjective conclusions, and (3) include Non-Attributional Source Path
Traceability for directing RFIs and Details on Sightings to the original
Source(s).  One can then compile "Earliest Seen", "Latest Seen" metrics
along with Sector/Target specific Threat Characterization details to
determine an effective measure of risk.

Patrick Maroney

_____________________________
From: Jerome Athias <athiasjerome@gmail.com>
Sent: Sunday, October 25, 2015 10:04 PM
Subject: Re: [cti-users] Publication of another threat intelligence
standard: Open Threat Partner eXchange (OpenTPX)
To: Jason Lewis <jlewis@lgscout.com>
Cc: Jordan, Bret <bret.jordan@bluecoat.com>, Grobauer, Bernd



Yep the decay is interesting
It could be evaluated as an option like the Valid_Time_Position where both
have benefits depending the use case (e.g. Exercise scenario)

Regarding scoring, there is opportunity for researches based on STIX ;-)


On Monday, 26 October 2015, Jason Lewis < jlewis@lgscout.com> wrote:

Just to point out some key differences from the FB format.  Primarily
the topology support (networks, bgp, etc) and scoring.  Part of the
scoring is the decay, which becomes very important when dealing with
billions of elements.

On Wed, Oct 21, 2015 at 1:28 PM, Jordan, Bret < bret.jordan@bluecoat.com>
wrote:
> Thanks for sending this out... It looks interesting. We will need to
> watch
> it closely, they have some neat things that are very similar to FB's
> threat
> exchange.
>
> Thanks,
>
> Bret
>
>
>
> Bret Jordan CISSP
> Director of Security Architecture and Standards | Office of the CTO
> Blue Coat Systems
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
> can
> not be unscrambled is an egg."
>
> On Oct 21, 2015, at 04:17, Grobauer, Bernd < Bernd.Grobauer@siemens.com>
> wrote:
>
> Hi,
>
> I found this news item (from yesterday) about a new Open Source effort
> on TI
> standardization
> and thought it might be of interest to the group:
>
>
>
> Docs, JSON-schema, etc. on
>
>
>
> According to the FAQ:
>
> Q: Does OpenTPX replace STIX?
>
> A: No. OpenTPX was designed primarily as a optimized mechanism for data
> exchange at large volume, high scale and high speed ingestion for a
> broader
> set of Internet intelligence and threat context. Aspects of data
> available
> in STIX (e.g. indicators) have direct mapping to OpenTPX.
>
> Kind regards,
>
> Bernd
>
>
> -------------
>
> Bernd Grobauer, Siemens CERT
>
>
>
>
> This publicly archived list provides a forum for asking questions,
> offering answers, and discussing topics of interest on STIX,
> TAXII, and CybOX.  Users and developers of solutions that leverage
> STIX, TAXII and CybOX are invited to participate.
>
> In order to verify user consent to OASIS mailing list guidelines
> and to minimize spam in the list archive, subscription is required
> before posting.
>
>
>

This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.





This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX.  Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.

In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.



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