[STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Barnum, Sean D.

Everyone,

 

Back in December we sent out a refined proposal for the Report Object including two sub-proposals on fine details in an attempt to reach final consensus on what will go into the STIX 1.2 release.

 

The three relevant proposals are:

 

     Implement Report Object – note that this is not about whether to implement the report object but how to implement the report object

o   Reports Cannot Embed Content – this issue was large enough that we split it into a separate topic

o   Packages Cannot Contain Other Packages – this issue was large enough that we split it into a separate topic

 

 

We received a limited amount of feedback on the list in regards to the two sub-proposals but all of it voiced opinions that for the STIX 1.2 release both sub-proposals should be rejected. In other words, +STIX 1.2 should allow content to be embedded within the new Report Object and that Packages (while stripped of their contextual fields that will be moved to the new Report Object) should be allowed to contain other Packages.

The same opinion on the two sub-proposals was also strongly expressed by various community stakeholders off the list and directly to the STIX team via [hidden email]. These players expressed clear opposition to the broader Report Object proposal both on the list and off. However, they expressed a willingness to compromise and accept the broader Report Object proposal given the apparent consensus rejection of the sub-proposals.

 

These sub-proposals and their apparent consensus rejection was a topic of conversation on last week’s STIX community call.

The first sub-proposal discussed was regarding the embedding of content within Report Objects. A couple of community members on the call expressed that while they would prefer that embedding not be allowed, they were willing to compromise and not contest the point in order to move the community forward.

The second sub-proposal discussed was regarding the ability of Packages to contain other Packages. On this point, several members expressed concern on the call that had not been raised as feedback on the list. 

In a nutshell, a belief was expressed that nesting packages may bring significantly more complexity while others assert that the capability already exists in STIX (it is not adding something new) and given the newly limited context for Packages (based on the new Report Object) the difference in complexity is actually rather minimal. Based on the comments, it appears that we have not yet actually reached consensus on this point and that more discussion may need to occur on the list. If you have clear opinions one way or the other (this includes those who spoke up on the call), please express them on the list so that we can nail this down and move forward on our activity for the 1.2 release.

 

Thanks,

Sean Barnum

STIX Project Team

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

pmaroney
[+1] For support for content embedding now and going forward.
[+1] For ability of Packages to contain other Packages now and going forward.

  • We have Use Cases that require both capabilities. 
  • Understand the general concerns for the potential complexities of Nested Packages. 
  • Suggest investigation of application of STIX Profiles (and Extensions to same if required) to establish a basic set of  conventions that address common Community Use Cases.
  • Suggest we identify and enumerate the specific concerns of those advocating removal and mitigate same by providing “Best Practices”, Idioms, code snippets,  and examples of “Good” and “Bad” implementations that demonstrate and address those concerns.
Patrick Maroney
Office: (856)983-0001
Cell: (609)841-5104
[hidden email]


From: <Barnum>, Sean Barnum <[hidden email]>
Reply-To: Sean Barnum <[hidden email]>
Date: Wednesday, February 25, 2015 at 12:55 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Everyone,

 

Back in December we sent out a refined proposal for the Report Object including two sub-proposals on fine details in an attempt to reach final consensus on what will go into the STIX 1.2 release.

 

The three relevant proposals are:

 

     Implement Report Object – note that this is not about whether to implement the report object but how to implement the report object

o   Reports Cannot Embed Content – this issue was large enough that we split it into a separate topic

o   Packages Cannot Contain Other Packages – this issue was large enough that we split it into a separate topic

 

 

We received a limited amount of feedback on the list in regards to the two sub-proposals but all of it voiced opinions that for the STIX 1.2 release both sub-proposals should be rejected. In other words, +STIX 1.2 should allow content to be embedded within the new Report Object and that Packages (while stripped of their contextual fields that will be moved to the new Report Object) should be allowed to contain other Packages.

The same opinion on the two sub-proposals was also strongly expressed by various community stakeholders off the list and directly to the STIX team via [hidden email]. These players expressed clear opposition to the broader Report Object proposal both on the list and off. However, they expressed a willingness to compromise and accept the broader Report Object proposal given the apparent consensus rejection of the sub-proposals.

 

These sub-proposals and their apparent consensus rejection was a topic of conversation on last week’s STIX community call.

The first sub-proposal discussed was regarding the embedding of content within Report Objects. A couple of community members on the call expressed that while they would prefer that embedding not be allowed, they were willing to compromise and not contest the point in order to move the community forward.

The second sub-proposal discussed was regarding the ability of Packages to contain other Packages. On this point, several members expressed concern on the call that had not been raised as feedback on the list. 

In a nutshell, a belief was expressed that nesting packages may bring significantly more complexity while others assert that the capability already exists in STIX (it is not adding something new) and given the newly limited context for Packages (based on the new Report Object) the difference in complexity is actually rather minimal. Based on the comments, it appears that we have not yet actually reached consensus on this point and that more discussion may need to occur on the list. If you have clear opinions one way or the other (this includes those who spoke up on the call), please express them on the list so that we can nail this down and move forward on our activity for the 1.2 release.

 

Thanks,

Sean Barnum

STIX Project Team

 

 

 

 

JA
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

JA
In reply to this post by Barnum, Sean D.
Hi,

I would suggest kind of a SWOT analysis approach based on feedbacks,
use cases, changes/options, concerns.

2015-02-25 18:55 GMT+01:00 Barnum, Sean D. <[hidden email]>:

> Everyone,
>
>
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach final
> consensus on what will go into the STIX 1.2 release.
>
>
>
> The three relevant proposals are:
>
>
>
>      Implement Report Object – note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed Content – this issue was large enough that we split
> it into a separate topic
>
> o   Packages Cannot Contain Other Packages – this issue was large enough
> that we split it into a separate topic
>
>
>
>
>
> We received a limited amount of feedback on the list in regards to the two
> sub-proposals but all of it voiced opinions that for the STIX 1.2 release
> both sub-proposals should be rejected. In other words, +STIX 1.2 should
> allow content to be embedded within the new Report Object and that Packages
> (while stripped of their contextual fields that will be moved to the new
> Report Object) should be allowed to contain other Packages.
>
> The same opinion on the two sub-proposals was also strongly expressed by
> various community stakeholders off the list and directly to the STIX team
> via [hidden email]. These players expressed clear opposition to the broader
> Report Object proposal both on the list and off. However, they expressed a
> willingness to compromise and accept the broader Report Object proposal
> given the apparent consensus rejection of the sub-proposals.
>
>
>
> These sub-proposals and their apparent consensus rejection was a topic of
> conversation on last week’s STIX community call.
>
> The first sub-proposal discussed was regarding the embedding of content
> within Report Objects. A couple of community members on the call expressed
> that while they would prefer that embedding not be allowed, they were
> willing to compromise and not contest the point in order to move the
> community forward.
>
> The second sub-proposal discussed was regarding the ability of Packages to
> contain other Packages. On this point, several members expressed concern on
> the call that had not been raised as feedback on the list.
>
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the newly
> limited context for Packages (based on the new Report Object) the difference
> in complexity is actually rather minimal. Based on the comments, it appears
> that we have not yet actually reached consensus on this point and that more
> discussion may need to occur on the list. If you have clear opinions one way
> or the other (this includes those who spoke up on the call), please express
> them on the list so that we can nail this down and move forward on our
> activity for the 1.2 release.
>
>
>
> Thanks,
>
> Sean Barnum
>
> STIX Project Team
>
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Aharon Chernin
In reply to this post by Barnum, Sean D.
Optionality increases complexity and increases chance of error. Imagine receiving a document with nested STIX packages, with report objects that contain inline data, that also have report objects that reference data somewhere else within other nested packages.

Due to this flexibility, one of the issues with stix package is that it's easy to use incorrectly. By elimating nested packages and inline stix content within the report object we can reduce some of this complexity. I am all for removing complexity.

+1 reports cannot embed
+1 packages cannot nest

Like I said on the community call, I can go either way on this.

Aharon

Sent using OWA for iPhone
________________________________
From: Barnum, Sean D. <[hidden email]>
Sent: Wednesday, February 25, 2015 12:55:14 PM
To: [hidden email]
Subject: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Everyone,

Back in December we sent out a refined proposal for the Report Object including two sub-proposals on fine details in an attempt to reach final consensus on what will go into the STIX 1.2 release.

The three relevant proposals are:


     Implement Report Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-Implement-Report-Object> – note that this is not about whether to implement the report object but how to implement the report object

o   Reports Cannot Embed Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content> – this issue was large enough that we split it into a separate topic

o   Packages Cannot Contain Other Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-Packages-Cannot-Contain-Other-Packages> – this issue was large enough that we split it into a separate topic


We received a limited amount of feedback on the list in regards to the two sub-proposals but all of it voiced opinions that for the STIX 1.2 release both sub-proposals should be rejected. In other words, +STIX 1.2 should allow content to be embedded within the new Report Object and that Packages (while stripped of their contextual fields that will be moved to the new Report Object) should be allowed to contain other Packages.
The same opinion on the two sub-proposals was also strongly expressed by various community stakeholders off the list and directly to the STIX team via [hidden email]<mailto:[hidden email]>. These players expressed clear opposition to the broader Report Object proposal both on the list and off. However, they expressed a willingness to compromise and accept the broader Report Object proposal given the apparent consensus rejection of the sub-proposals.

These sub-proposals and their apparent consensus rejection was a topic of conversation on last week’s STIX community call.
The first sub-proposal discussed was regarding the embedding of content within Report Objects. A couple of community members on the call expressed that while they would prefer that embedding not be allowed, they were willing to compromise and not contest the point in order to move the community forward.
The second sub-proposal discussed was regarding the ability of Packages to contain other Packages. On this point, several members expressed concern on the call that had not been raised as feedback on the list.
In a nutshell, a belief was expressed that nesting packages may bring significantly more complexity while others assert that the capability already exists in STIX (it is not adding something new) and given the newly limited context for Packages (based on the new Report Object) the difference in complexity is actually rather minimal. Based on the comments, it appears that we have not yet actually reached consensus on this point and that more discussion may need to occur on the list. If you have clear opinions one way or the other (this includes those who spoke up on the call), please express them on the list so that we can nail this down and move forward on our activity for the 1.2 release.

Thanks,
Sean Barnum
STIX Project Team




Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Foley, Alexander - GIS
In reply to this post by Barnum, Sean D.

I’m sorry I missed last week’s meeting, I fell victim to the reschedule.  For those of you who prefer summarized arguments, I recommend Sean’s three links below, they have an enviable brevity.

 

[+1] to Reports Cannot Embed Content; references back to other objects in the same package seems like the easiest overall implementation of the report object and nicely divides unstructured content from structured content (in general).  Also, because it reminds me of inline CSS which is basically non-essential and leads to bad habits.

 

[0] to Packages Cannot Contain Other Packages;  I can see the pluses and minuses of both sides but fail at being able to imagine what will be the best practice.  I do think if we disallow embedded content it increases the likelihood that nested packages create interesting parsing challenges, which may be a reason to disallow the practice until we know it’s needed, but I may not be imaging the right situations yet.

 

Thanks,

 

Alex

 

From: Barnum, Sean D. [mailto:[hidden email]]
Sent: Wednesday, February 25, 2015 12:55 PM
To: [hidden email]
Subject: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

 

Everyone,

 

Back in December we sent out a refined proposal for the Report Object including two sub-proposals on fine details in an attempt to reach final consensus on what will go into the STIX 1.2 release.

 

The three relevant proposals are:

 

     Implement Report Object – note that this is not about whether to implement the report object but how to implement the report object

o   Reports Cannot Embed Content – this issue was large enough that we split it into a separate topic

o   Packages Cannot Contain Other Packages – this issue was large enough that we split it into a separate topic

 

 

We received a limited amount of feedback on the list in regards to the two sub-proposals but all of it voiced opinions that for the STIX 1.2 release both sub-proposals should be rejected. In other words, +STIX 1.2 should allow content to be embedded within the new Report Object and that Packages (while stripped of their contextual fields that will be moved to the new Report Object) should be allowed to contain other Packages.

The same opinion on the two sub-proposals was also strongly expressed by various community stakeholders off the list and directly to the STIX team via [hidden email]. These players expressed clear opposition to the broader Report Object proposal both on the list and off. However, they expressed a willingness to compromise and accept the broader Report Object proposal given the apparent consensus rejection of the sub-proposals.

 

These sub-proposals and their apparent consensus rejection was a topic of conversation on last week’s STIX community call.

The first sub-proposal discussed was regarding the embedding of content within Report Objects. A couple of community members on the call expressed that while they would prefer that embedding not be allowed, they were willing to compromise and not contest the point in order to move the community forward.

The second sub-proposal discussed was regarding the ability of Packages to contain other Packages. On this point, several members expressed concern on the call that had not been raised as feedback on the list. 

In a nutshell, a belief was expressed that nesting packages may bring significantly more complexity while others assert that the capability already exists in STIX (it is not adding something new) and given the newly limited context for Packages (based on the new Report Object) the difference in complexity is actually rather minimal. Based on the comments, it appears that we have not yet actually reached consensus on this point and that more discussion may need to occur on the list. If you have clear opinions one way or the other (this includes those who spoke up on the call), please express them on the list so that we can nail this down and move forward on our activity for the 1.2 release.

 

Thanks,

Sean Barnum

STIX Project Team

 

 

 

 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Joep Gommers
In reply to this post by Barnum, Sean D.
Since packages can already embed packages, we don't care as we need to be able to handle that as part of 1.1.1 compatibility.

Since embedding has to already be part of handling any other object, I can't see why we shouldn't allow it. Personally seems cleaner not too. @wouter, engineer working on this at Intelworks: your call?

Strongly +1 on report object itself, plus many future additions. Propose workgroup to figure out 2.0 spec. 

Sent from my iPhone

On 25 Feb 2015, at 18:56, Barnum, Sean D. <[hidden email]> wrote:

Everyone,

 

Back in December we sent out a refined proposal for the Report Object including two sub-proposals on fine details in an attempt to reach final consensus on what will go into the STIX 1.2 release.

 

The three relevant proposals are:

 

     Implement Report Object – note that this is not about whether to implement the report object but how to implement the report object

o   Reports Cannot Embed Content – this issue was large enough that we split it into a separate topic

o   Packages Cannot Contain Other Packages – this issue was large enough that we split it into a separate topic

 

 

We received a limited amount of feedback on the list in regards to the two sub-proposals but all of it voiced opinions that for the STIX 1.2 release both sub-proposals should be rejected. In other words, +STIX 1.2 should allow content to be embedded within the new Report Object and that Packages (while stripped of their contextual fields that will be moved to the new Report Object) should be allowed to contain other Packages.

The same opinion on the two sub-proposals was also strongly expressed by various community stakeholders off the list and directly to the STIX team via [hidden email]. These players expressed clear opposition to the broader Report Object proposal both on the list and off. However, they expressed a willingness to compromise and accept the broader Report Object proposal given the apparent consensus rejection of the sub-proposals.

 

These sub-proposals and their apparent consensus rejection was a topic of conversation on last week’s STIX community call.

The first sub-proposal discussed was regarding the embedding of content within Report Objects. A couple of community members on the call expressed that while they would prefer that embedding not be allowed, they were willing to compromise and not contest the point in order to move the community forward.

The second sub-proposal discussed was regarding the ability of Packages to contain other Packages. On this point, several members expressed concern on the call that had not been raised as feedback on the list. 

In a nutshell, a belief was expressed that nesting packages may bring significantly more complexity while others assert that the capability already exists in STIX (it is not adding something new) and given the newly limited context for Packages (based on the new Report Object) the difference in complexity is actually rather minimal. Based on the comments, it appears that we have not yet actually reached consensus on this point and that more discussion may need to occur on the list. If you have clear opinions one way or the other (this includes those who spoke up on the call), please express them on the list so that we can nail this down and move forward on our activity for the 1.2 release.

 

Thanks,

Sean Barnum

STIX Project Team

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Grobauer, Bernd
In reply to this post by Aharon Chernin
Hi,

I am completely with Aharon on this one: we have enough
complexity as it is ...

+1 reports cannot embed
+1 packages cannot nest

Kind regards,

Bernd


> -----Original Message-----
> From: Aharon Chernin [mailto:[hidden email]]
> Sent: Mittwoch, 25. Februar 2015 19:47
> To: [hidden email]
> Subject: Re: [STIX] Reaching final consensus on the Report Object
> proposal for the STIX 1.2 release
>
> Optionality increases complexity and increases chance of error. Imagine
> receiving a document with nested STIX packages, with report objects
> that contain inline data, that also have report objects that reference
> data somewhere else within other nested packages.
>
> Due to this flexibility, one of the issues with stix package is that
> it's easy to use incorrectly. By elimating nested packages and inline
> stix content within the report object we can reduce some of this
> complexity. I am all for removing complexity.
>
> +1 reports cannot embed
> +1 packages cannot nest
>
> Like I said on the community call, I can go either way on this.
>
> Aharon
>
> Sent using OWA for iPhone
> ________________________________
> From: Barnum, Sean D. <[hidden email]>
> Sent: Wednesday, February 25, 2015 12:55:14 PM
> To: [hidden email]
> Subject: [STIX] Reaching final consensus on the Report Object proposal
> for the STIX 1.2 release
>
> Everyone,
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach
> final consensus on what will go into the STIX 1.2 release.
>
> The three relevant proposals are:
>
>
>      Implement Report
> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
> Implement-Report-Object> - note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed
> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
> Reports-Cannot-Embed-Content> - this issue was large enough that we
> split it into a separate topic
>
> o   Packages Cannot Contain Other
> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
> that we split it into a separate topic
>
>
> We received a limited amount of feedback on the list in regards to the
> two sub-proposals but all of it voiced opinions that for the STIX 1.2
> release both sub-proposals should be rejected. In other words, +STIX
> 1.2 should allow content to be embedded within the new Report Object
> and that Packages (while stripped of their contextual fields that will
> be moved to the new Report Object) should be allowed to contain other
> Packages.
> The same opinion on the two sub-proposals was also strongly expressed
> by various community stakeholders off the list and directly to the STIX
> team via [hidden email]<mailto:[hidden email]>. These players expressed
> clear opposition to the broader Report Object proposal both on the list
> and off. However, they expressed a willingness to compromise and accept
> the broader Report Object proposal given the apparent consensus
> rejection of the sub-proposals.
>
> These sub-proposals and their apparent consensus rejection was a topic
> of conversation on last week's STIX community call.
> The first sub-proposal discussed was regarding the embedding of content
> within Report Objects. A couple of community members on the call
> expressed that while they would prefer that embedding not be allowed,
> they were willing to compromise and not contest the point in order to
> move the community forward.
> The second sub-proposal discussed was regarding the ability of Packages
> to contain other Packages. On this point, several members expressed
> concern on the call that had not been raised as feedback on the list.
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the
> newly limited context for Packages (based on the new Report Object) the
> difference in complexity is actually rather minimal. Based on the
> comments, it appears that we have not yet actually reached consensus on
> this point and that more discussion may need to occur on the list. If
> you have clear opinions one way or the other (this includes those who
> spoke up on the call), please express them on the list so that we can
> nail this down and move forward on our activity for the 1.2 release.
>
> Thanks,
> Sean Barnum
> STIX Project Team
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

pmaroney
I know we're looking for up or down at this point, but wanted to ask a clarifying question from those opposed to nesting (in particular when those expressing same are highly respected and contribute a lot to our "thing").

Caveats:

1) Hope the following is reasonably clear.

