Re: [cti-stix] How should this look

I agree with that. End to end workflow is where we need to be talking about this.

Bret

Sent from my Commodore 64

On Jan 29, 2016, at 2:49 PM, Wunder, John A. <jwunder@mitre.org> wrote:

Let’s focus on defining how this will work as a full-stack and then later on we can decide the exact tearlines between TAXII and STIX. Right now I think it’s still hard to say what the responsibilities/data will be at each level and so it’s hard to have concrete discussions.

Bottom line though I do think we need the concept of content-aware message types.

On 1/29/16, 4:47 PM, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

Maybe, maybe not. We will need to work through the end to end work

flow and see what makes the most sense.

For broad scale use, and wide adoption within tools, STIX and TAXII will be joined at the hip.  You will really need both to get the full experience.  And people wanting to share stuff over CDs or email or IM will probably just ask the person for the data.  The reason for doing things in structured objects is so machines and devices can operate on the data in near real-time.

I do not think the analogies of STIX and TAXII to networking protocols is a good way to go.  It is more attuned to something further up the stack.

Bret

Sent from my Commodore 64

On Jan 29, 2016, at 2:30 PM, Terry MacDonald <terry@soltra.com> wrote:

I disagree. TAXII in my mind deals with transferring CTI data from one l location to another. I view it as analogous to the IP protocol. It's about getting days from one place to another to the people who should be a allowed to receive it.

STIX is the actual data being sent to those people. It's partially analogous to the TCP protocol. This clear separation of duties offers multiple benefits:

- STIX requests and responses will still work when TAXII isn't being used

- STIX only needs to know about STIX objects.

- TAXII only needs to worry about delivering content to everyone in the group

- it makes it possible for TAXII to carry other CTI types of data, e.g. CVRF, VERIS, out anything else that someone will register a mime type for.

In my mind the flexibility that is gained by having STIX requests and responses separate from TAXII query are useful and important. The ability to use STIX requests and responses over mediums that are not TAXII are especially important during the transition phases that we have now. There will be people who send STIX over email, others who share via file shares. It is important that these people have access to the same enhanced functionality as well (even of they don't have a TAXII server).

Cheers

Terry MacDonald

On 29/01/2016 14:50, "Jordan, Bret" <bret.jordan@bluecoat.com> wrote:

I understand the desire for having this functionality amongst a sharing group, but I believe this is best done via TAXII, even though the TAXII 2.0 design does not yet have this functionality.  STIX should just be STIX.

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 Jan 28, 2016, at 20:04, Wunder, John A. <jwunder@mitre.org> wrote:

IMO this really gets at the messaging concept…how will people be sharing STIX? In STIX 1.2 it’s been “here’s a package of STIX content”, but moving forward we’ve talked about things like more focused messages and request/response.

So I would think we need to build out a “message base” like we’re doing with the CTI core object fields. Things like message IDs, types, and timestamps but also things that need to go alongside all STIX content: information sources, data markings, etc. Then if we define a “package”, it’s probably just a big list of objects (including relationships).

(fwiw we mocked this up in twigs, though haven’t had a lot of time to work through it so consider it very rough: https://github.com/johnwunder/twigs/tree/master/data-model/messages)

From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry@soltra.com>

Date: Thursday, January 28, 2016 at 7:49 PM

To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>

Subject: [cti-stix] RE: How should this look

Yep Bret,

I like that. I think it would work well with STIX requests and responses as well so I like that:

{

  "type": "stix-request",

  "id": "stix-request--3ba2c668-6aa3-4f3d-abd4-82f884e8f99d",

  "request": {

     …

  }

}

And

{

  "type": "stix-response",

  "id": "stix-response--656ff5b4-3c2b-441c-b570-9f6ec549582f",

  "request_id": "stix-request--3ba2c668-6aa3-4f3d-abd4-82f884e8f99d",

  "response": {

     …

  }

}

I have a couple of questions about the stix-package use though…

1.       Will multiple stix packages be able to be sent in the same TAXII exchange?

2.       Will STIX packages be able to be sent along with STIX requests and STIX responses in the same TAXII exchange? I think they should so that we open up the possibility of long polling/streaming of data

3.       Does the stix package need an ID if we are only concerned about the id’s of the objects within the stix-package? i.e. its only an envelope at present, does that need an ID.

4.       Or.. should we keep the stix-package ID to keep in line with the stix-requests and stix-responses that will need an ID to keep track of them and the relationships between them

That’s off the top of my head so please excuse any mistakes J.

Cheers

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret

Sent: Friday, 29 January 2016 10:13 AM

To: cti-stix@lists.oasis-open.org

Subject: [cti-stix] How should this look

I want to start writing some APIs for STIX 2.0..  But I am not yet sure how things should look at the top level...  I am thinking something like????  This is meant to get people talking so we can start fleshing this out as cleanly and rapidly as possible.

{

  "type": "stix-package",

  "id": "stix-package--ad3d029f-6fe7-4923-aafc-3b69aed32365",

  "indicators": [

    {

      "type": "indicator",

      "id": "indicator--3d5338a0-9305-4373-b59c-616ac2e9b18f",

      "timestamp": "2016-01-28T15:44:53Z",

      "title": "Some really neat indicator that we found"

    }

  ]

}

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

---------------------------------------------------------------------

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

cti-stix message