[STIX] Exploring Alternatives to Proposed Report Object

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

[STIX] Exploring Alternatives to Proposed Report Object

Smith, Pamela A.

Hello.  This is my first posting to the discussion group but I have been lurking for a while.   I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.   I wanted to raise an issue to this discussion group and I’m hoping that those who have already created STIX-based solutions will weigh in.

 

I understand that, given this is a minor release, STIX 1.2 will maintain backwards compatibility and that the cascading changes that result from the proposed new object, Report, will not *yet* be deprecated.   My point is not whether or not 1.2 is backwards compatible (a short-term issue) but the impact that the addition of this new object will eventually have on those who have already deployed STIX systems.  There are two potential outcomes:

 

(1) Backwards compatibility is maintained and a bifurcation of the standard exists where one group of apps will use Report and others will not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual deprecation of a number of STIX elements/capabilities that a number of early-STIX-adopters are counting on.

 

I’m going to assume that the first outcome is not desired by anyone.   So this discussion is *not* about 1.2 but is about the addition of the Report object and the resulting eventual deprecation of existing STIX elements and the embedded content construct.

 

So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.  Obviously, some changes are so compelling that re-write is necessary but we should always strive to look for alternatives before we break backwards compatibility.   (I know STIX is not a standard yet but for all intents and purposes….)  Creating a fundamental change in the STIX format incurs significant rewrite costs to the organizations that have adopted STIX and reduces the adoption rate of new organizations because they do not want to spend resources working towards a standard that is still going through large changes.  Implementing the Report object will slow the adoption of STIX and result in a step backwards for organizations that have already implemented STIX.  Resources that could be spent building new TAXII and STIX capabilities must now be spent rewriting existing capabilities to adhere to this standards change.

 

The Report object was proposed to accommodate the following problem with STIX:   Consumers may misinterpret the contextual grouping within a STIX package because sometimes there is a contextual grouping and sometimes there is not and there is no way to tell when there is and isn’t.   The code required to handle the dual purposes is more complex than it needs to be.

 

I am of the opinion that (-) there is no compelling reason to add the Reports object because the above problem could be solved in a manner that is less destructive to the existing standard and (-) the addition of the Report object actually results in loss of capability.

 

Loss of Capability:

By separating context into the Report object we are increasing the amount of work necessary for a producer to share additional information.  We are basically encouraging a producer to only share indicators and observables unless they have a significant body of knowledge that warrants the creation of a report object and the associated references between the report object and the STIX package.

The advantage of STIX over previously developed standards was that it provided a rich set of context attached to content.  The creation of the Report object greatly reduces this asset of STIX by adding complexity to read and write contextual information. 

 

Let’s posit a use case that involves cyber threat reporting about large topics (i.e. a country) which focuses on a number of facets about this large topic (i.e. cyber infrastructure, known actors, government agencies).  To share this large topic, we want to push ONE STIX document, with multiple STIX packages, to ensure that the entire scope of the reporting is self-contained and relationships and history are not lost should the receiver miss a transmission.   We also want to be able to keep track of this information collection as a single tracked entity because that is how it is tracked internally.    Those who are pushing for the Report object, can still support all of their use cases without the Report object.  While we understand that others may not have our use case, please know that with the Report object, you have removed our ability to support this use case.     (Although I understand rejecting proposal https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content  has potential to partially mitigate this).

 

Less Destructive Options:

In terms of examining other options (to the Report object), we believe the following options should be examined much more thoroughly before such a major change is made:

 

(A) create a STIX profile for report objects instead of trying to redesign the entire spec to fit this one use case. The evolution and development of each of the other STIX profiles did not involve pushes to redesign STIX and inadequate research has been made into why that cannot be done in this case.

 

(B) If the need is to distinguish between a STIX package with or without contextual grouping, the addition of a flag that states whether or not contextual-grouping=true is much less destructive to backwards compatibility than the Report object.

 

Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Aharon Chernin

> I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups. 


STIX is a community driven specification. To make sure we don't have these issues in the future, your clients should explore ways to participate in whatever type of voting processes we have.


> So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.


In general, I agree with this assertion when the standard has been put into operation through running code. During our early report object debates ( over a year ago ), there was such little operational STIX code that it didn't make sense to force us to find ways around the report object. To me it feels like we were moving from classroom theory to real world operations and discovering that the theory and operations didn't quite match up.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Smith, Pamela A. <[hidden email]>
Sent: Thursday, January 29, 2015 11:40 AM
To: [hidden email]
Subject: [STIX] Exploring Alternatives to Proposed Report Object
 

Hello.  This is my first posting to the discussion group but I have been lurking for a while.   I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.   I wanted to raise an issue to this discussion group and I’m hoping that those who have already created STIX-based solutions will weigh in.

 

I understand that, given this is a minor release, STIX 1.2 will maintain backwards compatibility and that the cascading changes that result from the proposed new object, Report, will not *yet* be deprecated.   My point is not whether or not 1.2 is backwards compatible (a short-term issue) but the impact that the addition of this new object will eventually have on those who have already deployed STIX systems.  There are two potential outcomes:

 

(1) Backwards compatibility is maintained and a bifurcation of the standard exists where one group of apps will use Report and others will not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual deprecation of a number of STIX elements/capabilities that a number of early-STIX-adopters are counting on.

 

I’m going to assume that the first outcome is not desired by anyone.   So this discussion is *not* about 1.2 but is about the addition of the Report object and the resulting eventual deprecation of existing STIX elements and the embedded content construct.

 

So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.  Obviously, some changes are so compelling that re-write is necessary but we should always strive to look for alternatives before we break backwards compatibility.   (I know STIX is not a standard yet but for all intents and purposes….)  Creating a fundamental change in the STIX format incurs significant rewrite costs to the organizations that have adopted STIX and reduces the adoption rate of new organizations because they do not want to spend resources working towards a standard that is still going through large changes.  Implementing the Report object will slow the adoption of STIX and result in a step backwards for organizations that have already implemented STIX.  Resources that could be spent building new TAXII and STIX capabilities must now be spent rewriting existing capabilities to adhere to this standards change.

 

The Report object was proposed to accommodate the following problem with STIX:   Consumers may misinterpret the contextual grouping within a STIX package because sometimes there is a contextual grouping and sometimes there is not and there is no way to tell when there is and isn’t.   The code required to handle the dual purposes is more complex than it needs to be.

 

I am of the opinion that (-) there is no compelling reason to add the Reports object because the above problem could be solved in a manner that is less destructive to the existing standard and (-) the addition of the Report object actually results in loss of capability.

 

Loss of Capability:

By separating context into the Report object we are increasing the amount of work necessary for a producer to share additional information.  We are basically encouraging a producer to only share indicators and observables unless they have a significant body of knowledge that warrants the creation of a report object and the associated references between the report object and the STIX package.

The advantage of STIX over previously developed standards was that it provided a rich set of context attached to content.  The creation of the Report object greatly reduces this asset of STIX by adding complexity to read and write contextual information. 

 

Let’s posit a use case that involves cyber threat reporting about large topics (i.e. a country) which focuses on a number of facets about this large topic (i.e. cyber infrastructure, known actors, government agencies).  To share this large topic, we want to push ONE STIX document, with multiple STIX packages, to ensure that the entire scope of the reporting is self-contained and relationships and history are not lost should the receiver miss a transmission.   We also want to be able to keep track of this information collection as a single tracked entity because that is how it is tracked internally.    Those who are pushing for the Report object, can still support all of their use cases without the Report object.  While we understand that others may not have our use case, please know that with the Report object, you have removed our ability to support this use case.     (Although I understand rejecting proposal https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content  has potential to partially mitigate this).

 

Less Destructive Options:

In terms of examining other options (to the Report object), we believe the following options should be examined much more thoroughly before such a major change is made:

 

(A) create a STIX profile for report objects instead of trying to redesign the entire spec to fit this one use case. The evolution and development of each of the other STIX profiles did not involve pushes to redesign STIX and inadequate research has been made into why that cannot be done in this case.

 

(B) If the need is to distinguish between a STIX package with or without contextual grouping, the addition of a flag that states whether or not contextual-grouping=true is much less destructive to backwards compatibility than the Report object.

 

Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Lavoie, Daniel J
In reply to this post by Smith, Pamela A.

+1, Thanks Pam.

 

I’ve had the pleasure of managing the development of an analysis and cyber defense information sharing system for 3 years.  We saw the value in community-adopted standardized/structured information sharing, but the constant updates (without backwards compatibility support) posed too much risk to ensure delivery of a fully functional system.  We (developers) recommended to not support STIX/MAEC/CYBOX for our project for almost 2 years because of the backwards compatibility issues, and our customer concurred.

 

STIX has since become more stable, and we decided to adopt.  We invested many, many months of development hours designing a new reporting capability that maintains our existing format AND provides a means to support standardized info sharing.

 

I have spoken with my peers about the deprecation issue, and we agree with Pam, and second her motion on the following:

 

1.       A standard should stay the same unless there is a compelling reason to change it.

2.       We should always strive to look for alternatives before we break backwards compatibility.

 

I ask the change control board members to consider the overall risk this poses to the standard, and the community members who have chosen to adopt it.  If backwards compatibility is broken, you’re going to cause teams to ask for a fork.  Many teams simply do not have the money or time to support yet-another redesign to support a single use case.

 

V/r,

 

Dan LaVoie

Project Manager

ManTech Int’l

 

From: Smith, Pamela A. [mailto:[hidden email]]
Sent: Thursday, January 29, 2015 10:40 AM
To: [hidden email]
Subject: [STIX] Exploring Alternatives to Proposed Report Object

 

Hello.  This is my first posting to the discussion group but I have been lurking for a while.   I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.   I wanted to raise an issue to this discussion group and I’m hoping that those who have already created STIX-based solutions will weigh in.

 

I understand that, given this is a minor release, STIX 1.2 will maintain backwards compatibility and that the cascading changes that result from the proposed new object, Report, will not *yet* be deprecated.   My point is not whether or not 1.2 is backwards compatible (a short-term issue) but the impact that the addition of this new object will eventually have on those who have already deployed STIX systems.  There are two potential outcomes:

 

(1) Backwards compatibility is maintained and a bifurcation of the standard exists where one group of apps will use Report and others will not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual deprecation of a number of STIX elements/capabilities that a number of early-STIX-adopters are counting on.

 

I’m going to assume that the first outcome is not desired by anyone.   So this discussion is *not* about 1.2 but is about the addition of the Report object and the resulting eventual deprecation of existing STIX elements and the embedded content construct.

 

So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.  Obviously, some changes are so compelling that re-write is necessary but we should always strive to look for alternatives before we break backwards compatibility.   (I know STIX is not a standard yet but for all intents and purposes….)  Creating a fundamental change in the STIX format incurs significant rewrite costs to the organizations that have adopted STIX and reduces the adoption rate of new organizations because they do not want to spend resources working towards a standard that is still going through large changes.  Implementing the Report object will slow the adoption of STIX and result in a step backwards for organizations that have already implemented STIX.  Resources that could be spent building new TAXII and STIX capabilities must now be spent rewriting existing capabilities to adhere to this standards change.

 

The Report object was proposed to accommodate the following problem with STIX:   Consumers may misinterpret the contextual grouping within a STIX package because sometimes there is a contextual grouping and sometimes there is not and there is no way to tell when there is and isn’t.   The code required to handle the dual purposes is more complex than it needs to be.

 

I am of the opinion that (-) there is no compelling reason to add the Reports object because the above problem could be solved in a manner that is less destructive to the existing standard and (-) the addition of the Report object actually results in loss of capability.

 

Loss of Capability:

By separating context into the Report object we are increasing the amount of work necessary for a producer to share additional information.  We are basically encouraging a producer to only share indicators and observables unless they have a significant body of knowledge that warrants the creation of a report object and the associated references between the report object and the STIX package.

The advantage of STIX over previously developed standards was that it provided a rich set of context attached to content.  The creation of the Report object greatly reduces this asset of STIX by adding complexity to read and write contextual information. 

 

Let’s posit a use case that involves cyber threat reporting about large topics (i.e. a country) which focuses on a number of facets about this large topic (i.e. cyber infrastructure, known actors, government agencies).  To share this large topic, we want to push ONE STIX document, with multiple STIX packages, to ensure that the entire scope of the reporting is self-contained and relationships and history are not lost should the receiver miss a transmission.   We also want to be able to keep track of this information collection as a single tracked entity because that is how it is tracked internally.    Those who are pushing for the Report object, can still support all of their use cases without the Report object.  While we understand that others may not have our use case, please know that with the Report object, you have removed our ability to support this use case.     (Although I understand rejecting proposal https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content  has potential to partially mitigate this).

 

Less Destructive Options:

In terms of examining other options (to the Report object), we believe the following options should be examined much more thoroughly before such a major change is made:

 

(A) create a STIX profile for report objects instead of trying to redesign the entire spec to fit this one use case. The evolution and development of each of the other STIX profiles did not involve pushes to redesign STIX and inadequate research has been made into why that cannot be done in this case.

 

(B) If the need is to distinguish between a STIX package with or without contextual grouping, the addition of a flag that states whether or not contextual-grouping=true is much less destructive to backwards compatibility than the Report object.

 

Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory




This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Katz, Gary
In reply to this post by Aharon Chernin
Aharon, Pam,
    Thanks for getting this conversation jumpstarted again.  The creation of the report object has been a concern for the organization that I support along with a number of the organizations that we share information with, so I appreciate the continued debate on the topic.  Aharon, as you mentioned, about a year ago there was little operational STIX code, but many organizations were working on building up capabilities during that time and have continued to build new systems based upon the STIX standard since then.  Making such a change will result in some significant rewrites.  

  I also agree with Pam's comment concerning contextual information.  The organizations I work with are trying to incentivize as much information sharing as possible, and not all organizations have the same level of sophistication as others.  By breaking out contextual information into a separate object it disincentives sharing of additional information.  One of the main advantages of STIX (for us) is to allow us to easily ingest significantly more information than what is currently being shared.  If we encourage only sharing indicators and observables, then we are putting ourselves at a disadvantage for defending against the evolving threats we are facing.


I appreciate your comment about getting Pam's clients to be able to participate in the voting process. I know that MITRE has a wide breadth in the organizations they interact with.  Perhaps they can be a conduit for capturing the votes of those clients.

-Gary
   

-----Original Message-----
From: Aharon Chernin [mailto:[hidden email]]
Sent: Thursday, January 29, 2015 12:29 PM
To: [hidden email]
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object

> I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.




STIX is a community driven specification. To make sure we don't have these issues in the future, your clients should explore ways to participate in whatever type of voting processes we have.





> So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.




In general, I agree with this assertion when the standard has been put into operation through running code. During our early report object debates ( over a year ago ), there was such little operational STIX code that it didn't make sense to force us to find ways around the report object. To me it feels like we were moving from classroom theory to real world operations and discovering that the theory and operations didn't quite match up.





Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

813.470.2173 | [hidden email] <mailto:[hidden email]> www.soltra.com <http://www.soltra.com> ________________________________

From: Smith, Pamela A. <[hidden email]>
Sent: Thursday, January 29, 2015 11:40 AM
To: [hidden email]
Subject: [STIX] Exploring Alternatives to Proposed Report Object
 

Hello.  This is my first posting to the discussion group but I have been lurking for a while.   I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.   I wanted to raise an issue to this discussion group and I'm hoping that those who have already created STIX-based solutions will weigh in.

 

I understand that, given this is a minor release, STIX 1.2 will maintain backwards compatibility and that the cascading changes that result from the proposed new object, Report, will not *yet* be deprecated.   My point is not whether or not 1.2 is backwards compatible (a short-term issue) but the impact that the addition of this new object will eventually have on those who have already deployed STIX systems.  There are two potential outcomes:

 

(1) Backwards compatibility is maintained and a bifurcation of the standard exists where one group of apps will use Report and others will not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual deprecation of a number of STIX elements/capabilities that a number of early-STIX-adopters are counting on.

 

I'm going to assume that the first outcome is not desired by anyone.   So this discussion is *not* about 1.2 but is about the addition of the Report object and the resulting eventual deprecation of existing STIX elements and the embedded content construct.

 

So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.  Obviously, some changes are so compelling that re-write is necessary but we should always strive to look for alternatives before we break backwards compatibility.   (I know STIX is not a standard yet but for all intents and purposes....)  Creating a fundamental change in the STIX format incurs significant rewrite costs to the organizations that have adopted STIX and reduces the adoption rate of new organizations because they do not want to spend resources working towards a standard that is still going through large changes.  Implementing the Report object will slow the adoption of STIX and result in a step backwards for organizations that have already implemented STIX.  Resources that could be spent building new TAXII and STIX capabilities must now be spent rewriting existing capabilities to adhere to this standards change.

 

The Report object was proposed to accommodate the following problem with STIX:   Consumers may misinterpret the contextual grouping within a STIX package because sometimes there is a contextual grouping and sometimes there is not and there is no way to tell when there is and isn't.   The code required to handle the dual purposes is more complex than it needs to be.

 

I am of the opinion that (-) there is no compelling reason to add the Reports object because the above problem could be solved in a manner that is less destructive to the existing standard and (-) the addition of the Report object actually results in loss of capability.

 

Loss of Capability:

By separating context into the Report object we are increasing the amount of work necessary for a producer to share additional information.  We are basically encouraging a producer to only share indicators and observables unless they have a significant body of knowledge that warrants the creation of a report object and the associated references between the report object and the STIX package.

The advantage of STIX over previously developed standards was that it provided a rich set of context attached to content.  The creation of the Report object greatly reduces this asset of STIX by adding complexity to read and write contextual information.  

 

Let's posit a use case that involves cyber threat reporting about large topics (i.e. a country) which focuses on a number of facets about this large topic (i.e. cyber infrastructure, known actors, government agencies).  To share this large topic, we want to push ONE STIX document, with multiple STIX packages, to ensure that the entire scope of the reporting is self-contained and relationships and history are not lost should the receiver miss a transmission.   We also want to be able to keep track of this information collection as a single tracked entity because that is how it is tracked internally.    Those who are pushing for the Report object, can still support all of their use cases without the Report object.  While we understand that others may not have our use case, please know that with the Report object, you have removed our ability to support this use case.     (Although I understand rejecting proposal https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content <https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content>   has potential to partially mitigate this).

 

Less Destructive Options:

In terms of examining other options (to the Report object), we believe the following options should be examined much more thoroughly before such a major change is made:

 

(A) create a STIX profile for report objects instead of trying to redesign the entire spec to fit this one use case. The evolution and development of each of the other STIX profiles did not involve pushes to redesign STIX and inadequate research has been made into why that cannot be done in this case.

 

(B) If the need is to distinguish between a STIX package with or without contextual grouping, the addition of a flag that states whether or not contextual-grouping=true is much less destructive to backwards compatibility than the Report object.

 

Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Joep Gommers
In reply to this post by Smith, Pamela A.
I would add that we¹re still in the very early days of adoption and
although it might cause pain now (us included), we have to deal with some
very serious issues (Report Object, Sightings Object) and frankly a
significant expansion of the Report Object as currently envisioned until
it can really serve most of the use-cases it would require too in the
following ~5 years. The earlier we deal with these, the better.

Not trying to be incentive here, I apologize if it sounds like it. But if
we¹re going to have STIX fuel this revolution - we have to deal with these
issues now IMO.

J-

On 1/29/15, 9:32 PM, "Katz, Gary Contractor DC3" <[hidden email]>
wrote:

>Aharon, Pam,
>    Thanks for getting this conversation jumpstarted again.  The creation
>of the report object has been a concern for the organization that I
>support along with a number of the organizations that we share
>information with, so I appreciate the continued debate on the topic.
>Aharon, as you mentioned, about a year ago there was little operational
>STIX code, but many organizations were working on building up
>capabilities during that time and have continued to build new systems
>based upon the STIX standard since then.  Making such a change will
>result in some significant rewrites.
>
>  I also agree with Pam's comment concerning contextual information.  The
>organizations I work with are trying to incentivize as much information
>sharing as possible, and not all organizations have the same level of
>sophistication as others.  By breaking out contextual information into a
>separate object it disincentives sharing of additional information.  One
>of the main advantages of STIX (for us) is to allow us to easily ingest
>significantly more information than what is currently being shared.  If
>we encourage only sharing indicators and observables, then we are putting
>ourselves at a disadvantage for defending against the evolving threats we
>are facing.
>
>
>I appreciate your comment about getting Pam's clients to be able to
>participate in the voting process. I know that MITRE has a wide breadth
>in the organizations they interact with.  Perhaps they can be a conduit
>for capturing the votes of those clients.
>
>-Gary
>  
>
>-----Original Message-----
>From: Aharon Chernin [mailto:[hidden email]]
>Sent: Thursday, January 29, 2015 12:29 PM
>To: [hidden email]
>Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object
>
>> I work with a number of clients who have embraced STIX and have working
>>systems.   These clients are unable to readily participate in discussion
>>groups.
>
>
>
>
>STIX is a community driven specification. To make sure we don't have
>these issues in the future, your clients should explore ways to
>participate in whatever type of voting processes we have.
>
>
>
>
>
>> So, let me start by proposing a fundamental rule for standards
>>maintenance.  A standard stays the same unless there is a compelling
>>reason to change it.
>
>
>
>
>In general, I agree with this assertion when the standard has been put
>into operation through running code. During our early report object
>debates ( over a year ago ), there was such little operational STIX code
>that it didn't make sense to force us to find ways around the report
>object. To me it feels like we were moving from classroom theory to real
>world operations and discovering that the theory and operations didn't
>quite match up.
>
>
>
>
>
>Aharon Chernin
>CTO
>
>SOLTRA | An FS-ISAC & DTCC Company
>18301 Bermuda green Dr
>Tampa, fl 33647
>
>813.470.2173 | [hidden email] <mailto:[hidden email]>
>www.soltra.com <http://www.soltra.com> ________________________________
>
>From: Smith, Pamela A. <[hidden email]>
>Sent: Thursday, January 29, 2015 11:40 AM
>To: [hidden email]
>Subject: [STIX] Exploring Alternatives to Proposed Report Object
>
>
>Hello.  This is my first posting to the discussion group but I have been
>lurking for a while.   I work with a number of clients who have embraced
>STIX and have working systems.   These clients are unable to readily
>participate in discussion groups.   I wanted to raise an issue to this
>discussion group and I'm hoping that those who have already created
>STIX-based solutions will weigh in.
>
>
>
>I understand that, given this is a minor release, STIX 1.2 will maintain
>backwards compatibility and that the cascading changes that result from
>the proposed new object, Report, will not *yet* be deprecated.   My point
>is not whether or not 1.2 is backwards compatible (a short-term issue)
>but the impact that the addition of this new object will eventually have
>on those who have already deployed STIX systems.  There are two potential
>outcomes:
>
>
>
>(1) Backwards compatibility is maintained and a bifurcation of the
>standard exists where one group of apps will use Report and others will
>not (which runs counter to the idea of a standard)
>
>(2) The addition of the Report object will result in the eventual
>deprecation of a number of STIX elements/capabilities that a number of
>early-STIX-adopters are counting on.
>
>
>
>I'm going to assume that the first outcome is not desired by anyone.   So
>this discussion is *not* about 1.2 but is about the addition of the
>Report object and the resulting eventual deprecation of existing STIX
>elements and the embedded content construct.
>
>
>
>So, let me start by proposing a fundamental rule for standards
>maintenance.  A standard stays the same unless there is a compelling
>reason to change it.  Obviously, some changes are so compelling that
>re-write is necessary but we should always strive to look for
>alternatives before we break backwards compatibility.   (I know STIX is
>not a standard yet but for all intents and purposes....)  Creating a
>fundamental change in the STIX format incurs significant rewrite costs to
>the organizations that have adopted STIX and reduces the adoption rate of
>new organizations because they do not want to spend resources working
>towards a standard that is still going through large changes.
>Implementing the Report object will slow the adoption of STIX and result
>in a step backwards for organizations that have already implemented STIX.
> Resources that could be spent building new TAXII and STIX capabilities
>must now be spent rewriting existing capabilities to adhere to this
>standards change.
>
>
>
>The Report object was proposed to accommodate the following problem with
>STIX:   Consumers may misinterpret the contextual grouping within a STIX
>package because sometimes there is a contextual grouping and sometimes
>there is not and there is no way to tell when there is and isn't.   The
>code required to handle the dual purposes is more complex than it needs
>to be.
>
>
>
>I am of the opinion that (-) there is no compelling reason to add the
>Reports object because the above problem could be solved in a manner that
>is less destructive to the existing standard and (-) the addition of the
>Report object actually results in loss of capability.
>
>
>
>Loss of Capability:
>
>By separating context into the Report object we are increasing the amount
>of work necessary for a producer to share additional information.  We are
>basically encouraging a producer to only share indicators and observables
>unless they have a significant body of knowledge that warrants the
>creation of a report object and the associated references between the
>report object and the STIX package.
>
>The advantage of STIX over previously developed standards was that it
>provided a rich set of context attached to content.  The creation of the
>Report object greatly reduces this asset of STIX by adding complexity to
>read and write contextual information.
>
>
>
>Let's posit a use case that involves cyber threat reporting about large
>topics (i.e. a country) which focuses on a number of facets about this
>large topic (i.e. cyber infrastructure, known actors, government
>agencies).  To share this large topic, we want to push ONE STIX document,
>with multiple STIX packages, to ensure that the entire scope of the
>reporting is self-contained and relationships and history are not lost
>should the receiver miss a transmission.   We also want to be able to
>keep track of this information collection as a single tracked entity
>because that is how it is tracked internally.    Those who are pushing
>for the Report object, can still support all of their use cases without
>the Report object.  While we understand that others may not have our use
>case, please know that with the Report object, you have removed our
>ability to support this use case.     (Although I understand rejecting
>proposal
>https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Emb
>ed-Content
><https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Em
>bed-Content>   has potential to partially mitigate this).
>
>
>
>Less Destructive Options:
>
>In terms of examining other options (to the Report object), we believe
>the following options should be examined much more thoroughly before such
>a major change is made:
>
>
>
>(A) create a STIX profile for report objects instead of trying to
>redesign the entire spec to fit this one use case. The evolution and
>development of each of the other STIX profiles did not involve pushes to
>redesign STIX and inadequate research has been made into why that cannot
>be done in this case.
>
>
>
>(B) If the need is to distinguish between a STIX package with or without
>contextual grouping, the addition of a flag that states whether or not
>contextual-grouping=true is much less destructive to backwards
>compatibility than the Report object.
>
>
>
>Pam Smith
>
>Systems Engineer
>
>Johns Hopkins University Applied Physics Laboratory
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Eric Burger
No one can disagree with Dan:
> On Jan 29, 2015, at 12:57 PM, Lavoie, Daniel J <[hidden email]> wrote:
>
> 1.       A standard should stay the same unless there is a compelling reason to change it.
> 2.       We should always strive to look for alternatives before we break backwards compatibility.

In general, these are good principles to hold to. No one should be willy-nilly changing things because they look a little bit better. HOWEVER, I have seen the most promising technologies wither and die because people were unwilling to make non-backwards compatible changes TO DRAFTS. Here I am recalling the Session Initiation Protocol development in the IETF. Major, respected players, when confronted with non-backwards compatible changes TO DRAFTS fought tooth and nail to not allow the changes to occur, “because our customers are already using the old stuff and they are happy with it.” Guess what, and most especially relevant to this group, many those changes were to fix fundamental security flaws. We know the end of the story: the Internet multimedia ecosystem was pushed back 15 years. Pissing off one or ten customers is nothing to losing your entire market and becoming irrelevant in five years.

So, yes, we should do our best not to piss off anyone and keep STIX backwards compatible.
And yes, we should be unafraid to make changes to STIX if those changes are really, really important.

[Note I am NOT weighing in on the Report Object. I haven’t thought enough about it to have a position.]

> On Jan 29, 2015, at 3:12 PM, Joep Gommers <[hidden email]> wrote:
>
> I would add that we¹re still in the very early days of adoption and
> although it might cause pain now (us included), we have to deal with some
> very serious issues (Report Object, Sightings Object) and frankly a
> significant expansion of the Report Object as currently envisioned until
> it can really serve most of the use-cases it would require too in the
> following ~5 years. The earlier we deal with these, the better.
>
> Not trying to be incentive here, I apologize if it sounds like it. But if
> we¹re going to have STIX fuel this revolution - we have to deal with these
> issues now IMO.
>
> J-
>
> On 1/29/15, 9:32 PM, "Katz, Gary Contractor DC3" <[hidden email]>
> wrote:
>
>> Aharon, Pam,
>>   Thanks for getting this conversation jumpstarted again.  The creation
>> of the report object has been a concern for the organization that I
>> support along with a number of the organizations that we share
>> information with, so I appreciate the continued debate on the topic.
>> Aharon, as you mentioned, about a year ago there was little operational
>> STIX code, but many organizations were working on building up
>> capabilities during that time and have continued to build new systems
>> based upon the STIX standard since then.  Making such a change will
>> result in some significant rewrites.
>>
>> I also agree with Pam's comment concerning contextual information.  The
>> organizations I work with are trying to incentivize as much information
>> sharing as possible, and not all organizations have the same level of
>> sophistication as others.  By breaking out contextual information into a
>> separate object it disincentives sharing of additional information.  One
>> of the main advantages of STIX (for us) is to allow us to easily ingest
>> significantly more information than what is currently being shared.  If
>> we encourage only sharing indicators and observables, then we are putting
>> ourselves at a disadvantage for defending against the evolving threats we
>> are facing.
>>
>>
>> I appreciate your comment about getting Pam's clients to be able to
>> participate in the voting process. I know that MITRE has a wide breadth
>> in the organizations they interact with.  Perhaps they can be a conduit
>> for capturing the votes of those clients.
>>
>> -Gary
>>
>>
>> -----Original Message-----
>> From: Aharon Chernin [mailto:[hidden email]]
>> Sent: Thursday, January 29, 2015 12:29 PM
>> To: [hidden email]
>> Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object
>>
>>> I work with a number of clients who have embraced STIX and have working
>>> systems.   These clients are unable to readily participate in discussion
>>> groups.
>>
>>
>>
>>
>> STIX is a community driven specification. To make sure we don't have
>> these issues in the future, your clients should explore ways to
>> participate in whatever type of voting processes we have.
>>
>>
>>
>>
>>
>>> So, let me start by proposing a fundamental rule for standards
>>> maintenance.  A standard stays the same unless there is a compelling
>>> reason to change it.
>>
>>
>>
>>
>> In general, I agree with this assertion when the standard has been put
>> into operation through running code. During our early report object
>> debates ( over a year ago ), there was such little operational STIX code
>> that it didn't make sense to force us to find ways around the report
>> object. To me it feels like we were moving from classroom theory to real
>> world operations and discovering that the theory and operations didn't
>> quite match up.
>>
>>
>>
>>
>>
>> Aharon Chernin
>> CTO
>>
>> SOLTRA | An FS-ISAC & DTCC Company
>> 18301 Bermuda green Dr
>> Tampa, fl 33647
>>
>> 813.470.2173 | [hidden email] <mailto:[hidden email]>
>> www.soltra.com <http://www.soltra.com> ________________________________
>>
>> From: Smith, Pamela A. <[hidden email]>
>> Sent: Thursday, January 29, 2015 11:40 AM
>> To: [hidden email]
>> Subject: [STIX] Exploring Alternatives to Proposed Report Object
>>
>>
>> Hello.  This is my first posting to the discussion group but I have been
>> lurking for a while.   I work with a number of clients who have embraced
>> STIX and have working systems.   These clients are unable to readily
>> participate in discussion groups.   I wanted to raise an issue to this
>> discussion group and I'm hoping that those who have already created
>> STIX-based solutions will weigh in.
>>
>>
>>
>> I understand that, given this is a minor release, STIX 1.2 will maintain
>> backwards compatibility and that the cascading changes that result from
>> the proposed new object, Report, will not *yet* be deprecated.   My point
>> is not whether or not 1.2 is backwards compatible (a short-term issue)
>> but the impact that the addition of this new object will eventually have
>> on those who have already deployed STIX systems.  There are two potential
>> outcomes:
>>
>>
>>
>> (1) Backwards compatibility is maintained and a bifurcation of the
>> standard exists where one group of apps will use Report and others will
>> not (which runs counter to the idea of a standard)
>>
>> (2) The addition of the Report object will result in the eventual
>> deprecation of a number of STIX elements/capabilities that a number of
>> early-STIX-adopters are counting on.
>>
>>
>>
>> I'm going to assume that the first outcome is not desired by anyone.   So
>> this discussion is *not* about 1.2 but is about the addition of the
>> Report object and the resulting eventual deprecation of existing STIX
>> elements and the embedded content construct.
>>
>>
>>
>> So, let me start by proposing a fundamental rule for standards
>> maintenance.  A standard stays the same unless there is a compelling
>> reason to change it.  Obviously, some changes are so compelling that
>> re-write is necessary but we should always strive to look for
>> alternatives before we break backwards compatibility.   (I know STIX is
>> not a standard yet but for all intents and purposes....)  Creating a
>> fundamental change in the STIX format incurs significant rewrite costs to
>> the organizations that have adopted STIX and reduces the adoption rate of
>> new organizations because they do not want to spend resources working
>> towards a standard that is still going through large changes.
>> Implementing the Report object will slow the adoption of STIX and result
>> in a step backwards for organizations that have already implemented STIX.
>> Resources that could be spent building new TAXII and STIX capabilities
>> must now be spent rewriting existing capabilities to adhere to this
>> standards change.
>>
>>
>>
>> The Report object was proposed to accommodate the following problem with
>> STIX:   Consumers may misinterpret the contextual grouping within a STIX
>> package because sometimes there is a contextual grouping and sometimes
>> there is not and there is no way to tell when there is and isn't.   The
>> code required to handle the dual purposes is more complex than it needs
>> to be.
>>
>>
>>
>> I am of the opinion that (-) there is no compelling reason to add the
>> Reports object because the above problem could be solved in a manner that
>> is less destructive to the existing standard and (-) the addition of the
>> Report object actually results in loss of capability.
>>
>>
>>
>> Loss of Capability:
>>
>> By separating context into the Report object we are increasing the amount
>> of work necessary for a producer to share additional information.  We are
>> basically encouraging a producer to only share indicators and observables
>> unless they have a significant body of knowledge that warrants the
>> creation of a report object and the associated references between the
>> report object and the STIX package.
>>
>> The advantage of STIX over previously developed standards was that it
>> provided a rich set of context attached to content.  The creation of the
>> Report object greatly reduces this asset of STIX by adding complexity to
>> read and write contextual information.
>>
>>
>>
>> Let's posit a use case that involves cyber threat reporting about large
>> topics (i.e. a country) which focuses on a number of facets about this
>> large topic (i.e. cyber infrastructure, known actors, government
>> agencies).  To share this large topic, we want to push ONE STIX document,
>> with multiple STIX packages, to ensure that the entire scope of the
>> reporting is self-contained and relationships and history are not lost
>> should the receiver miss a transmission.   We also want to be able to
>> keep track of this information collection as a single tracked entity
>> because that is how it is tracked internally.    Those who are pushing
>> for the Report object, can still support all of their use cases without
>> the Report object.  While we understand that others may not have our use
>> case, please know that with the Report object, you have removed our
>> ability to support this use case.     (Although I understand rejecting
>> proposal
>> https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Emb
>> ed-Content
>> <https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Em
>> bed-Content>   has potential to partially mitigate this).
>>
>>
>>
>> Less Destructive Options:
>>
>> In terms of examining other options (to the Report object), we believe
>> the following options should be examined much more thoroughly before such
>> a major change is made:
>>
>>
>>
>> (A) create a STIX profile for report objects instead of trying to
>> redesign the entire spec to fit this one use case. The evolution and
>> development of each of the other STIX profiles did not involve pushes to
>> redesign STIX and inadequate research has been made into why that cannot
>> be done in this case.
>>
>>
>>
>> (B) If the need is to distinguish between a STIX package with or without
>> contextual grouping, the addition of a flag that states whether or not
>> contextual-grouping=true is much less destructive to backwards
>> compatibility than the Report object.
>>
>>
>>
>> Pam Smith
>>
>> Systems Engineer
>>
>> Johns Hopkins University Applied Physics Laboratory


--
Dr. Eric Burger
Director, Security and Software Engineering Research Center at Georgetown, <https://s2erc.georgetown.edu/>
Research Professor of Computer Science, <http://www.cs.georgetown.edu/~eburger/>
Skype: eburger
Mobile: 603-305-7886 (preferred)
Office: 202-687-4107
CALENDAR NOTE: please send invitations to [hidden email]
You may see responses and invitations come from that address.
PGP Public Key: 7AAEC917.asc
PGP Fingerprint: D0D8 0E8B EB30 B07B 14DF  3509 3CE3 0ED9 7AAE C917
S/MIME chain of trust should be InCommon, signed by UTN-USERFirst, root at AddTrust External CA Root (Comodo)
SHA1 Fingerprint: 82 A4 20 9F C0 C9 2C B1 B8 F0 15 79 A6 BD 2F CD 72 8A E2 57


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Aharon Chernin
In reply to this post by Lavoie, Daniel J

I thought I would provide the list some additional context :


Q) Is the Report object backwards compatible?

A) Yes, versions of STIX earlier than 1.2 will still operate with 1.2 compliant interpreters.  Both methods of creating report context (STIX_Packages vs Report Object) will still function within the language.


Q) Will we will lose functionality once the Report object comes out?

A) Both methods will still work, however the STIX_Package method will be noted as depreciated within the documentation.  STIX_Package based reporting would be removed during the creation of STIX 2.0. A word of caution... A lot of backwards incompatible changes will likely be introduced during a 2.0 revamp of the language. There is no ETA for 2.0. Do we think we have leveraged the full capabilities of the 1.x series?


Q) Will we end up with products using either the STIX_Package reporting method or the Report method?

A) Yes, it's likely. This is also not the only STIX function that can be done several different ways.


Q) Report object, why?

A) We see a STIX_Package as a wrapper or an envelope. Prior to the report object we were required to keep track of old envelopes as they contained things that envelopes shouldn't contain - like reporting and additional context. By moving this additional context to its own "report" object, we are able to do several things. One, now that report context is in it's own object, we can discard envelopes once processing has completed ( if a vendor decides to ). Two, we can reuse this report object over and over again. Three, it allows us to expand on the report object in the future to provide it more capabilities than it has today (imagine embedding an encoded document into the header of your STIX_Package vs inside a Report object). And finally, it's easier to describe how STIX works to the layperson ( we have all these objects for data, except for reporting - that goes in a STIX_Package header ).



Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

From: Lavoie, Daniel J <[hidden email]>
Sent: Thursday, January 29, 2015 12:57 PM
To: [hidden email]
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object
 