2) There are many Worldviews and each is valid.  "Our" primary worldview is that any externally exposed TAXII Gateways should only provide for the reliable transport and distribution of ephemeral STIX packages.  From a security architecture perspective, all externally facing services, the assets supporting them, and any data stored on same must be considered at high risk of compromise over time (exposure and integrity).  Therefore, all Cyber-Intelligence data should only be stored on any externally exposed TAXII Gateways for as long as is required to assemble and ensure delivery to all recipients.  Presuming best practices of sending event logging to central log management facility are follwed, a Stateless Model is established that empowers the use of automated provisioning systems to periodically revert high risk systems back to a known good state.

Use Case:

I have a real-life challenge right now with integration of a third party tool.  This tool uses a graph-like internal data model.  When extracting from any given node one specifies the maximum depth of relations to traverse and maximum number of objects.  It decomposes the graph of all related objects into multiple STIX packages of individual objects with external references to related objects.

So I end up with a folder with 100's of inter-related STIX packages that I need to wrap in a single STIX container that describes/conveys the global attributes and broader context, in aggregate, of the package and it's individual elements.

The ultimate objective is to extract the multi-dimensional model to the depth specified, transform into two dimensional STIX XML, transport it via TAXII, transform, and then join the vertices and edges with the target's unique data instantiation of the same multi-dimensional model.

There are future extensions to this use case where individual classes of objects are routed to methods specific to that class, but where the global attributes and broader context need to be passed, maintained, and returned with the method results.

For example Transitive Tokenization processes that maintain form ([hidden email] ==>  [hidden email]), convey statistically viable meaning for Analytics, while also ensuring redaction of attributional data will require differing methods and workflows (i.e., external sharing of Tokenized Credit Card, Social Security numbers, etc. may all get routed to different organizations and review/approval processes).

We would want to immediately share actionable intelligence for classes of data that do not require vetting.  Then as each class completes it's unique workflow, it can be passed on with referential integrity to the original global package and the individual sub-packages.

...So taking the simplistic approach of zipping up the 100's of individual STIX files and passing as a binary blob to the other side is not an option.

There are many other scenarios, so hopefully this narrow example suffices to convey the concepts.

I have not attempted to build an actual reference implementation, but I can envision how one would approach this with nested STIX packages.  How would one approach this without nesting?

Patrick Maroney
Office: (856)983-0001
Cell: (609)841-5104
[hidden email]
________________________________________
From: Grobauer, Bernd <[hidden email]>
Sent: Thursday, February 26, 2015 8:02:19 AM
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Hi,

I am completely with Aharon on this one: we have enough
complexity as it is ...

+1 reports cannot embed
+1 packages cannot nest

Kind regards,

Bernd


> -----Original Message-----
> From: Aharon Chernin [mailto:[hidden email]]
> Sent: Mittwoch, 25. Februar 2015 19:47
> To: [hidden email]
> Subject: Re: [STIX] Reaching final consensus on the Report Object
> proposal for the STIX 1.2 release
>
> Optionality increases complexity and increases chance of error. Imagine
> receiving a document with nested STIX packages, with report objects
> that contain inline data, that also have report objects that reference
> data somewhere else within other nested packages.
>
> Due to this flexibility, one of the issues with stix package is that
> it's easy to use incorrectly. By elimating nested packages and inline
> stix content within the report object we can reduce some of this
> complexity. I am all for removing complexity.
>
> +1 reports cannot embed
> +1 packages cannot nest
>
> Like I said on the community call, I can go either way on this.
>
> Aharon
>
> Sent using OWA for iPhone
> ________________________________
> From: Barnum, Sean D. <[hidden email]>
> Sent: Wednesday, February 25, 2015 12:55:14 PM
> To: [hidden email]
> Subject: [STIX] Reaching final consensus on the Report Object proposal
> for the STIX 1.2 release
>
> Everyone,
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach
> final consensus on what will go into the STIX 1.2 release.
>
> The three relevant proposals are:
>
>
>      Implement Report
> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
> Implement-Report-Object> - note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed
> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
> Reports-Cannot-Embed-Content> - this issue was large enough that we
> split it into a separate topic
>
> o   Packages Cannot Contain Other
> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
> that we split it into a separate topic
>
>
> We received a limited amount of feedback on the list in regards to the
> two sub-proposals but all of it voiced opinions that for the STIX 1.2
> release both sub-proposals should be rejected. In other words, +STIX
> 1.2 should allow content to be embedded within the new Report Object
> and that Packages (while stripped of their contextual fields that will
> be moved to the new Report Object) should be allowed to contain other
> Packages.
> The same opinion on the two sub-proposals was also strongly expressed
> by various community stakeholders off the list and directly to the STIX
> team via [hidden email]<mailto:[hidden email]>. These players expressed
> clear opposition to the broader Report Object proposal both on the list
> and off. However, they expressed a willingness to compromise and accept
> the broader Report Object proposal given the apparent consensus
> rejection of the sub-proposals.
>
> These sub-proposals and their apparent consensus rejection was a topic
> of conversation on last week's STIX community call.
> The first sub-proposal discussed was regarding the embedding of content
> within Report Objects. A couple of community members on the call
> expressed that while they would prefer that embedding not be allowed,
> they were willing to compromise and not contest the point in order to
> move the community forward.
> The second sub-proposal discussed was regarding the ability of Packages
> to contain other Packages. On this point, several members expressed
> concern on the call that had not been raised as feedback on the list.
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the
> newly limited context for Packages (based on the new Report Object) the
> difference in complexity is actually rather minimal. Based on the
> comments, it appears that we have not yet actually reached consensus on
> this point and that more discussion may need to occur on the list. If
> you have clear opinions one way or the other (this includes those who
> spoke up on the call), please express them on the list so that we can
> nail this down and move forward on our activity for the 1.2 release.
>
> Thanks,
> Sean Barnum
> STIX Project Team
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Joep Gommers
Disclaimer: i¹m not apposed to nesting, yet:

Since STIX_Packages are simply non-substantive wrappers of actual STIX
entities, how would sending one STIX_Package containing others be
different then sending a 100 STIX_Packages - other then overhead?

We do a similar thing, but the de-composing and re-composing of entities
and their relationships, would (in our case, but like to understand yours)
not require anything the STIX_Package (as a non-substantive wrapper) has
to offer.

Best regards,
Joep




On 2/26/15, 6:30 PM, "Patrick Maroney" <[hidden email]> wrote:

