cti message

Subject: Re: [cti] CTI TC Adoption and Interoperability SCs

From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Mon, 13 Jul 2015 15:27:23 -0300

RE STIX 3.h, I would also like to see included in the profile a list of the CybOX objects supported.

RE TAXII 8,9 I am not sure how authentication types can be included in the profile when they are not part of the TAXII protocol.

-
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

"Jordan, Bret" ---2015/07/13 01:18:43 PM---Wow we have gotten off in to the weeds quickly. Might I suggest that before we build the Autobahn a

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/07/13 01:18 PM
Subject: Re: [cti] CTI TC Adoption and Interoperability SCs
Sent by: <cti@lists.oasis-open.org>

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
5) Do you support STIX Profile processing at all

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: