Hi Eric,
Just to clarify something mentioned below. "Since we do not have profiles (yet), one would be hard pressed to say one does “profile processing.”"
We do currently have profiles and we do currently have “profile processing”. Many community members (including sharing communities that are CTI community members) are currently leveraging profiles. They specify them, share them and design their processes
around them.
There is a difference between:
having the capability to specify, understand and leverage a profile
and
having a catalog/registry of officially blessed profiles and shared tooling implementations to process them
The second is a great goal but is not required for using profiles.
Does that make sense?
sean
From: Eric Burger <
Eric.Burger@georgetown.edu >
Date: Monday, July 13, 2015 at 12:34 PM
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Agreed. It will also be telling if people are not implementing the required fields. Either that means the fields really are not required, we are not being clear enough on why (or what) they are required, or the implementation is simply “not CTI”.
On the STIX side, see below.
On Jul 13, 2015, at 12:18 PM, Jordan, Bret <
bret.jordan@bluecoat.com > wrote:
Wow we have gotten off in to the weeds quickly. Might I suggest that before we build the Autobahn and the Golden Gate Bridge, that we first learn how to ride a horse?
All I would like to see for Phase 1 of this is "high level compatibly statements". Something like----
For STIX:
Does your product support:
1) Data marking / handing
2) Information source integrity
3) The required fields from
a) Indicators
b) Incidents
c) Threat Actors
d) Campaigns
e) TTPs
f) Course of Actions
g) Exploit Targets
h) Observables
4) Do you have a UI for STIX generation
If all I do is receive and correlate STIX, then I can be fully compliant yet not do the fancy GUI.
5) Do you support STIX Profile processing at all
Since we do not have profiles (yet), one would be hard pressed to say one does “profile processing.” Likewise, what would profile processing look like? I would offer the relevant question is “can you {process, generate} STIX Profile A, B, C, …"
For TAXII:
Does your product support:
1) Discovery Services
2) Collection Services
3) Subscription Services
4) Poll Services
5) Inbox Services
6) Data Feeds
7) Data Collections
8) Authentication
9) Two-factor Authentication
10) Delete Requests
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 Jul 13, 2015, at 08:41, Eric Burger <
Eric.Burger@georgetown.edu > wrote:
I
am (clearly) all for profiles. However, negotiating at the profile level would be very bad for the future of the protocol.
Let us say we have Profile A that uses STIX optional* features S1, S2, and S3 as well as CybOX objects O1, O2, and O3. Then we have Profile B that uses STIX optional features S2, S3, and S4 as well as CybOX objects O1, O3, and O4. Profile A and B are well-known,
are in the registry, and are broadly implemented.
Tomorrow, my buddies and I (e.g., trading partners) come up with a new use case. Let us call it Use Case C. Use Case C uses STIX features S1, S3, and S4 and CybOX object O1, O2, and O4.
If we negotiate at the STIX and CybOX level, my new use case just works. As it happens, everybody implements S1, S3, S4, O1, O2, and O4. Life is good. We just quashed a major attack from a real baddie through the wonders of information sharing and the power
of TAXII, STIX, and CybOX. Thank you DHS, MITRE, and the community for all of our hard work. It paid off.
Now let us imagine what happens if we negotiate at the Profile level. Again, my buddies and I come up with Use Case C. However, before we can use it, we have to bring it to OASIS. Now, OASIS works (today) a lot faster than the ITU-T or the IETF. So, in a scant
six months, we publish Profile C. Then, the vendors start to pick it up. Within two years, everybody that cares about Use Case C can negotiate support for it.
In the intervening three years, bank accounts are drained, the power grid got shut off, and child pornography runs rampant.
Worse yet, enterprises who cared about Profile A and Profile B did not think care about Profile C. So, they chose not to pay their vendors megabucks for the Profile C ‘upgrade.’ It is a real upgrade, in that the systems need to know about Profile C to negotiate
for it. However, it is an upgrade in quotes, because no new STIX or CybOX support needed to be implemented. Of course, you know what comes next. Those enterprises succumb to Use Case C attacks. Now, Armageddon was launched as Use Case C turns out to be an
APT that targets the SBLM MIRV fire control system. Bad day for the world.
All because we decided to negotiate profiles and not capabilities.
Please , keep negotiation at the building block level, not the profile level. Profiles are incredibly useful to let purchasers of CTI systems know what they are buying and likewise they are incredibly useful to manufacturers of CTI systems to
let them know what to build. However, profiles are harmful as a protocol mechanism.
* Notice that profiles only tell folks what optional (SHOULD, MAY) features need to be there. Of course, all mandatory features are there.
Otherwise, you should not call your product an implementation of TAXII, STIX, and CybOX.
On Jul 13, 2015, at 9:03 AM, Davidson II, Mark S <
mdavidson@MITRE.ORG > wrote:
I’ll note, shortly, that TAXII 1.1 has the ability to negotiate STIX Profiles using the Content Type / Subtype mechanism, where the Subtype is used to specify
a STIX Profile.
That said, I’m not sure the heart of the discussion has much to do with TAXII’s current form. I think the heart of this discussion is: “What capabilities offer
the greatest value to cyber defenders? How do we implement those capabilities?” From there, we can evaluate TAXII (and STIX) against those desired capabilities and identify any gaps that need to be closed. Of course my feeling is that we are already “pretty
close”, but I’d rather that conclusion become evidence based (I’m noting the quote in Jason’s signature as I type this).
Thank you.
-Mark
From:
cti@lists.oasis-open.org [ mailto:
cti@lists.oasis-open.org ] On
Behalf Of Jason Keirstead
Sent: Monday, July 13, 2015 8:27 AM
To: Trey Darley
Cc: Eric Burger;
cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
That would be fantastic.... along with a profile negotiation mechanism added to TAXII, the mechanism could refer to the profiles in the repository by URI.
-
Jason Keirstead
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
<image001.gif> Trey Darley ---2015/07/13 06:40:07 AM---What about having the TC maintain a repository of STIX Profiles aligned with specific use cases,
som
From: Trey Darley <
trey@soltra.com >
To: Eric Burger <
Eric.Burger@georgetown.edu >,
"
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Date: 2015/07/13 06:40 AM
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Sent by: <
cti@lists.oasis-open.org >
What about having the TC maintain a repository of STIX Profiles aligned with specific use cases, something like a standard library?
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
Soltra An FS-ISAC & DTCC Company
www.soltra.com From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org >
on behalf of Eric Burger <
Eric.Burger@georgetown.edu >
Sent: Monday, July 13, 2015 11:25
To:
cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
We are years too soon for a ‘maturity’ or “My product implements X% of STIX and CybOX” scale to be of any use to anybody, except perhaps the marketing departments of vendors.
One of the great features of STIX and CybOX is they do everything . The biggest downside of STIX and CybOX, as evidenced by
a number of the IETF references that have flown about on the list, is they do everything .
Think of profiles as applications that run on top of STIX and CybOX. If you want to exchange DDoS information, think of it as the DDoS application that runs on STIX and CybOX with features
A, B, D, and Q. If you want to exchange phishing information, that is the phishing application that runs on STIX and CybOX with features A, R, and S.
A critical success factor for STIX and CybOX is that anyone should be able to create any kind of application without asking OASIS. If you want to exchange foo information that uses
features A, T, and Z, so long as the underlying implementations offer A, T, and Z, the exchange will happen. That means that we need to have meaningful behavior for implementations that do not offer T, such that the person sending the foo will know why the
other side barfed.
Said another way, TAXII needs to be able to negotiate capabilities in terms of A, B, C, … It would be a disaster and spell doom for the adoption of STIX/TAXII/CybOX if TAXII negotiated
capabilities in terms of DDoS, phishing, and foo.
On Jul 9, 2015, at 12:55 PM, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
wrote:
I feel like the profile conversation does not get well served by trying to use it to discuss it as a "maturity scale" - they are not really the same thing. CybOX*, STIX and TAXII are
very robust protocols that have *a lot* of optional information, and not all of that information is relevant to all consumers or producers of STIX. Just because a product only supports a given profile does not mean that product is not mature... the information
in other profiles may not be in any way relevant to that product class, and the product class will likely never support any more as a result.
This is why profiles are so important, because in order for products to inter-operate using these protocols, people using them need to "know what to expect" when they connect the products.
* As well, trying to call out the importance of CybOX in the profile conversation, simply because I don't see it mentioned much in these emails... the CybOX objects supported is a critical component of any profile in my opinion. I foresee a lot of consumer
products not being able to support the full set of all possible CybOX objects and their operators.
-
Jason Keirstead
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
<graycol.gif> Mark Clancy ---2015/07/09 01:38:42 PM---Maybe the context that would be helpful to add is what does the thing implementing TAXIISTIXCybox
From: Mark Clancy <
mclancy@soltra.com >
To: Terry MacDonald <
terry.macdonald@threatloop.com >,
Eric Burger <
Eric.Burger@georgetown.edu >
Cc: "
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Date: 2015/07/09 01:38 PM
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Sent by: <
cti@lists.oasis-open.org >
Maybe the context that would be helpful to add is what does the thing implementing TAXIISTIXCybox actually do?
Does it consume specific data, does it publish specific data, or does it aggregate/link all data ?
The STIX profile attempted to address this with kind of saying. “Hey this is what I actually support”. If I am a CTI producer focusing on one thing like say DDoS attacks that narrow subset of Stix and Cybox objects defined in the profile may well be the maximum
content I would every produce anyway so having a maturity of "X" is the max that I could ever be and similarly if I was a defensive tool that re-directed access to evil web sites support cybox object with Windows Registry keys are fairly irrelevant. On the
other hand if I am sharing hub/aggregation portal or a SIEM those same levels of support in the STIX profile are way below what a customer of that platform would expect. Those should not get treated in the same way on a maturity curve.
The downside of a "maturity scale" is that it can be viewed as penalizing specialty services/tools that don't need every widget to have maximum effectiveness for what they do where as you kind of want to point out that another platform is less mature as it
left a lot of capability on the table with their implementation and therefore have sub-optimal effectiveness given what it could be doing to feel that pressure.
So what the heck should we do?
We need to put life into the STIX profiles.
We need to figure out a way to differentiate STIX profiles where the maximum needed to do the purpose has been achieved and where things are left on the table.
For the buyer of a solution this is the critical difference and if we can’t express that difference some how that in my experience tend to lay blame (in the mind of the buyer) with the standards not the implementation by their suppliers.
-Mark
Mark Clancy
Chief Executive Officer
SOLTRA An
FS-ISAC and DTCC Company
+1.813.470.2400 office +1.610.659.6671 US mobile ? +44
7823 626 535 UK mobile
mclancy@soltra.com soltra.com
One organization's incident becomes everyone's defense.
?
From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org >
on behalf of Terry MacDonald <
terry.macdonald@threatloop.com >
Sent: Wednesday, July 8, 2015 8:26 PM
To: Eric Burger
Cc:
cti@lists.oasis-open.org Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Yes, well stated Pat. I especially like the notion of describing what you need and nothing more.
Cheers
Terry MacDonald STIX, TAXII, CybOX Consultant
M: +61-407-203-026
E:
terry.macdonald@threatloop.com W:
www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
On 9 July 2015 at 03:45, Eric Burger <
Eric.Burger@georgetown.edu >
wrote:
I am normally allergic to profiles, but as Bret says, let’s look at this from the perspective of the customer or the product manager. They are not buying
STIX. They are buying in to an information sharing ecosystem. No matter how much we wish they did, they will not care whether it is STIX, IODEF, OpenIOC, or carrier pigeon under the hood. We offer that by building STIX-enabled products (product manager), your
products will seamlessly fit into the ecosystem, which makes the product more attractive to customers.
We are WAY too early in the process to define levels of STIXiness. However, the profiles (should) fit into use cases. Use cases (should) reflect what customers want to buy (use cases that need solving) and as such what people want to build.
So, I would offer while we are not ready (I’m thinking years here) for building a maturity model, we are getting close (I’m thinking 18 months here) for having ‘profiles’ or “documented use cases” that enumerate which of the optional components of the CTI suite
a product needs to have to meaningfully address the use case.
On Jul 8, 2015, at 1:13 PM, Barnum, Sean D. <
sbarnum@mitre.org >
wrote:
+1 Well stated, Pat. I think that profiles are a key part of use case breakdown on these issues.
sean
From: Patrick Maroney <
Pmaroney@Specere.org >
Date: Wednesday, July 8, 2015 at 12:45 PM
To: "Barnum, Sean D." <
sbarnum@mitre.org >,
Steve Cell <
ikirillov@mitre.org >,
Terry MacDonald <
terry.macdonald@threatloop.com >,
"Jordan, Bret" <
bret.jordan@bluecoat.com >
Cc: David Eilken <
deilken@fsisac.us >,
"Struse, Richard" <
Richard.Struse@HQ.DHS.GOV >,
Eric Burger <
Eric.Burger@georgetown.edu >,
"
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
I may be missing something here and have been hesitating throwing in my usual advocacy for STIX Profiles [Plus] as a method to help manage complexity, interoperability,
different world views, use cases, etc.,
We've had almost identical conversations when defining the two initial "Standard STIX Profiles" (1) Simple, (2) Complex. The objective of this exercise was to establish consensus for two initial Community driven "Standard" STIX Profiles and then use these and
iterate over them to revise or create new Community "Standard" STIX Profiles.
Dr. Burger makes good arguments on these topics, which I will attempt to paraphrase:
(1) The CTI language should be precise both in terms of how one expresses any given "thing" and similarly precise in how one interprets "things" expressed in this manner.
(2) The language should (must?) limit the ability to represent a given "thing" in multiple ways.
I have always agreed with these objectives.
However, I still see extended STIX Profiles (Human and Machine readable) as a viable approach to providing an Abstraction Layer to help manage Complexity, establish and iterate on common Use Cases, clearly specify what I can convey/consume (from Simple to Complex),
and to describe methods and any assumptions (e.g. Tokenization, TLP Mapping Transforms, COA).
Context for my World View is that CTI provides the Inter-exchange mechanisms for specific dialogs between specific members of a very specific Community of Trust and/or Operational Domains. Many variations of these CTIX Communities/Operational Domains will be
established. So from these perspectives there is never any intent to forge "One Ring to Rule Them All". Understand there are also those quite legitimately seeking a unified "STIX" package (a lthough I might quip that Einstein was quite legitimately
seeking similar unification ;-).
Also note that I've argued for the addition of a very explicit form of STIX Profile: I only describe the things I can (1) Convey, (2) Consume, and/or (3) Understand. this proposed form of STIX Profile can
be extremely simple and only needs to enumerate what I can (1) Convey and (2) Consume. This form of STIX Profile would include provisions to optionally share information on policies, exception handling, etc (i.e.,
My Policy for Undefined Content: (1) Ignore, (2) Discard, (3) Save for future consideration/reprocessing, (4) Reject Entire Package, (5) Hold and Contact Source. However, Key take-away here is: You
only describe what you need and nothing more.
Perhaps a different way of expressing the underlying concept of what I'm proposing for consideration :
Before sending our "Little CTI" out in the world on her own: Let's define some initial boundaries and give her some training wheels. As she explores, try's new things, makes mistakes, learns, and continue
to expand her horizons, we can eventually remove the Training Wheels.
I was planning to wait for the CTI TC re-organization dust to settle before re-engaging the community in discourse on extending STIX Profiles. However, I wanted to raise it here in the contexts of the ongoing discussions on complexity, interoperability, maturity
levels, impediments, to adoption, etc.
Patrick Maroney
Office: (856)983-0001
Cell:: (609)841-5104
Email:
pmaroney@specere.org From: <
cti@lists.oasis-open.org >
on behalf of Sean Barnum <
sbarnum@mitre.org >
Date: Wednesday, July 8, 2015 at 10:15 AM
To: "Kirillov, Ivan A." <
ikirillov@mitre.org >,
Terry MacDonald <
terry.macdonald@threatloop.com >,
"Jordan, Bret" <
bret.jordan@bluecoat.com >
Cc: David Eilken <
deilken@fsisac.us >,
Richard Struse <
Richard.Struse@HQ.DHS.GOV >,
Eric Burger <
Eric.Burger@georgetown.edu >,
"
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
+!
I think Ivan hit the nail squarely on the head here. I think this is the only way that a maturity model can be effective. Blurring the lines together will generally mean the maturity levels are misleading.
sean
From: <Kirillov>, Steve Cell <
ikirillov@mitre.org >
Date: Wednesday, July 8, 2015 at 8:35 AM
To: Terry MacDonald <
terry.macdonald@threatloop.com >,
"Jordan, Bret" <
bret.jordan@bluecoat.com >
Cc: David Eilken <
deilken@fsisac.us >,
"Struse, Richard" <
Richard.Struse@HQ.DHS.GOV >,
Eric Burger <
Eric.Burger@georgetown.edu >,
"
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Interoperability is important, but I’m a little wary of having any sort of abstract system of maturity levels without additional context. The thing is, STIX and CybOX support so many different use cases that just saying that one has to meet a certain threshold
with regards to a particular maturity level isn’t terribly useful and in my view could be harmful. For example, if my product is only focused on the generation of simple network indicators (IPs, URLs, etc.), why should I have to support every CybOX Object?
Also, just saying that one supports a CybOX Object doesn’t necessarily mean that one supports every field in the Object, which is quite relevant for some of the larger objects out there (e.g., the Windows Executable File).
Instead, I would suggest that we begin by documenting, even at a high level, the particular use cases that we wish to support with STIX and CybOX. These could then, in turn, have their own native set of maturity levels (defined independently for STIX and/or
CybOX as appropriate ). I could envision this as a taxonomy, e.g.,
· Indicator
Characterization/Sharing
· Host-based
Indicator Sharing
· STIX
· Level
1: Basic Context
· Level
2: Level 1 + Supports Sightings
· CybOX
· Level
1: Supports File Object
· File_Path
field
· Hashes
field
· Level
2: Level 1 + Supports Windows Registry Key Object
· Network
Indicator Sharing
· TTP/Malware
Characterization Sharing
· Basic
TTP/Malware Characterization
Still arbitrary, but at least we could then tell vendors that if they want to minimally/somewhat/fully support a particular use case in TAXII they need to do XYZ. Also, if we do go
down this road of per-use case based maturity levels, I’d recommend limiting the number of levels to 3 to keep things sane:
· Level
1: minimal support – very basic, incomplete support
· Level
2: partial support – typical/average support (with what is commonly expected with regards to the use case)
· Level
3: full support – fully supports the use case, in all facets
Regards,
Ivan
From: Terry MacDonald <
terry.macdonald@threatloop.com >
Date: Tuesday, July 7, 2015 at 7:26 PM
To: Bret Jordan <
bret.jordan@bluecoat.com >
Cc: David Eilken <
deilken@fsisac.us >,
Richard Struse <
Richard.Struse@HQ.DHS.GOV >,
Eric Burger <
Eric.Burger@georgetown.edu >,
"
cti@lists.oasis-open.org "
<
cti@lists.oasis-open.org >
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
I agree. I like the way this is headed.
I would like to see each SC produce a list of levels that help guide vendors towards a development roadmap for their products. The number of levels could be different for each SC if that makes sense to the SC, but would also align as closely as possible with
the equivalent level of the other SCs e.g. TAXII Level 2 would work with STIX Level 2 and CybOX Level 2. I prefer separate maturity levels per SC as it frees products to support STIX and CybOX, but not TAXII, or to be fully STIX compliant but not support all
CybOX objects. It will give vendors a better chance of documenting their maturity more accurately, and as mentioned gives each SC the ability to identify what the requirements of each level are independently.
Cheers
Terry MacDonald STIX, TAXII, CybOX Consultant
M: +61-407-203-026
E:
terry.macdonald@threatloop.com W:
www.threatloop.com Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
On 7 July 2015 at 06:55, Jordan, Bret <
bret.jordan@bluecoat.com >
wrote:
The thing I like about this, if it is simple enough to understand and figure out/test for, is it gives developers/product managers a line in the sand to shoot for.
I often get asked by many a vendor, "how much of STIX / TAXII do I need to implement to do XYZ?"
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 Jul 6, 2015, at 14:50, David Eilken <
deilken@fsisac.us >
wrote:
Eric, I was just about to chime in that we do need some maturity measurements (vs testing/ validation), but I it didn't sound like you are necessarily in contention with that, and I wouldn't advocate for layers and layers of testing.
More on Maturity Measurements, since we recently took a stab at it (below). To Mark's previous points, there is value in essentially chunking the STIX profile into different levels of maturity and also identifying certain features (STIX Editing for example)
as measurements of more mature implementations. Same could be done for TAXII (ingesting STIX from a Feed is simple compared to pushing data back to an Inbox). This approach starts to overlap with the more "qualitative" aspects that Jane referred to.
Level 1: Supports a subset of STIX object types (Indicators). Supports a subset of CybOx object types (observables)
Level 2: In addition to level 1, adds basic context like: title, description, types, date/times, producer, etc.
Level 3: In addition to level 2, adds support for Sightings
Level 4: In addition to level 3, adds all STIX and CybOx object types.
Level 5: In addition to level 4, adds support for STIX object updates and Revocation
Testing and measuring maturity would essentially be separate items. One would test sample data against a submitted profile for validation/ interoperability, and then measure it's maturity.
Dave
________________________________________
From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org >
on behalf of Struse, Richard <
Richard.Struse@HQ.DHS.GOV >
Sent: Monday, July 6, 2015 1:09 PM
To: Eric Burger;
cti@lists.oasis-open.org Subject: RE: [cti] CTI TC Adoption and Interoperability SCs
I think we are actually in agreement. I'm not advocating heavyweight "suites" of exhaustive tests but I do think we will benefit from a shared understanding of the basic outlines of what it means to be interoperable. Definitely a question that the SC would
need to tackle.
Original Message-----
From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Eric Burger
Sent: Monday, July 06, 2015 3:47 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Believe it or not, I would shy away from any measurements short of what we say someone needs to do to meet a profile, which is the profile definition itself.
Likewise, I would shy away from test or verification suites. The industry’s experience with standards with elaborate verification suites has been the protocols fail because it takes ages to build the verification suites, they are obsolete when published, which
ossifies the underlying specification.
In a decade after everyone is using STIX and TAXII, we can think about formal acceptance suites.
If the specifications are so obfuscated we need specifications to specify what the specifications specify, we have failed.
On Jul 6, 2015, at 3:39 PM, Struse, Richard < Richard.Struse@hq.dhs.gov >
wrote:
Makes sense.
If we (the CTI TC) focus on defining what interoperability means for
STIX/TAXII/CybOX and how to measure/verify it, that leaves the door open for
third-party organizations such as testing labs to conduct interoperability
tests using the CTI TC-defined benchmarks.
Original Message-----
From: cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf
Of Eric Burger
Sent: Monday, July 06, 2015 3:18 PM
To: cti@lists.oasis-open.org
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
When I was Chair of the SPEECHSC IETF Work Group (speech server control), we
setup a self-reported interoperability matrix:
http://standardstrack.com/ietf/speechsc/MRCPv2-Plans.html
Same for LEMONADE (mobile messaging):
http://standardstrack.com/ietf/lemonade/Lemonade-Plans.html
The idea is OASIS will *not* become the protocol police. That is too
expensive and carries unlimited liability. What a self-reporting resource
does do is (1) advertise who is running with the standards and (2) who has
tested against whom. That is not a guarantee of interoperability, but it is
lightyears ahead of publishing and praying.
On Jul 6, 2015, at 2:31 PM, Tony Rutkowski < tony@yaanatech.com >
wrote:
It would be useful if CTI maintained the equivalent of
the MILE Implementation Report ID just announced below.
Additionally, in a world of dramatic scaling of cloud data
center virtualization, especially NFV, instantiating a CTI
dedicated focus on the subject is important.
--tony
---------------
https://tools.ietf.org/html/draft-ietf-mile-implementreport-05
MILE C. Inacio
Internet-Draft CMU
Intended status: Informational D. Miyamoto
Expires: January 6, 2016 UTokyo
July 5, 2015
MILE Implementation Report
draft-ietf-mile-implementreport-05
Abstract
This document is a collection of implementation reports from vendors,
consortiums, and researchers who have implemented one or more of the
standards published from the IETF INCident Handling (INCH) and
Management Incident Lightweight Exchange (MILE) working groups.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php