>I know we're looking for up or down at this point, but wanted to ask a
>clarifying question from those opposed to nesting (in particular when
>those expressing same are highly respected and contribute a lot to our
>"thing").
>
>Caveats:
>
>1) Hope the following is reasonably clear.
>
>2) There are many Worldviews and each is valid.  "Our" primary worldview
>is that any externally exposed TAXII Gateways should only provide for the
>reliable transport and distribution of ephemeral STIX packages.  From a
>security architecture perspective, all externally facing services, the
>assets supporting them, and any data stored on same must be considered at
>high risk of compromise over time (exposure and integrity).  Therefore,
>all Cyber-Intelligence data should only be stored on any externally
>exposed TAXII Gateways for as long as is required to assemble and ensure
>delivery to all recipients.  Presuming best practices of sending event
>logging to central log management facility are follwed, a Stateless Model
>is established that empowers the use of automated provisioning systems to
>periodically revert high risk systems back to a known good state.
>
>Use Case:
>
>I have a real-life challenge right now with integration of a third party
>tool.  This tool uses a graph-like internal data model.  When extracting
>from any given node one specifies the maximum depth of relations to
>traverse and maximum number of objects.  It decomposes the graph of all
>related objects into multiple STIX packages of individual objects with
>external references to related objects.
>
>So I end up with a folder with 100's of inter-related STIX packages that
>I need to wrap in a single STIX container that describes/conveys the
>global attributes and broader context, in aggregate, of the package and
>it's individual elements.
>
>The ultimate objective is to extract the multi-dimensional model to the
>depth specified, transform into two dimensional STIX XML, transport it
>via TAXII, transform, and then join the vertices and edges with the
>target's unique data instantiation of the same multi-dimensional model.
>
>There are future extensions to this use case where individual classes of
>objects are routed to methods specific to that class, but where the
>global attributes and broader context need to be passed, maintained, and
>returned with the method results.
>
>For example Transitive Tokenization processes that maintain form
>([hidden email] ==>  [hidden email]), convey statistically viable
>meaning for Analytics, while also ensuring redaction of attributional
>data will require differing methods and workflows (i.e., external sharing
>of Tokenized Credit Card, Social Security numbers, etc. may all get
>routed to different organizations and review/approval processes).
>
>We would want to immediately share actionable intelligence for classes of
>data that do not require vetting.  Then as each class completes it's
>unique workflow, it can be passed on with referential integrity to the
>original global package and the individual sub-packages.
>
>...So taking the simplistic approach of zipping up the 100's of
>individual STIX files and passing as a binary blob to the other side is
>not an option.
>
>There are many other scenarios, so hopefully this narrow example suffices
>to convey the concepts.
>
>I have not attempted to build an actual reference implementation, but I
>can envision how one would approach this with nested STIX packages.  How
>would one approach this without nesting?
>
>Patrick Maroney
>Office: (856)983-0001
>Cell: (609)841-5104
>[hidden email]
>________________________________________
>From: Grobauer, Bernd <[hidden email]>
>Sent: Thursday, February 26, 2015 8:02:19 AM
>To: [hidden email]
>Subject: Re: [STIX] Reaching final consensus on the Report Object
>proposal for the STIX 1.2 release
>
>Hi,
>
>I am completely with Aharon on this one: we have enough
>complexity as it is ...
>
>+1 reports cannot embed
>+1 packages cannot nest
>
>Kind regards,
>
>Bernd
>
>
>> -----Original Message-----
>> From: Aharon Chernin [mailto:[hidden email]]
>> Sent: Mittwoch, 25. Februar 2015 19:47
>> To: [hidden email]
>> Subject: Re: [STIX] Reaching final consensus on the Report Object
>> proposal for the STIX 1.2 release
>>
>> Optionality increases complexity and increases chance of error. Imagine
>> receiving a document with nested STIX packages, with report objects
>> that contain inline data, that also have report objects that reference
>> data somewhere else within other nested packages.
>>
>> Due to this flexibility, one of the issues with stix package is that
>> it's easy to use incorrectly. By elimating nested packages and inline
>> stix content within the report object we can reduce some of this
>> complexity. I am all for removing complexity.
>>
>> +1 reports cannot embed
>> +1 packages cannot nest
>>
>> Like I said on the community call, I can go either way on this.
>>
>> Aharon
>>
>> Sent using OWA for iPhone
>> ________________________________
>> From: Barnum, Sean D. <[hidden email]>
>> Sent: Wednesday, February 25, 2015 12:55:14 PM
>> To: [hidden email]
>> Subject: [STIX] Reaching final consensus on the Report Object proposal
>> for the STIX 1.2 release
>>
>> Everyone,
>>
>> Back in December we sent out a refined proposal for the Report Object
>> including two sub-proposals on fine details in an attempt to reach
>> final consensus on what will go into the STIX 1.2 release.
>>
>> The three relevant proposals are:
>>
>>
>>      Implement Report
>> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>> Implement-Report-Object> - note that this is not about whether to
>> implement the report object but how to implement the report object
>>
>> o   Reports Cannot Embed
>> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>> Reports-Cannot-Embed-Content> - this issue was large enough that we
>> split it into a separate topic
>>
>> o   Packages Cannot Contain Other
>> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
>> that we split it into a separate topic
>>
>>
>> We received a limited amount of feedback on the list in regards to the
>> two sub-proposals but all of it voiced opinions that for the STIX 1.2
>> release both sub-proposals should be rejected. In other words, +STIX
>> 1.2 should allow content to be embedded within the new Report Object
>> and that Packages (while stripped of their contextual fields that will
>> be moved to the new Report Object) should be allowed to contain other
>> Packages.
>> The same opinion on the two sub-proposals was also strongly expressed
>> by various community stakeholders off the list and directly to the STIX
>> team via [hidden email]<mailto:[hidden email]>. These players expressed
>> clear opposition to the broader Report Object proposal both on the list
>> and off. However, they expressed a willingness to compromise and accept
>> the broader Report Object proposal given the apparent consensus
>> rejection of the sub-proposals.
>>
>> These sub-proposals and their apparent consensus rejection was a topic
>> of conversation on last week's STIX community call.
>> The first sub-proposal discussed was regarding the embedding of content
>> within Report Objects. A couple of community members on the call
>> expressed that while they would prefer that embedding not be allowed,
>> they were willing to compromise and not contest the point in order to
>> move the community forward.
>> The second sub-proposal discussed was regarding the ability of Packages
>> to contain other Packages. On this point, several members expressed
>> concern on the call that had not been raised as feedback on the list.
>> In a nutshell, a belief was expressed that nesting packages may bring
>> significantly more complexity while others assert that the capability
>> already exists in STIX (it is not adding something new) and given the
>> newly limited context for Packages (based on the new Report Object) the
>> difference in complexity is actually rather minimal. Based on the
>> comments, it appears that we have not yet actually reached consensus on
>> this point and that more discussion may need to occur on the list. If
>> you have clear opinions one way or the other (this includes those who
>> spoke up on the call), please express them on the list so that we can
>> nail this down and move forward on our activity for the 1.2 release.
>>
>> Thanks,
>> Sean Barnum
>> STIX Project Team
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Trey Darley-3
In reply to this post by Barnum, Sean D.

+1 Reports Cannot Embed Content

+1 Packages Cannot Contain Other Packages


I may be a Soltra guy now but I am most certainly _not_ just parroting Aharon. I've been in this community much longer than I've been with Soltra.


This whole effort started off with the notion that there had to be a better way of sharing threat intel than emailing around CSV. One thing I'll say for CSV is that at least it _is_ parsable. With STIX/CybOX as they exist today, there are so many redundant ways of saying that two bits of data are contextually related that it sometimes feels like trying to solve the halting problem trying to account for all the permutations.


The whole point of the report object is to _reduce_ that complexity. In human-to-human communications, having many synonymous modes of expressing the same thought is virtuous. But the report object is targeting machine-to-machine communications. Don't conflate the two.​ Stop the madness! :-)


Cheers,
Trey
--
Trey Darley, CISSP
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
+32/494.766.080 | [hidden email]
www.soltra.com

From: Barnum, Sean D. <[hidden email]>
Sent: Wednesday, February 25, 2015 18:55
To: [hidden email]
Subject: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release
 

Everyone,

 

Back in December we sent out a refined proposal for the Report Object including two sub-proposals on fine details in an attempt to reach final consensus on what will go into the STIX 1.2 release.

 

The three relevant proposals are:

 

     Implement Report Object – note that this is not about whether to implement the report object but how to implement the report object

o   Reports Cannot Embed Content – this issue was large enough that we split it into a separate topic

o   Packages Cannot Contain Other Packages – this issue was large enough that we split it into a separate topic

 

 

We received a limited amount of feedback on the list in regards to the two sub-proposals but all of it voiced opinions that for the STIX 1.2 release both sub-proposals should be rejected. In other words, +STIX 1.2 should allow content to be embedded within the new Report Object and that Packages (while stripped of their contextual fields that will be moved to the new Report Object) should be allowed to contain other Packages.

The same opinion on the two sub-proposals was also strongly expressed by various community stakeholders off the list and directly to the STIX team via [hidden email]. These players expressed clear opposition to the broader Report Object proposal both on the list and off. However, they expressed a willingness to compromise and accept the broader Report Object proposal given the apparent consensus rejection of the sub-proposals.

 

These sub-proposals and their apparent consensus rejection was a topic of conversation on last week’s STIX community call.

The first sub-proposal discussed was regarding the embedding of content within Report Objects. A couple of community members on the call expressed that while they would prefer that embedding not be allowed, they were willing to compromise and not contest the point in order to move the community forward.

The second sub-proposal discussed was regarding the ability of Packages to contain other Packages. On this point, several members expressed concern on the call that had not been raised as feedback on the list. 

In a nutshell, a belief was expressed that nesting packages may bring significantly more complexity while others assert that the capability already exists in STIX (it is not adding something new) and given the newly limited context for Packages (based on the new Report Object) the difference in complexity is actually rather minimal. Based on the comments, it appears that we have not yet actually reached consensus on this point and that more discussion may need to occur on the list. If you have clear opinions one way or the other (this includes those who spoke up on the call), please express them on the list so that we can nail this down and move forward on our activity for the 1.2 release.

 

Thanks,

Sean Barnum

STIX Project Team

 

 

 

 

JA
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

JA
You touch a critical point there (thank you, as I was asking it to
myself yesterday...)
Just to make it crystal clear. Do we/you want H2H, M2M, M2H, H2M?
Based on the answer(s), maybe the word "Report" is not fully appropriate.
M2M is fine for me. But I would see it more as a "Context_Package" in
this case, as the word Report would be more like for human.

Thoughts?

PS: Trying to implement (code) something programmatically 'generic'
when dealing with the relationships is indeed a 'nightmare'.
Doing this analysis, in front, via human brain (and experience) (think
about the Ontology here) takes time but is feasible, and reduce
drastically the complexity when programming.
We made good progress in there with the latest CybOX documentation I think.

My 2c for now


2015-02-26 18:48 GMT+01:00 Trey Darley <[hidden email]>:

> +1 Reports Cannot Embed Content
>
> +1 Packages Cannot Contain Other Packages
>
>
> I may be a Soltra guy now but I am most certainly _not_ just parroting
> Aharon. I've been in this community much longer than I've been with Soltra.
>
>
> This whole effort started off with the notion that there had to be a better
> way of sharing threat intel than emailing around CSV. One thing I'll say for
> CSV is that at least it _is_ parsable. With STIX/CybOX as they exist today,
> there are so many redundant ways of saying that two bits of data are
> contextually related that it sometimes feels like trying to solve the
> halting problem trying to account for all the permutations.
>
>
> The whole point of the report object is to _reduce_ that complexity. In
> human-to-human communications, having many synonymous modes of expressing
> the same thought is virtuous. But the report object is targeting
> machine-to-machine communications. Don't conflate the two. Stop the madness!
> :-)
>
>
> Cheers,
> Trey
> --
> Trey Darley, CISSP
> Senior Security Engineer
> Soltra | An FS-ISAC & DTCC Company
> +32/494.766.080 | [hidden email]
> www.soltra.com
> ________________________________
> From: Barnum, Sean D. <[hidden email]>
> Sent: Wednesday, February 25, 2015 18:55
> To: [hidden email]
> Subject: [STIX] Reaching final consensus on the Report Object proposal for
> the STIX 1.2 release
>
>
> Everyone,
>
>
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach final
> consensus on what will go into the STIX 1.2 release.
>
>
>
> The three relevant proposals are:
>
>
>
>      Implement Report Object – note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed Content – this issue was large enough that we split
> it into a separate topic
>
> o   Packages Cannot Contain Other Packages – this issue was large enough
> that we split it into a separate topic
>
>
>
>
>
> We received a limited amount of feedback on the list in regards to the two
> sub-proposals but all of it voiced opinions that for the STIX 1.2 release
> both sub-proposals should be rejected. In other words, +STIX 1.2 should
> allow content to be embedded within the new Report Object and that Packages
> (while stripped of their contextual fields that will be moved to the new
> Report Object) should be allowed to contain other Packages.
>
> The same opinion on the two sub-proposals was also strongly expressed by
> various community stakeholders off the list and directly to the STIX team
> via [hidden email]. These players expressed clear opposition to the broader
> Report Object proposal both on the list and off. However, they expressed a
> willingness to compromise and accept the broader Report Object proposal
> given the apparent consensus rejection of the sub-proposals.
>
>
>
> These sub-proposals and their apparent consensus rejection was a topic of
> conversation on last week’s STIX community call.
>
> The first sub-proposal discussed was regarding the embedding of content
> within Report Objects. A couple of community members on the call expressed
> that while they would prefer that embedding not be allowed, they were
> willing to compromise and not contest the point in order to move the
> community forward.
>
> The second sub-proposal discussed was regarding the ability of Packages to
> contain other Packages. On this point, several members expressed concern on
> the call that had not been raised as feedback on the list.
>
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the newly
> limited context for Packages (based on the new Report Object) the difference
> in complexity is actually rather minimal. Based on the comments, it appears
> that we have not yet actually reached consensus on this point and that more
> discussion may need to occur on the list. If you have clear opinions one way
> or the other (this includes those who spoke up on the call), please express
> them on the list so that we can nail this down and move forward on our
> activity for the 1.2 release.
>
>
>
> Thanks,
>
> Sean Barnum
>
> STIX Project Team
>
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Trey Darley-3
My primary concern (taking off my Soltra hat) has always been the ability to easily distinguish between STIX that's intended for a human analyst reader versus machine-to-machine STIX.

My original proposal  was to just add a 'human_generated' boolean flag to the Package header.

Once I grokked how Soltra decomposes Packages into their constituent parts with a sort-of directed graph linking them together, the notion of treating the Package as a throwaway envelope and moving the context-specific attributes into the Report object seemed intuitively obvious.

Cheers,
Trey
--
Trey Darley, CISSP
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: Jerome Athias <[hidden email]>
Sent: Thursday, February 26, 2015 19:03
To: Trey Darley
Cc: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

You touch a critical point there (thank you, as I was asking it to
myself yesterday...)
Just to make it crystal clear. Do we/you want H2H, M2M, M2H, H2M?
Based on the answer(s), maybe the word "Report" is not fully appropriate.
M2M is fine for me. But I would see it more as a "Context_Package" in
this case, as the word Report would be more like for human.

Thoughts?

PS: Trying to implement (code) something programmatically 'generic'
when dealing with the relationships is indeed a 'nightmare'.
Doing this analysis, in front, via human brain (and experience) (think
about the Ontology here) takes time but is feasible, and reduce
drastically the complexity when programming.
We made good progress in there with the latest CybOX documentation I think.

My 2c for now
JA
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

JA
makes sense

regarding "With STIX/CybOX as they exist today, there are so many
redundant ways of saying that two bits of data are contextually
related that it sometimes feels like trying to solve the halting
problem trying to account for all the permutations."
Understood, and agree.
I have observed that.
For information, during my experimental approach (relational
database), I've seen the complexity largely reduced as each concept
will appear only once at the end, with relationships to the other
concepts currently in STIX/CybOX.
To go further, I've also seen opportunities for more relationships
between current concepts.

Cheers


2015-02-26 19:10 GMT+01:00 Trey Darley <[hidden email]>:

> My primary concern (taking off my Soltra hat) has always been the ability to easily distinguish between STIX that's intended for a human analyst reader versus machine-to-machine STIX.
>
> My original proposal  was to just add a 'human_generated' boolean flag to the Package header.
>
> Once I grokked how Soltra decomposes Packages into their constituent parts with a sort-of directed graph linking them together, the notion of treating the Package as a throwaway envelope and moving the context-specific attributes into the Report object seemed intuitively obvious.
>
> Cheers,
> Trey
> --
> Trey Darley, CISSP
> Senior Security Engineer
> Soltra | An FS-ISAC & DTCC Company
> www.soltra.com
>
> ________________________________________
> From: Jerome Athias <[hidden email]>
> Sent: Thursday, February 26, 2015 19:03
> To: Trey Darley
> Cc: stix-discussion-list Structured Threat Information Expression/ST
> Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release
>
> You touch a critical point there (thank you, as I was asking it to
> myself yesterday...)
> Just to make it crystal clear. Do we/you want H2H, M2M, M2H, H2M?
> Based on the answer(s), maybe the word "Report" is not fully appropriate.
> M2M is fine for me. But I would see it more as a "Context_Package" in
> this case, as the word Report would be more like for human.
>
> Thoughts?
>
> PS: Trying to implement (code) something programmatically 'generic'
> when dealing with the relationships is indeed a 'nightmare'.
> Doing this analysis, in front, via human brain (and experience) (think
> about the Ontology here) takes time but is feasible, and reduce
> drastically the complexity when programming.
> We made good progress in there with the latest CybOX documentation I think.
>
> My 2c for now
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Collie, Byron S.
In reply to this post by JA
I absolutely disagree on the point that the only object of this data model is for machine to machine communication.  

The entity model it brings with it is much more than that.  I attend meetings with senior people in government who are using the STIX entity model to help build cyber exercise scenarios so to look at the entity model we are constructing with such a limited lens is not the reality.   Some of our have already had to implement reports as a logical construct (together with collections and sources as the hierarchy) in order to be able to order all of the data in a meaningful way and to answer human questions from regulatory agencies:

- when and from what source did you first receive the IOCs associated with (big real world incident)
- did you possess any other information that correlated to the IOCs
- what is your assessment of those IOCs in terms of:
        - observations (ie sightings)
        - actions taken on those IOCs (Courses of Action - Implementation)

An intel platform for a regulated entity, particularly in the US financial services sector, is going to need to support answering human, real world questions about IOCs, their pedigree, correlation and actions associated with them.

Byron
 

-----Original Message-----
From: Jerome Athias [mailto:[hidden email]]
Sent: Thursday, February 26, 2015 1:03 PM
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

You touch a critical point there (thank you, as I was asking it to myself yesterday...) Just to make it crystal clear. Do we/you want H2H, M2M, M2H, H2M?
Based on the answer(s), maybe the word "Report" is not fully appropriate.
M2M is fine for me. But I would see it more as a "Context_Package" in this case, as the word Report would be more like for human.

Thoughts?

PS: Trying to implement (code) something programmatically 'generic'
when dealing with the relationships is indeed a 'nightmare'.
Doing this analysis, in front, via human brain (and experience) (think about the Ontology here) takes time but is feasible, and reduce drastically the complexity when programming.
We made good progress in there with the latest CybOX documentation I think.

My 2c for now


2015-02-26 18:48 GMT+01:00 Trey Darley <[hidden email]>:

> +1 Reports Cannot Embed Content
>
> +1 Packages Cannot Contain Other Packages
>
>
> I may be a Soltra guy now but I am most certainly _not_ just parroting
> Aharon. I've been in this community much longer than I've been with Soltra.
>
>
> This whole effort started off with the notion that there had to be a
> better way of sharing threat intel than emailing around CSV. One thing
> I'll say for CSV is that at least it _is_ parsable. With STIX/CybOX as
> they exist today, there are so many redundant ways of saying that two
> bits of data are contextually related that it sometimes feels like
> trying to solve the halting problem trying to account for all the permutations.
>
>
> The whole point of the report object is to _reduce_ that complexity.
> In human-to-human communications, having many synonymous modes of
> expressing the same thought is virtuous. But the report object is
> targeting machine-to-machine communications. Don't conflate the two. Stop the madness!
> :-)
>
>
> Cheers,
> Trey
> --
> Trey Darley, CISSP
> Senior Security Engineer
> Soltra | An FS-ISAC & DTCC Company
> +32/494.766.080 | [hidden email]
> www.soltra.com
> ________________________________
> From: Barnum, Sean D. <[hidden email]>
> Sent: Wednesday, February 25, 2015 18:55
> To: [hidden email]
> Subject: [STIX] Reaching final consensus on the Report Object proposal
> for the STIX 1.2 release
>
>
> Everyone,
>
>
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach
> final consensus on what will go into the STIX 1.2 release.
>
>
>
> The three relevant proposals are:
>
>
>
>      Implement Report Object – note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed Content – this issue was large enough that we split
> it into a separate topic
>
> o   Packages Cannot Contain Other Packages – this issue was large enough
> that we split it into a separate topic
>
>
>
>
>
> We received a limited amount of feedback on the list in regards to the
> two sub-proposals but all of it voiced opinions that for the STIX 1.2
> release both sub-proposals should be rejected. In other words, +STIX
> 1.2 should allow content to be embedded within the new Report Object
> and that Packages (while stripped of their contextual fields that will
> be moved to the new Report Object) should be allowed to contain other Packages.
>
> The same opinion on the two sub-proposals was also strongly expressed
> by various community stakeholders off the list and directly to the
> STIX team via [hidden email]. These players expressed clear opposition
> to the broader Report Object proposal both on the list and off.
> However, they expressed a willingness to compromise and accept the
> broader Report Object proposal given the apparent consensus rejection of the sub-proposals.
>
>
>
> These sub-proposals and their apparent consensus rejection was a topic
> of conversation on last week’s STIX community call.
>
> The first sub-proposal discussed was regarding the embedding of
> content within Report Objects. A couple of community members on the
> call expressed that while they would prefer that embedding not be
> allowed, they were willing to compromise and not contest the point in
> order to move the community forward.
>
> The second sub-proposal discussed was regarding the ability of
> Packages to contain other Packages. On this point, several members
> expressed concern on the call that had not been raised as feedback on the list.
>
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the
> newly limited context for Packages (based on the new Report Object)
> the difference in complexity is actually rather minimal. Based on the
> comments, it appears that we have not yet actually reached consensus
> on this point and that more discussion may need to occur on the list.
> If you have clear opinions one way or the other (this includes those
> who spoke up on the call), please express them on the list so that we
> can nail this down and move forward on our activity for the 1.2 release.
>
>
>
> Thanks,
>
> Sean Barnum
>
> STIX Project Team
>
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Marlon.Taylor
In reply to this post by Joep Gommers
It might help the community if we went through some of the concerns with embedding at the Package level and/or Report level.

Originally, without the inclusion of the Report Object, STIX allowed Packages to embed other packages.

The Report Object allows the embedding of other Reports.

Through the inclusion of the Report proposal we now have two ways to embed entire content/context into a document (at the Package level and/or at the Report level).

This overlap in capability has sparked some concern with  members of the Community. While this would increase the complexity for members trying to address both embedding methods, I think we address the need for this complexity by answering the question "Why".

Why would someone embed at the Package level rather than the Report level or vice-versa (besides the fact that the schema would allow them to do so)?