+1, Thanks Pam.

 

I’ve had the pleasure of managing the development of an analysis and cyber defense information sharing system for 3 years.  We saw the value in community-adopted standardized/structured information sharing, but the constant updates (without backwards compatibility support) posed too much risk to ensure delivery of a fully functional system.  We (developers) recommended to not support STIX/MAEC/CYBOX for our project for almost 2 years because of the backwards compatibility issues, and our customer concurred.

 

STIX has since become more stable, and we decided to adopt.  We invested many, many months of development hours designing a new reporting capability that maintains our existing format AND provides a means to support standardized info sharing.

 

I have spoken with my peers about the deprecation issue, and we agree with Pam, and second her motion on the following:

 

1.       A standard should stay the same unless there is a compelling reason to change it.

2.       We should always strive to look for alternatives before we break backwards compatibility.

 

I ask the change control board members to consider the overall risk this poses to the standard, and the community members who have chosen to adopt it.  If backwards compatibility is broken, you’re going to cause teams to ask for a fork.  Many teams simply do not have the money or time to support yet-another redesign to support a single use case.

 

V/r,

 

Dan LaVoie

Project Manager

ManTech Int’l

 

From: Smith, Pamela A. [mailto:[hidden email]]
Sent: Thursday, January 29, 2015 10:40 AM
To: [hidden email]
Subject: [STIX] Exploring Alternatives to Proposed Report Object

 

Hello.  This is my first posting to the discussion group but I have been lurking for a while.   I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.   I wanted to raise an issue to this discussion group and I’m hoping that those who have already created STIX-based solutions will weigh in.

 

I understand that, given this is a minor release, STIX 1.2 will maintain backwards compatibility and that the cascading changes that result from the proposed new object, Report, will not *yet* be deprecated.   My point is not whether or not 1.2 is backwards compatible (a short-term issue) but the impact that the addition of this new object will eventually have on those who have already deployed STIX systems.  There are two potential outcomes:

 

(1) Backwards compatibility is maintained and a bifurcation of the standard exists where one group of apps will use Report and others will not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual deprecation of a number of STIX elements/capabilities that a number of early-STIX-adopters are counting on.

 

I’m going to assume that the first outcome is not desired by anyone.   So this discussion is *not* about 1.2 but is about the addition of the Report object and the resulting eventual deprecation of existing STIX elements and the embedded content construct.

 

So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.  Obviously, some changes are so compelling that re-write is necessary but we should always strive to look for alternatives before we break backwards compatibility.   (I know STIX is not a standard yet but for all intents and purposes….)  Creating a fundamental change in the STIX format incurs significant rewrite costs to the organizations that have adopted STIX and reduces the adoption rate of new organizations because they do not want to spend resources working towards a standard that is still going through large changes.  Implementing the Report object will slow the adoption of STIX and result in a step backwards for organizations that have already implemented STIX.  Resources that could be spent building new TAXII and STIX capabilities must now be spent rewriting existing capabilities to adhere to this standards change.

 

The Report object was proposed to accommodate the following problem with STIX:   Consumers may misinterpret the contextual grouping within a STIX package because sometimes there is a contextual grouping and sometimes there is not and there is no way to tell when there is and isn’t.   The code required to handle the dual purposes is more complex than it needs to be.

 

I am of the opinion that (-) there is no compelling reason to add the Reports object because the above problem could be solved in a manner that is less destructive to the existing standard and (-) the addition of the Report object actually results in loss of capability.

 

Loss of Capability:

By separating context into the Report object we are increasing the amount of work necessary for a producer to share additional information.  We are basically encouraging a producer to only share indicators and observables unless they have a significant body of knowledge that warrants the creation of a report object and the associated references between the report object and the STIX package.

The advantage of STIX over previously developed standards was that it provided a rich set of context attached to content.  The creation of the Report object greatly reduces this asset of STIX by adding complexity to read and write contextual information. 

 

Let’s posit a use case that involves cyber threat reporting about large topics (i.e. a country) which focuses on a number of facets about this large topic (i.e. cyber infrastructure, known actors, government agencies).  To share this large topic, we want to push ONE STIX document, with multiple STIX packages, to ensure that the entire scope of the reporting is self-contained and relationships and history are not lost should the receiver miss a transmission.   We also want to be able to keep track of this information collection as a single tracked entity because that is how it is tracked internally.    Those who are pushing for the Report object, can still support all of their use cases without the Report object.  While we understand that others may not have our use case, please know that with the Report object, you have removed our ability to support this use case.     (Although I understand rejecting proposal https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content  has potential to partially mitigate this).

 

Less Destructive Options:

In terms of examining other options (to the Report object), we believe the following options should be examined much more thoroughly before such a major change is made:

 

(A) create a STIX profile for report objects instead of trying to redesign the entire spec to fit this one use case. The evolution and development of each of the other STIX profiles did not involve pushes to redesign STIX and inadequate research has been made into why that cannot be done in this case.

 

(B) If the need is to distinguish between a STIX package with or without contextual grouping, the addition of a flag that states whether or not contextual-grouping=true is much less destructive to backwards compatibility than the Report object.

 

Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory




This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Terry MacDonald
In reply to this post by Katz, Gary
Hi All,

I'm a little puzzled as to why the addition of the Report object or other changes that break backwards compatibility are so contentious. If it does become part of the next iteration of the standard, and your organization believes it requires too much change to support it on your organizations platform, then just don't accept that version of STIX documents. Instead, only accept documents that adhere to the earlier version of STIX that your parser supports, and then everything should work as it had done previously. There will be multiple changes within the next version of STIX (as there are with each version release), and each version adds various needed functionality to expand the number of use cases supported by the standard.

Its an important point - This is a fairly new standard, and like any new standards changes are to be expected as we discover what works and what doesn't. Its part of the risks of playing in this space at such an early stage. If an organization is not able to modify code to keep up with the changes in an evolving standard such as this, then it may be better for that organization to wait a while until the standard is more stable.

I'm also interested in what the single use case is that was mentioned regarding the Report object.

Cheers
Terry MacDonald

Disclaimer - the preceeding comments are all my own and have nothing to do with my employers or customers.


On 29 January 2015 at 11:32, Katz, Gary Contractor DC3 <[hidden email]> wrote:
Aharon, Pam,
    Thanks for getting this conversation jumpstarted again.  The creation of the report object has been a concern for the organization that I support along with a number of the organizations that we share information with, so I appreciate the continued debate on the topic.  Aharon, as you mentioned, about a year ago there was little operational STIX code, but many organizations were working on building up capabilities during that time and have continued to build new systems based upon the STIX standard since then.  Making such a change will result in some significant rewrites.

  I also agree with Pam's comment concerning contextual information.  The organizations I work with are trying to incentivize as much information sharing as possible, and not all organizations have the same level of sophistication as others.  By breaking out contextual information into a separate object it disincentives sharing of additional information.  One of the main advantages of STIX (for us) is to allow us to easily ingest significantly more information than what is currently being shared.  If we encourage only sharing indicators and observables, then we are putting ourselves at a disadvantage for defending against the evolving threats we are facing.


I appreciate your comment about getting Pam's clients to be able to participate in the voting process. I know that MITRE has a wide breadth in the organizations they interact with.  Perhaps they can be a conduit for capturing the votes of those clients.

-Gary


-----Original Message-----
From: Aharon Chernin [mailto:[hidden email]]
Sent: Thursday, January 29, 2015 12:29 PM
To: [hidden email]
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object

> I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.




STIX is a community driven specification. To make sure we don't have these issues in the future, your clients should explore ways to participate in whatever type of voting processes we have.





> So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.




In general, I agree with this assertion when the standard has been put into operation through running code. During our early report object debates ( over a year ago ), there was such little operational STIX code that it didn't make sense to force us to find ways around the report object. To me it feels like we were moving from classroom theory to real world operations and discovering that the theory and operations didn't quite match up.





Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

813.470.2173<img title="Call: 813.470.2173" style="margin: 0px; border: currentColor; border-image: none; left: 0px; top: 0px; width: 16px; height: 16px; right: 0px; bottom: 0px; overflow: hidden; vertical-align: middle; float: none; display: inline; white-space: nowrap; position: static !important;" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAACXBIWXMAAA7EAAAOxAGVKw4bAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAAAaNJREFUeNqk009oz3Ecx/HH9/P9/YQRWSi2MGmNrebkpJgSLluKEw5Kk5zUsgMOTrO42MUVxUWRg+LgaPWbUGq7rRk7sExKNPt9vx8H32l921z2vrw+n3fvz/Pz/vP5JDFGy7HKwk1/fz/sR09VNjAZG6fv1buQHcZm3P8vAMfwCKswncoHCn8nbuAratiEUQglwLXiMJz/FhvWYC9OFb4htBV6B9VyBtsKzRJxbDhvbSS5i1kcQo736MNrjJcBeaG3MuFyInagA0fwckHcGzzGiXIJU38bk1U+x3W+x7U/yOvYU4prwG5MlAHPoS4925TMNDeHLxNUh0gGcRC9eFqk34TBMuAhfmL9b5Vz3elIbAmfLq02d4HQhbc4gBYcxUgZMFrcIJecrsgaT6avdl6sPqu1hw9XSWs4U5Q6udgYFfP+he25MEysVWQvutORLcfTYax4gn3z/VoM8A7Xi/WuKNmQCRujpLc1TGkP46hOI1sKADdxG3PzjkzoTNCT1rSFiX+PuLIEoI4rGC+6/xEPMsFKs7YmM8bsAMlyf2OwTPszAMZMeayGCpJVAAAAAElFTkSuQmCC"> | [hidden email] <mailto:[hidden email]> www.soltra.com <http://www.soltra.com> ________________________________

From: Smith, Pamela A. <[hidden email]>
Sent: Thursday, January 29, 2015 11:40 AM
To: [hidden email]
Subject: [STIX] Exploring Alternatives to Proposed Report Object


