[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] 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
| From: | "Andras Iklody" <andras.iklody@circl.lu> |
| To: | cti-cybox@lists.oasis-open.org, Mark.Davidson@nc4.com |
| Date: | Tue, Aug 22, 2017 10:04 AM |
| Subject: | Re: [cti-cybox] 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 |
Hi Mark,
I agree with this not being feasible to expect every STIX/TAXII user to
adhere to the IEP restrictions. Depending on the community, even
something as straight forward as TLP won't have an actual implementation
consensus, with IEP's complexity and openness to interpretation this
sounds like an unrealistic expectation.
The way we have solved this issue with MISP, back when IEP was first
introduced at FIRST, was to use an IEP taxonomy
(https://github.com/MISP/misp-taxonomies/blob/master/iep/machinetag.json)
and let the community use it for filtering based on their own
interpretations and requirements.
Best regards,
Andras
On 22. aug. 2017 13:58, Mark Davidson wrote:
> As STIX/TAXII deployments scale, it will not be practical for large
> sharing hubs (e.g., ISACs/ISAOs) to effectively manage policy the way we
> are describing. For a sharing community with 1,000+ users, how can you
> possibly know the capabilities of each member’s STIX/TAXII software?
> You’d have to either survey your users and configure your software
> appropriately, or you’d have to make policy support part of the contract
> for ISAC/ISAO membership. Both solutions require deep technical
> knowledge of STIX at an ISAC/ISAO program level, which is just absurd.
> More likely is that the sharing hub will avoid IEP altogether because
> policy enforcement around IEP is so cumbersome and complex that it can’t
> be effectively managed.
>
>
>
> Alternatively, we could somehow solve this at the specification level.
> I’d like to see us find a way to manage this at the
> specification/implementation level, so that we don’t push the entire
> complexity of policy management all the way up to the end-users of STIX
> and TAXII. The solution I’ve proposed does not need to be the solution
> we adopt. My goal is to head off what I see as an ecosystem-wide problem
> that we are close to introducing.
>
>
>
> With that, I’ve made all my points related to the topic and consensus is
> certainly leaning on the “don’t do anything about this in STIX” side.
> Unless I see/hear a desire to solve the problem I’m articulating –
> policy management within STIX – I think it’s fair to say consensus is
> against policy management within STIX and that policy management is
> solved at the deployment/configuration level.
>
>
>
> Thank you.
>
> -Mark
>
>
>
> *From: *Terry MacDonald <terry.macdonald@cosive.com>
> *Date: *Monday, August 21, 2017 at 9:55 PM
> *To: *Bret Jordan <Bret_Jordan@symantec.com>
> *Cc: *Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Mark Davidson
> <Mark.Davidson@nc4.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>, Dave
> Cridland <dave.cridland@surevine.com>, "Back, Greg" <gback@mitre.org>,
> John-Mark Gurney <jmg@newcontext.com>
> *Subject: *Re: [cti-cybox] 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
>
>
>
> Hi All,
>
>
>
> TLP and IEP should be optional within STIX. We need to be able to allow
> producers to share the restrictions they have on the use of their data
> at the STIX level, and that is it.
>
>
>
> That said, intel sharing communities should be allowed to place their
> own restrictions on what is considered acceptable to be shared within
> their community. I see this sitting at the TAXII channel level (as that
> effectively would represent a community within TAXII). Those
> restrictions shouldn't just be about IEP or TLP, but should also be
> about things like what Cuber observable objects are supported, if the
> channel only accepts indicators, how long data should be retained within
> the recipients TIP, what terms of use are acceptable. We may even be
> able to have the TAXII servers tell the TAXII client if there are
> mandatory restrictions which will be forcefully applied to the data they
> post. Maybe the objects will be re-generated by the recipient TAXII
> server channel. Giving TAXII channels (communities) the optional ability
> to restrict the data being posted to the channel will help normalize the
> sort of data on that channel, and will be the first step towards
> automatic subscribing of TAXII clients to TAXII channels (e.g. thousands
> of AV endpoints from different vendors joining a single TAXII channel to
> get indicators to look for within a large org)
>
>
> Cheers
>
>
>
> *Terry MacDonald** *| Chief Product Officer
>
>
>
>
>
> M: +64 211 918 814 <tel:+64+211+918+814>
>
> E: terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>
>
> W: www.cosive.com <https://www.cosive.com/>
>
>
>
>
>
>
>
>
>
> On Tue, Aug 22, 2017 at 10:56 AM, Bret Jordan <Bret_Jordan@symantec.com
> <mailto:Bret_Jordan@symantec.com>> wrote:
>
> How do you know if you should even be allowed to send something that
> is marked with IEP?
>
>
>
> It seems like a compliant system should be able to say "I understand
> IEP marking". Now the following is also implied "what I do with
> them and whether I honor them is up to me, but I can at least
> process them".
>
>
>
> Bret
>
> Sent from my iPhone
>
>
> On Aug 21, 2017, at 6:34 AM, Jason Keirstead
> <Jason.Keirstead@ca.ibm.com <mailto:Jason.Keirstead@ca.ibm.com>> wrote:
>
> Mark - you are hitting the nail on the head here.
>
> /"//how does software that supports IEP understand whether
> “other” software supports IEP, and supports it correctly?//"/
>
> I do not believe this is possible, at all in a spec. It is up to
> trust communities to define this.
>
> To make an analogy - I can send whatever TCP QOS flags I want,
> but it is up to the network intermediaries to decide if it does
> anything at all with those and what those mean. There is no
> other way to do things in a standard.
>
> IE - we should be focused on codifying how to *communicate *IEP
> (and other markings) - not how to *implement *them.
>
> -
> Jason Keirstead
> STSM, Product Architect, Security Intelligence, IBM Security Systems
> www.ibm.com/security <http://www.ibm.com/security>
>
> Without data, all you are is just another person with an opinion
> - Unknown
>
>
>
>
> From: Mark Davidson <Mark.Davidson@nc4.com
> <mailto:Mark.Davidson@nc4.com>>
> To: Jason Keirstead <Jason.Keirstead@ca.ibm.com
> <mailto:Jason.Keirstead@ca.ibm.com>>, Dave Cridland
> <dave.cridland@surevine.com <mailto:dave.cridland@surevine.com>>
> Cc: Allan Thomson <athomson@lookingglasscyber.com
> <mailto:athomson@lookingglasscyber.com>>, Bret Jordan
> <Bret_Jordan@symantec.com <mailto:Bret_Jordan@symantec.com>>,
> "cti-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>"
> <cti-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>>,
> "cti-stix@lists.oasis-open.org
> <mailto:cti-stix@lists.oasis-open.org>"
> <cti-stix@lists.oasis-open.org
> <mailto:cti-stix@lists.oasis-open.org>>, "Back, Greg"
> <gback@mitre.org <mailto:gback@mitre.org>>, "John-Mark Gurney"
> <jmg@newcontext.com <mailto:jmg@newcontext.com>>, Terry
> MacDonald <terry.macdonald@cosive.com
> <mailto:terry.macdonald@cosive.com>>
> Date: 08/21/2017 09:24 AM
> Subject: [cti-cybox] 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-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>>
>
> ------------------------------------------------------------------------
>
>
>
>
> Maybe this is the core of the issue:
>
> At an interoperability level – how does software that supports
> IEP understand whether “other” software supports IEP, and
> supports it correctly?
>
> If I’m understanding the points being made by Jason and Dave,
> it’s that this is solved at the configuration/deployment level
> and not at the implementation level. I may be missing something,
> but I don’t know how to write software that understands what the
> receiver is actually going to do.
>
> The only way I see to guarantee what the receiver is going to do
> – at an ecosystem level – is to require it in the specification.
> IMHO, solving it at the configuration/deployment level is
> pushing the responsibility of understanding IEP to the end user.
> This lays a trap for the security team that is not an expert in
> STIX 2.0 or IEP.
>
> Assuming widespread deployment of STIX 2 w/ IEP, we will see a
> scenario where the recipient did not honor IEP markings and did
> something incorrect. By making this a clearly articulated
> requirement in the spec, the “fault” will lie at the
> non-conformant implementer, and not at the feet of the entire
> STIX/TAXII ecosystem.
>
> Thank you.
> -Mark
>
> *From: *Jason Keirstead <Jason.Keirstead@ca.ibm.com
> <mailto:Jason.Keirstead@ca.ibm.com>>*
> Date: *Friday, August 18, 2017 at 12:47 PM*
> To: *Dave Cridland <dave.cridland@surevine.com
> <mailto:dave.cridland@surevine.com>>*
> Cc: *Allan Thomson <athomson@lookingglasscyber.com
> <mailto:athomson@lookingglasscyber.com>>, Bret Jordan
> <Bret_Jordan@symantec.com <mailto:Bret_Jordan@symantec.com>>,
> "cti-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>"
> <cti-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>>,
> "cti-stix@lists.oasis-open.org
> <mailto:cti-stix@lists.oasis-open.org>"
> <cti-stix@lists.oasis-open.org
> <mailto:cti-stix@lists.oasis-open.org>>, "Back, Greg"
> <gback@mitre.org <mailto:gback@mitre.org>>, John-Mark Gurney
> <jmg@newcontext.com <mailto:jmg@newcontext.com>>, Mark Davidson
> <Mark.Davidson@nc4.com <mailto:Mark.Davidson@nc4.com>>, Terry
> MacDonald <terry.macdonald@cosive.com
> <mailto:terry.macdonald@cosive.com>>*
> 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
>
> Agree Dave; this is the point I was making. Whenever dealing
> with markings, the sender and reciever have to have some level
> of trust and understanding of what the reciever is actually
> going to do with the marking. This isn't something we can solve
> in STIX, unless IEP becomes much more complicated than it
> currently is.
>
> -
> Jason Keirstead
> STSM, Product Architect, Security Intelligence, IBM Security
> Systems_
> _www.ibm.com/security <http://www.ibm.com/security>
>
> Without data, all you are is just another person with an opinion
> - Unknown
>
>
>
>
> From: Dave Cridland <dave.cridland@surevine.com
> <mailto:dave.cridland@surevine.com>>
> To: Mark Davidson <Mark.Davidson@nc4.com
> <mailto:Mark.Davidson@nc4.com>>
> Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com
> <mailto:Jason.Keirstead@ca.ibm.com>>, John-Mark Gurney
> <jmg@newcontext.com <mailto:jmg@newcontext.com>>, Allan Thomson
> <athomson@lookingglasscyber.com
> <mailto:athomson@lookingglasscyber.com>>, Bret Jordan
> <Bret_Jordan@symantec.com <mailto:Bret_Jordan@symantec.com>>,
> "cti-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>"
> <cti-cybox@lists.oasis-open.org
> <mailto:cti-cybox@lists.oasis-open.org>>,
> "cti-stix@lists.oasis-open.org
> <mailto:cti-stix@lists.oasis-open.org>"
> <cti-stix@lists.oasis-open.org
> <mailto:cti-stix@lists.oasis-open.org>>, "Back, Greg"
> <gback@mitre.org <mailto:gback@mitre.org>>, Terry MacDonald
> <terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>>
> Date: 08/18/2017 12:19 PM
> 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
> <mailto:cti-stix@lists.oasis-open.org>>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
>
> On 18 August 2017 at 13:52, Mark Davidson <Mark.Davidson@nc4.com
> <mailto:Mark.Davidson@nc4.com>> wrote:
> 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.
>
>
> Well, certainly signalling that the software is capable of
> understanding IEP at all is useful; however it's merely changing
> the clearance of the receiver.
>
> For IEP, you obviously don't want to transmit the data
> unencrypted if the IEP indicates it must be encrypted, but a
> receiver might understand IEP but be incapable of storing the
> data encrypted at rest - you're then reliant on the receiver
> being honest when it receives data which stipulates that. Again,
> this becomes a trust (and therefore clearance) issue - do you
> trust the receiver to honour that bit in the IEP? Should you
> really be sending data to the receiver if it cannot store it
> properly in the first place?
>
> Dave.
> --
>
> *Dave Cridland*
>
> phone +448454681066 <tel:+44%20845%20468%201066>
> email dave.cridland@surevine.com
> <mailto:dave.cridland@surevine.com>
> skype dave.cridland.surevine
>
> *Participate | Collaborate | Innovate*
>
> Surevine Limited, registered in England and Wales with number
> 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
> If you think you have received this message in error, please
> notify us.
>
> 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.
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]