Put another way, Does 1 Package with 10 embedded Packages mean something different from 1 Report with 10 embedded reports? (We're not even going to look into the possible matrix of embedded Packages containing embedded Reports) I think answering this question would bring to the necessity of both methods to light, then we can decide which if any is needed.

Note: the word 'embed' could be replaced with 'relate'.

-Marlon
-----Original Message-----
From: Joep Gommers [mailto:[hidden email]]
Sent: Thursday, February 26, 2015 11:41 AM
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Disclaimer: i¹m not apposed to nesting, yet:

Since STIX_Packages are simply non-substantive wrappers of actual STIX entities, how would sending one STIX_Package containing others be different then sending a 100 STIX_Packages - other then overhead?

We do a similar thing, but the de-composing and re-composing of entities and their relationships, would (in our case, but like to understand yours) not require anything the STIX_Package (as a non-substantive wrapper) has to offer.

Best regards,
Joep




On 2/26/15, 6:30 PM, "Patrick Maroney" <[hidden email]> wrote:

>I know we're looking for up or down at this point, but wanted to ask a
>clarifying question from those opposed to nesting (in particular when
>those expressing same are highly respected and contribute a lot to our
>"thing").
>
>Caveats:
>
>1) Hope the following is reasonably clear.
>
>2) There are many Worldviews and each is valid.  "Our" primary
>worldview is that any externally exposed TAXII Gateways should only
>provide for the reliable transport and distribution of ephemeral STIX
>packages.  From a security architecture perspective, all externally
>facing services, the assets supporting them, and any data stored on
>same must be considered at high risk of compromise over time (exposure
>and integrity).  Therefore, all Cyber-Intelligence data should only be
>stored on any externally exposed TAXII Gateways for as long as is
>required to assemble and ensure delivery to all recipients.  Presuming
>best practices of sending event logging to central log management
>facility are follwed, a Stateless Model is established that empowers
>the use of automated provisioning systems to periodically revert high risk systems back to a known good state.
>
>Use Case:
>
>I have a real-life challenge right now with integration of a third
>party tool.  This tool uses a graph-like internal data model.  When
>extracting from any given node one specifies the maximum depth of
>relations to traverse and maximum number of objects.  It decomposes the
>graph of all related objects into multiple STIX packages of individual
>objects with external references to related objects.
>
>So I end up with a folder with 100's of inter-related STIX packages
>that I need to wrap in a single STIX container that describes/conveys
>the global attributes and broader context, in aggregate, of the package
>and it's individual elements.
>
>The ultimate objective is to extract the multi-dimensional model to the
>depth specified, transform into two dimensional STIX XML, transport it
>via TAXII, transform, and then join the vertices and edges with the
>target's unique data instantiation of the same multi-dimensional model.
>
>There are future extensions to this use case where individual classes
>of objects are routed to methods specific to that class, but where the
>global attributes and broader context need to be passed, maintained,
>and returned with the method results.
>
>For example Transitive Tokenization processes that maintain form
>([hidden email] ==>  [hidden email]), convey statistically
>viable meaning for Analytics, while also ensuring redaction of
>attributional data will require differing methods and workflows (i.e.,
>external sharing of Tokenized Credit Card, Social Security numbers,
>etc. may all get routed to different organizations and review/approval processes).
>
>We would want to immediately share actionable intelligence for classes
>of data that do not require vetting.  Then as each class completes it's
>unique workflow, it can be passed on with referential integrity to the
>original global package and the individual sub-packages.
>
>...So taking the simplistic approach of zipping up the 100's of
>individual STIX files and passing as a binary blob to the other side is
>not an option.
>
>There are many other scenarios, so hopefully this narrow example
>suffices to convey the concepts.
>
>I have not attempted to build an actual reference implementation, but I
>can envision how one would approach this with nested STIX packages.  
>How would one approach this without nesting?
>
>Patrick Maroney
>Office: (856)983-0001
>Cell: (609)841-5104
>[hidden email]
>________________________________________
>From: Grobauer, Bernd <[hidden email]>
>Sent: Thursday, February 26, 2015 8:02:19 AM
>To: [hidden email]
>Subject: Re: [STIX] Reaching final consensus on the Report Object
>proposal for the STIX 1.2 release
>
>Hi,
>
>I am completely with Aharon on this one: we have enough complexity as
>it is ...
>
>+1 reports cannot embed
>+1 packages cannot nest
>
>Kind regards,
>
>Bernd
>
>
>> -----Original Message-----
>> From: Aharon Chernin [mailto:[hidden email]]
>> Sent: Mittwoch, 25. Februar 2015 19:47
>> To: [hidden email]
>> Subject: Re: [STIX] Reaching final consensus on the Report Object
>> proposal for the STIX 1.2 release
>>
>> Optionality increases complexity and increases chance of error.
>> Imagine receiving a document with nested STIX packages, with report
>> objects that contain inline data, that also have report objects that
>> reference data somewhere else within other nested packages.
>>
>> Due to this flexibility, one of the issues with stix package is that
>> it's easy to use incorrectly. By elimating nested packages and inline
>> stix content within the report object we can reduce some of this
>> complexity. I am all for removing complexity.
>>
>> +1 reports cannot embed
>> +1 packages cannot nest
>>
>> Like I said on the community call, I can go either way on this.
>>
>> Aharon
>>
>> Sent using OWA for iPhone
>> ________________________________
>> From: Barnum, Sean D. <[hidden email]>
>> Sent: Wednesday, February 25, 2015 12:55:14 PM
>> To: [hidden email]
>> Subject: [STIX] Reaching final consensus on the Report Object
>> proposal for the STIX 1.2 release
>>
>> Everyone,
>>
>> Back in December we sent out a refined proposal for the Report Object
>> including two sub-proposals on fine details in an attempt to reach
>> final consensus on what will go into the STIX 1.2 release.
>>
>> The three relevant proposals are:
>>
>>
>>      Implement Report
>> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>> Implement-Report-Object> - note that this is not about whether to
>> implement the report object but how to implement the report object
>>
>> o   Reports Cannot Embed
>> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>> Reports-Cannot-Embed-Content> - this issue was large enough that we
>> split it into a separate topic
>>
>> o   Packages Cannot Contain Other
>> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
>> that we split it into a separate topic
>>
>>
>> We received a limited amount of feedback on the list in regards to
>> the two sub-proposals but all of it voiced opinions that for the STIX
>> 1.2 release both sub-proposals should be rejected. In other words,
>> +STIX
>> 1.2 should allow content to be embedded within the new Report Object
>> and that Packages (while stripped of their contextual fields that
>> will be moved to the new Report Object) should be allowed to contain
>> other Packages.
>> The same opinion on the two sub-proposals was also strongly expressed
>> by various community stakeholders off the list and directly to the
>> STIX team via [hidden email]<mailto:[hidden email]>. These players
>> expressed clear opposition to the broader Report Object proposal both
>> on the list and off. However, they expressed a willingness to
>> compromise and accept the broader Report Object proposal given the
>> apparent consensus rejection of the sub-proposals.
>>
>> These sub-proposals and their apparent consensus rejection was a
>> topic of conversation on last week's STIX community call.
>> The first sub-proposal discussed was regarding the embedding of
>> content within Report Objects. A couple of community members on the
>> call expressed that while they would prefer that embedding not be
>> allowed, they were willing to compromise and not contest the point in
>> order to move the community forward.
>> The second sub-proposal discussed was regarding the ability of
>> Packages to contain other Packages. On this point, several members
>> expressed concern on the call that had not been raised as feedback on the list.
>> In a nutshell, a belief was expressed that nesting packages may bring
>> significantly more complexity while others assert that the capability
>> already exists in STIX (it is not adding something new) and given the
>> newly limited context for Packages (based on the new Report Object)
>> the difference in complexity is actually rather minimal. Based on the
>> comments, it appears that we have not yet actually reached consensus
>> on this point and that more discussion may need to occur on the list.
>> If you have clear opinions one way or the other (this includes those
>> who spoke up on the call), please express them on the list so that we
>> can nail this down and move forward on our activity for the 1.2 release.
>>
>> Thanks,
>> Sean Barnum
>> STIX Project Team
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Trey Darley-3
In reply to this post by Collie, Byron S.
Hey, Byron -

Don't get me wrong. I didn't mean to say that the Report object was _just_ about machine-to-machine. Perhaps I misspoke or gave the wrong impression. I certainly did not intend to make light of the challenges faced by others in the community (such as your own) nor to make light of use cases apart from my own.

What I intended to say was:

1) I'm very interested in having a way to indicate that a particular bit of STIX is intended for a human or for a machine. I expect that capability from the Report object.

2) I'm very, very interested in reducing unnecessary complexity. It would sadden me if the Report object had the opposite effect.

Cheers,
Trey
--
Trey Darley, CISSP
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: Collie, Byron S. <[hidden email]>
Sent: Thursday, February 26, 2015 19:23
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

I absolutely disagree on the point that the only object of this data model is for machine to machine communication.

The entity model it brings with it is much more than that.  I attend meetings with senior people in government who are using the STIX entity model to help build cyber exercise scenarios so to look at the entity model we are constructing with such a limited lens is not the reality.   Some of our have already had to implement reports as a logical construct (together with collections and sources as the hierarchy) in order to be able to order all of the data in a meaningful way and to answer human questions from regulatory agencies:

- when and from what source did you first receive the IOCs associated with (big real world incident)
- did you possess any other information that correlated to the IOCs
- what is your assessment of those IOCs in terms of:
        - observations (ie sightings)
        - actions taken on those IOCs (Courses of Action - Implementation)

An intel platform for a regulated entity, particularly in the US financial services sector, is going to need to support answering human, real world questions about IOCs, their pedigree, correlation and actions associated with them.

Byron


-----Original Message-----
From: Jerome Athias [mailto:[hidden email]]
Sent: Thursday, February 26, 2015 1:03 PM
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

You touch a critical point there (thank you, as I was asking it to myself yesterday...) Just to make it crystal clear. Do we/you want H2H, M2M, M2H, H2M?
Based on the answer(s), maybe the word "Report" is not fully appropriate.
M2M is fine for me. But I would see it more as a "Context_Package" in this case, as the word Report would be more like for human.

Thoughts?

PS: Trying to implement (code) something programmatically 'generic'
when dealing with the relationships is indeed a 'nightmare'.
Doing this analysis, in front, via human brain (and experience) (think about the Ontology here) takes time but is feasible, and reduce drastically the complexity when programming.
We made good progress in there with the latest CybOX documentation I think.

My 2c for now


2015-02-26 18:48 GMT+01:00 Trey Darley <[hidden email]>:

> +1 Reports Cannot Embed Content
>
> +1 Packages Cannot Contain Other Packages
>
>
> I may be a Soltra guy now but I am most certainly _not_ just parroting
> Aharon. I've been in this community much longer than I've been with Soltra.
>
>
> This whole effort started off with the notion that there had to be a
> better way of sharing threat intel than emailing around CSV. One thing
> I'll say for CSV is that at least it _is_ parsable. With STIX/CybOX as
> they exist today, there are so many redundant ways of saying that two
> bits of data are contextually related that it sometimes feels like
> trying to solve the halting problem trying to account for all the permutations.
>
>
> The whole point of the report object is to _reduce_ that complexity.
> In human-to-human communications, having many synonymous modes of
> expressing the same thought is virtuous. But the report object is
> targeting machine-to-machine communications. Don't conflate the two. Stop the madness!
> :-)
>
>
> Cheers,
> Trey
> --
> Trey Darley, CISSP
> Senior Security Engineer
> Soltra | An FS-ISAC & DTCC Company
> +32/494.766.080 | [hidden email]
> www.soltra.com
> ________________________________
> From: Barnum, Sean D. <[hidden email]>
> Sent: Wednesday, February 25, 2015 18:55
> To: [hidden email]
> Subject: [STIX] Reaching final consensus on the Report Object proposal
> for the STIX 1.2 release
>
>
> Everyone,
>
>
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach
> final consensus on what will go into the STIX 1.2 release.
>
>
>
> The three relevant proposals are:
>
>
>
>      Implement Report Object – note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed Content – this issue was large enough that we split
> it into a separate topic
>
> o   Packages Cannot Contain Other Packages – this issue was large enough
> that we split it into a separate topic
>
>
>
>
>
> We received a limited amount of feedback on the list in regards to the
> two sub-proposals but all of it voiced opinions that for the STIX 1.2
> release both sub-proposals should be rejected. In other words, +STIX
> 1.2 should allow content to be embedded within the new Report Object
> and that Packages (while stripped of their contextual fields that will
> be moved to the new Report Object) should be allowed to contain other Packages.
>
> The same opinion on the two sub-proposals was also strongly expressed
> by various community stakeholders off the list and directly to the
> STIX team via [hidden email]. These players expressed clear opposition
> to the broader Report Object proposal both on the list and off.
> However, they expressed a willingness to compromise and accept the
> broader Report Object proposal given the apparent consensus rejection of the sub-proposals.
>
>
>
> These sub-proposals and their apparent consensus rejection was a topic
> of conversation on last week’s STIX community call.
>
> The first sub-proposal discussed was regarding the embedding of
> content within Report Objects. A couple of community members on the
> call expressed that while they would prefer that embedding not be
> allowed, they were willing to compromise and not contest the point in
> order to move the community forward.
>
> The second sub-proposal discussed was regarding the ability of
> Packages to contain other Packages. On this point, several members
> expressed concern on the call that had not been raised as feedback on the list.
>
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the
> newly limited context for Packages (based on the new Report Object)
> the difference in complexity is actually rather minimal. Based on the
> comments, it appears that we have not yet actually reached consensus
> on this point and that more discussion may need to occur on the list.
> If you have clear opinions one way or the other (this includes those
> who spoke up on the call), please express them on the list so that we
> can nail this down and move forward on our activity for the 1.2 release.
>
>
>
> Thanks,
>
> Sean Barnum
>
> STIX Project Team
>
>
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Trey Darley-3
An analogy for your consideration:

If I hit a rest endpoint, in a way I am accessing a webpage. As a human, I can easily read and parse the json output. But clearly that is intended for a machine consumer and handling that output is computationally, qualitatively distinct from screen-scraping cnn.com.

As STIX currently exists, there is no way of indicating whether the intended consumer is carbon or silicon-based.

Cheers,
Trey
--
Trey Darley, CISSP
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: Trey Darley <[hidden email]>
Sent: Thursday, February 26, 2015 19:33
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Hey, Byron -

Don't get me wrong. I didn't mean to say that the Report object was _just_ about machine-to-machine. Perhaps I misspoke or gave the wrong impression. I certainly did not intend to make light of the challenges faced by others in the community (such as your own) nor to make light of use cases apart from my own.

What I intended to say was:

1) I'm very interested in having a way to indicate that a particular bit of STIX is intended for a human or for a machine. I expect that capability from the Report object.

2) I'm very, very interested in reducing unnecessary complexity. It would sadden me if the Report object had the opposite effect.

Cheers,
Trey
--
Trey Darley, CISSP
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com

________________________________________
From: Collie, Byron S. <[hidden email]>
Sent: Thursday, February 26, 2015 19:23
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

I absolutely disagree on the point that the only object of this data model is for machine to machine communication.

The entity model it brings with it is much more than that.  I attend meetings with senior people in government who are using the STIX entity model to help build cyber exercise scenarios so to look at the entity model we are constructing with such a limited lens is not the reality.   Some of our have already had to implement reports as a logical construct (together with collections and sources as the hierarchy) in order to be able to order all of the data in a meaningful way and to answer human questions from regulatory agencies:

- when and from what source did you first receive the IOCs associated with (big real world incident)
- did you possess any other information that correlated to the IOCs
- what is your assessment of those IOCs in terms of:
        - observations (ie sightings)
        - actions taken on those IOCs (Courses of Action - Implementation)

