cti-users message

Subject: RE: [cti-users] "Data Marking" syntaxes

From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
To: "Davidson II, Mark S" <mdavidson@mitre.org>
Date: Thu, 5 Nov 2015 10:30:00 -0400

I do not believe the marking has to know or care about the organizational membership. What matters is that the marking can contain a reference to it, so that software can dereference it if required.

It is easier to use examples - this is the current TLP marking:

<stix:Handling>

<marking:Marking>

<marking:Controlled_Structure>

//node() | //@*

</marking:Controlled_Structure>

<marking:Marking_Structure

xsi:type=

"tlp:TLPMarkingStructureType"

tlp:color=

"AMBER"

</marking:Marking>

</stix:Handling>

What is required is something akin to this, where I can mark one piece of data with multiple different controls based on target

<stix:Handling>

<marking:Marking>

<marking:Controlled_Structure>

//node() | //@*

</marking:Controlled_Structure>

<marking:Marking_Structure

xsi:type=

"tlp_plus:TLPPlusMarkingStructureType"

tlp:color=

"RED"

tlp:target="//fs-isac.com"

</marking:Marking>

<marking:Marking>

<marking:Controlled_Structure>

//node() | //@*

</marking:Controlled_Structure>

<marking:Marking_Structure

xsi:type=

"tlp_plus:TLPPlusMarkingStructureType"

tlp:color=

"AMBER"

tlp:target="

//dhs.gov

</marking:Marking>

<marking:Marking>

<marking:Controlled_Structure>

//node() | //@*

</marking:Controlled_Structure>

<marking:Marking_Structure

xsi:type=

"tlp_plus:TLPPlusMarkingStructureType"

tlp:color=

"AMBER"

tlp:target="

mycompany.com"

</marking:Marking>

</stix:Handling>

As others pointed out in the past - it's up to the consuming software implementation and/or humans to decide to enforce or not enforce the marking, so we don't need to worry about STIX caring about who belongs to an organization.

The important part is that the marking can contain the orgnization at all - today, with TLP, it can not.

-
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

"Davidson II, Mark S" ---2015/11/05 10:14:45 AM---For me, the concept of an organization is nebulous enough that it’s really hard for a software syste

From: "Davidson II, Mark S" <mdavidson@mitre.org>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Collie, Byron S." <Byron.Collie@gs.com>
Cc: "Camp, Warren (CTR)" <warren.camp@associates.hq.dhs.gov>, Michael Hammer <michael.hammer@yaanatech.com>, "Pam.Smith@jhuapl.edu" <Pam.Smith@jhuapl.edu>, "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Date: 2015/11/05 10:14 AM
Subject: RE: [cti-users] "Data Marking" syntaxes

For me, the concept of an organization is nebulous enough that it’s really hard for a software system to determine organizational membership without a very well curated dataset or some other simplifying constraint(s). I believe that there are solutions that work well for their current case (as many on this list provide evidence for), but do those solutions also work in a fully automated, at-scale future? Partly I don’t know, because partly I don’t know exactly what the future will look like.

The threat sharing vision today seems to include this idea that a blob of threat information can be properly marked, sent to property functioning threat sharing system(s), and properly distributed throughout the threat sharing ecosystem, which depending on who you ask might include hundreds of to-be ISAOs. I have two pieces of evidence that suggest this might not work. The first is that I’m not aware of any existing technology that works this way (if there is, we can just steal that and call it a day). The second is that, to the best of my knowledge (which I readily admit is incomplete), the implementations that I know about make simplifying assumptions that will not work for widespread and automated threat sharing. Partly I make these assertions as a challenge – please show that I’m wrong and that we have a workable, scalable design.

@Byron, I’m also interested in how the TLP setup works for FS-ISAC. I’m anticipating a simplifying assumption (e.g., centrally managed credentials), but I hope there isn’t one and that we can just leverage what’s already been invented.

I’ll also re-iterate my earlier suggestion for end-running the re-sharing problem. If information owners also perform access control instead of trusting the community to do it for them, then I’m hoping that many of the marking uses can be simplified out of existence.

Thank you.
-Mark

From:

cti-users@lists.oasis-open.org [

mailto:cti-users@lists.oasis-open.org

]

On Behalf Of

Jason Keirstead

Sent:

Thursday, November 05, 2015 8:43 AM

To:

Collie, Byron S. <Byron.Collie@gs.com>

Cc:

Camp, Warren (CTR) <warren.camp@associates.hq.dhs.gov>; Michael Hammer <michael.hammer@yaanatech.com>; Pam.Smith@jhuapl.edu; cti-users@lists.oasis-open.org

Subject:

RE: [cti-users] "Data Marking" syntaxes

@Byron, can you expound on this

"TLP AMBER to the FS-ISAC membership only. We do this all the time. "

If you are using a shared system for Threat Intelligence, how do you mark one piece of data as TLP Amber "For FS-ISAC Only" and then mark a different piece of data TLP Amber for Entity 2. This is my exact point.. there is no way to mark data as "TLP Amber For FS-ISAC Only" today with STIX. You would have to run two different, independent repository systems to do something like that, and have most of your intelligence duplicated, along with all of the systems consuming the intelligence.

-
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

"Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other g

From: "Collie, Byron S." <Byron.Collie@gs.com>
To: "Camp, Warren (CTR)" <warren.camp@associates.hq.dhs.gov>, Michael Hammer <michael.hammer@yaanatech.com>, "Pam.Smith@jhuapl.edu" <Pam.Smith@jhuapl.edu>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <cti-users@lists.oasis-open.org>

Use Case 1: IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but not the other global entity. TLP does not allow one to do this. This problem with TLP is very bad and makes intra-organizational sharing impossible with TLP.

TLP AMBER to the FS-ISAC membership only. We do this all the time. Often times we may try and remove attribution to allow broader sharing with partners but if the submitting member says FS-ISAC only, we honor Originator Control, just the same as the Intel Community does.

Use Case 2: Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but, when the information is shared globally, Company A wants (or does not want) anonymity.

Currently anonymity is afforded through manual submission on the FS-ISAC portal only. Automated anonymity is a bit harder to implement and still maintain some level of integrity around the source of the data.

TLP AMBER. TLP RED would mean no one not on the direct communication could action it.

Use Case 4: Acme Indicators supplying indicators for profit to Company C. Company C is not allowed to do further sharing but is allowed to create and share, without restriction, any derivative works.

ACME > Company C TLP AMBER. The question is what is considered a derivative work? The general understanding we have with most sources/organizations is, we can share any direct observations and information not considered proprietary under the ACME – Company C NDA. We also have contractual caveats to allow sharing with law enforcement in response scenarios as well.

Use Case 5: Company A posts an indicator that is free to share, no restrictions, no anonymity required (Does TLP White as-is work for this?).

TLP WHITE.

Use Case 6: Company A shares an indicator with Company B. No further sharing allowed with anyone. (Does TLP Red as-is work for this?)

TLP AMBER.

Byron

From:

Camp, Warren (CTR) [

mailto:warren.camp@associates.hq.dhs.gov

]

Sent:

Wednesday, November 04, 2015 1:57 PM

To:

Michael Hammer;

Pam.Smith@jhuapl.edu

;

Jason.Keirstead@ca.ibm.com

; Collie, Byron S. [Tech]

Cc: