| I completely agree with this John. Another element that would make this valuable is for consumers to rate the threat feeds they get. If threat provider ISAC-foo sends a bunch of content down with a rating of Low and the consumer finds that most of that information for them is High, then that is also very valuable for an analytics engine inside of the consumers org.
<putting on vendor hat> We have been doing this rating thing for some time now and all of our customers, which are most of the people that you all represent love it. It allows us to do some very interesting proprietary things with the data that all of the end orgs (banks, government agencies, industrial control facilities, etc etc etc) make use of. </taking off hat>
Thanks,
Bret Bret Jordan CISSPDirector 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."
I think this is true for cross-organizational sharing but just to add another perspective, one of the groups that I’m working with involves a “cyber analysis center” sending some intelligence to a “cyber operations center” at the same organization.
That information ideally includes an assessment of the severity of that threat activity to the organization. So I understand that severity may not make sense for cross-organizational sharing, but if one of the STIX use cases is to support sharing among centers/tools/sub-organizations
in the same organization I think we need to consider it.
There might also be use cases where a threat intel provider provides scored threat information tuned to a consumer. Lots of small and mid-sized businesses with an online presence probably don’t have in-house analysis capabilities to determine
their own scores but could still use some rough guidance about severity from their vendors.
This isn’t to disagree with Pat and Sean, I agree that for sharing data between organizations (in particular advanced organizations) where the orgs have that analysis capability that approach will lead to better results. Just wanted to expand
our horizons a bit beyond that use case include some less ideal scenarios that may be prevalent in the real world.
John
Pat’s statements here align with the opinions I have heard expressed over the last few years from organizations doing actual cyber threat intelligence or active incident response.
The assertions that I have heard are that scoring is a great concept but that any importance/criticality scoring (based on a myriad of potential factors like some that Pat names) asserted by a producer is rarely accurate or applicable within the
context of different consumers.
The way that I have had it characterized to me is typically along the lines of the following.
At best (in the rare cases where they are accurate) they may help a consumer prioritize one issue over another. Nominally, they are noise information for consumers drowning in information. At worst they are misleading and cause the wrong decisions/actions
to be taken (such as the case Pat describes below).
The preferred approach that I have heard is to give the consumer as much of the context for the information as possible to enable the consumer to determine their own scoring based also on their own internal context.
One possible approach for us might be to ensure that we can support conveying the appropriate level of context information in our normative standards and then provide some non-normative consensus suggestions/guidelines (separate from the standards
themselves) on how consumers could use that information to “score” threat information.
I am not arguing or asserting a “right” way to do this just pointing out that what Pat says here jibes with what I have heard from many others and should certainly take such considerations into account when thinking about this topic.
sean
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.
_____________________________
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 < bernd.grobauer@siemens.com>,
< cti-users@lists.oasis-open.org>
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:
>
>
http://www.businesswire.com/news/home/20151020005120/en/LookingGlass-Introduces-Open-Threat-Partner-eXchange-OpenTPX
>
> Docs, JSON-schema, etc. on
>
> https://www.opentpx.org/
>
>
> 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.
>
> Subscribe: cti-users-subscribe@lists.oasis-open.org
> Unsubscribe: cti-users-unsubscribe@lists.oasis-open.org
> Post: cti-users@lists.oasis-open.org
> List help: cti-users-help@lists.oasis-open.org
> List archive:
http://lists.oasis-open.org/archives/cti-users/
> List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
> CTI Technical Committee:
https://www.oasis-open.org/committees/cti/
> Join OASIS: http://www.oasis-open.org/join/
>
>
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.
Subscribe: cti-users-subscribe@lists.oasis-open.org
Unsubscribe: cti-users-unsubscribe@lists.oasis-open.org
Post: cti-users@lists.oasis-open.org
List help: cti-users-help@lists.oasis-open.org
List archive:
http://lists.oasis-open.org/archives/cti-users/
List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee:
https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
|