cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-stix] Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for an Infrastructure SDO for STIX 2.1
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Wed, 15 Nov 2017 08:55:09 -0400
We could discuss on a working call, but
I am unsure what the agenda of said working call would be. We first need
someone to propose something.... this is what JMG and I are saying... lead
us to the water here...
It is easy to call for change -
I could easily call for a reopening of timestamps because of the order
of magnitude higher computation overhead of parsing the current ones -
but it wouldn't pass muster as this is an issue long ago voted upon by
the TC, and STIX 2.0 will work without that change - * the burden needs
to be high * for proponents to re-open fundamental debates that the TC
has already voted on.
RE code, there are many, many folks
who have written (and are writing now) STIX 2.0 code. There are multiple
vendors who have support out in production, and I am sure there are many
more in internal test. The Interoperability plugfest in January has many
vendors signed up to participage. This change would break all of those
implementations, and send people back to the drawing board. We need to
stop with the "we need to write code" arguments... there is a
lot of code already written. Just because one entity is having problems
adapting an internal model, does not mean there is a fundamental problem
with the specification. The problem can just as easily be with their own
model. STIX isn't going to seamlessly adapt to every single data model
in existence.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
From:
Bret Jordan <Bret_Jordan@symantec.com>
To:
John-Mark Gurney <jmg@newcontext.com>
Cc:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>,
Sean Barnum <sean.barnum@FireEye.com>, "cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>, "Katz, Gary CTR DC3DCCI"
<Gary.Katz.ctr@dc3.mil>, JG on CTI-TC <jg@ctin.us>
Date:
11/14/2017 11:35 PM
Subject:
Re: [cti-stix]
Re: [EXT] [cti-stix] RE: [Non-DoD Source] [cti-stix] Eight Arguments for
an Infrastructure SDO for STIX 2.1
Sent by:
<cti-stix@lists.oasis-open.org>
We should probably get people together to talk about and
discuss. This will help us know for sure if a change is needed and
to what extent that change is needed.
What we really need is people that have started writing
code for this. This discussion is not about theory, or perceived
goodness or badness, but what have people seen in working code.
Bret
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8
ACAE 7415 0050
On Nov 15, 2017, at 7:51 AM, John-Mark Gurney <jmg@newcontext.com>
wrote:
Jason Keirstead wrote this message on Tue, Nov 14, 2017
at 16:48 +0000:
I have yet to see someone present a concrete use case
for why we should
make cyber observables a TLO. It has been proposed multiple
times in the
past and debated to death - it is perhaps the second-most
debated subject
in the TC (after timestamps). I am all for the idea
of "fixing what is
broken" in STIX, as Brett says, but to me if we are
going to re-open
topics that have been extensively debated and yet voted
on in another
direction, there is a significant burden on the proposer
as to why it
should be re-opened. I don't see that burden being met
here.
What are the specific modeling problem(s) that would be
solved by making
cyber observables top level objects, that can not be solved
in any other
fashion?
I agree. There is lots of talk, but little documentation on why the
change should be done, what it will look like, how it will be used, etc.
Yes, people have bits and pieces throughout emails, but there is not a
document that even a majority of the proponets of the concept even agree
upon things should look like.
--
John-Mark
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]