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


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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

Subject: RE: [cti-stix] RE: Indicator TLO

I agree that `decay_rate` (or `halflife_v3` or whatever) doesn't necessarily need to be in MVP. We already have an optional end time stamp for when the indicator is no longer valid. I would like to see the research pointing to good methods for decaying indicators logarithmically.


Regarding patterning: I fully recognize that YARA / OpenIOC / Snort do not address all use cases. They are insufficient (though, I'd suggest, necessary due to existing "installed base") for describing CTI. That said, I have two concerns about the current approach.

First: will we be able to hit the July dates? I think that's of paramount importance. Patterning is SUPER important but people can start to work with STIX even without it. Allan's mention of a CV for the patterning language is exactly how I'd do it.

Second: Patterning is going to require significant effort by implementers, and that will in turn require a "charm offensive" to convince folks that they should go to that effort. And many, many folks will say (correctly) that they have lots of stuff already in existing languages - telling analysts they need to write in a new language (even if it's a lot like SIEM rules) is going to result in lots of pushback, so we need to be prepared to deal with that objection.

I will say again here: patterning is useful and important. I understand and agree with the reasons why we need it, and the initial proposal we saw in Linthicum looked like a great starting point. But I am unsure we can or should do it for 2.0 in July rather than 2.1 in December/January.

Kyle Maxwell [kmaxwell@verisign.com]

iDefense Senior Analyst

From: cti-stix@lists.oasis-open.org [cti-stix@lists.oasis-open.org] on behalf of Jason Keirstead [Jason.Keirstead@ca.ibm.com]
Sent: Tuesday, May 17, 2016 06:57
To: Thompson, Dean
Cc: Maxwell, Kyle; 'Jordan, Bret'; 'cti-stix@lists.oasis-open.org'
Subject: Re: [cti-stix] RE: Indicator TLO

I think we would need to discuss decay rate in detail (I would actually like to discuss on one of the working calls) because I think having a fixed linear decay rate is a bad idea. Most situations involving decay of things like confidence require for logarithmic decay rates. IE, the confidence drops rapidly at first, then more slowly later. Having a "half_life" is akin to a linear decay rate so I also don't think that is a good idea.

I also question if the producer should even be the entity who is deciding what a decay_rate is for their data. This isn't clear to me either.

As such IMO it would be better to pull decay_rate out of MVP.

Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

Inactive hide details for "Thompson, Dean" ---05/16/2016 08:54:55 PM---Hi!, Do we potentially want to use the term: 'half_life'"Thompson, Dean" ---05/16/2016 08:54:55 PM---Hi!, Do we potentially want to use the term: 'half_life' rather than decay or aging ?, works for sci

From: "Thompson, Dean" <Dean.Thompson@anz.com>
To: "'Maxwell, Kyle'" <kmaxwell@verisign.com>, "'Jordan, Bret'" <bret.jordan@bluecoat.com>, "'cti-stix@lists.oasis-open.org'" <cti-stix@lists.oasis-open.org>
Date: 05/16/2016 08:54 PM
Subject: [cti-stix] RE: Indicator TLO
Sent by: <cti-stix@lists.oasis-open.org>


Do we potentially want to use the term: ‘half_life’ rather than decay or aging ?, works for science.



From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Maxwell, Kyle
Tuesday, 17 May 2016 6:05 AM
Jordan, Bret; cti-stix@lists.oasis-open.org
[cti-stix] RE: Indicator TLO

I added some comments and suggested text. TL;DR: `decay_rate` (or `aging` or whatever we decide to call it) is important but I don't think it's MVP.

Similarly, for patterning, we should make the non-CybOX patterns MVP and I suspect push the STIX patterning out to the winter release. I feel like that's a huge feature and we've already got coverage from other languages for much (not all) of the proposed functionality.

Kyle Maxwell [kmaxwell@verisign.com]

iDefense Senior Analyst

From: cti-stix@lists.oasis-open.org [cti-stix@lists.oasis-open.org] on behalf of Jordan, Bret [bret.jordan@bluecoat.com]
Sunday, May 15, 2016 16:24
[cti-stix] Indicator TLO

John and I were reviewing the Indicator TLO today and there are just a few open tasks remaining before it can be moved to the Review phase. Can we ask everyone to help us resolve these last few things? It would be nice to move this from Development to Review by end of week.


Open Tasks
• What are the values for the Labels field? Is it a controlled vocab or just an array of strings?
• What is the Decay_Rate and is it MVP?
• Do we allow non-cybox patterns (test mechanisms, like yara, openIOC, snort)? And is it MVP?
• Clean up property descriptions



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

This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ Bank New Zealand Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication.

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