> " As
a sender of information, I know which user accounts have which permissions,
and can control access accordingly. I " I am not sure what you mean by this.
When someone creates a piece of intelligence in a STIX document and submits
it to some sharing system, they are not necessarily going to know what
user accounts are on that system. In fact I would argue they hardly ever
will. If I create a piece of intelligence and send it to an ISAO TIP, it
is highly unlikely I know what specific users are authorized on that TIP.
> 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. What rules are we talking about here?
I don't see how we can get into this at all. I will copy/paste a comment i made on
Slack on this topic: Supporting any marking is a trust
group and product decision. Its not needed for product interoperability. This is the biggest challenge I have
with data markings, have been talking about it on and off since I first
started getting involved in STIX in 2015 or whatever. [A TLP example is]
you mark something with a TLP Amber, super… can’t share outside my org.
But what is “my org” and how is that enforced? That is COMPLETELY up
to the trust group to define, and how they decide to enforce that, is also
up to them. [Consider that an ISAO may have a TAXII system without any
user accounts at all, and trust is simply having access to the system as
a whole]. So how could we possibly tackle in
[STIX or] Interop and say “your product must do XYZ”, when it is up to
the trust group? We can’t. - 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:
Mark Davidson <
Mark.Davidson@nc4.com> To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com>,
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> Date:
08/18/2017 09:52 AM Subject:
Re: [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 Sent by:
<
cti-stix@lists.oasis-open.org> 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 Disclaimer: This message is intended only for the use of
the individual or entity to which it is addressed and may contain information
which is privileged, confidential, proprietary, or exempt from disclosure
under applicable law. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, you are
strictly prohibited from disclosing, distributing, copying, or in any way
using this message. If you have received this communication in error, please
notify the sender and destroy and delete any copies you may have received.