Re: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [cti-s

Sorry for the late response – I was on travel and then took personal time. Responding to some of the points brought up:

Rich – you accurately relayed my thoughts. When I said “consumer” I meant the software system.

If somebody places IEP markings (or any marking, really, including TLP) on a STIX document, they will expect those markings to be honored.

Responding to Dave’s point:

> But even just a simple binary switch on *sending* IEP-marked data seems more sensible than relying on the receiver to filter out thing they shouldn't have received in the first place.

This is feasible from an ACL perspective, but not from a software capability perspective. As a sender of information, I know which user accounts have which permissions, and can control access accordingly. I have no way of knowing if the receiving software will honor the IEP markings, unless it is mandated in the spec. Maybe we are talking about the same thing. I agree with only sending marked data to those who have permission to get it. However, how will I know if the person/org with permission has _software_ that’s capable of processing what I’m sending? I know of two ways – content negotiation and rules in the spec.

I don’t think adding the rule anywhere other than in STIX makes sense. We can add properties to TAXII to help with the content negotiation, but that won’t help us in the case where e.g., STIX documents get uploaded manually to a central repo. This happens more than you might think.

If IEP is to be added to STIX, it’s 100% reasonable for software to declare whether it supports IEP or not. Otherwise, IEP will be a boondoggle for the whole ecosystem. I have suggested rejecting content as a solution for declaring support, and I am open to other solutions. Content negotiation in TAXII is not a complete solution, because plenty of STIX content is uploaded via file, and will continue to be uploaded via file.

Thank you.

-Mark

From: <cti-stix@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, August 11, 2017 at 8:05 AM
To: John-Mark Gurney <jmg@newcontext.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, Terry MacDonald <terry.macdonald@cosive.com>
Subject: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [EXT] [cti-cybox] Agenda for August 8 Working Call

To be clear - I don't think it can or should be implied that simply because a collection says it requires or supports a marking, that it is doing some kind of filtering. That is dangerous territory. The way that makings are interpreted is up to vendor to vendor and ISAO to ISAO, it can't be codified into TAXII spec.

In fact, I have been having this debate on slack and due to it I actually now think we should *not* have a "supported_markings" field because the definition of what "support" means is not going to be something we can ever define.

I think we should only have the "required_markings" field, as we *can* codify and test this in the spec (if the content doesn't contain the marking, it is rejected - easy peasy).

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security

Without data, all you are is just another person with an opinion - Unknown

From: John-Mark Gurney <jmg@newcontext.com>
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, Allan Thomson <athomson@lookingglasscyber.com>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, Terry MacDonald <terry.macdonald@cosive.com>
Date: 08/10/2017 08:53 PM
Subject: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [EXT] [cti-cybox] Agenda for August 8 Working Call
Sent by: <cti-cybox@lists.oasis-open.org>

Jason Keirstead wrote this message on Thu, Aug 10, 2017 at 09:34 -0300:
> I like this as well, I can foresee two fields being added to both
> collections and channels:
>
> required_markings
> supported_markings
>
> I will also throw out there that TAXII channels really needs work if we
> want it to be completed.

I agree that this is a great way to handle this... It is up to the sharing
groups to define what markings are required.

Having the TAXII client specify which marking it supports, and allowing the
TAXII server to filter what data it sends is the correct method IMO.

John-Mark

> From: Bret Jordan <Bret_Jordan@symantec.com>
> To: Terry MacDonald <terry.macdonald@cosive.com>, Jason Keirstead
> <Jason.Keirstead@ca.ibm.com>
> Cc: Allan Thomson <athomson@lookingglasscyber.com>,
> "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>,
> "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>, "Back,
> Greg" <gback@mitre.org>
> Date: 08/09/2017 06:41 PM
> Subject: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox]
> Re: [cti-stix] Re: [cti-cybox] Re: [EXT] [cti-cybox] Agenda for August 8
> Working Call
> Sent by: <cti-stix@lists.oasis-open.org>
>
>
>
> Terry,
>
> I really like the idea of including IEP support in TAXII. Assuming a user
> has the rights to know about certain levels of content it would be great
> if you could pre-filter on IEP restrictions.
>
> Bret
>
> From: Terry MacDonald <terry.macdonald@cosive.com>
> Sent: Wednesday, August 9, 2017 1:39:45 PM
> To: Jason Keirstead
> Cc: Allan Thomson; cti-stix@lists.oasis-open.org; Bret Jordan;
> cti-cybox@lists.oasis-open.org; Back, Greg
> Subject: Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re:
> [cti-cybox] Re: [EXT] [cti-cybox] Agenda for August 8 Working Call
>
> Perhaps this is where we could add the ability within TAXII channels to
> specify mandatory data marking requirements for that channel? That seems a
> nice way of saying 'to participate in this community, you need to support
> X'.
>
> Cheers
> Terry MacDonald
>
> On 10/08/2017 05:35, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:
> That said... I would be extremely strongly against requiring IEP in any
> interoperability profile.
>
> Data markings have many uses, but there are entire swaths of the
> cybersecurity space to which they are simply not applicable. There is no
> way we can mandate marking support in interoperability testing without
> excluding whole segments of the market.
>
> -
> Jason Keirstead
> STSM, Product Architect, Security Intelligence, IBM Security Systems
> www.ibm.com/security
>
> Without data, all you are is just another person with an opinion - Unknown
>
>
>
>
>
> From: Allan Thomson <athomson@lookingglasscyber.com>
> To: Bret Jordan <Bret_Jordan@symantec.com>, "Back, Greg" <
> gback@mitre.org>
> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org
> >, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
> Date: 08/08/2017 12:51 AM
> Subject: [cti-stix] Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox]
> Re: [EXT] [cti-cybox] Agenda for August 8 Working Call
> Sent by: <cti-stix@lists.oasis-open.org>
>
>
>
>
> We have not finished interop test specification for STIX 2.0 so until we
> have done that, it’s premature to be talking about what STIX 2.1 interop
> will or will not do.
>
> Part 1 ballot is still outstanding. Getting the TC to focus on Interop 2.0
> is hard enough.
>
> Allan Thomson
> CTO
> +1-408-331-6646
> LookingGlass Cyber Solutions
>
> From: OASIS list <cti-cybox@lists.oasis-open.org> on behalf of Bret Jordan
> <Bret_Jordan@symantec.com>
> Date: Monday, August 7, 2017 at 7:58 PM
> To: "Back, Greg" <gback@mitre.org>
> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, OASIS
> list <cti-cybox@lists.oasis-open.org>
> Subject: Re: [cti-cybox] Re: [cti-stix] Re: [cti-cybox] Re: [EXT]
> [cti-cybox] Agenda for August 8 Working Call
>
> Those are good questions. The specification will not mandate, or I hope
> will not mandate, the use of IEP, but is the interop SC going to mandate
> it in their profiles?
>
> Bret
>
> Sent from my iPhone
>
> On Aug 7, 2017, at 7:46 PM, Back, Greg <gback@mitre.org> wrote:
> As long as we aren’t mandating all consumers (and producers, though I’m
> more worried about consumers) to implement IEP, I’m fine with this. I’m
> also fine with using interoperability to promote the use of IEP, and
> (hopefully) letting market forces make IEP used universally.
>
> On 2017-08-07, 19:01 UTC, "cti-stix@lists.oasis-open.orgon behalf of
> Struse, Richard J." <cti-stix@lists.oasis-open.orgon behalf of
> rjs@mitre.org> wrote:
>
> Meant to say: “…that we are NOTrequiring IEP nor…”
>
>
> From: <cti-stix@lists.oasis-open.org> on behalf of Richard Struse <
> rjs@mitre.org>
> Date: Monday, August 7, 2017 at 2:59 PM
> To: Bret Jordan <Bret_Jordan@symantec.com>, "Wunder, John A." <
> jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <
> cti-stix@lists.oasis-open.org>, "cti-cybox@lists.oasis-open.org" <
> cti-cybox@lists.oasis-open.org>
> Subject: [cti-stix] Re: [cti-cybox] Re: [EXT] [cti-cybox] Agenda for
> August 8 Working Call
>
> Since we began this work there has been a clear recognition that TLP,
> while useful, isn’t sufficient to represent the sorts of policy
> expressions that are required to truly enable CTI sharing ecosystems. The
> FIRST community is exactly the sort of hands-on community best suited to
> develop such policy frameworks and it doesn’t seem like there are any
> competing policy frameworks under consideration. Given that, and the fact
> that we are requiring IEP nor are we “tying” STIX to IEP (or vice-versa),
> it seems worthwhile to do the work necessary to figure out how to best
> support those communities that wish to use IEP.
>
> Is there anyone actively opposed to the TC figuring out how we might
> support IEP?
>
> From: <cti-cybox@lists.oasis-open.org> on behalf of Bret Jordan <
> Bret_Jordan@symantec.com>
> Date: Monday, August 7, 2017 at 2:45 PM
> To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org"
> <cti-stix@lists.oasis-open.org>, "cti-cybox@lists.oasis-open.org" <
> cti-cybox@lists.oasis-open.org>
> Subject: [cti-cybox] Re: [EXT] [cti-cybox] Agenda for August 8 Working
> Call
>
> On the IEP front, we need to make sure the TC wants to do it before we
> figure out how we should do it. I would love to see some discussion over
> email first, before we tackle it on a working call that only has a subset
> of the membership. In other words, a working call is not a good place to
> decide "if" we should do something. It is a great place to figure out
> "how" we should do it, once the TC has sufficiently debated and decided to
> do it.
>
>
> Bret
>
>
>
> From: cti-cybox@lists.oasis-open.org<cti-cybox@lists.oasis-open.org> on
> behalf of Wunder, John A. <jwunder@mitre.org>
> Sent: Monday, August 7, 2017 9:11 AM
> To: cti-stix@lists.oasis-open.org; cti-cybox@lists.oasis-open.org
> Subject: [EXT] [cti-cybox] Agenda for August 8 Working Call
>
> All,
>
> We have three topics for the working call this week:
>
> 1. Continue work on DNS Request/Response
> 2. Continue work on Location, in particular discuss ISO 3166
> 3. Discuss inclusion of IEP (how we should do it)
>
> John
>
>
>
>
>
>

--
John-Mark

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