An intel platform for a regulated entity, particularly in the US financial services sector, is going to need to support answering human, real world questions about IOCs, their pedigree, correlation and actions associated with them.

Byron


-----Original Message-----
From: Jerome Athias [mailto:[hidden email]]
Sent: Thursday, February 26, 2015 1:03 PM
To: [hidden email]
Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

You touch a critical point there (thank you, as I was asking it to myself yesterday...) Just to make it crystal clear. Do we/you want H2H, M2M, M2H, H2M?
Based on the answer(s), maybe the word "Report" is not fully appropriate.
M2M is fine for me. But I would see it more as a "Context_Package" in this case, as the word Report would be more like for human.

Thoughts?

PS: Trying to implement (code) something programmatically 'generic'
when dealing with the relationships is indeed a 'nightmare'.
Doing this analysis, in front, via human brain (and experience) (think about the Ontology here) takes time but is feasible, and reduce drastically the complexity when programming.
We made good progress in there with the latest CybOX documentation I think.

My 2c for now


2015-02-26 18:48 GMT+01:00 Trey Darley <[hidden email]>:

> +1 Reports Cannot Embed Content
>
> +1 Packages Cannot Contain Other Packages
>
>
> I may be a Soltra guy now but I am most certainly _not_ just parroting
> Aharon. I've been in this community much longer than I've been with Soltra.
>
>
> This whole effort started off with the notion that there had to be a
> better way of sharing threat intel than emailing around CSV. One thing
> I'll say for CSV is that at least it _is_ parsable. With STIX/CybOX as
> they exist today, there are so many redundant ways of saying that two
> bits of data are contextually related that it sometimes feels like
> trying to solve the halting problem trying to account for all the permutations.
>
>
> The whole point of the report object is to _reduce_ that complexity.
> In human-to-human communications, having many synonymous modes of
> expressing the same thought is virtuous. But the report object is
> targeting machine-to-machine communications. Don't conflate the two. Stop the madness!
> :-)
>
>
> Cheers,
> Trey
> --
> Trey Darley, CISSP
> Senior Security Engineer
> Soltra | An FS-ISAC & DTCC Company
> +32/494.766.080 | [hidden email]
> www.soltra.com
> ________________________________
> From: Barnum, Sean D. <[hidden email]>
> Sent: Wednesday, February 25, 2015 18:55
> To: [hidden email]
> Subject: [STIX] Reaching final consensus on the Report Object proposal
> for the STIX 1.2 release
>
>
> Everyone,
>
>
>
> Back in December we sent out a refined proposal for the Report Object
> including two sub-proposals on fine details in an attempt to reach
> final consensus on what will go into the STIX 1.2 release.
>
>
>
> The three relevant proposals are:
>
>
>
>      Implement Report Object – note that this is not about whether to
> implement the report object but how to implement the report object
>
> o   Reports Cannot Embed Content – this issue was large enough that we split
> it into a separate topic
>
> o   Packages Cannot Contain Other Packages – this issue was large enough
> that we split it into a separate topic
>
>
>
>
>
> We received a limited amount of feedback on the list in regards to the
> two sub-proposals but all of it voiced opinions that for the STIX 1.2
> release both sub-proposals should be rejected. In other words, +STIX
> 1.2 should allow content to be embedded within the new Report Object
> and that Packages (while stripped of their contextual fields that will
> be moved to the new Report Object) should be allowed to contain other Packages.
>
> The same opinion on the two sub-proposals was also strongly expressed
> by various community stakeholders off the list and directly to the
> STIX team via [hidden email]. These players expressed clear opposition
> to the broader Report Object proposal both on the list and off.
> However, they expressed a willingness to compromise and accept the
> broader Report Object proposal given the apparent consensus rejection of the sub-proposals.
>
>
>
> These sub-proposals and their apparent consensus rejection was a topic
> of conversation on last week’s STIX community call.
>
> The first sub-proposal discussed was regarding the embedding of
> content within Report Objects. A couple of community members on the
> call expressed that while they would prefer that embedding not be
> allowed, they were willing to compromise and not contest the point in
> order to move the community forward.
>
> The second sub-proposal discussed was regarding the ability of
> Packages to contain other Packages. On this point, several members
> expressed concern on the call that had not been raised as feedback on the list.
>
> In a nutshell, a belief was expressed that nesting packages may bring
> significantly more complexity while others assert that the capability
> already exists in STIX (it is not adding something new) and given the
> newly limited context for Packages (based on the new Report Object)
> the difference in complexity is actually rather minimal. Based on the
> comments, it appears that we have not yet actually reached consensus
> on this point and that more discussion may need to occur on the list.
> If you have clear opinions one way or the other (this includes those
> who spoke up on the call), please express them on the list so that we
> can nail this down and move forward on our activity for the 1.2 release.
>
>
>
> Thanks,
>
> Sean Barnum
>
> STIX Project Team
>
>
>
>
>
>
>
>
JA
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

JA
In reply to this post by Marlon.Taylor
Ok, why not trying with an analogy. (I hope you guys like French cuisine :p)

We do have ingredients (Packages, or would this be Objects*?) in the kitchen
We need multiple recipes (individual Reports, or would this be Packages*)
We want to eat a good meal (final Report ((maybe the full Menu)))



2015-02-26 19:24 GMT+01:00  <[hidden email]>:

> It might help the community if we went through some of the concerns with embedding at the Package level and/or Report level.
>
> Originally, without the inclusion of the Report Object, STIX allowed Packages to embed other packages.
>
> The Report Object allows the embedding of other Reports.
>
> Through the inclusion of the Report proposal we now have two ways to embed entire content/context into a document (at the Package level and/or at the Report level).
>
> This overlap in capability has sparked some concern with  members of the Community. While this would increase the complexity for members trying to address both embedding methods, I think we address the need for this complexity by answering the question "Why".
>
> Why would someone embed at the Package level rather than the Report level or vice-versa (besides the fact that the schema would allow them to do so)?
>
> Put another way, Does 1 Package with 10 embedded Packages mean something different from 1 Report with 10 embedded reports? (We're not even going to look into the possible matrix of embedded Packages containing embedded Reports) I think answering this question would bring to the necessity of both methods to light, then we can decide which if any is needed.
>
> Note: the word 'embed' could be replaced with 'relate'.
>
> -Marlon
> -----Original Message-----
> From: Joep Gommers [mailto:[hidden email]]
> Sent: Thursday, February 26, 2015 11:41 AM
> To: [hidden email]
> Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release
>
> Disclaimer: i¹m not apposed to nesting, yet:
>
> Since STIX_Packages are simply non-substantive wrappers of actual STIX entities, how would sending one STIX_Package containing others be different then sending a 100 STIX_Packages - other then overhead?
>
> We do a similar thing, but the de-composing and re-composing of entities and their relationships, would (in our case, but like to understand yours) not require anything the STIX_Package (as a non-substantive wrapper) has to offer.
>
> Best regards,
> Joep
>
>
>
>
> On 2/26/15, 6:30 PM, "Patrick Maroney" <[hidden email]> wrote:
>
>>I know we're looking for up or down at this point, but wanted to ask a
>>clarifying question from those opposed to nesting (in particular when
>>those expressing same are highly respected and contribute a lot to our
>>"thing").
>>
>>Caveats:
>>
>>1) Hope the following is reasonably clear.
>>
>>2) There are many Worldviews and each is valid.  "Our" primary
>>worldview is that any externally exposed TAXII Gateways should only
>>provide for the reliable transport and distribution of ephemeral STIX
>>packages.  From a security architecture perspective, all externally
>>facing services, the assets supporting them, and any data stored on
>>same must be considered at high risk of compromise over time (exposure
>>and integrity).  Therefore, all Cyber-Intelligence data should only be
>>stored on any externally exposed TAXII Gateways for as long as is
>>required to assemble and ensure delivery to all recipients.  Presuming
>>best practices of sending event logging to central log management
>>facility are follwed, a Stateless Model is established that empowers
>>the use of automated provisioning systems to periodically revert high risk systems back to a known good state.
>>
>>Use Case:
>>
>>I have a real-life challenge right now with integration of a third
>>party tool.  This tool uses a graph-like internal data model.  When
>>extracting from any given node one specifies the maximum depth of
>>relations to traverse and maximum number of objects.  It decomposes the
>>graph of all related objects into multiple STIX packages of individual
>>objects with external references to related objects.
>>
>>So I end up with a folder with 100's of inter-related STIX packages
>>that I need to wrap in a single STIX container that describes/conveys
>>the global attributes and broader context, in aggregate, of the package
>>and it's individual elements.
>>
>>The ultimate objective is to extract the multi-dimensional model to the
>>depth specified, transform into two dimensional STIX XML, transport it
>>via TAXII, transform, and then join the vertices and edges with the
>>target's unique data instantiation of the same multi-dimensional model.
>>
>>There are future extensions to this use case where individual classes
>>of objects are routed to methods specific to that class, but where the
>>global attributes and broader context need to be passed, maintained,
>>and returned with the method results.
>>
>>For example Transitive Tokenization processes that maintain form
>>([hidden email] ==>  [hidden email]), convey statistically
>>viable meaning for Analytics, while also ensuring redaction of
>>attributional data will require differing methods and workflows (i.e.,
>>external sharing of Tokenized Credit Card, Social Security numbers,
>>etc. may all get routed to different organizations and review/approval processes).
>>
>>We would want to immediately share actionable intelligence for classes
>>of data that do not require vetting.  Then as each class completes it's
>>unique workflow, it can be passed on with referential integrity to the
>>original global package and the individual sub-packages.
>>
>>...So taking the simplistic approach of zipping up the 100's of
>>individual STIX files and passing as a binary blob to the other side is
>>not an option.
>>
>>There are many other scenarios, so hopefully this narrow example
>>suffices to convey the concepts.
>>
>>I have not attempted to build an actual reference implementation, but I
>>can envision how one would approach this with nested STIX packages.
>>How would one approach this without nesting?
>>
>>Patrick Maroney
>>Office: (856)983-0001
>>Cell: (609)841-5104
>>[hidden email]
>>________________________________________
>>From: Grobauer, Bernd <[hidden email]>
>>Sent: Thursday, February 26, 2015 8:02:19 AM
>>To: [hidden email]
>>Subject: Re: [STIX] Reaching final consensus on the Report Object
>>proposal for the STIX 1.2 release
>>
>>Hi,
>>
>>I am completely with Aharon on this one: we have enough complexity as
>>it is ...
>>
>>+1 reports cannot embed
>>+1 packages cannot nest
>>
>>Kind regards,
>>
>>Bernd
>>
>>
>>> -----Original Message-----
>>> From: Aharon Chernin [mailto:[hidden email]]
>>> Sent: Mittwoch, 25. Februar 2015 19:47
>>> To: [hidden email]
>>> Subject: Re: [STIX] Reaching final consensus on the Report Object
>>> proposal for the STIX 1.2 release
>>>
>>> Optionality increases complexity and increases chance of error.
>>> Imagine receiving a document with nested STIX packages, with report
>>> objects that contain inline data, that also have report objects that
>>> reference data somewhere else within other nested packages.
>>>
>>> Due to this flexibility, one of the issues with stix package is that
>>> it's easy to use incorrectly. By elimating nested packages and inline
>>> stix content within the report object we can reduce some of this
>>> complexity. I am all for removing complexity.
>>>
>>> +1 reports cannot embed
>>> +1 packages cannot nest
>>>
>>> Like I said on the community call, I can go either way on this.
>>>
>>> Aharon
>>>
>>> Sent using OWA for iPhone
>>> ________________________________
>>> From: Barnum, Sean D. <[hidden email]>
>>> Sent: Wednesday, February 25, 2015 12:55:14 PM
>>> To: [hidden email]
>>> Subject: [STIX] Reaching final consensus on the Report Object
>>> proposal for the STIX 1.2 release
>>>
>>> Everyone,
>>>
>>> Back in December we sent out a refined proposal for the Report Object
>>> including two sub-proposals on fine details in an attempt to reach
>>> final consensus on what will go into the STIX 1.2 release.
>>>
>>> The three relevant proposals are:
>>>
>>>
>>>      Implement Report
>>> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>> Implement-Report-Object> - note that this is not about whether to
>>> implement the report object but how to implement the report object
>>>
>>> o   Reports Cannot Embed
>>> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>> Reports-Cannot-Embed-Content> - this issue was large enough that we
>>> split it into a separate topic
>>>
>>> o   Packages Cannot Contain Other
>>> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
>>> that we split it into a separate topic
>>>
>>>
>>> We received a limited amount of feedback on the list in regards to
>>> the two sub-proposals but all of it voiced opinions that for the STIX
>>> 1.2 release both sub-proposals should be rejected. In other words,
>>> +STIX
>>> 1.2 should allow content to be embedded within the new Report Object
>>> and that Packages (while stripped of their contextual fields that
>>> will be moved to the new Report Object) should be allowed to contain
>>> other Packages.
>>> The same opinion on the two sub-proposals was also strongly expressed
>>> by various community stakeholders off the list and directly to the
>>> STIX team via [hidden email]<mailto:[hidden email]>. These players
>>> expressed clear opposition to the broader Report Object proposal both
>>> on the list and off. However, they expressed a willingness to
>>> compromise and accept the broader Report Object proposal given the
>>> apparent consensus rejection of the sub-proposals.
>>>
>>> These sub-proposals and their apparent consensus rejection was a
>>> topic of conversation on last week's STIX community call.
>>> The first sub-proposal discussed was regarding the embedding of
>>> content within Report Objects. A couple of community members on the
>>> call expressed that while they would prefer that embedding not be
>>> allowed, they were willing to compromise and not contest the point in
>>> order to move the community forward.
>>> The second sub-proposal discussed was regarding the ability of
>>> Packages to contain other Packages. On this point, several members
>>> expressed concern on the call that had not been raised as feedback on the list.
>>> In a nutshell, a belief was expressed that nesting packages may bring
>>> significantly more complexity while others assert that the capability
>>> already exists in STIX (it is not adding something new) and given the
>>> newly limited context for Packages (based on the new Report Object)
>>> the difference in complexity is actually rather minimal. Based on the
>>> comments, it appears that we have not yet actually reached consensus
>>> on this point and that more discussion may need to occur on the list.
>>> If you have clear opinions one way or the other (this includes those
>>> who spoke up on the call), please express them on the list so that we
>>> can nail this down and move forward on our activity for the 1.2 release.
>>>
>>> Thanks,
>>> Sean Barnum
>>> STIX Project Team
>>>
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Wunder, John A.
I just wanted to send a quick clarification of the difference between package and report in the new version of STIX:

