[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [EXT] [cti-stix] RE: [iep-sig] [cti-stix] RE: STIX 2.1: Adding IEP Framework to STIX 2.1
It was not a demand. It was a question. Sorry if it came across that way. I did also bring this up back when IEPv1 first came out.
The problem with using a dash for property names is, as you know, various programming languages have a really hard dealing with it. Some will require that you map them to different names in your code.
If IEP is embedded or externally referenced, the problem still remains. A STIX processor will need to know how to consume it and deal with it. If we do hand waving and say that it is just some arbitrary extension point, then I think you will get a mix of people that support it and ones that do not.
What happens if you send a STIX object to someone that can not understand or parse IEP data because it is not defined in STIX? I mean, if we can not write a conformance clause for it, there is no guarantee that people will be able to interoperate with it.
Personally I really dislike arbitrary extension points for who knows what content, especially when that content is critical to the use and understanding on the data. So if STIX is going to provide support for IEP, then I think it should provide support for it and callout exactly how it will be used. This will allow us to write conformance clauses for it and make sure interoperability can build tests for it.
Bret
Terry,
Are you going to be able to make changes to the IEP JSON representation to fix some of the parts? Namely, property names should NOT have a "dash" to separate words.
Bret
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.orgSent: Friday, May 5, 2017 3:24:01 PM> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
To: Millar, Thomas
Cc: Jason Keirstead; cti-stix@lists.oasis-open.org; Merike Kaeo; Carothers, Matt (CCI-Atlanta); iep-sig@first.org; Paul Patrick; Andrew Storms; Struse, Richard; Patrick Maroney
Subject: [EXT] [cti-stix] RE: [iep-sig] [cti-stix] RE: STIX 2.1: Adding IEP Framework to STIX 2.1Hi all,
An important point is that I am not advocating making IEP part off the STIX standard, but instead I am advocating making only the IEP Data Marking object part of STIX.
Users would then either directly embed a IEP JSON Policy (as defined in the FIRST IEP standard) into the STIX IEP data marking object, or better yet they would reference an external IEP JSON Policy file (e.g. https://example.com/mypolicy.iepj ) into the six IEP data marking object.
The point is that the STIX IEP data marking object is only a container for the IEP policy, and that the actual definition of what the IEP stands for is still handled FIRST IEP standard.
The idea for the FIRST IEP-SIG has always been to make a policy framework that can be used in many different information sharing idioms, not just STIX. As such we really only need STIX to support an IEP 'connector' that allows us to use IEP within STIX, and that's what the IEP Data Marking object is for.Hopefully that makes sense?
CheersTerry MacDonaldCosive
On 5/05/2017 07:04, "Millar, Thomas" <Thomas.Millar@hq.dhs.gov> wrote:
I know there’s an MOU between FIRST and OASIS now, but it does not seem advisable to include IEP (governed and developed by a FIRST SIG) inside of STIX (yada yada OASIS TC), except as a normative reference.
I’d decouple TLP too (TLP was a de facto standard when the TC began work, I believe, but is now also a FIRST standard governed by the TLP SIG).
From: iep-sig-request@lists.first.or
g [mailto:iep-sig-request@lists.first.org ] On Behalf Of "Struse, Richard" via iep-sig
Sent: 4 May, 2017 14:56
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Andrew Storms <storms@newcontext.com>
Cc: Patrick Maroney <pmaroney@wapacklabs.com>; Paul Patrick <Paul.Patrick@fireeye.com>; Merike Kaeo <merike@fsi.io>; Carothers, Matt (CCI-Atlanta) <Matt.Carothers@cox.com>; Terry MacDonald <terry.macdonald@cosive.com>; cti-stix@lists.oasis-open.org; iep-sig@first.org
Subject: RE: [iep-sig] [cti-stix] RE: STIX 2.1: Adding IEP Framework to STIX 2.1
I would encourage us to fully support marking content via IEP in STIX but not somehow require IEP to be specified in STIX.
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-o
pen.org ] On Behalf Of Jason Keirstead
Sent: Thursday, May 04, 2017 1:58 PM
To: Andrew Storms
Cc: Patrick Maroney; Paul Patrick; Struse, Richard; Merike Kaeo; Carothers, Matt (CCI-Atlanta); Terry MacDonald; cti-stix@lists.oasis-open.org; iep-sig@first.org
Subject: Re: [cti-stix] RE: [iep-sig] STIX 2.1: Adding IEP Framework to STIX 2.1
I am pondering... Should IEP be part of STIX itself, or should it be perhaps done in a simpler and separate work product?
If it was defined in its own simple work product it could be used with STIX 2.0 content *AND* STIX 2.1 content.
If not separate.. then how to decide which marking standards in the future should be included right in the spec via revision, and which left to their own devices? Should TLP have maybe not been inside STIX itself, but a separate work product? I have been unable to trace back why we made this decision to bake it right into the standard and set this precedent. Is there a large advantage by tightly coupling marking definitions to standard revisions? I don't see one on the surface...
-
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: Andrew Storms <storms@newcontext.com>
To: Patrick Maroney <pmaroney@wapacklabs.com>
Cc: Paul Patrick <Paul.Patrick@fireeye.com>, "Struse, Richard" <Richard.Struse@hq.dhs.gov>, Merike Kaeo <merike@fsi.io>, "Carothers, Matt (CCI-Atlanta)" <Matt.Carothers@cox.com>, Terry MacDonald <terry.macdonald@cosive.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >, "iep-sig@first.org" <iep-sig@first.org>
Date: 05/02/2017 07:56 PM
Subject: Re: [cti-stix] RE: [iep-sig] STIX 2.1: Adding IEP Framework to STIX 2.1
Sent by: <cti-stix@lists.oasis-open.org >
Also in support of IEP
On Tue, May 2, 2017 at 3:51 PM, Patrick Maroney <pmaroney@wapacklabs.com> wrote:
Absolutely - we should adopt IEP.
Patrick Maroney
Principal Engineer - Data Science & Analytics
(609)841-5104
pmaroney@wapacklabs.com
On May 2, 2017, at 6:06 PM, Paul Patrick <Paul.Patrick@FireEye.com> wrote:Strongly encouraged
From: <cti-stix@lists.oasis-open.org
> on behalf of "Struse, Richard" < Richard.Struse@HQ.DHS.GOV>
Date: Tuesday, May 2, 2017 at 2:56 PM
To: Merike Kaeo <merike@fsi.io>, "Carothers, Matt (CCI-Atlanta)" <Matt.Carothers@cox.com>
Cc: Terry MacDonald <terry.macdonald@cosive.com>, "cti-stix@lists.oasis-open.org" < cti-stix@lists.oasis-open.org>, " iep-sig@first.org" <iep-sig@first.org>
Subject: [cti-stix] RE: [iep-sig] STIX 2.1: Adding IEP Framework to STIX 2.1
I concur as well – the addition of IEP could greatly enhance our collective ability to specify, and comply with, policies for handling machine-readable CTI!
From: iep-sig-request@lists.first.or
g [mailto:iep-sig-request@lists.first.org ] On Behalf Of Merike Kaeo via iep-sig
Sent: Tuesday, May 02, 2017 2:15 PM
To: Carothers, Matt (CCI-Atlanta)
Cc: Terry MacDonald; cti-stix@lists.oasis-open.org; iep-sig@first.org
Subject: Re: [iep-sig] STIX 2.1: Adding IEP Framework to STIX 2.1
Thanks Matt.
Any others who want to chime in?
- merike
On May 2, 2017, at 6:29 AM, Carothers, Matt (CCI-Atlanta) via iep-sig (via iep-sig Mailing List) <iep-sig@lists.first.org> wrote:
I’m a big fan of the IEP, and I’d like to see it included.
- Matt
From: iep-sig-request@lists.fi
rst.org [mailto:iep-sig-request@lists.first.org ] On Behalf Of Terry MacDonald via iep-sig
Sent: Monday, May 1, 2017 9:01 PM
To: cti-stix@lists.oasis-open.org ; iep-sig@first.org
Subject: Re: [iep-sig] STIX 2.1: Adding IEP Framework to STIX 2.1
Hi All,
Just checking with everyone to see their thoughts on the suggestion to add IEP v2 to STIX 2.1. Does anyone at all have any objections to this being an additional method for producers to describe in greater detail what consumers can do with the data? People could still use TLP if they wished (although IEP includes TLP and a lot more besides).
Cheers
Terry MacDonald | Chief Product Officer
<image001.png>
On Sun, Apr 30, 2017 at 9:22 AM, Terry MacDonald <terry.macdonald@cosive.com> wrote:
Hi All,
I've got an update on the FIRST Information Exchange Policy (IEP) Framework work currently being done within the FIRST IEP-SIG.
For those of you who have never heard of IEP, it is a JSON based way for threat intel producers to inform recipients of how they are allowed to use the data threat intel they receive. It extends the Traffic Light Protocol (TLP) to fill a lot of the gaps, removing ambiguity when sharing information..
IEP version 2.0 differs from IEP version 1.0 in that it now allows threat intel to reference remote IEP policies. This allows communities to create a network accessible IEPJ file, and all threat intel to just reference that url. We plan on drafting some standard IEP policies to help kick start the process off.
You can view more about the draft IEP Framework documents in the attached documentation:
· FIRST_IEP_Framework_2_20170418
.pdf describes the IEP Framework at a high level · FIRST_IEP_2_JSON_20170104.pdf describes the JSON implementation of the IEP Framework.
We know that IEP would provide a lot of value to STIX 2.1, as it would clear up a lot of the confusion that recipients have regarding how they can use they data they receive. For this reason, we have created a draft STIX Data Marking object specifically for IEP, and we submit this to the community for inclusion in STIX 2.1. STIX2.1Proposal-InformationEx
changePolicyMarkingObjectType. pdf describes our proposal in greater depth.
Cheers
Terry MacDonald | Chief Product Officer
<image001.png>
______________________________
_____________________________
This is a FIRST restricted and confidential mailing list.
Do not Forward, Cc, Bcc, copy or summarize this email
outside of the FIRST community without the express
permission of the content owner(s).
FIRST.Org Lists
___________________________________________________________
This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
--
Phone: 707.477.4335
@st0rmz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]