Hello.  This is my first posting to the discussion group but I have been lurking for a while.   I work with a number of clients who have embraced STIX and have working systems.   These clients are unable to readily participate in discussion groups.   I wanted to raise an issue to this discussion group and I'm hoping that those who have already created STIX-based solutions will weigh in.



I understand that, given this is a minor release, STIX 1.2 will maintain backwards compatibility and that the cascading changes that result from the proposed new object, Report, will not *yet* be deprecated.   My point is not whether or not 1.2 is backwards compatible (a short-term issue) but the impact that the addition of this new object will eventually have on those who have already deployed STIX systems.  There are two potential outcomes:



(1) Backwards compatibility is maintained and a bifurcation of the standard exists where one group of apps will use Report and others will not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual deprecation of a number of STIX elements/capabilities that a number of early-STIX-adopters are counting on.



I'm going to assume that the first outcome is not desired by anyone.   So this discussion is *not* about 1.2 but is about the addition of the Report object and the resulting eventual deprecation of existing STIX elements and the embedded content construct.



So, let me start by proposing a fundamental rule for standards maintenance.  A standard stays the same unless there is a compelling reason to change it.  Obviously, some changes are so compelling that re-write is necessary but we should always strive to look for alternatives before we break backwards compatibility.   (I know STIX is not a standard yet but for all intents and purposes....)  Creating a fundamental change in the STIX format incurs significant rewrite costs to the organizations that have adopted STIX and reduces the adoption rate of new organizations because they do not want to spend resources working towards a standard that is still going through large changes.  Implementing the Report object will slow the adoption of STIX and result in a step backwards for organizations that have already implemented STIX.  Resources that could be spent building new TAXII and STIX capabilities must now be spent rewriting existing capabilities to adhere to this standards change.



The Report object was proposed to accommodate the following problem with STIX:   Consumers may misinterpret the contextual grouping within a STIX package because sometimes there is a contextual grouping and sometimes there is not and there is no way to tell when there is and isn't.   The code required to handle the dual purposes is more complex than it needs to be.



I am of the opinion that (-) there is no compelling reason to add the Reports object because the above problem could be solved in a manner that is less destructive to the existing standard and (-) the addition of the Report object actually results in loss of capability.



Loss of Capability:

By separating context into the Report object we are increasing the amount of work necessary for a producer to share additional information.  We are basically encouraging a producer to only share indicators and observables unless they have a significant body of knowledge that warrants the creation of a report object and the associated references between the report object and the STIX package.

The advantage of STIX over previously developed standards was that it provided a rich set of context attached to content.  The creation of the Report object greatly reduces this asset of STIX by adding complexity to read and write contextual information.



Let's posit a use case that involves cyber threat reporting about large topics (i.e. a country) which focuses on a number of facets about this large topic (i.e. cyber infrastructure, known actors, government agencies).  To share this large topic, we want to push ONE STIX document, with multiple STIX packages, to ensure that the entire scope of the reporting is self-contained and relationships and history are not lost should the receiver miss a transmission.   We also want to be able to keep track of this information collection as a single tracked entity because that is how it is tracked internally.    Those who are pushing for the Report object, can still support all of their use cases without the Report object.  While we understand that others may not have our use case, please know that with the Report object, you have removed our ability to support this use case.     (Although I understand rejecting proposal https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content <https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Embed-Content>   has potential to partially mitigate this).



Less Destructive Options:

In terms of examining other options (to the Report object), we believe the following options should be examined much more thoroughly before such a major change is made:



(A) create a STIX profile for report objects instead of trying to redesign the entire spec to fit this one use case. The evolution and development of each of the other STIX profiles did not involve pushes to redesign STIX and inadequate research has been made into why that cannot be done in this case.



(B) If the need is to distinguish between a STIX package with or without contextual grouping, the addition of a flag that states whether or not contextual-grouping=true is much less destructive to backwards compatibility than the Report object.



Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Eric Burger
In reply to this post by Aharon Chernin
Agreed that when we put out building blocks, people are likely to figure out useful ways to put those blocks together. However, we will bifurcate the market if, once we learn common, useful ways to put those blocks together to produce the same things different ways. Report is one of those things that could be done different ways, and it was through experience some suggest that Report needs to be a first-class STIX element. I would offer that if we do decide Report is the way to go, that we update the envelope header documentation to mention that while you could use envelope information to get the Report functionality, and that some products do that, that behavior is not suggested and should go away over time.

On Jan 30, 2015, at 12:29 AM, Aharon Chernin <[hidden email]> wrote: [emphasis Eric's]

Q) Will we end up with products using either the STIX_Package reporting method or the Report method?
A) Yes, it's likely. This is also not the only STIX function that can be done several different ways.

Q) Report object, why?
A) We see a STIX_Package as a wrapper or an envelope. Prior to the report object we were required to keep track of old envelopes as they contained things that envelopes shouldn't contain - like reporting and additional context. By moving this additional context to its own "report" object, we are able to do several things. One, now that report context is in it's own object, we can discard envelopes once processing has completed ( if a vendor decides to ). Two, we can reuse this report object over and over again. Three, it allows us to expand on the report object in the future to provide it more capabilities than it has today (imagine embedding an encoded document into the header of your STIX_Package vs inside a Report object). And finally, it's easier to describe how STIX works to the layperson ( we have all these objects for data, except for reporting - that goes in a STIX_Package header ). 


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Collie, Byron S.

Part of the question is whether you are only attempting to track the STIX entities themselves or also your sources. Once you starting tracking source and collection, doing actual analysis and measuring the efficacy and effectiveness of reporting, not just the embedded entities themselves, becomes critical. It also becomes critical when you have an information conflict between two sources and/or reports.  Mandiant says it’s APT28 (Russian) and CrowdStrike says it is Aurora Panda (Chinese) so the Source, Collection, Report tracking becomes critical in tracking these kinds of conflicts.

 

From: Eric Burger [mailto:[hidden email]]
Sent: Friday, January 30, 2015 12:38 PM
To: [hidden email]
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object

 

Agreed that when we put out building blocks, people are likely to figure out useful ways to put those blocks together. However, we will bifurcate the market if, once we learn common, useful ways to put those blocks together to produce the same things different ways. Report is one of those things that could be done different ways, and it was through experience some suggest that Report needs to be a first-class STIX element. I would offer that if we do decide Report is the way to go, that we update the envelope header documentation to mention that while you could use envelope information to get the Report functionality, and that some products do that, that behavior is not suggested and should go away over time.

On Jan 30, 2015, at 12:29 AM, Aharon Chernin <[hidden email]> wrote: [emphasis Eric's]

 

Q) Will we end up with products using either the STIX_Package reporting method or the Report method?

A) Yes, it's likely. This is also not the only STIX function that can be done several different ways.

 

Q) Report object, why?

A) We see a STIX_Package as a wrapper or an envelope. Prior to the report object we were required to keep track of old envelopes as they contained things that envelopes shouldn't contain - like reporting and additional context. By moving this additional context to its own "report" object, we are able to do several things. One, now that report context is in it's own object, we can discard envelopes once processing has completed ( if a vendor decides to ). Two, we can reuse this report object over and over again. Three, it allows us to expand on the report object in the future to provide it more capabilities than it has today (imagine embedding an encoded document into the header of your STIX_Package vs inside a Report object). And finally, it's easier to describe how STIX works to the layperson ( we have all these objects for data, except for reporting - that goes in a STIX_Package header ). 

 

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Jason Keirstead

There will be products that work with both the entities and the sources, and there will be products that only work with entities and for whom sources have little to no value, and there will be products that work primarily with the sources and for whom the entities have little value. A network-level blocking device who is simply using STIX as an instruction set may not care what the name of a set of indicators is because it has no user interface. A high level reporting tool that is visualizing threat trends, may not care what the underlying cybox observables were, because it never gets to that level of detail in anything in the product. STIX is an attempt at a very comprehensive standard... it is all-encompassing from a very highest level description of the threat to the lowest level of fidelity. However, not all products will use all facets (in fact I would argue there will be very few products that operationalize all of STIX simultaneously, at least for the foreseeable future). Therefore that whenever possible, facets of STIX should be structured so that they are as "optional" as possible... when things can be de-coupled, they should be... this is why I am in total agreement with the report object, it decouples these things that do not really need to be coupled.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

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


Inactive hide details for "Collie, Byron S." ---2015/01/30 02:41:44 PM---Part of the question is whether you are only attemptin"Collie, Byron S." ---2015/01/30 02:41:44 PM---Part of the question is whether you are only attempting to track the STIX entities themselves or als

From: "Collie, Byron S." <[hidden email]>
To: <[hidden email]>
Date: 2015/01/30 02:41 PM
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object





Part of the question is whether you are only attempting to track the STIX entities themselves or also your sources. Once you starting tracking source and collection, doing actual analysis and measuring the efficacy and effectiveness of reporting, not just the embedded entities themselves, becomes critical. It also becomes critical when you have an information conflict between two sources and/or reports.  Mandiant says it’s APT28 (Russian) and CrowdStrike says it is Aurora Panda (Chinese) so the Source, Collection, Report tracking becomes critical in tracking these kinds of conflicts.
 
From: Eric Burger [[hidden email]]
Sent:
 Friday, January 30, 2015 12:38 PM
To:
 [hidden email]
Subject:
 Re: [STIX] Exploring Alternatives to Proposed Report Object
 