* A Package is a wrapper used to convey STIX content. It is NOT used to represent context about the content included in it other than simple data markings and information source. The old Title, Description, and Package_Intent fields are deprecated and should not be used.

* A Report is a construct used to express context amongst the various STIX content that it references (or, if the embedding proposal is accepted, embeds): components like TTPs, Indicators, Campaigns, and even other Reports. To that extent Reports CAN contain other Reports even if the package-in-another-package proposal is rejected, so if you have cases where you want to create nested groupings of context (i.e. a main Report with several sections also represented as reports) you can do so.

* One particular use case (as expressed to me) for nesting packages in other packages is in cases where you have a federated query, in particular with signed content. In those cases, the middleware layer that's passing on the query results from the targets and consolidating them for return to the initiating client can either embed the results as-is (i.e. embed the packages from the targets in the package that they're creating) or strip out the extra package layer from the targets and stick everything directly in the package that they're creating. The former is somewhat easier because you don't have to recalculate package-level data markings or information source constructs and, in particular for digital signatures once STIX supports them, can ensure that the signed content doesn't change and therefore invalidate signatures. I'm not saying that's the only use case for nested packages, but it's the one I've heard.

Hope that helps,
John

>-----Original Message-----
>From: Jerome Athias [mailto:[hidden email]]
>Sent: Thursday, February 26, 2015 1:54 PM
>To: stix-discussion-list Structured Threat Information Expression/ST
>Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for
>the STIX 1.2 release
>
>Ok, why not trying with an analogy. (I hope you guys like French cuisine :p)
>
>We do have ingredients (Packages, or would this be Objects*?) in the kitchen
>We need multiple recipes (individual Reports, or would this be Packages*)
>We want to eat a good meal (final Report ((maybe the full Menu)))
>
>
>
>2015-02-26 19:24 GMT+01:00  <[hidden email]>:
>> It might help the community if we went through some of the concerns with
>embedding at the Package level and/or Report level.
>>
>> Originally, without the inclusion of the Report Object, STIX allowed Packages
>to embed other packages.
>>
>> The Report Object allows the embedding of other Reports.
>>
>> Through the inclusion of the Report proposal we now have two ways to
>embed entire content/context into a document (at the Package level and/or
>at the Report level).
>>
>> This overlap in capability has sparked some concern with  members of the
>Community. While this would increase the complexity for members trying to
>address both embedding methods, I think we address the need for this
>complexity by answering the question "Why".
>>
>> Why would someone embed at the Package level rather than the Report
>level or vice-versa (besides the fact that the schema would allow them to do
>so)?
>>
>> Put another way, Does 1 Package with 10 embedded Packages mean
>something different from 1 Report with 10 embedded reports? (We're not
>even going to look into the possible matrix of embedded Packages containing
>embedded Reports) I think answering this question would bring to the
>necessity of both methods to light, then we can decide which if any is needed.
>>
>> Note: the word 'embed' could be replaced with 'relate'.
>>
>> -Marlon
>> -----Original Message-----
>> From: Joep Gommers [mailto:[hidden email]]
>> Sent: Thursday, February 26, 2015 11:41 AM
>> To: [hidden email]
>> Subject: Re: [STIX] Reaching final consensus on the Report Object proposal
>for the STIX 1.2 release
>>
>> Disclaimer: i¹m not apposed to nesting, yet:
>>
>> Since STIX_Packages are simply non-substantive wrappers of actual STIX
>entities, how would sending one STIX_Package containing others be different
>then sending a 100 STIX_Packages - other then overhead?
>>
>> We do a similar thing, but the de-composing and re-composing of entities
>and their relationships, would (in our case, but like to understand yours) not
>require anything the STIX_Package (as a non-substantive wrapper) has to
>offer.
>>
>> Best regards,
>> Joep
>>
>>
>>
>>
>> On 2/26/15, 6:30 PM, "Patrick Maroney" <[hidden email]>
>wrote:
>>
>>>I know we're looking for up or down at this point, but wanted to ask a
>>>clarifying question from those opposed to nesting (in particular when
>>>those expressing same are highly respected and contribute a lot to our
>>>"thing").
>>>
>>>Caveats:
>>>
>>>1) Hope the following is reasonably clear.
>>>
>>>2) There are many Worldviews and each is valid.  "Our" primary
>>>worldview is that any externally exposed TAXII Gateways should only
>>>provide for the reliable transport and distribution of ephemeral STIX
>>>packages.  From a security architecture perspective, all externally
>>>facing services, the assets supporting them, and any data stored on
>>>same must be considered at high risk of compromise over time (exposure
>>>and integrity).  Therefore, all Cyber-Intelligence data should only be
>>>stored on any externally exposed TAXII Gateways for as long as is
>>>required to assemble and ensure delivery to all recipients.  Presuming
>>>best practices of sending event logging to central log management
>>>facility are follwed, a Stateless Model is established that empowers
>>>the use of automated provisioning systems to periodically revert high risk
>systems back to a known good state.
>>>
>>>Use Case:
>>>
>>>I have a real-life challenge right now with integration of a third
>>>party tool.  This tool uses a graph-like internal data model.  When
>>>extracting from any given node one specifies the maximum depth of
>>>relations to traverse and maximum number of objects.  It decomposes the
>>>graph of all related objects into multiple STIX packages of individual
>>>objects with external references to related objects.
>>>
>>>So I end up with a folder with 100's of inter-related STIX packages
>>>that I need to wrap in a single STIX container that describes/conveys
>>>the global attributes and broader context, in aggregate, of the package
>>>and it's individual elements.
>>>
>>>The ultimate objective is to extract the multi-dimensional model to the
>>>depth specified, transform into two dimensional STIX XML, transport it
>>>via TAXII, transform, and then join the vertices and edges with the
>>>target's unique data instantiation of the same multi-dimensional model.
>>>
>>>There are future extensions to this use case where individual classes
>>>of objects are routed to methods specific to that class, but where the
>>>global attributes and broader context need to be passed, maintained,
>>>and returned with the method results.
>>>
>>>For example Transitive Tokenization processes that maintain form
>>>([hidden email] ==>  [hidden email]), convey statistically
>>>viable meaning for Analytics, while also ensuring redaction of
>>>attributional data will require differing methods and workflows (i.e.,
>>>external sharing of Tokenized Credit Card, Social Security numbers,
>>>etc. may all get routed to different organizations and review/approval
>processes).
>>>
>>>We would want to immediately share actionable intelligence for classes
>>>of data that do not require vetting.  Then as each class completes it's
>>>unique workflow, it can be passed on with referential integrity to the
>>>original global package and the individual sub-packages.
>>>
>>>...So taking the simplistic approach of zipping up the 100's of
>>>individual STIX files and passing as a binary blob to the other side is
>>>not an option.
>>>
>>>There are many other scenarios, so hopefully this narrow example
>>>suffices to convey the concepts.
>>>
>>>I have not attempted to build an actual reference implementation, but I
>>>can envision how one would approach this with nested STIX packages.
>>>How would one approach this without nesting?
>>>
>>>Patrick Maroney
>>>Office: (856)983-0001
>>>Cell: (609)841-5104
>>>[hidden email]
>>>________________________________________
>>>From: Grobauer, Bernd <[hidden email]>
>>>Sent: Thursday, February 26, 2015 8:02:19 AM
>>>To: [hidden email]
>>>Subject: Re: [STIX] Reaching final consensus on the Report Object
>>>proposal for the STIX 1.2 release
>>>
>>>Hi,
>>>
>>>I am completely with Aharon on this one: we have enough complexity as
>>>it is ...
>>>
>>>+1 reports cannot embed
>>>+1 packages cannot nest
>>>
>>>Kind regards,
>>>
>>>Bernd
>>>
>>>
>>>> -----Original Message-----
>>>> From: Aharon Chernin [mailto:[hidden email]]
>>>> Sent: Mittwoch, 25. Februar 2015 19:47
>>>> To: [hidden email]
>>>> Subject: Re: [STIX] Reaching final consensus on the Report Object
>>>> proposal for the STIX 1.2 release
>>>>
>>>> Optionality increases complexity and increases chance of error.
>>>> Imagine receiving a document with nested STIX packages, with report
>>>> objects that contain inline data, that also have report objects that
>>>> reference data somewhere else within other nested packages.
>>>>
>>>> Due to this flexibility, one of the issues with stix package is that
>>>> it's easy to use incorrectly. By elimating nested packages and inline
>>>> stix content within the report object we can reduce some of this
>>>> complexity. I am all for removing complexity.
>>>>
>>>> +1 reports cannot embed
>>>> +1 packages cannot nest
>>>>
>>>> Like I said on the community call, I can go either way on this.
>>>>
>>>> Aharon
>>>>
>>>> Sent using OWA for iPhone
>>>> ________________________________
>>>> From: Barnum, Sean D. <[hidden email]>
>>>> Sent: Wednesday, February 25, 2015 12:55:14 PM
>>>> To: [hidden email]
>>>> Subject: [STIX] Reaching final consensus on the Report Object
>>>> proposal for the STIX 1.2 release
>>>>
>>>> Everyone,
>>>>
>>>> Back in December we sent out a refined proposal for the Report Object
>>>> including two sub-proposals on fine details in an attempt to reach
>>>> final consensus on what will go into the STIX 1.2 release.
>>>>
>>>> The three relevant proposals are:
>>>>
>>>>
>>>>      Implement Report
>>>> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>>> Implement-Report-Object> - note that this is not about whether to
>>>> implement the report object but how to implement the report object
>>>>
>>>> o   Reports Cannot Embed
>>>> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>>> Reports-Cannot-Embed-Content> - this issue was large enough that we
>>>> split it into a separate topic
>>>>
>>>> o   Packages Cannot Contain Other
>>>> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>>> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
>>>> that we split it into a separate topic
>>>>
>>>>
>>>> We received a limited amount of feedback on the list in regards to
>>>> the two sub-proposals but all of it voiced opinions that for the STIX
>>>> 1.2 release both sub-proposals should be rejected. In other words,
>>>> +STIX
>>>> 1.2 should allow content to be embedded within the new Report Object
>>>> and that Packages (while stripped of their contextual fields that
>>>> will be moved to the new Report Object) should be allowed to contain
>>>> other Packages.
>>>> The same opinion on the two sub-proposals was also strongly expressed
>>>> by various community stakeholders off the list and directly to the
>>>> STIX team via [hidden email]<mailto:[hidden email]>. These players
>>>> expressed clear opposition to the broader Report Object proposal both
>>>> on the list and off. However, they expressed a willingness to
>>>> compromise and accept the broader Report Object proposal given the
>>>> apparent consensus rejection of the sub-proposals.
>>>>
>>>> These sub-proposals and their apparent consensus rejection was a
>>>> topic of conversation on last week's STIX community call.
>>>> The first sub-proposal discussed was regarding the embedding of
>>>> content within Report Objects. A couple of community members on the
>>>> call expressed that while they would prefer that embedding not be
>>>> allowed, they were willing to compromise and not contest the point in
>>>> order to move the community forward.
>>>> The second sub-proposal discussed was regarding the ability of
>>>> Packages to contain other Packages. On this point, several members
>>>> expressed concern on the call that had not been raised as feedback on
>the list.
>>>> In a nutshell, a belief was expressed that nesting packages may bring
>>>> significantly more complexity while others assert that the capability
>>>> already exists in STIX (it is not adding something new) and given the
>>>> newly limited context for Packages (based on the new Report Object)
>>>> the difference in complexity is actually rather minimal. Based on the
>>>> comments, it appears that we have not yet actually reached consensus
>>>> on this point and that more discussion may need to occur on the list.
>>>> If you have clear opinions one way or the other (this includes those
>>>> who spoke up on the call), please express them on the list so that we
>>>> can nail this down and move forward on our activity for the 1.2 release.
>>>>
>>>> Thanks,
>>>> Sean Barnum
>>>> STIX Project Team
>>>>
>>>>
>>>>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Reaching final consensus on the Report Object proposal for the STIX 1.2 release

