Re: [cti-stix] RE: Indicator TLO

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

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

---

Hi!,
 
Do we potentially want to use the term: ‘half_life’ rather than decay or aging ?, works for science.
 
Regards,
 
Dean
 
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Maxwell, Kyle
Sent: Tuesday, 17 May 2016 6:05 AM
To: Jordan, Bret; cti-stix@lists.oasis-open.org
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 [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]
Sent: Sunday, May 15, 2016 16:24
To: cti-stix@lists.oasis-open.org
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.