Agreed that when we put out building blocks, people are likely to figure out useful ways to put those blocks together. However, we will bifurcate the market if, once we learn common, useful ways to put those blocks together to produce the same things different ways. Report is one of those things that could be done different ways, and it was through experience some suggest that Report needs to be a first-class STIX element. I would offer that if we do decide Report is the way to go, that we update the envelope header documentation to mention that while you could use envelope information to get the Report functionality, and that some products do that, that behavior is not suggested and should go away over time.
    On Jan 30, 2015, at 12:29 AM, Aharon Chernin <[hidden email]> wrote: [emphasis Eric's]
     
    Q) Will we end up with products using either the STIX_Package reporting method or the Report method?
    A) Yes, it's likely. This is also not the only STIX function that can be done several different ways.
     
    Q) Report object, why?
    A) We see a STIX_Package as a wrapper or an envelope. Prior to the report object we were required to keep track of old envelopes as they contained things that envelopes shouldn't contain - like reporting and additional context. By moving this additional context to its own "report" object, we are able to do several things. One, now that report context is in it's own object, we can discard envelopes once processing has completed ( if a vendor decides to ). Two, we can reuse this report object over and over again. Three, it allows us to expand on the report object in the future to provide it more capabilities than it has today (imagine embedding an encoded document into the header of your STIX_Package vs inside a Report object). And finally, it's easier to describe how STIX works to the layperson ( we have all these objects for data, except for reporting - that goes in a STIX_Package header ).
     
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Terry MacDonald

[+1]. Also why I believe relationships should be able to sent independently from the other STIX objects in stix v2.... But will leave that conversation for another thread.

Cheers
Terry MacDonald

On 30/01/2015 10:58 am, "Jason Keirstead" <[hidden email]> wrote:

There will be products that work with both the entities and the sources, and there will be products that only work with entities and for whom sources have little to no value, and there will be products that work primarily with the sources and for whom the entities have little value. A network-level blocking device who is simply using STIX as an instruction set may not care what the name of a set of indicators is because it has no user interface. A high level reporting tool that is visualizing threat trends, may not care what the underlying cybox observables were, because it never gets to that level of detail in anything in the product. STIX is an attempt at a very comprehensive standard... it is all-encompassing from a very highest level description of the threat to the lowest level of fidelity. However, not all products will use all facets (in fact I would argue there will be very few products that operationalize all of STIX simultaneously, at least for the foreseeable future). Therefore that whenever possible, facets of STIX should be structured so that they are as "optional" as possible... when things can be de-coupled, they should be... this is why I am in total agreement with the report object, it decouples these things that do not really need to be coupled.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

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


Inactive hide details for "Collie, Byron S." ---2015/01/30 02:41:44 PM---Part of the question is whether you are only attemptin"Collie, Byron S." ---2015/01/30 02:41:44 PM---Part of the question is whether you are only attempting to track the STIX entities themselves or als

From: "Collie, Byron S." <[hidden email]>
To: <[hidden email]>
Date: 2015/01/30 02:41 PM
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object





Part of the question is whether you are only attempting to track the STIX entities themselves or also your sources. Once you starting tracking source and collection, doing actual analysis and measuring the efficacy and effectiveness of reporting, not just the embedded entities themselves, becomes critical. It also becomes critical when you have an information conflict between two sources and/or reports.  Mandiant says it’s APT28 (Russian) and CrowdStrike says it is Aurora Panda (Chinese) so the Source, Collection, Report tracking becomes critical in tracking these kinds of conflicts.
 
From: Eric Burger [[hidden email]]
Sent:
 Friday, January 30, 2015 12:38 PM
To:
 [hidden email]
Subject:
 Re: [STIX] Exploring Alternatives to Proposed Report Object
 
Agreed that when we put out building blocks, people are likely to figure out useful ways to put those blocks together. However, we will bifurcate the market if, once we learn common, useful ways to put those blocks together to produce the same things different ways. Report is one of those things that could be done different ways, and it was through experience some suggest that Report needs to be a first-class STIX element. I would offer that if we do decide Report is the way to go, that we update the envelope header documentation to mention that while you could use envelope information to get the Report functionality, and that some products do that, that behavior is not suggested and should go away over time.
    On Jan 30, 2015, at 12:29 AM, Aharon Chernin <[hidden email]> wrote: [emphasis Eric's]
     
    Q) Will we end up with products using either the STIX_Package reporting method or the Report method?
    A) Yes, it's likely. This is also not the only STIX function that can be done several different ways.
     
    Q) Report object, why?
    A) We see a STIX_Package as a wrapper or an envelope. Prior to the report object we were required to keep track of old envelopes as they contained things that envelopes shouldn't contain - like reporting and additional context. By moving this additional context to its own "report" object, we are able to do several things. One, now that report context is in it's own object, we can discard envelopes once processing has completed ( if a vendor decides to ). Two, we can reuse this report object over and over again. Three, it allows us to expand on the report object in the future to provide it more capabilities than it has today (imagine embedding an encoded document into the header of your STIX_Package vs inside a Report object). And finally, it's easier to describe how STIX works to the layperson ( we have all these objects for data, except for reporting - that goes in a STIX_Package header ).
     

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Jordan, Bret
In reply to this post by Eric Burger
+1 Eric,

With all standards, early versions, aka 1.x, are always a bit shaky.  IMHO the 1.x version is a line in the sand that allows early development work to take place.  This allows us, as a community to understand the thing that work well and those that do not.  The 2.x branch is where things should really begin to stabilize.  And yes, there will be some code rewrite, but that is inevitable to move things forward. 

Food for thought, it will be so much easier to fix things in 2015 than in 2020 when there are hundreds or thousands of apps are using STIX data.  Lets do our best to find all of the issues that need to be addressed in a STIX 2.0 version.  This means, we need lots of groups working with the data and finding issues with the structure.  If we can document those use cases and the problems we can get busy with building the fixes to 2.0.  The report object is but one of the issues we are facing..  Another is signatures of data, and another, which should be super simple, but is not, is Sightings +1.  The more we start using the data, the more we can find issues and get them fixed for 2.0. 

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Jan 29, 2015, at 2:09 PM, Eric Burger <[hidden email]> wrote:

No one can disagree with Dan:
On Jan 29, 2015, at 12:57 PM, Lavoie, Daniel J <[hidden email]> wrote:

1.       A standard should stay the same unless there is a compelling reason to change it.
2.       We should always strive to look for alternatives before we break backwards compatibility.

In general, these are good principles to hold to. No one should be willy-nilly changing things because they look a little bit better. HOWEVER, I have seen the most promising technologies wither and die because people were unwilling to make non-backwards compatible changes TO DRAFTS. Here I am recalling the Session Initiation Protocol development in the IETF. Major, respected players, when confronted with non-backwards compatible changes TO DRAFTS fought tooth and nail to not allow the changes to occur, “because our customers are already using the old stuff and they are happy with it.” Guess what, and most especially relevant to this group, many those changes were to fix fundamental security flaws. We know the end of the story: the Internet multimedia ecosystem was pushed back 15 years. Pissing off one or ten customers is nothing to losing your entire market and becoming irrelevant in five years.

So, yes, we should do our best not to piss off anyone and keep STIX backwards compatible.
And yes, we should be unafraid to make changes to STIX if those changes are really, really important.

[Note I am NOT weighing in on the Report Object. I haven’t thought enough about it to have a position.]

On Jan 29, 2015, at 3:12 PM, Joep Gommers <[hidden email]> wrote:

I would add that we¹re still in the very early days of adoption and
although it might cause pain now (us included), we have to deal with some
very serious issues (Report Object, Sightings Object) and frankly a
significant expansion of the Report Object as currently envisioned until
it can really serve most of the use-cases it would require too in the
following ~5 years. The earlier we deal with these, the better.

Not trying to be incentive here, I apologize if it sounds like it. But if
we¹re going to have STIX fuel this revolution - we have to deal with these
issues now IMO.

J-

On 1/29/15, 9:32 PM, "Katz, Gary Contractor DC3" <[hidden email]>
wrote:

Aharon, Pam,
 Thanks for getting this conversation jumpstarted again.  The creation
of the report object has been a concern for the organization that I
support along with a number of the organizations that we share
information with, so I appreciate the continued debate on the topic.
Aharon, as you mentioned, about a year ago there was little operational
STIX code, but many organizations were working on building up
capabilities during that time and have continued to build new systems
based upon the STIX standard since then.  Making such a change will
result in some significant rewrites.

I also agree with Pam's comment concerning contextual information.  The
organizations I work with are trying to incentivize as much information
sharing as possible, and not all organizations have the same level of
sophistication as others.  By breaking out contextual information into a
separate object it disincentives sharing of additional information.  One
of the main advantages of STIX (for us) is to allow us to easily ingest
significantly more information than what is currently being shared.  If
we encourage only sharing indicators and observables, then we are putting
ourselves at a disadvantage for defending against the evolving threats we
are facing.


I appreciate your comment about getting Pam's clients to be able to
participate in the voting process. I know that MITRE has a wide breadth
in the organizations they interact with.  Perhaps they can be a conduit
for capturing the votes of those clients.

-Gary


-----Original Message-----
From: Aharon Chernin [[hidden email]]
Sent: Thursday, January 29, 2015 12:29 PM
To: [hidden email]
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object

I work with a number of clients who have embraced STIX and have working
systems.   These clients are unable to readily participate in discussion
groups.




STIX is a community driven specification. To make sure we don't have
these issues in the future, your clients should explore ways to
participate in whatever type of voting processes we have.





So, let me start by proposing a fundamental rule for standards
maintenance.  A standard stays the same unless there is a compelling
reason to change it.




In general, I agree with this assertion when the standard has been put
into operation through running code. During our early report object
debates ( over a year ago ), there was such little operational STIX code
that it didn't make sense to force us to find ways around the report
object. To me it feels like we were moving from classroom theory to real
world operations and discovering that the theory and operations didn't
quite match up.





Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647

813.470.2173 | [hidden email] <[hidden email]>
www.soltra.com <http://www.soltra.com> ________________________________

From: Smith, Pamela A. <[hidden email]>
Sent: Thursday, January 29, 2015 11:40 AM
To: [hidden email]
Subject: [STIX] Exploring Alternatives to Proposed Report Object


