Agreed half_life and decay_rate are subjective and shouldn't be MVP.
Given versioning, an Intel shop should be able to REVOKE an indicator whenever they so please to fulfill this objective.
In other words, aging is in the eye of the beholder.
-----Original Message-----
From: Maxwell, Kyle []
Sent: Tuesday, May 17, 2016 09:52 AM Central Standard Time
To: Jason Keirstead; Thompson, Dean
Cc: 'Jordan, Bret'; ''
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 []
iDefense Senior Analyst
From: [] on behalf of Jason Keirstead []
Sent: Tuesday, May 17, 2016 06:57
To: Thompson, Dean
Cc: Maxwell, Kyle; 'Jordan, Bret'; ''
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
"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" <>
To: "'Maxwell, Kyle'" <>, "'Jordan, Bret'" <>, "''" <>
Date: 05/16/2016 08:54 PM
Subject: [cti-stix] RE: Indicator TLO
Sent by: <>
Hi!,
Do we potentially want to use the term: ‘half_life’ rather than decay or aging ?, works for science.
Regards,
Dean
From: [mailto:]
On Behalf Of Maxwell, Kyle
Sent: Tuesday, 17 May 2016 6:05 AM
To: Jordan, Bret;
Subject: [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 []
iDefense Senior Analyst
From:
[] on behalf of Jordan, Bret []
Sent: Sunday, May 15, 2016 16:24
To:
Subject: [cti-stix] Indicator TLO
All,
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.
https://docs.google.com/document/d/1F1c05GgYaJFV1Z04B8c_T3vEE-LRQTPExF24LvOQAsk/edit#heading=h.8gcmzx50n1ri
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
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."
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.
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
