OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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>
Date: Friday, August 18, 2017 at 12:47 PM
To: Dave Cridland <dave.cridland@surevine.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>, John-Mark Gurney <jmg@newcontext.com>, Mark Davidson <Mark.Davidson@nc4.com>, Terry MacDonald <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

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




From:        Dave Cridland <dave.cridland@surevine.com>
To:        Mark Davidson <Mark.Davidson@nc4.com>
Cc:        Jason Keirstead <Jason.Keirstead@ca.ibm.com>, John-Mark Gurney <jmg@newcontext.com>, 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 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>







On 18 August 2017 at 13:52, Mark Davidson <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
email  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]