Hello.  This is my first posting to the discussion group but I have been
lurking for a while.   I work with a number of clients who have embraced
STIX and have working systems.   These clients are unable to readily
participate in discussion groups.   I wanted to raise an issue to this
discussion group and I'm hoping that those who have already created
STIX-based solutions will weigh in.



I understand that, given this is a minor release, STIX 1.2 will maintain
backwards compatibility and that the cascading changes that result from
the proposed new object, Report, will not *yet* be deprecated.   My point
is not whether or not 1.2 is backwards compatible (a short-term issue)
but the impact that the addition of this new object will eventually have
on those who have already deployed STIX systems.  There are two potential
outcomes:



(1) Backwards compatibility is maintained and a bifurcation of the
standard exists where one group of apps will use Report and others will
not (which runs counter to the idea of a standard)

(2) The addition of the Report object will result in the eventual
deprecation of a number of STIX elements/capabilities that a number of
early-STIX-adopters are counting on.



I'm going to assume that the first outcome is not desired by anyone.   So
this discussion is *not* about 1.2 but is about the addition of the
Report object and the resulting eventual deprecation of existing STIX
elements and the embedded content construct.



So, let me start by proposing a fundamental rule for standards
maintenance.  A standard stays the same unless there is a compelling
reason to change it.  Obviously, some changes are so compelling that
re-write is necessary but we should always strive to look for
alternatives before we break backwards compatibility.   (I know STIX is
not a standard yet but for all intents and purposes....)  Creating a
fundamental change in the STIX format incurs significant rewrite costs to
the organizations that have adopted STIX and reduces the adoption rate of
new organizations because they do not want to spend resources working
towards a standard that is still going through large changes.
Implementing the Report object will slow the adoption of STIX and result
in a step backwards for organizations that have already implemented STIX.
Resources that could be spent building new TAXII and STIX capabilities
must now be spent rewriting existing capabilities to adhere to this
standards change.



The Report object was proposed to accommodate the following problem with
STIX:   Consumers may misinterpret the contextual grouping within a STIX
package because sometimes there is a contextual grouping and sometimes
there is not and there is no way to tell when there is and isn't.   The
code required to handle the dual purposes is more complex than it needs
to be.



I am of the opinion that (-) there is no compelling reason to add the
Reports object because the above problem could be solved in a manner that
is less destructive to the existing standard and (-) the addition of the
Report object actually results in loss of capability.



Loss of Capability:

By separating context into the Report object we are increasing the amount
of work necessary for a producer to share additional information.  We are
basically encouraging a producer to only share indicators and observables
unless they have a significant body of knowledge that warrants the
creation of a report object and the associated references between the
report object and the STIX package.

The advantage of STIX over previously developed standards was that it
provided a rich set of context attached to content.  The creation of the
Report object greatly reduces this asset of STIX by adding complexity to
read and write contextual information.



Let's posit a use case that involves cyber threat reporting about large
topics (i.e. a country) which focuses on a number of facets about this
large topic (i.e. cyber infrastructure, known actors, government
agencies).  To share this large topic, we want to push ONE STIX document,
with multiple STIX packages, to ensure that the entire scope of the
reporting is self-contained and relationships and history are not lost
should the receiver miss a transmission.   We also want to be able to
keep track of this information collection as a single tracked entity
because that is how it is tracked internally.    Those who are pushing
for the Report object, can still support all of their use cases without
the Report object.  While we understand that others may not have our use
case, please know that with the Report object, you have removed our
ability to support this use case.     (Although I understand rejecting
proposal
https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Emb
ed-Content
<https://github.com/STIXProject/schemas/wiki/Proposal%3A-Reports-Cannot-Em
bed-Content>   has potential to partially mitigate this).



Less Destructive Options:

In terms of examining other options (to the Report object), we believe
the following options should be examined much more thoroughly before such
a major change is made:



(A) create a STIX profile for report objects instead of trying to
redesign the entire spec to fit this one use case. The evolution and
development of each of the other STIX profiles did not involve pushes to
redesign STIX and inadequate research has been made into why that cannot
be done in this case.



(B) If the need is to distinguish between a STIX package with or without
contextual grouping, the addition of a flag that states whether or not
contextual-grouping=true is much less destructive to backwards
compatibility than the Report object.



Pam Smith

Systems Engineer

Johns Hopkins University Applied Physics Laboratory



--
Dr. Eric Burger
Director, Security and Software Engineering Research Center at Georgetown, <https://s2erc.georgetown.edu/>
Research Professor of Computer Science, <http://www.cs.georgetown.edu/~eburger/>
Skype: eburger
Mobile: 603-305-7886 (preferred)
Office: 202-687-4107
CALENDAR NOTE: please send invitations to [hidden email]
You may see responses and invitations come from that address.
PGP Public Key: 7AAEC917.asc
PGP Fingerprint: D0D8 0E8B EB30 B07B 14DF  3509 3CE3 0ED9 7AAE C917
S/MIME chain of trust should be InCommon, signed by UTN-USERFirst, root at AddTrust External CA Root (Comodo)
SHA1 Fingerprint: 82 A4 20 9F C0 C9 2C B1 B8 F0 15 79 A6 BD 2F CD 72 8A E2 57



signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Jordan, Bret
In reply to this post by Jason Keirstead
+1 Jason.  

On Jan 30, 2015, at 11:57 AM, Jason Keirstead <[hidden email]> wrote:
However, not all products will use all facets (in fact I would argue there will be very few products that operationalize all of STIX simultaneously, at least for the foreseeable future)


Most products over the next few years will use just a couple of the idioms.  IMHO, most vendors will be working with:   Indicators (and basic Cybox data) and basic Course of Action data.  But when you think of it, these idioms alone will allow for a lot of networking vendors to do a lot of great things. 

And as Jason has called out, some vendors may use other parts of STIX and IMO they will create wonderful additions to the market that will help us address cyber threats in ways we do not yet realize.  That is the beauty of STIX, it can do so much for so many people in so many different areas.


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 





signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Exploring Alternatives to Proposed Report Object

Jordan, Bret
In reply to this post by Terry MacDonald
Terry I like that idea.  If we have a pool of STIX data, it would be great to be able to just send the report data and reference already sent or existing objects.  


Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Jan 30, 2015, at 12:10 PM, Terry MacDonald <[hidden email]> wrote:

[+1]. Also why I believe relationships should be able to sent independently from the other STIX objects in stix v2.... But will leave that conversation for another thread.

Cheers
Terry MacDonald

On 30/01/2015 10:58 am, "Jason Keirstead" <[hidden email]> wrote:

There will be products that work with both the entities and the sources, and there will be products that only work with entities and for whom sources have little to no value, and there will be products that work primarily with the sources and for whom the entities have little value. A network-level blocking device who is simply using STIX as an instruction set may not care what the name of a set of indicators is because it has no user interface. A high level reporting tool that is visualizing threat trends, may not care what the underlying cybox observables were, because it never gets to that level of detail in anything in the product. STIX is an attempt at a very comprehensive standard... it is all-encompassing from a very highest level description of the threat to the lowest level of fidelity. However, not all products will use all facets (in fact I would argue there will be very few products that operationalize all of STIX simultaneously, at least for the foreseeable future). Therefore that whenever possible, facets of STIX should be structured so that they are as "optional" as possible... when things can be de-coupled, they should be... this is why I am in total agreement with the report object, it decouples these things that do not really need to be coupled.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

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


<graycol.gif>"Collie, Byron S." ---2015/01/30 02:41:44 PM---Part of the question is whether you are only attempting to track the STIX entities themselves or als

From: "Collie, Byron S." <[hidden email]>
To: <[hidden email]>
Date: 2015/01/30 02:41 PM
Subject: Re: [STIX] Exploring Alternatives to Proposed Report Object





Part of the question is whether you are only attempting to track the STIX entities themselves or also your sources. Once you starting tracking source and collection, doing actual analysis and measuring the efficacy and effectiveness of reporting, not just the embedded entities themselves, becomes critical. It also becomes critical when you have an information conflict between two sources and/or reports.  Mandiant says it’s APT28 (Russian) and CrowdStrike says it is Aurora Panda (Chinese) so the Source, Collection, Report tracking becomes critical in tracking these kinds of conflicts.
 
From: Eric Burger [[hidden email]]
Sent:
 Friday, January 30, 2015 12:38 PM
To:
 [hidden email]
Subject:
 Re: [STIX] Exploring Alternatives to Proposed Report Object
 
Agreed that when we put out building blocks, people are likely to figure out useful ways to put those blocks together. However, we will bifurcate the market if, once we learn common, useful ways to put those blocks together to produce the same things different ways. Report is one of those things that could be done different ways, and it was through experience some suggest that Report needs to be a first-class STIX element. I would offer that if we do decide Report is the way to go, that we update the envelope header documentation to mention that while you could use envelope information to get the Report functionality, and that some products do that, that behavior is not suggested and should go away over time.
    On Jan 30, 2015, at 12:29 AM, Aharon Chernin <[hidden email]> wrote: [emphasis Eric's]
     
    Q) Will we end up with products using either the STIX_Package reporting method or the Report method?
    A) Yes, it's likely. This is also not the only STIX function that can be done several different ways.
     
    Q) Report object, why?
    A) We see a STIX_Package as a wrapper or an envelope. Prior to the report object we were required to keep track of old envelopes as they contained things that envelopes shouldn't contain - like reporting and additional context. By moving this additional context to its own "report" object, we are able to do several things. One, now that report context is in it's own object, we can discard envelopes once processing has completed ( if a vendor decides to ). Two, we can reuse this report object over and over again. Three, it allows us to expand on the report object in the future to provide it more capabilities than it has today (imagine embedding an encoded document into the header of your STIX_Package vs inside a Report object). And finally, it's easier to describe how STIX works to the layperson ( we have all these objects for data, except for reporting - that goes in a STIX_Package header ).
     



signature.asc (858 bytes) Download Attachment