Trey Darley-3

Hey, John -

I hadn't considered nested packages vis-a-vis crypto sigs. In hindsight, that's an obvious use case.

Can I anticipate some form of (carbon¦silicon) flag or do I need to continue agitating for that?

Cheers,
Trey
--
Trey Darley, CISSP
Senior Security Engineer
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
++----------------------------------------------------------------------------++
Sent from my CRM-114 Discriminator

On Feb 26, 2015 9:34 PM, "Wunder, John A." <[hidden email]> wrote:
I just wanted to send a quick clarification of the difference between package and report in the new version of STIX:

* A Package is a wrapper used to convey STIX content. It is NOT used to represent context about the content included in it other than simple data markings and information source. The old Title, Description, and Package_Intent fields are deprecated and should not be used.

* A Report is a construct used to express context amongst the various STIX content that it references (or, if the embedding proposal is accepted, embeds): components like TTPs, Indicators, Campaigns, and even other Reports. To that extent Reports CAN contain other Reports even if the package-in-another-package proposal is rejected, so if you have cases where you want to create nested groupings of context (i.e. a main Report with several sections also represented as reports) you can do so.

* One particular use case (as expressed to me) for nesting packages in other packages is in cases where you have a federated query, in particular with signed content. In those cases, the middleware layer that's passing on the query results from the targets and consolidating them for return to the initiating client can either embed the results as-is (i.e. embed the packages from the targets in the package that they're creating) or strip out the extra package layer from the targets and stick everything directly in the package that they're creating. The former is somewhat easier because you don't have to recalculate package-level data markings or information source constructs and, in particular for digital signatures once STIX supports them, can ensure that the signed content doesn't change and therefore invalidate signatures. I'm not saying that's the only use case for nested packages, but it's the one I've heard.

Hope that helps,
John

>-----Original Message-----
>From: Jerome Athias [[hidden email]]
>Sent: Thursday, February 26, 2015 1:54 PM
>To: stix-discussion-list Structured Threat Information Expression/ST
>Subject: Re: [STIX] Reaching final consensus on the Report Object proposal for
>the STIX 1.2 release
>
>Ok, why not trying with an analogy. (I hope you guys like French cuisine :p)
>
>We do have ingredients (Packages, or would this be Objects*?) in the kitchen
>We need multiple recipes (individual Reports, or would this be Packages*)
>We want to eat a good meal (final Report ((maybe the full Menu)))
>
>
>
>2015-02-26 19:24 GMT+01:00  <[hidden email]>:
>> It might help the community if we went through some of the concerns with
>embedding at the Package level and/or Report level.
>>
>> Originally, without the inclusion of the Report Object, STIX allowed Packages
>to embed other packages.
>>
>> The Report Object allows the embedding of other Reports.
>>
>> Through the inclusion of the Report proposal we now have two ways to
>embed entire content/context into a document (at the Package level and/or
>at the Report level).
>>
>> This overlap in capability has sparked some concern with  members of the
>Community. While this would increase the complexity for members trying to
>address both embedding methods, I think we address the need for this
>complexity by answering the question "Why".
>>
>> Why would someone embed at the Package level rather than the Report
>level or vice-versa (besides the fact that the schema would allow them to do
>so)?
>>
>> Put another way, Does 1 Package with 10 embedded Packages mean
>something different from 1 Report with 10 embedded reports? (We're not
>even going to look into the possible matrix of embedded Packages containing
>embedded Reports) I think answering this question would bring to the
>necessity of both methods to light, then we can decide which if any is needed.
>>
>> Note: the word 'embed' could be replaced with 'relate'.
>>
>> -Marlon
>> -----Original Message-----
>> From: Joep Gommers [[hidden email]]
>> Sent: Thursday, February 26, 2015 11:41 AM
>> To: [hidden email]
>> Subject: Re: [STIX] Reaching final consensus on the Report Object proposal
>for the STIX 1.2 release
>>
>> Disclaimer: i¹m not apposed to nesting, yet:
>>
>> Since STIX_Packages are simply non-substantive wrappers of actual STIX
>entities, how would sending one STIX_Package containing others be different
>then sending a 100 STIX_Packages - other then overhead?
>>
>> We do a similar thing, but the de-composing and re-composing of entities
>and their relationships, would (in our case, but like to understand yours) not
>require anything the STIX_Package (as a non-substantive wrapper) has to
>offer.
>>
>> Best regards,
>> Joep
>>
>>
>>
>>
>> On 2/26/15, 6:30 PM, "Patrick Maroney" <[hidden email]>
>wrote:
>>
>>>I know we're looking for up or down at this point, but wanted to ask a
>>>clarifying question from those opposed to nesting (in particular when
>>>those expressing same are highly respected and contribute a lot to our
>>>"thing").
>>>
>>>Caveats:
>>>
>>>1) Hope the following is reasonably clear.
>>>
>>>2) There are many Worldviews and each is valid.  "Our" primary
>>>worldview is that any externally exposed TAXII Gateways should only
>>>provide for the reliable transport and distribution of ephemeral STIX
>>>packages.  From a security architecture perspective, all externally
>>>facing services, the assets supporting them, and any data stored on
>>>same must be considered at high risk of compromise over time (exposure
>>>and integrity).  Therefore, all Cyber-Intelligence data should only be
>>>stored on any externally exposed TAXII Gateways for as long as is
>>>required to assemble and ensure delivery to all recipients.  Presuming
>>>best practices of sending event logging to central log management
>>>facility are follwed, a Stateless Model is established that empowers
>>>the use of automated provisioning systems to periodically revert high risk
>systems back to a known good state.
>>>
>>>Use Case:
>>>
>>>I have a real-life challenge right now with integration of a third
>>>party tool.  This tool uses a graph-like internal data model.  When
>>>extracting from any given node one specifies the maximum depth of
>>>relations to traverse and maximum number of objects.  It decomposes the
>>>graph of all related objects into multiple STIX packages of individual
>>>objects with external references to related objects.
>>>
>>>So I end up with a folder with 100's of inter-related STIX packages
>>>that I need to wrap in a single STIX container that describes/conveys
>>>the global attributes and broader context, in aggregate, of the package
>>>and it's individual elements.
>>>
>>>The ultimate objective is to extract the multi-dimensional model to the
>>>depth specified, transform into two dimensional STIX XML, transport it
>>>via TAXII, transform, and then join the vertices and edges with the
>>>target's unique data instantiation of the same multi-dimensional model.
>>>
>>>There are future extensions to this use case where individual classes
>>>of objects are routed to methods specific to that class, but where the
>>>global attributes and broader context need to be passed, maintained,
>>>and returned with the method results.
>>>
>>>For example Transitive Tokenization processes that maintain form
>>>([hidden email] ==>  [hidden email]), convey statistically
>>>viable meaning for Analytics, while also ensuring redaction of
>>>attributional data will require differing methods and workflows (i.e.,
>>>external sharing of Tokenized Credit Card, Social Security numbers,
>>>etc. may all get routed to different organizations and review/approval
>processes).
>>>
>>>We would want to immediately share actionable intelligence for classes
>>>of data that do not require vetting.  Then as each class completes it's
>>>unique workflow, it can be passed on with referential integrity to the
>>>original global package and the individual sub-packages.
>>>
>>>...So taking the simplistic approach of zipping up the 100's of
>>>individual STIX files and passing as a binary blob to the other side is
>>>not an option.
>>>
>>>There are many other scenarios, so hopefully this narrow example
>>>suffices to convey the concepts.
>>>
>>>I have not attempted to build an actual reference implementation, but I
>>>can envision how one would approach this with nested STIX packages.
>>>How would one approach this without nesting?
>>>
>>>Patrick Maroney
>>>Office: (856)983-0001
>>>Cell: (609)841-5104
>>>[hidden email]
>>>________________________________________
>>>From: Grobauer, Bernd <[hidden email]>
>>>Sent: Thursday, February 26, 2015 8:02:19 AM
>>>To: [hidden email]
>>>Subject: Re: [STIX] Reaching final consensus on the Report Object
>>>proposal for the STIX 1.2 release
>>>
>>>Hi,
>>>
>>>I am completely with Aharon on this one: we have enough complexity as
>>>it is ...
>>>
>>>+1 reports cannot embed
>>>+1 packages cannot nest
>>>
>>>Kind regards,
>>>
>>>Bernd
>>>
>>>
>>>> -----Original Message-----
>>>> From: Aharon Chernin [[hidden email]]
>>>> Sent: Mittwoch, 25. Februar 2015 19:47
>>>> To: [hidden email]
>>>> Subject: Re: [STIX] Reaching final consensus on the Report Object
>>>> proposal for the STIX 1.2 release
>>>>
>>>> Optionality increases complexity and increases chance of error.
>>>> Imagine receiving a document with nested STIX packages, with report
>>>> objects that contain inline data, that also have report objects that
>>>> reference data somewhere else within other nested packages.
>>>>
>>>> Due to this flexibility, one of the issues with stix package is that
>>>> it's easy to use incorrectly. By elimating nested packages and inline
>>>> stix content within the report object we can reduce some of this
>>>> complexity. I am all for removing complexity.
>>>>
>>>> +1 reports cannot embed
>>>> +1 packages cannot nest
>>>>
>>>> Like I said on the community call, I can go either way on this.
>>>>
>>>> Aharon
>>>>
>>>> Sent using OWA for iPhone
>>>> ________________________________
>>>> From: Barnum, Sean D. <[hidden email]>
>>>> Sent: Wednesday, February 25, 2015 12:55:14 PM
>>>> To: [hidden email]
>>>> Subject: [STIX] Reaching final consensus on the Report Object
>>>> proposal for the STIX 1.2 release
>>>>
>>>> Everyone,
>>>>
>>>> Back in December we sent out a refined proposal for the Report Object
>>>> including two sub-proposals on fine details in an attempt to reach
>>>> final consensus on what will go into the STIX 1.2 release.
>>>>
>>>> The three relevant proposals are:
>>>>
>>>>
>>>>      Implement Report
>>>> Object<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>>> Implement-Report-Object> - note that this is not about whether to
>>>> implement the report object but how to implement the report object
>>>>
>>>> o   Reports Cannot Embed
>>>> Content<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>>> Reports-Cannot-Embed-Content> - this issue was large enough that we
>>>> split it into a separate topic
>>>>
>>>> o   Packages Cannot Contain Other
>>>> Packages<https://github.com/STIXProject/schemas/wiki/Proposal%3A-
>>>> Packages-Cannot-Contain-Other-Packages> - this issue was large enough
>>>> that we split it into a separate topic
>>>>
>>>>
>>>> We received a limited amount of feedback on the list in regards to
>>>> the two sub-proposals but all of it voiced opinions that for the STIX
>>>> 1.2 release both sub-proposals should be rejected. In other words,
>>>> +STIX
>>>> 1.2 should allow content to be embedded within the new Report Object
>>>> and that Packages (while stripped of their contextual fields that
>>>> will be moved to the new Report Object) should be allowed to contain
>>>> other Packages.
>>>> The same opinion on the two sub-proposals was also strongly expressed
>>>> by various community stakeholders off the list and directly to the
>>>> STIX team via [hidden email]<[hidden email]>. These players
>>>> expressed clear opposition to the broader Report Object proposal both
>>>> on the list and off. However, they expressed a willingness to
>>>> compromise and accept the broader Report Object proposal given the
>>>> apparent consensus rejection of the sub-proposals.
>>>>
>>>> These sub-proposals and their apparent consensus rejection was a
>>>> topic of conversation on last week's STIX community call.
>>>> The first sub-proposal discussed was regarding the embedding of
>>>> content within Report Objects. A couple of community members on the
>>>> call expressed that while they would prefer that embedding not be
>>>> allowed, they were willing to compromise and not contest the point in
>>>> order to move the community forward.
>>>> The second sub-proposal discussed was regarding the ability of
>>>> Packages to contain other Packages. On this point, several members
>>>> expressed concern on the call that had not been raised as feedback on
>the list.
>>>> In a nutshell, a belief was expressed that nesting packages may bring
>>>> significantly more complexity while others assert that the capability
>>>> already exists in STIX (it is not adding something new) and given the
>>>> newly limited context for Packages (based on the new Report Object)
>>>> the difference in complexity is actually rather minimal. Based on the
>>>> comments, it appears that we have not yet actually reached consensus
>>>> on this point and that more discussion may need to occur on the list.
>>>> If you have clear opinions one way or the other (this includes those
>>>> who spoke up on the call), please express them on the list so that we
>>>> can nail this down and move forward on our activity for the 1.2 release.
>>>>
>>>> Thanks,
>>>> Sean Barnum
>>>> STIX Project Team
>>>>
>>>>
>>>>
123