[STIX] Report Object Proposal

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

[STIX] Report Object Proposal

Wunder, John A.

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Joep Gommers
Dear list,

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

Some clarifications/questions/comments:
  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives
It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.
  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

There might be more then will come to mind which we’ll share at that time.

All the best,
Joep




From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Aharon

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email]

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [mailto:[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

 

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives

It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.

  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Joep Gommers
Agree on the need for explicit rather then implicit report content. In that respect, we fully support the creation of this object. This will allow us to “transport” information in STIX_Package and “transport” relationships within an Report Object.

J-

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [STIX] Report Object Proposal

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email]

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

 

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives

It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.

  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Otto Fowler
Hi everyone, 

Sorry if this is the wrong level for reply, but I just joined the list and this message is what I have.  Also please excuse me if any of this shows my ignorance since I am just beginning with Stix.

Why would the Report still be embedded within the STIX_Package if the STIX_Package is just content?  Wouldn’t there be a case where a Report may want to give context to multiple packages?   Wouldn’t embedding the Report into the STIX_Package tightly couple a Report or number of Reports with the STIX_Package they are embedded with?  Maybe I am missing the distinction here, but the STIX_Package still has more than content, you just moved it out of the header and into the report.  

Wouldn’t Reports be either a peer to the STIX_Package or there be a new wrapper inside of the package for content that would be a peer to Reports?

If Report was done as a peer to Package, you would almost imagine introducing it without changing Stix, or more specifically allowing Report references to existing STIX_Packages.

Would you ever just produce a report alone?  One that referenced other, already published STIX_Packages?  A consumer of multiple STIX_Packages may be able to add context between them and publish a report referring to those packages but not reproducing the content?

Again, I apologize if this somewhat ignorant.


Otto Fowler

Principal Software Engineer

Industrial Defender Solutions
Lockheed Martin Corporation
 
16 Chestnut Street, Suite 300, Foxborough, MA 02035
O  508-718-6726  | E  [hidden email]

On Sep 18, 2014, at 09:11 AM, Joep Gommers <[hidden email]> wrote:

Agree on the need for explicit rather then implicit report content. In that respect, we fully support the creation of this object. This will allow us to “transport” information in STIX_Package and “transport” relationships within an Report Object.

J-

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [STIX] Report Object Proposal

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.
  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.
DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin
Security Automation
DTCC Tampa
813-470-2173 | [hidden email]
 
<image001.jpg>
 
From: Joep Gommers [[hidden email]] 
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal
 
Dear list,
 
Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);
 
In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 
 
With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.
 
Some clarifications/questions/comments:
  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives
It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.
  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.
 
There might be more then will come to mind which we’ll share at that time.
 
All the best,
Joep
 
 
 
 
From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal
 
All,
 
During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).
 
In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:
 
o   Look at the samples, evaluate the advantages and disadvantages to the current state
o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.
·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.
·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options
o   Consider these hypotheticals:
§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?
§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?
 
We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.
 
Thanks,
 
John Wunder
STIX Project Team

DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
<image001.jpg>

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

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

I just wanted to offer some clarification on something that may not be clear to some.
That is that the current structure in STIX does actually support explicit report content in addition to implicit.
I have been seeing some misunderstanding on the list regarding this point during our discussion of this proposal.

Just to clarify:
  • A STIX_Package of content coming from a single producer at a given time has implicit context in that it all came from that producer at that time.
  • The STIX_Package structure also lets you specify explicit “report” context through the existing Package_Intent, Title, Description, Short_Description fields (these are the exact fields that are proposed to be moved from STIX_Package to a new Report object). If these are present, they are specifying explicit “report” content in that STIX_Package just as they would do in a separate Report object. 
  • The current structure also lets you specify STIX_Packages that define a “report” context but only contain references to other content rather than defining new content within them. We typically refer to these as “Manifest” Packages. This is the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.
  • The current structure also lets you specify a STIX_Package as a “wrapper” without any specific context that contains STIX content (Indicators, TTPs, etc.) and one or more “Manifest” Packages that define explicit context and reference the content in the “wrapper” Package. This is again, the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.

So, in summary, the Report Object proposal is not about adding new capability or filling some existing gap (you are able to do everything now that you would be able to do under the proposal). Rather, it is about a desire to clearly distinguish for human beings the difference between the use cases of STIX_Package as an “envelope” and STIX_Package as a “report”. For machines, this would currently be deterministically clear based on the presence or absence of the contextual fields on the STIX_Package but FS-ISAC feels humans may still be confused and potentially use the structure in ways they do not feel are appropriate. They are proposing that the outlined structural changes (along with identified implications outlined in the proposal document) are desirable to address this issue they feel strongly about.

Each stakeholder should weigh this proposal with careful consideration of their current and future needs, what capabilities and limitations exist in the current structure, what capabilities and limitations exist in the proposed structure, how the identified implications are likely to affect them and the community and all identified potential options. Based on these considerations they should form an opinion to support the proposal or not and let us all know what they think.

We are definitely interested in hearing everyone’s opinions.
We just want to make sure that such considerations are based on clear and accurate information with as little misunderstandings as possible.


Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent in my summary paragraph above.


Hopefully, this helps.

Sean

From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <[hidden email]>
Date: Thursday, September 18, 2014 at 9:11 AM
To: stix-discussion-list Structured Threat Information Expression/ST <[hidden email]>
Subject: Re: [STIX] Report Object Proposal

Agree on the need for explicit rather then implicit report content. In that respect, we fully support the creation of this object. This will allow us to “transport” information in STIX_Package and “transport” relationships within an Report Object.

J-

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [STIX] Report Object Proposal

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email]

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

 

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives

It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.

  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Wunder, John A.

I’m going to jump in here with a small request…if this proposal is something you support can you let us know what kind of priority you put on it? At this point we’re not just trying to figure out what to do, but also trying to figure out when to do it. In particular we’re looking for an answer to these questions:

 

1.       Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now as a minor release or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

2.       In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

The different options are here: https://github.com/STIXProject/schemas/wiki/Report-Object-Options. If you feel these options aren’t enough and we’re missing an obvious course of action let us know.

 

Thanks,

John

 

From: Barnum, Sean D. [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 12:37 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Hi Joep,

 

I just wanted to offer some clarification on something that may not be clear to some.

That is that the current structure in STIX does actually support explicit report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point during our discussion of this proposal.

 

Just to clarify:

  • A STIX_Package of content coming from a single producer at a given time has implicit context in that it all came from that producer at that time.
  • The STIX_Package structure also lets you specify explicit “report” context through the existing Package_Intent, Title, Description, Short_Description fields (these are the exact fields that are proposed to be moved from STIX_Package to a new Report object). If these are present, they are specifying explicit “report” content in that STIX_Package just as they would do in a separate Report object. 
  • The current structure also lets you specify STIX_Packages that define a “report” context but only contain references to other content rather than defining new content within them. We typically refer to these as “Manifest” Packages. This is the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.
  • The current structure also lets you specify a STIX_Package as a “wrapper” without any specific context that contains STIX content (Indicators, TTPs, etc.) and one or more “Manifest” Packages that define explicit context and reference the content in the “wrapper” Package. This is again, the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.

 

So, in summary, the Report Object proposal is not about adding new capability or filling some existing gap (you are able to do everything now that you would be able to do under the proposal). Rather, it is about a desire to clearly distinguish for human beings the difference between the use cases of STIX_Package as an “envelope” and STIX_Package as a “report”. For machines, this would currently be deterministically clear based on the presence or absence of the contextual fields on the STIX_Package but FS-ISAC feels humans may still be confused and potentially use the structure in ways they do not feel are appropriate. They are proposing that the outlined structural changes (along with identified implications outlined in the proposal document) are desirable to address this issue they feel strongly about.

 

Each stakeholder should weigh this proposal with careful consideration of their current and future needs, what capabilities and limitations exist in the current structure, what capabilities and limitations exist in the proposed structure, how the identified implications are likely to affect them and the community and all identified potential options. Based on these considerations they should form an opinion to support the proposal or not and let us all know what they think.

 

We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and accurate information with as little misunderstandings as possible.

 

 

Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent in my summary paragraph above.

 

 

Hopefully, this helps.

 

Sean

 

From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <[hidden email]>
Date: Thursday, September 18, 2014 at 9:11 AM
To: stix-discussion-list Structured Threat Information Expression/ST <[hidden email]>
Subject: Re: [STIX] Report Object Proposal

 

Agree on the need for explicit rather then implicit report content. In that respect, we fully support the creation of this object. This will allow us to “transport” information in STIX_Package and “transport” relationships within an Report Object.

 

J-

 

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [STIX] Report Object Proposal

 

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email]

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

 

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives

It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.

  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Katz, Gary
In reply to this post by Barnum, Sean D.
STIX Community,
     I apologize for my late inputs into the discussion.  After reviewing
the Report object proposal, we recommend MITRE’s Option 4: Implementing the
proposal via a profile to restrict the fields that are allowed in the
top-level STIX_Package.  There are a number of reasons for not removing
context from STIX_Package and separating it into a new Report object.  


1. Increases Complexity: In the current STIX framework, the user can
include any amount of context that they wish, without having to go through
creating a new Report object to link information together.  Having to create
a separate object to hold this context is an increase in complexity rather
than representing that information in the current constructs.  While the
creation of the Report object may reduce complexity for certain
implementations of a database, the STIX framework is implementation agnostic
and should not be significantly changed to meet certain users or groups of
users.

2. Breaking backwards compatibility: While major releases are allowed
to break backwards compatibility, such a change should still be avoided if
possible.  There are many systems currently deployed and many more still
that are currently in development, a real cost exists to changing these
systems that could be avoided through other options.  Performing a change to
the STIX structure that could otherwise be achieved through using the
current constructs is ill-advised.  If the community wishes to increase the
adoption of STIX then we need to show that the language is stable.
Increasing volatility will reduce adoption and be counterproductive to the
overall goal of STIX, increasing information sharing.

3. Decreasing Reporting: Breaking relationships into a separate
construct creates additional work for the producer (and consumer).  If a
producer only has a small number of relationships in their data, they may
choose to simply leave the context out of the STIX document rather than
creating a separate Report object.  You also run the risk of individuals
viewing the Report construct as showing that you have compiled enough
information to make a formal ‘report’ and anything less than a formal report
should not include a Report object, resulting in recipients of the
information receiving less information than they otherwise would have.  

4. Limiting the usability of STIX:  The proposal makes the assumption
that there are two and only two use cases for STIX.  This may be an
incorrect assumption.  By breaking out how STIX can be used, to convey raw
data or to convey a report, it reduces the ability for STIX to be applied to
new use cases.  If there is a new use case that organizations come up with,
does that imply that a new construct, similar to Report, must be created to
support that new use case?  In the current implementation of STIX, there is
no assumption about how the information will be used, it only states how
information is stored.  Similarly to the English language, if I needed to
say “Conversation” every time I started talking to someone and “Book” every
time I wrote a book, would it then discourage using English for a Blog?
What about a Twitter message?

An example of this issue relates to STIX responding to a TAXII query.
Currently a user can respond to a TAXII query by simply including any
information (within a profile) that fits the parameter of the query.  With
the proposed changes, I am not sure how I would respond to a TAXII query.
The response to a TAXII query is not a ‘report’ but can contain more than
raw data.  Categorizing it as a “Report” object, may imply certain
characteristics to the data, which may not actually exist. Limiting the
usage of STIX based upon the use cases that we have devised during the
initial years of its creation, will stunt future creativity in how STIX can
be used to support the cyber security community.

I hope this provides some additional perspective on some of the issues with
the proposed Report object.  While I do not speak for the national cyber
centers, I have engaged with multiple counterparts at other agencies who
have similar concerns with the proposal.  I would suggest leveraging some of
the current constructs within STIX that meet the needs this proposal hopes
to address, rather than introducing the Report object into STIX.

Thank you,

    Gary Katz
    Chief Architect Ctr.
    Technology Solutions Development
    Defense Cyber Crime Center



-----Original Message-----
From: Barnum, Sean D. [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 12:37 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

Hi Joep,

I just wanted to offer some clarification on something that may not be clear
to some.
That is that the current structure in STIX does actually support explicit
report content in addition to implicit.
I have been seeing some misunderstanding on the list regarding this point
during our discussion of this proposal.

Just to clarify:

* A STIX_Package of content coming from a single producer at a given
time has implicit context in that it all came from that producer at that
time.
* The STIX_Package structure also lets you specify explicit “report”
context through the existing Package_Intent, Title, Description,
Short_Description fields (these are the exact fields that are proposed to be
moved from STIX_Package to a new Report object). If these are present, they
are specifying explicit “report” content in that STIX_Package just as they
would do in a separate Report object.
* The current structure also lets you specify STIX_Packages that
define a “report” context but only contain references to other content
rather than defining new content within them. We typically refer to these as
“Manifest” Packages. This is the same use structure as is being proposed for
the new Report object. The only difference is that it is called
STIX_Package, not Report.
* The current structure also lets you specify a STIX_Package as a
“wrapper” without any specific context that contains STIX content
(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define
explicit context and reference the content in the “wrapper” Package. This is
again, the same use structure as is being proposed for the new Report
object. The only difference is that it is called STIX_Package, not Report.


So, in summary, the Report Object proposal is not about adding new
capability or filling some existing gap (you are able to do everything now
that you would be able to do under the proposal). Rather, it is about a
desire to clearly distinguish for human beings the difference between the
use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.
For machines, this would currently be deterministically clear based on the
presence or absence of the contextual fields on the STIX_Package but FS-ISAC
feels humans may still be confused and potentially use the structure in ways
they do not feel are appropriate. They are proposing that the outlined
structural changes (along with identified implications outlined in the
proposal document
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
ject-as-Minor-Release> ) are desirable to address this issue they feel
strongly about.

Each stakeholder should weigh this proposal with careful consideration of
their current and future needs, what capabilities and limitations exist in
the current structure, what capabilities and limitations exist in the
proposed structure, how the identified implications are likely to affect
them and the community and all identified potential options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> . Based
on these considerations they should form an opinion to support the proposal
or not and let us all know what they think.

We are definitely interested in hearing everyone’s opinions.
We just want to make sure that such considerations are based on clear and
accurate information with as little misunderstandings as possible.


Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent
in my summary paragraph above.


Hopefully, this helps.

Sean

From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <[hidden email]>
Date: Thursday, September 18, 2014 at 9:11 AM
To: stix-discussion-list Structured Threat Information Expression/ST
<[hidden email]>
Subject: Re: [STIX] Report Object Proposal


Agree on the need for explicit rather then implicit report content. In that
respect, we fully support the creation of this object. This will allow us to
“transport” information in STIX_Package and “transport” relationships within
an Report Object.

J-

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <[hidden email]>,
"[hidden email]"
<[hidden email]>
Subject: RE: [STIX] Report Object Proposal



I can see how users can easily be confused about the need for the report
object. The functionality exists today within the STIX_Header, primarily
within the Title and Description field. Our opinion is that this is easy for
content creators to abuse (they don’t have to think about using the correct
STIX object), and doesn’t make sense given the high level object pattern
already in use by STIX today. We also believe that report content should be
explicit instead of implicit, which is how report context is done today
using STIX_Package. Technically this allows us to split explicit
relationships of objects  from the STIX_Package and allow us to use the
STIX_Package just as a container for our STIX “object soup”.

* Are we understanding correctly that the Report object would carry
contextual meta-data itself, and reference other STIX components as being
“part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to
explicitly reference report context between STIX objects without having to
infer it from a STIX_Package. Adding additional fields to the report object
at the same time as we are adding the report object increases complexity and
confusion for the community. At this stage of the game we are just trying to
get “buy-in” from the community that a report object should exist. Once we
succeed, I think it would be appropriate to discuss adding the elements to
the object that you are proposing.

* We foresee that confidence statements, estimate statements and
handling constraints that become relevant on paragraphs rather then
“reports”. Are we correct in saying that we can “abuse” multiple “report”
objects for this use-case? Would there be opportunities to create “analysis
paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are
adding the report object increases complexity and confusion for the
community. If agreed upon by the community, the report object could support
this type of functionality in the future.

* If the Report Object is a contextual wrapper (with a specific
purpose) of a group of STIX components, isn’t the Incident Object the same?
If we look at the workflows of the key “actors”/“user types” that are
working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators
(don’t sue me if I forgot one) and focuses on providing incident detail
only. The report object can reference any STIX high level object and provide
any report like context that you wish to provide. In the future we can
continue to expand the functionality of the report object so that it further
differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email] <mailto:[hidden email]>

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [mailto:[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started
with STIX);

 

In our view STIX allows for a conceptual graph-like representation of,
predominantly, “red” (vs “blue”), components of a target model and its
intended or realized impact (and possibly course of action). If we take the
time to “deconstruct” and “construct” from our graph to STIX traffic. It
allows us to share STIX components and how they inter-relate. One of the
problems we’re struggling with is exactly what “Report Object” is here to
solve. A wrapper for some of the components in a target model and their
relationships, together with the analysis of how we came about those
estimations/conclusions. We strongly support its use-case.

 

With regards to impact of changing current systems to comply with these
changes. STIX has a long way to go and we would prefer bigger changes (not
rushed) as soon as possible, before the ecosystem of software (at Intelworks
or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

* Are we understanding correctly that the Report object would carry
contextual meta-data itself, and reference other STIX components as being
“part of” that contextual wrapper. We’d look to be able to add to its META:

        * Title(s)
        * Key-Points (could be embedded in analysis)
        * Analysis/Description
        * Tags (some free-form way of assigning different dimensions
for software use such as ‘part of which category of problem’, ‘has to do
with..’, etc.)
        * Confidence statements (not on source, but analysis/analyst)
        * Information cut-off (as apposed to “publish” or
“distribution” dates (could be embedded in analysis)
        * External references

* We foresee that confidence statements, estimate statements and
handling constraints that become relevant on paragraphs rather then
“reports”. Are we correct in saying that we can “abuse” multiple “report”
objects for this use-case? Would there be opportunities to create “analysis
paragraphs” with their own META inside a STIX report object.
* If the Report Object is a contextual wrapper (with a specific
purpose) of a group of STIX components, isn’t the Incident Object the same?
If we look at the workflows of the key “actors”/“user types” that are
working with cyber intelligence in large enterprises we identify:

        * Security Operations
        * CERT (usually network related investigations)
        * Revenue Assurance / Anti-Fraud
        * Investigations (in context of revenue assurance/fraud)
        * Intelligence Analysts
        * Warfare Commanders (cyber or otherwise)
        * Risk Analysts / Managers
        * Decision makers
        * Executives

        It seems that “Report Object” might be the same for an intelligence
analysts as “Incident Object” would be for an incident handler. Might there
be other “Contextual wrappers” relevant for other types of consumers that
are currently out-of-scope. Would simple a “wrapper” that can be of
different META and of different purpose be an option? Without having to
extent STIX every time there is a new “contextual” concept required.

* If the “Report Object” is to represent an “Intelligence Report” of
sorts. It might, depending on the type of conflict it covers, have relevance
to different use-cases and in “storing it for later use” not be conflated
with other information. For example strategic intelligence for the purposes
of budget planning or tactical current intelligence for the purposes of
crisis management or immediate detection. Widely different use-cases and
we’d want to ensure that we can earmark “Reports” (contextual meta related
to STIX objects) as such. Current intelligence is something that is relevant
for integration in detection tools, some information mentioned in a
strategic report – far from. We don’t want humans as the bottleneck, so as
much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]"
<[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past
year or so FS-ISAC has brought up the idea of adding a new “Report Object”
to STIX (note: this not a CybOX object, it would be a STIX major construct
at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language
is headed, we’d like to continue that discussion with one final list thread
where we hopefully come to rough consensus on the way forward. So, to that
end:

 

·         Read the proposal:
https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
ect-as-Minor-Release
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
ject-as-Minor-Release>

o   Look at the samples, evaluate the advantages and disadvantages to the
current state

o   Consider the impact of changing your systems to the proposed state,
including advantages as pointed out by FS-ISAC but also costs in terms of
implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond!
Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together:
https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your
preferred option? Is it worth the added capabilities to implement the
FS-ISAC proposal now or should it wait to the major release to minimize the
minor release implications? When would you like to see the process for the
minor release started?

§  In your ideal world, what course of action would you take? Implement it
as a minor release now? Not implement it at all? Implement it as a major
release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user
organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

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

Re: [STIX] Report Object Proposal

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

This is very helpful and not obvious from the concepts or other documentation, this might however be my inexperience with STIX and not knowing where to look.

Practically, option 4 (profiles) are in the context of Sean’s and Gary's response an attractive option. We see many use-cases for STIX and an intelligence report is just one of them. STIX is after all, trying to be allot of things to allot of people (revenue assurance, incident response, security operations, intelligence analysis, etc.).

I do wonder if an “intelligence report”, being context and explicit relationships between STIX objects, isn’t similar to an “incident” and possibly in the future constructs such as “fraud” or “investigation” or really any other type of target modeling relevant to a specific group of people/processes. I’d definitely be a proponent of moving (and allowing many more) context constructs in profiles, while keeping the “soup” in STIX.

So personally I’d say;
IF we intent to “grow” the META-data of STIX_Package to be more then just simple descriptions in the near future – but more relevant to intelligence reporting and
IF we can agree clearly on what constructs should be in a profile and what will be native to STIX (again, “incident” confuses me in this regard)
IF profiles will be versioned and maintain as rigorously as STIX itself (it can make or break software)

Then I totally understand the attractiveness of option 4/profiles.

Love to hear more viewpoints.

Best regards,
Joep



From: <Barnum>, "Sean D." <[hidden email]>
Date: Thursday, September 18, 2014 at 6:37 PM
To: Joep Gommers <[hidden email]>, stix-discussion-list Structured Threat Information Expression/ST <[hidden email]>
Subject: Re: [STIX] Report Object Proposal

Hi Joep,

I just wanted to offer some clarification on something that may not be clear to some.
That is that the current structure in STIX does actually support explicit report content in addition to implicit.
I have been seeing some misunderstanding on the list regarding this point during our discussion of this proposal.

Just to clarify:
  • A STIX_Package of content coming from a single producer at a given time has implicit context in that it all came from that producer at that time.
  • The STIX_Package structure also lets you specify explicit “report” context through the existing Package_Intent, Title, Description, Short_Description fields (these are the exact fields that are proposed to be moved from STIX_Package to a new Report object). If these are present, they are specifying explicit “report” content in that STIX_Package just as they would do in a separate Report object. 
  • The current structure also lets you specify STIX_Packages that define a “report” context but only contain references to other content rather than defining new content within them. We typically refer to these as “Manifest” Packages. This is the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.
  • The current structure also lets you specify a STIX_Package as a “wrapper” without any specific context that contains STIX content (Indicators, TTPs, etc.) and one or more “Manifest” Packages that define explicit context and reference the content in the “wrapper” Package. This is again, the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.

So, in summary, the Report Object proposal is not about adding new capability or filling some existing gap (you are able to do everything now that you would be able to do under the proposal). Rather, it is about a desire to clearly distinguish for human beings the difference between the use cases of STIX_Package as an “envelope” and STIX_Package as a “report”. For machines, this would currently be deterministically clear based on the presence or absence of the contextual fields on the STIX_Package but FS-ISAC feels humans may still be confused and potentially use the structure in ways they do not feel are appropriate. They are proposing that the outlined structural changes (along with identified implications outlined in the proposal document) are desirable to address this issue they feel strongly about.

Each stakeholder should weigh this proposal with careful consideration of their current and future needs, what capabilities and limitations exist in the current structure, what capabilities and limitations exist in the proposed structure, how the identified implications are likely to affect them and the community and all identified potential options. Based on these considerations they should form an opinion to support the proposal or not and let us all know what they think.

We are definitely interested in hearing everyone’s opinions.
We just want to make sure that such considerations are based on clear and accurate information with as little misunderstandings as possible.


Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent in my summary paragraph above.


Hopefully, this helps.

Sean

From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <[hidden email]>
Date: Thursday, September 18, 2014 at 9:11 AM
To: stix-discussion-list Structured Threat Information Expression/ST <[hidden email]>
Subject: Re: [STIX] Report Object Proposal

Agree on the need for explicit rather then implicit report content. In that respect, we fully support the creation of this object. This will allow us to “transport” information in STIX_Package and “transport” relationships within an Report Object.

J-

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [STIX] Report Object Proposal

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email]

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

 

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives

It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.

  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Aharon
In reply to this post by Katz, Gary

On complexity: The report object is an additional object that will need to be used, and in turn will require that applications generating STIX content will need to facilitate a method of interacting with it.

 

On backwards compatibility: All content created before the report object will still function properly. Mitre and FS-ISAC agree that this is a backwards compatible change. On another note, at this early stage of STIX, let’s do the big changes now versus two years from now when our ability to innovate and change the language is hindered due to mass adoption.

 

Decreased reporting: This is subjective. If we do not create a report object, we could also make the argument that additional context provided within the STIX_Header is crippled due to a machines inability to determine the type of context being provided. If we put “Hello World” into the title of a STIX_Header, all that I know is that Hello World should somehow be implied to the objects in the STIX_Package. If we put Hello World in the title of a report object, now the machines know that this is being used in a report context and can react as such. I agree that some context is better than no context, but the type of context allows us to create tools with STIX that do things with the data other than display it on a page. The creation of a report object also allows analysts to update the human readable portions of a report, regardless of the STIX objects used within the STIX_Package or the STIX_Package in general. This change may actually increase reporting.

 

Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections

 

Aharon

 

 

-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object. 

 

 

1.            Increases Complexity: In the current STIX framework, the user can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.

 

2.            Breaking backwards compatibility: While major releases are allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.

 

3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have. 

 

4.            Limiting the usability of STIX:  The proposal makes the assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?

 

An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.

 

I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.

 

Thank you,

 

    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center

 

 

 

-----Original Message-----

From: Barnum, Sean D. [[hidden email]]

Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]

Subject: Re: [STIX] Report Object Proposal

 

Hi Joep,

 

I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.

 

Just to clarify:

 

*              A STIX_Package of content coming from a single producer at a given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit “report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.

 

 

So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.

 

Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> . Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.

 

We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.

 

 

Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.

 

 

Hopefully, this helps.

 

Sean

 

From: Joep Gommers <[hidden email]>

Reply-To: Joep Gommers <[hidden email]>

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]>

Subject: Re: [STIX] Report Object Proposal

 

 

Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.

 

J-

 

From: <Chernin>, "Michael A." <[hidden email]>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email]>,

"[hidden email]"

<[hidden email]>

Subject: RE: [STIX] Report Object Proposal

 

 

 

I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.

 

*              Are we understanding correctly that the Report object would carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:

 

I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.

 

*              We foresee that confidence statements, estimate statements and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

 

Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.

 

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:

 

The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.

 

DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin

 

Security Automation

 

DTCC Tampa

 

813-470-2173 | [hidden email] <[hidden email]>

 

 

<a href="cid:image002.jpg@01CF111C.3642D5E0">cid:image002.jpg@01CF111C.3642D5E0

 

 

From: Joep Gommers [[hidden email]]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]

Subject: Re: [STIX] Report Object Proposal

 

 

Dear list,

 

 

Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);

 

 

In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.

 

 

With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.

 

 

Some clarifications/questions/comments:

 

*              Are we understanding correctly that the Report object would carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:

 

                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but analysis/analyst)

                *              Information cut-off (as apposed to “publish” or

“distribution” dates (could be embedded in analysis)

                *              External references

 

*              We foresee that confidence statements, estimate statements and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:

 

                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives

 

                It seems that “Report Object” might be the same for an intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.

 

*              If the “Report Object” is to represent an “Intelligence Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.

 

 

There might be more then will come to mind which we’ll share at that time.

 

 

All the best,

 

Joep

 

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>

Reply-To: "Wunder, John A." <[hidden email]>

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]"

<[hidden email]>

Subject: [STIX] Report Object Proposal

 

 

All,

 

 

During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).

 

 

In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:

 

 

·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj

ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>

 

o   Look at the samples, evaluate the advantages and disadvantages to the

current state

 

o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.

 

·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.

 

·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

 

o   Consider these hypotheticals:

 

§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?

 

§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?

 

 

We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.

 

 

Thanks,

 

 

John Wunder

 

STIX Project Team

 

 

DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Katz, Gary
Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.  


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.  

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.  
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.  

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.  

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.  

Based on the below response I did not see how a profile would not suit the
use cases described.  

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.

 

On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.

 

Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.

 

Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections

 

Aharon

 

 

-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.  

 

 

1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.

 

2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.

 

3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.  

 

4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?

 

An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.

 

I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.

 

Thank you,

 

    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center

 

 

 

-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>

Subject: Re: [STIX] Report Object Proposal

 

Hi Joep,

 

I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.

 

Just to clarify:

 

*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.

 

 

So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.

 

Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.

 

We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.

 

 

Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.

 

 

Hopefully, this helps.

 

Sean

 

From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal

 

 

Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.

 

J-

 

From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: RE: [STIX] Report Object Proposal

 

 

 

I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.

 

*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:

 

I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.

 

*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

 

Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.

 

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:

 

The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.

 

DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin

 

Security Automation

 

DTCC Tampa

 

813-470-2173 | [hidden email] <mailto:[hidden email]>
<mailto:[hidden email] <mailto:[hidden email]> >

 

 

cid:image002.jpg@01CF111C.3642D5E0

 

 

From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>

Subject: Re: [STIX] Report Object Proposal

 

 

Dear list,

 

 

Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);

 

 

In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.

 

 

With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.

 

 

Some clarifications/questions/comments:

 

*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:

 

                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references

 

*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:

 

                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives

 

                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.

 

*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.

 

 

There might be more then will come to mind which we’ll share at that time.

 

 

All the best,

 

Joep

 

 

 

 

 

From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal

 

 

All,

 

 

During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).

 

 

In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:

 

 

·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>

ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>

 

o   Look at the samples, evaluate the advantages and disadvantages to the

current state

 

o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.

 

·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.

 

·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >

 

o   Consider these hypotheticals:

 

§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?

 

§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?

 

 

We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.

 

 

Thanks,

 

 

John Wunder

 

STIX Project Team

 

 

DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

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

Re: [STIX] Report Object Proposal

Terry MacDonald
Hi All,

I must say I was originally of the opinion that things should stay the same... that effectively the current version can convey the 'Report'  information. I was very skeptical. But after listening to both sides during the last call, I'm a convert.

On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

I don't see the addition of a Report object as adding too much complexity. To me, it cleans things up. Its a delineation between the the container that the STIX information rides in, and extra information about other objects within that container. Having the new Report object will allow consumers to look for the existence of the Report object, and the mere existence of the Report object proves that the producer was providing an explicit report. At present there is no easy way to determine if the STIX package header information that a consumer provides is just an automatically generated or contains a name that describes all the package. 

I don't see how the use of a profile will make it easier for new participants to understand where "Report-like" information goes. Creating a new separate Report object on the other hand will. New participants in this space will know where Report nformation goes, without having to know the whole backstory about why it goes where it goes. If they want to write a report, then it goes in the Report object. Job done. 

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Which is exactly spelt out in the STIX versioning scheme listed here: http://stix.mitre.org/language/versioning_policy.html. Major version updates will break your code. It just will. That's why having the migration period will allow the best of both worlds. If you don't want to add the report object processing/generation, then don't. Just use the existing functionality and set the STIX version to the 1.1.1. 

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

If you are a producer and don't want to generate the new content then you need to advertise that you only support STIX 1.1.1 (or whatever version you wish to generate). Same for a client. If a consumer/producer does want to support the latest standards then of course it will require code modification to do so, and you are right that it will require understanding report data in both places (at least in the transition timeframe), but any support of a new version of STIX will require code changes. The fact that a new STIX version has been released indicates modification is required to support the new STIX version. Its always been that way in any standard I can think of.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

It's exactly this ambiguity that I think the Report object fixes. Having an object called Report is exactly the place that people will look to put information about report data. 

Having the ability for that report object to span across STIX packages I think increases flexibility for transport mechanisms. It then supports long running communication sessions (which I believe is a core part of why FS-ISAC want this).

And having a separate Report object gives us a place to expand the information in the report to be more structured in the future if required. 
 
Cheers
Terry MacDonald

On 20 September 2014 06:57, Katz, Gary Contractor DC3 <[hidden email]> wrote:
Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.

Based on the below response I did not see how a profile would not suit the
use cases described.

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.



On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.



Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.



Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections



Aharon





-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal



STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.





1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.



2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.



3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.



4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?



An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.



I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.



Thank you,



    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center







-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>

Subject: Re: [STIX] Report Object Proposal



Hi Joep,



I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.



Just to clarify:



*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.





So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.



Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.



We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.





Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.





Hopefully, this helps.



Sean



From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal





Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.



J-



From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: RE: [STIX] Report Object Proposal







I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.



Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.



*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.



DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin



Security Automation



DTCC Tampa



813-470-2173 | [hidden email] <mailto:[hidden email]>
<mailto:[hidden email] <mailto:[hidden email]> >





cid:image002.jpg@01CF111C.3642D5E0





From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>

Subject: Re: [STIX] Report Object Proposal





Dear list,





Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);





In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.





With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.





Some clarifications/questions/comments:



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives



                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.



*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.





There might be more then will come to mind which we’ll share at that time.





All the best,



Joep











From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal





All,





During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).





In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:





·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>

ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>



o   Look at the samples, evaluate the advantages and disadvantages to the

current state



o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.



·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.



·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >



o   Consider these hypotheticals:



§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?



§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?





We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.





Thanks,





John Wunder



STIX Project Team





DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Foley, Alexander - GIS

Is there a survey up or some sort of vote-taking apparatus on all of the options?

 

We definitely believe that creating a report object will help clear up the confusion / ambiguity created by placing full text analysis in the name / description fields.  It will be far easier to try to develop best practices if we have clear places to put things.  It might be nice to reach consensus on this issue before trying to figure out when exactly to make the change.

 

Thanks,

 

Alex

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Saturday, September 20, 2014 9:07 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Hi All,

 

I must say I was originally of the opinion that things should stay the same... that effectively the current version can convey the 'Report'  information. I was very skeptical. But after listening to both sides during the last call, I'm a convert.

 

On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

 

I don't see the addition of a Report object as adding too much complexity. To me, it cleans things up. Its a delineation between the the container that the STIX information rides in, and extra information about other objects within that container. Having the new Report object will allow consumers to look for the existence of the Report object, and the mere existence of the Report object proves that the producer was providing an explicit report. At present there is no easy way to determine if the STIX package header information that a consumer provides is just an automatically generated or contains a name that describes all the package. 

 

I don't see how the use of a profile will make it easier for new participants to understand where "Report-like" information goes. Creating a new separate Report object on the other hand will. New participants in this space will know where Report nformation goes, without having to know the whole backstory about why it goes where it goes. If they want to write a report, then it goes in the Report object. Job done. 

 

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

 

Which is exactly spelt out in the STIX versioning scheme listed here: http://stix.mitre.org/language/versioning_policy.html. Major version updates will break your code. It just will. That's why having the migration period will allow the best of both worlds. If you don't want to add the report object processing/generation, then don't. Just use the existing functionality and set the STIX version to the 1.1.1. 

 

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

 

If you are a producer and don't want to generate the new content then you need to advertise that you only support STIX 1.1.1 (or whatever version you wish to generate). Same for a client. If a consumer/producer does want to support the latest standards then of course it will require code modification to do so, and you are right that it will require understanding report data in both places (at least in the transition timeframe), but any support of a new version of STIX will require code changes. The fact that a new STIX version has been released indicates modification is required to support the new STIX version. Its always been that way in any standard I can think of.

 

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

 

It's exactly this ambiguity that I think the Report object fixes. Having an object called Report is exactly the place that people will look to put information about report data. 

 

Having the ability for that report object to span across STIX packages I think increases flexibility for transport mechanisms. It then supports long running communication sessions (which I believe is a core part of why FS-ISAC want this).

 

And having a separate Report object gives us a place to expand the information in the report to be more structured in the future if required. 

 

Cheers
Terry MacDonald

 

On 20 September 2014 06:57, Katz, Gary Contractor DC3 <[hidden email]> wrote:

Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.

Based on the below response I did not see how a profile would not suit the
use cases described.

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.



On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.



Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.



Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections



Aharon





-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal



STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.





1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.



2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.



3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.



4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?



An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.



I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.



Thank you,



    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center







-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal



Hi Joep,



I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.



Just to clarify:



*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.





So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.



Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.



We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.





Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.





Hopefully, this helps.



Sean


From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal





Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.



J-



From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >


Subject: RE: [STIX] Report Object Proposal







I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.



Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.



*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.



DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin



Security Automation



DTCC Tampa



813-470-2173 | [hidden email] <mailto:[hidden email]>

<mailto:[hidden email] <mailto:[hidden email]> >





<a href="cid:image002.jpg@01CF111C.3642D5E0">cid:image002.jpg@01CF111C.3642D5E0





From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal





Dear list,





Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);





In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.





With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.





Some clarifications/questions/comments:



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives



                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.



*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.





There might be more then will come to mind which we’ll share at that time.





All the best,



Joep










From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal





All,





During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).





In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:





·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>


ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>



o   Look at the samples, evaluate the advantages and disadvantages to the

current state



o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.



·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.



·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >



o   Consider these hypotheticals:



§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?



§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?





We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.





Thanks,





John Wunder



STIX Project Team





DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

 


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

Re: [STIX] Report Object Proposal

Wunder, John A.

Alex,

 

We plan to collect opinions via e-mail, you have three options:

 

·         Send an e-mail to the public list at [hidden email]

·         Send an e-mail to the internal STIX team ([hidden email]) to have us anonymize it and pass it on to the public list

·         Send an e-mail to the internal STIX team ([hidden email]) for us to track internally but not to pass on to the public list

 

While discussion questions and thoughts are always encouraged it’s also fine to send a simple +1/-1 or vote among the 5 options we outlined.

 

Note that the decision will be made based on rough consensus rather than a literal counting of the votes.

 

John

 

From: Foley, Alexander [mailto:[hidden email]]
Sent: Monday, September 22, 2014 1:31 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Is there a survey up or some sort of vote-taking apparatus on all of the options?

 

We definitely believe that creating a report object will help clear up the confusion / ambiguity created by placing full text analysis in the name / description fields.  It will be far easier to try to develop best practices if we have clear places to put things.  It might be nice to reach consensus on this issue before trying to figure out when exactly to make the change.

 

Thanks,

 

Alex

 

From: Terry MacDonald [[hidden email]]
Sent: Saturday, September 20, 2014 9:07 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Hi All,

 

I must say I was originally of the opinion that things should stay the same... that effectively the current version can convey the 'Report'  information. I was very skeptical. But after listening to both sides during the last call, I'm a convert.

 

On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

 

I don't see the addition of a Report object as adding too much complexity. To me, it cleans things up. Its a delineation between the the container that the STIX information rides in, and extra information about other objects within that container. Having the new Report object will allow consumers to look for the existence of the Report object, and the mere existence of the Report object proves that the producer was providing an explicit report. At present there is no easy way to determine if the STIX package header information that a consumer provides is just an automatically generated or contains a name that describes all the package. 

 

I don't see how the use of a profile will make it easier for new participants to understand where "Report-like" information goes. Creating a new separate Report object on the other hand will. New participants in this space will know where Report nformation goes, without having to know the whole backstory about why it goes where it goes. If they want to write a report, then it goes in the Report object. Job done. 

 

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

 

Which is exactly spelt out in the STIX versioning scheme listed here: http://stix.mitre.org/language/versioning_policy.html. Major version updates will break your code. It just will. That's why having the migration period will allow the best of both worlds. If you don't want to add the report object processing/generation, then don't. Just use the existing functionality and set the STIX version to the 1.1.1. 

 

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

 

If you are a producer and don't want to generate the new content then you need to advertise that you only support STIX 1.1.1 (or whatever version you wish to generate). Same for a client. If a consumer/producer does want to support the latest standards then of course it will require code modification to do so, and you are right that it will require understanding report data in both places (at least in the transition timeframe), but any support of a new version of STIX will require code changes. The fact that a new STIX version has been released indicates modification is required to support the new STIX version. Its always been that way in any standard I can think of.

 

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

 

It's exactly this ambiguity that I think the Report object fixes. Having an object called Report is exactly the place that people will look to put information about report data. 

 

Having the ability for that report object to span across STIX packages I think increases flexibility for transport mechanisms. It then supports long running communication sessions (which I believe is a core part of why FS-ISAC want this).

 

And having a separate Report object gives us a place to expand the information in the report to be more structured in the future if required. 

 

Cheers
Terry MacDonald

 

On 20 September 2014 06:57, Katz, Gary Contractor DC3 <[hidden email]> wrote:

Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.

Based on the below response I did not see how a profile would not suit the
use cases described.

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.



On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.



Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.



Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections



Aharon





-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal



STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.





1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.



2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.



3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.



4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?



An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.



I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.



Thank you,



    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center







-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal



Hi Joep,



I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.



Just to clarify:



*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.





So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.



Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.



We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.





Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.





Hopefully, this helps.



Sean

From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal





Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.



J-



From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >


Subject: RE: [STIX] Report Object Proposal







I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.



Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.



*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.



DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin



Security Automation



DTCC Tampa



813-470-2173 | [hidden email] <mailto:[hidden email]>

<mailto:[hidden email] <mailto:[hidden email]> >





<a href="cid:image002.jpg@01CF111C.3642D5E0">cid:image002.jpg@01CF111C.3642D5E0





From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal





Dear list,





Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);





In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.





With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.





Some clarifications/questions/comments:



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives



                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.



*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.





There might be more then will come to mind which we’ll share at that time.





All the best,



Joep









From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal





All,





During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).





In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:





·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>


ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>



o   Look at the samples, evaluate the advantages and disadvantages to the

current state



o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.



·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.



·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >



o   Consider these hypotheticals:



§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?



§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?





We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.





Thanks,





John Wunder



STIX Project Team





DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

 


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

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Wunder, John A.

Along those lines, we had a request to anonymize and pass along the following message (forwarded w/o modification):

 

Questions:

1)      How will the use of a Report help if the contain is unrelated? (see GitHub example)

2)      If the document contains a Report, do I need to parse the other Top Level Objects?

·         The attached example.xml contains 2 indicators 1 TTP and 1 Report. The Report contains 1 of the Indicators embedded in the document along with the embedded TTP. What should the process be for handling the remaining Indicator contained in the document but not in the Report?

 

From: Wunder, John A. [mailto:[hidden email]]
Sent: Monday, September 22, 2014 2:56 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Alex,

 

We plan to collect opinions via e-mail, you have three options:

 

·         Send an e-mail to the public list at [hidden email]

·         Send an e-mail to the internal STIX team ([hidden email]) to have us anonymize it and pass it on to the public list

·         Send an e-mail to the internal STIX team ([hidden email]) for us to track internally but not to pass on to the public list

 

While discussion questions and thoughts are always encouraged it’s also fine to send a simple +1/-1 or vote among the 5 options we outlined.

 

Note that the decision will be made based on rough consensus rather than a literal counting of the votes.

 

John

 

From: Foley, Alexander [mailto:[hidden email]]
Sent: Monday, September 22, 2014 1:31 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Is there a survey up or some sort of vote-taking apparatus on all of the options?

 

We definitely believe that creating a report object will help clear up the confusion / ambiguity created by placing full text analysis in the name / description fields.  It will be far easier to try to develop best practices if we have clear places to put things.  It might be nice to reach consensus on this issue before trying to figure out when exactly to make the change.

 

Thanks,

 

Alex

 

From: Terry MacDonald [[hidden email]]
Sent: Saturday, September 20, 2014 9:07 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Hi All,

 

I must say I was originally of the opinion that things should stay the same... that effectively the current version can convey the 'Report'  information. I was very skeptical. But after listening to both sides during the last call, I'm a convert.

 

On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

 

I don't see the addition of a Report object as adding too much complexity. To me, it cleans things up. Its a delineation between the the container that the STIX information rides in, and extra information about other objects within that container. Having the new Report object will allow consumers to look for the existence of the Report object, and the mere existence of the Report object proves that the producer was providing an explicit report. At present there is no easy way to determine if the STIX package header information that a consumer provides is just an automatically generated or contains a name that describes all the package. 

 

I don't see how the use of a profile will make it easier for new participants to understand where "Report-like" information goes. Creating a new separate Report object on the other hand will. New participants in this space will know where Report nformation goes, without having to know the whole backstory about why it goes where it goes. If they want to write a report, then it goes in the Report object. Job done. 

 

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

 

Which is exactly spelt out in the STIX versioning scheme listed here: http://stix.mitre.org/language/versioning_policy.html. Major version updates will break your code. It just will. That's why having the migration period will allow the best of both worlds. If you don't want to add the report object processing/generation, then don't. Just use the existing functionality and set the STIX version to the 1.1.1. 

 

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

 

If you are a producer and don't want to generate the new content then you need to advertise that you only support STIX 1.1.1 (or whatever version you wish to generate). Same for a client. If a consumer/producer does want to support the latest standards then of course it will require code modification to do so, and you are right that it will require understanding report data in both places (at least in the transition timeframe), but any support of a new version of STIX will require code changes. The fact that a new STIX version has been released indicates modification is required to support the new STIX version. Its always been that way in any standard I can think of.

 

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

 

It's exactly this ambiguity that I think the Report object fixes. Having an object called Report is exactly the place that people will look to put information about report data. 

 

Having the ability for that report object to span across STIX packages I think increases flexibility for transport mechanisms. It then supports long running communication sessions (which I believe is a core part of why FS-ISAC want this).

 

And having a separate Report object gives us a place to expand the information in the report to be more structured in the future if required. 

 

Cheers
Terry MacDonald

 

On 20 September 2014 06:57, Katz, Gary Contractor DC3 <[hidden email]> wrote:

Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.

Based on the below response I did not see how a profile would not suit the
use cases described.

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.



On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.



Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.



Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections



Aharon





-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal



STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.





1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.



2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.



3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.



4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?



An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.



I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.



Thank you,



    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center







-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal



Hi Joep,



I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.



Just to clarify:



*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.





So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.



Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.



We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.





Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.





Hopefully, this helps.



Sean

From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal





Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.



J-



From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >


Subject: RE: [STIX] Report Object Proposal







I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.



Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.



*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.



DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin



Security Automation



DTCC Tampa



813-470-2173 | [hidden email] <mailto:[hidden email]>

<mailto:[hidden email] <mailto:[hidden email]> >





<a href="cid:image002.jpg@01CF111C.3642D5E0">cid:image002.jpg@01CF111C.3642D5E0





From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal





Dear list,





Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);





In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.





With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.





Some clarifications/questions/comments:



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives



                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.



*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.





There might be more then will come to mind which we’ll share at that time.





All the best,



Joep








From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal





All,





During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).





In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:





·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>


ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>



o   Look at the samples, evaluate the advantages and disadvantages to the

current state



o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.



·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.



·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >



o   Consider these hypotheticals:



§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?



§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?





We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.





Thanks,





John Wunder



STIX Project Team





DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

 


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


example.xml (10K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Collie, Byron S.
In reply to this post by Wunder, John A.

Apologies for delay in hitting send on this.

 

In the general intelligence community world, there are sources who provide reports which are grouped into collections. Source, collections and report are all objects in our extended STIX schema which is leveraging intelligence community models for its construction. A report may in fact have multiple STIX objects created from it as it may have content to be extracted on more than one threat actor, incident, etc etc.  So report is a core concept. 

 

We are not leaving Source as a technical attribute in packaging in our  extended STIX implementation.  To me/us the packaging is purely that, delivery metadata and should reference, not describe information report, collection or source reporting.

 

Metadata around Source (referred to as pedigree or provenance) reliability and credibility using the Admiralty Scale http://en.wikipedia.org/wiki/Admiralty_code is also critical to tracking reliability and potential ROI of a source, particularly commercial providers, over time. 

 

Concepts (and illustrative examples only) below.

 

·         First Order Object – Source

§  SANS Internet Storm Center Handlers Diary – B2

§  FS-ISAC Cyber Intelligence Email list – B2

§  CrowdStrike – Aggregated A1

§  Verisign iDefense – Aggregated A1

§  Internal Forensic Analysis – A1

§  …n

o   Second Order Object – Information Collection

§  Verisign iDefense – (Averaged  

·         Daily IP Reputation Feed – B2

·         Daily Threat Indicator Feed – A1

·         Weekly Malware Report – B2

·         Advanced Threat Research Report XXXXXXXX

·         …n

 

§  Third Order Object- Information Report

·          

·         STIX Object

o   Object Reliability/Credibility (Admiralty Scale)

·         STIX Object

o   Object Reliability/Credibility (Admiralty Scale)

·         ……n

 

Similarly Victim is a completely separate object and not part of the TTP construct. 

 

·         First Order Object – Victim

o   Second Order Object – Victim Demography

§  Target Type

·         Government

o   Departments and Agencies

o   Judiciary

o   Legislative

·         Commercial

o   Industry Vertical

·         Academic

o   Schools

o   Universities and Colleges

o   Think Tanks

o   Research and Development

·         Non-Government Organization

o   Humanitarian

o   Privacy

o   Environmental

·         Ethno/Cultural Group

o   National

o   Racial

o   Cultural

o   Religious

·         Ideological Group

o   Political

o   Environmental

o   Animal Rights

o   Religious

·         Interest Based Groups

o    

·         Individuals

§  Geography/region

·         Physical location

o   Second Order Object – Victim Impact

§  Confidentiality

§  Integrity

§  Availability

§  Authenticity

§  Financial Loss

 

Still working to expand the model completely but will share with the group when we get it to a reasonable state.

 

Byron

 

=====================================
Byron Collie
Vice President, Director of Cyber Intelligence
Technology Risk
Goldman Sachs

Off Tel: + 1 212-357-1207
Cell Tel: + 1 551-358-3848
P Please consider the environment before printing this e-mail.
   
NOTICE TO RECIPIENTS: This message may contain information that is confidential or privileged.  If you are not the intended recipient, please advise the sender immediately and delete this message.  See http://www.gs.com/disclaimer/email  for further information on confidentiality and the risks inherent in electronic communication.

 

 

 

From: Joep Gommers [mailto:[hidden email]]
Sent: Friday, September 19, 2014 4:08 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Hi Sean,

 

This is very helpful and not obvious from the concepts or other documentation, this might however be my inexperience with STIX and not knowing where to look.

 

Practically, option 4 (profiles) are in the context of Sean’s and Gary's response an attractive option. We see many use-cases for STIX and an intelligence report is just one of them. STIX is after all, trying to be allot of things to allot of people (revenue assurance, incident response, security operations, intelligence analysis, etc.).

 

I do wonder if an “intelligence report”, being context and explicit relationships between STIX objects, isn’t similar to an “incident” and possibly in the future constructs such as “fraud” or “investigation” or really any other type of target modeling relevant to a specific group of people/processes. I’d definitely be a proponent of moving (and allowing many more) context constructs in profiles, while keeping the “soup” in STIX.

 

So personally I’d say;

IF we intent to “grow” the META-data of STIX_Package to be more then just simple descriptions in the near future – but more relevant to intelligence reporting and

IF we can agree clearly on what constructs should be in a profile and what will be native to STIX (again, “incident” confuses me in this regard)

IF profiles will be versioned and maintain as rigorously as STIX itself (it can make or break software)

 

Then I totally understand the attractiveness of option 4/profiles.

 

Love to hear more viewpoints.

 

Best regards,

Joep

 

 

 

From: <Barnum>, "Sean D." <[hidden email]>
Date: Thursday, September 18, 2014 at 6:37 PM
To: Joep Gommers <
[hidden email]>, stix-discussion-list Structured Threat Information Expression/ST <[hidden email]>
Subject: Re: [STIX] Report Object Proposal

 

Hi Joep,

 

I just wanted to offer some clarification on something that may not be clear to some.

That is that the current structure in STIX does actually support explicit report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point during our discussion of this proposal.

 

Just to clarify:

  • A STIX_Package of content coming from a single producer at a given time has implicit context in that it all came from that producer at that time.
  • The STIX_Package structure also lets you specify explicit “report” context through the existing Package_Intent, Title, Description, Short_Description fields (these are the exact fields that are proposed to be moved from STIX_Package to a new Report object). If these are present, they are specifying explicit “report” content in that STIX_Package just as they would do in a separate Report object. 
  • The current structure also lets you specify STIX_Packages that define a “report” context but only contain references to other content rather than defining new content within them. We typically refer to these as “Manifest” Packages. This is the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.
  • The current structure also lets you specify a STIX_Package as a “wrapper” without any specific context that contains STIX content (Indicators, TTPs, etc.) and one or more “Manifest” Packages that define explicit context and reference the content in the “wrapper” Package. This is again, the same use structure as is being proposed for the new Report object. The only difference is that it is called STIX_Package, not Report.

 

So, in summary, the Report Object proposal is not about adding new capability or filling some existing gap (you are able to do everything now that you would be able to do under the proposal). Rather, it is about a desire to clearly distinguish for human beings the difference between the use cases of STIX_Package as an “envelope” and STIX_Package as a “report”. For machines, this would currently be deterministically clear based on the presence or absence of the contextual fields on the STIX_Package but FS-ISAC feels humans may still be confused and potentially use the structure in ways they do not feel are appropriate. They are proposing that the outlined structural changes (along with identified implications outlined in the proposal document) are desirable to address this issue they feel strongly about.

 

Each stakeholder should weigh this proposal with careful consideration of their current and future needs, what capabilities and limitations exist in the current structure, what capabilities and limitations exist in the proposed structure, how the identified implications are likely to affect them and the community and all identified potential options. Based on these considerations they should form an opinion to support the proposal or not and let us all know what they think.

 

We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and accurate information with as little misunderstandings as possible.

 

 

Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent in my summary paragraph above.

 

 

Hopefully, this helps.

 

Sean

 

From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <
[hidden email]>
Date: Thursday, September 18, 2014 at 9:11 AM
To: stix-discussion-list Structured Threat Information Expression/ST <
[hidden email]>
Subject: Re: [STIX] Report Object Proposal

 

Agree on the need for explicit rather then implicit report content. In that respect, we fully support the creation of this object. This will allow us to “transport” information in STIX_Package and “transport” relationships within an Report Object.

 

J-

 

From: <Chernin>, "Michael A." <[hidden email]>
Date: Wednesday, September 17, 2014 at 4:00 PM
To: Joep Gommers <
[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [STIX] Report Object Proposal

 

I can see how users can easily be confused about the need for the report object. The functionality exists today within the STIX_Header, primarily within the Title and Description field. Our opinion is that this is easy for content creators to abuse (they don’t have to think about using the correct STIX object), and doesn’t make sense given the high level object pattern already in use by STIX today. We also believe that report content should be explicit instead of implicit, which is how report context is done today using STIX_Package. Technically this allows us to split explicit relationships of objects  from the STIX_Package and allow us to use the STIX_Package just as a container for our STIX “object soup”.

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:

I would think of it less as a contextual wrapper and more like a way to explicitly reference report context between STIX objects without having to infer it from a STIX_Package. Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. At this stage of the game we are just trying to get “buy-in” from the community that a report object should exist. Once we succeed, I think it would be appropriate to discuss adding the elements to the object that you are proposing.

  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.

Adding additional fields to the report object at the same time as we are adding the report object increases complexity and confusion for the community. If agreed upon by the community, the report object could support this type of functionality in the future.

  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:

The incident object can only reference TTP, Course of Action, and Indicators (don’t sue me if I forgot one) and focuses on providing incident detail only. The report object can reference any STIX high level object and provide any report like context that you wish to provide. In the future we can continue to expand the functionality of the report object so that it further differentiates itself from the other objects.

DTCC Non-Confidential (White)
---------------------------------------------------
Michael “Aharon” Chernin

Security Automation

DTCC Tampa

813-470-2173 | [hidden email]

 

cid:image002.jpg@01CF111C.3642D5E0

 

From: Joep Gommers [[hidden email]]
Sent: Wednesday, September 17, 2014 8:51 AM
To:
[hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Dear list,

 

Feedback and some questions (pardon my ignorance, we’ve just got started with STIX);

 

In our view STIX allows for a conceptual graph-like representation of, predominantly, “red” (vs “blue”), components of a target model and its intended or realized impact (and possibly course of action). If we take the time to “deconstruct” and “construct” from our graph to STIX traffic. It allows us to share STIX components and how they inter-relate. One of the problems we’re struggling with is exactly what “Report Object” is here to solve. A wrapper for some of the components in a target model and their relationships, together with the analysis of how we came about those estimations/conclusions. We strongly support its use-case. 

 

With regards to impact of changing current systems to comply with these changes. STIX has a long way to go and we would prefer bigger changes (not rushed) as soon as possible, before the ecosystem of software (at Intelworks or elsewhere) grows much bigger.

 

Some clarifications/questions/comments:

  • Are we understanding correctly that the Report object would carry contextual meta-data itself, and reference other STIX components as being “part of” that contextual wrapper. We’d look to be able to add to its META:
    • Title(s)
    • Key-Points (could be embedded in analysis)
    • Analysis/Description
    • Tags (some free-form way of assigning different dimensions for software use such as ‘part of which category of problem’, ‘has to do with..’, etc.)
    • Confidence statements (not on source, but analysis/analyst)
    • Information cut-off (as apposed to “publish” or “distribution” dates (could be embedded in analysis)
    • External references
  • We foresee that confidence statements, estimate statements and handling constraints that become relevant on paragraphs rather then “reports”. Are we correct in saying that we can “abuse” multiple “report” objects for this use-case? Would there be opportunities to create “analysis paragraphs” with their own META inside a STIX report object.
  • If the Report Object is a contextual wrapper (with a specific purpose) of a group of STIX components, isn’t the Incident Object the same? If we look at the workflows of the key “actors”/“user types” that are working with cyber intelligence in large enterprises we identify:
    • Security Operations
    • CERT (usually network related investigations)
    • Revenue Assurance / Anti-Fraud
    • Investigations (in context of revenue assurance/fraud)
    • Intelligence Analysts
    • Warfare Commanders (cyber or otherwise)
    • Risk Analysts / Managers
    • Decision makers
    • Executives

It seems that “Report Object” might be the same for an intelligence analysts as “Incident Object” would be for an incident handler. Might there be other “Contextual wrappers” relevant for other types of consumers that are currently out-of-scope. Would simple a “wrapper” that can be of different META and of different purpose be an option? Without having to extent STIX every time there is a new “contextual” concept required.

  • If the “Report Object” is to represent an “Intelligence Report” of sorts. It might, depending on the type of conflict it covers, have relevance to different use-cases and in “storing it for later use” not be conflated with other information. For example strategic intelligence for the purposes of budget planning or tactical current intelligence for the purposes of crisis management or immediate detection. Widely different use-cases and we’d want to ensure that we can earmark “Reports” (contextual meta related to STIX objects) as such. Current intelligence is something that is relevant for integration in detection tools, some information mentioned in a strategic report – far from. We don’t want humans as the bottleneck, so as much inclusion of similar types of meta would be enormously beneficial.

 

There might be more then will come to mind which we’ll share at that time.

 

All the best,

Joep

 

 

 

 

From: <Wunder>, "John A." <[hidden email]>
Reply-To: "Wunder, John A." <
[hidden email]>
Date: Tuesday, September 16, 2014 at 9:44 PM
To: "
[hidden email]" <[hidden email]>
Subject: [STIX] Report Object Proposal

 

All,

 

During the September community call and at different times during the past year or so FS-ISAC has brought up the idea of adding a new “Report Object” to STIX (note: this not a CybOX object, it would be a STIX major construct at the same level of Indicator, Incident, etc.).

 

In the interest of finalizing a decision so people know where the language is headed, we’d like to continue that discussion with one final list thread where we hopefully come to rough consensus on the way forward. So, to that end:

 

·         Read the proposal: https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Object-as-Minor-Release

o   Look at the samples, evaluate the advantages and disadvantages to the current state

o   Consider the impact of changing your systems to the proposed state, including advantages as pointed out by FS-ISAC but also costs in terms of implementation time, compatibility, etc.

·         If you have any thoughts, concerns, questions, please respond! Hopefully this e-mail kicks off a discussion on the proposal itself.

·         Look through the options that we put together: https://github.com/STIXProject/schemas/wiki/Report-Object-Options

o   Consider these hypotheticals:

§  Assuming there is no STIX major release in the next 6 months, what’s your preferred option? Is it worth the added capabilities to implement the FS-ISAC proposal now or should it wait to the major release to minimize the minor release implications? When would you like to see the process for the minor release started?

§  In your ideal world, what course of action would you take? Implement it as a minor release now? Not implement it at all? Implement it as a major release now? Do something completely different?

 

We want to hear your opinions, in particular if you as a vendor or user organization are currently producing or consuming STIX.

 

Thanks,

 

John Wunder

STIX Project Team


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.

Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Terry MacDonald
In reply to this post by Wunder, John A.
As I understand it .....

1)      How will the use of a Report help if the contain is unrelated? (see GitHub example)

In short it won't. The Report object is not required, so the in this case, if the content is unrelated then the Report isn't needed. That said, a Report object will be able to reference content sent before or being sent later in other STIX packages, meaning that a Report object could be included in that example STIX package even though it doesn't reference any of the other objects in that same STIX Package. This gives us a lot of flexibility.

2)      If the document contains a Report, do I need to parse the other Top Level Objects?

·         The attached example.xml contains 2 indicators 1 TTP and 1 Report. The Report contains 1 of the Indicators embedded in the document along with the embedded TTP. What should the process be for handling the remaining Indicator contained in the document but not in the Report?

Yes. A Report object is just another Top level object. Each Top level object needs to be parsed and processed (if its included in the profile you support, but thats another story). As mentioned above the Report can reference content that is not in that particular STIX package. The Report can also reference only a subset of the Objects if it wants. The other objects not referenced in the Report object get stored as normal. They may end up being referenced in the future by another Report object, or may not.

Mitre - If this change goes ahead does it mean that we need to add a Report object to this page?: http://stixproject.github.io/data-model/
And then we need to add a Report object to this model?: http://stixproject.github.io/images/stix-architecture.png

Aharon/Mitre, if I've got anything wrong please correct me :).

Cheers

Terry MacDonald

On 23 September 2014 05:00, Wunder, John A. <[hidden email]> wrote:

Along those lines, we had a request to anonymize and pass along the following message (forwarded w/o modification):

 

Questions:

1)      How will the use of a Report help if the contain is unrelated? (see GitHub example)

2)      If the document contains a Report, do I need to parse the other Top Level Objects?

·         The attached example.xml contains 2 indicators 1 TTP and 1 Report. The Report contains 1 of the Indicators embedded in the document along with the embedded TTP. What should the process be for handling the remaining Indicator contained in the document but not in the Report?

 

From: Wunder, John A. [mailto:[hidden email]]
Sent: Monday, September 22, 2014 2:56 PM


To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Alex,

 

We plan to collect opinions via e-mail, you have three options:

 

·         Send an e-mail to the public list at [hidden email]

·         Send an e-mail to the internal STIX team ([hidden email]) to have us anonymize it and pass it on to the public list

·         Send an e-mail to the internal STIX team ([hidden email]) for us to track internally but not to pass on to the public list

 

While discussion questions and thoughts are always encouraged it’s also fine to send a simple +1/-1 or vote among the 5 options we outlined.

 

Note that the decision will be made based on rough consensus rather than a literal counting of the votes.

 

John

 

From: Foley, Alexander [mailto:[hidden email]]
Sent: Monday, September 22, 2014 1:31 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Is there a survey up or some sort of vote-taking apparatus on all of the options?

 

We definitely believe that creating a report object will help clear up the confusion / ambiguity created by placing full text analysis in the name / description fields.  It will be far easier to try to develop best practices if we have clear places to put things.  It might be nice to reach consensus on this issue before trying to figure out when exactly to make the change.

 

Thanks,

 

Alex

 

From: Terry MacDonald [[hidden email]]
Sent: Saturday, September 20, 2014 9:07 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Hi All,

 

I must say I was originally of the opinion that things should stay the same... that effectively the current version can convey the 'Report'  information. I was very skeptical. But after listening to both sides during the last call, I'm a convert.

 

On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

 

I don't see the addition of a Report object as adding too much complexity. To me, it cleans things up. Its a delineation between the the container that the STIX information rides in, and extra information about other objects within that container. Having the new Report object will allow consumers to look for the existence of the Report object, and the mere existence of the Report object proves that the producer was providing an explicit report. At present there is no easy way to determine if the STIX package header information that a consumer provides is just an automatically generated or contains a name that describes all the package. 

 

I don't see how the use of a profile will make it easier for new participants to understand where "Report-like" information goes. Creating a new separate Report object on the other hand will. New participants in this space will know where Report nformation goes, without having to know the whole backstory about why it goes where it goes. If they want to write a report, then it goes in the Report object. Job done. 

 

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

 

Which is exactly spelt out in the STIX versioning scheme listed here: http://stix.mitre.org/language/versioning_policy.html. Major version updates will break your code. It just will. That's why having the migration period will allow the best of both worlds. If you don't want to add the report object processing/generation, then don't. Just use the existing functionality and set the STIX version to the 1.1.1. 

 

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

 

If you are a producer and don't want to generate the new content then you need to advertise that you only support STIX 1.1.1 (or whatever version you wish to generate). Same for a client. If a consumer/producer does want to support the latest standards then of course it will require code modification to do so, and you are right that it will require understanding report data in both places (at least in the transition timeframe), but any support of a new version of STIX will require code changes. The fact that a new STIX version has been released indicates modification is required to support the new STIX version. Its always been that way in any standard I can think of.

 

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

 

It's exactly this ambiguity that I think the Report object fixes. Having an object called Report is exactly the place that people will look to put information about report data. 

 

Having the ability for that report object to span across STIX packages I think increases flexibility for transport mechanisms. It then supports long running communication sessions (which I believe is a core part of why FS-ISAC want this).

 

And having a separate Report object gives us a place to expand the information in the report to be more structured in the future if required. 

 

Cheers
Terry MacDonald

 

On 20 September 2014 06:57, Katz, Gary Contractor DC3 <[hidden email]> wrote:

Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.

Based on the below response I did not see how a profile would not suit the
use cases described.

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.



On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.



Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.



Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections



Aharon





-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal



STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.





1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.



2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.



3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.



4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?



An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.



I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.



Thank you,



    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center







-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal



Hi Joep,



I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.



Just to clarify:



*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.





So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.



Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.



We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.





Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.





Hopefully, this helps.



Sean

From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal





Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.



J-



From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >


Subject: RE: [STIX] Report Object Proposal







I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.



Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.



*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.



DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin



Security Automation



DTCC Tampa



813-470-2173 | [hidden email] <mailto:[hidden email]>

<mailto:[hidden email] <mailto:[hidden email]> >





cid:image002.jpg@01CF111C.3642D5E0





From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal





Dear list,





Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);





In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.





With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.





Some clarifications/questions/comments:



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives



                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.



*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.





There might be more then will come to mind which we’ll share at that time.





All the best,



Joep








From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal





All,





During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).





In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:





·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>


ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>



o   Look at the samples, evaluate the advantages and disadvantages to the

current state



o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.



·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.



·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >



o   Consider these hypotheticals:



§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?



§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?





We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.





Thanks,





John Wunder



STIX Project Team





DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

 


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


Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Report Object Proposal

Foley, Alexander - GIS

I’ll defer to DTCC / MITRE on the implications of the change in the data model / architecture, but in support of your commentary below:

 

#1 – flexibility being where infinite possibilities lie as well… I can remember the team musing about the idea of structured references between such a report and other STIX objects in the same way that HTML works today

 

#2 – just imagine the benefit we’ll get by knowing which portions of a STIX package that we need to parse according to the object model and which portion we need to aim full-text search and entity extraction engines at… this is a thorn in our side with many threat intelligence feeds today that disconnect their multi-page analyses from their indicator feeds

 

Thanks,

 

Alex

 

From: Terry MacDonald [mailto:[hidden email]]
Sent: Monday, September 22, 2014 7:12 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

As I understand it .....

1)      How will the use of a Report help if the contain is unrelated? (see GitHub example)

 

In short it won't. The Report object is not required, so the in this case, if the content is unrelated then the Report isn't needed. That said, a Report object will be able to reference content sent before or being sent later in other STIX packages, meaning that a Report object could be included in that example STIX package even though it doesn't reference any of the other objects in that same STIX Package. This gives us a lot of flexibility.

2)      If the document contains a Report, do I need to parse the other Top Level Objects?

·         The attached example.xml contains 2 indicators 1 TTP and 1 Report. The Report contains 1 of the Indicators embedded in the document along with the embedded TTP. What should the process be for handling the remaining Indicator contained in the document but not in the Report?

Yes. A Report object is just another Top level object. Each Top level object needs to be parsed and processed (if its included in the profile you support, but thats another story). As mentioned above the Report can reference content that is not in that particular STIX package. The Report can also reference only a subset of the Objects if it wants. The other objects not referenced in the Report object get stored as normal. They may end up being referenced in the future by another Report object, or may not.

Mitre - If this change goes ahead does it mean that we need to add a Report object to this page?: http://stixproject.github.io/data-model/

And then we need to add a Report object to this model?: http://stixproject.github.io/images/stix-architecture.png

 

Aharon/Mitre, if I've got anything wrong please correct me :).

Cheers

Terry MacDonald

 

On 23 September 2014 05:00, Wunder, John A. <[hidden email]> wrote:

Along those lines, we had a request to anonymize and pass along the following message (forwarded w/o modification):

 

Questions:

1)      How will the use of a Report help if the contain is unrelated? (see GitHub example)

2)      If the document contains a Report, do I need to parse the other Top Level Objects?

·         The attached example.xml contains 2 indicators 1 TTP and 1 Report. The Report contains 1 of the Indicators embedded in the document along with the embedded TTP. What should the process be for handling the remaining Indicator contained in the document but not in the Report?

 

From: Wunder, John A. [mailto:[hidden email]]
Sent: Monday, September 22, 2014 2:56 PM


To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Alex,

 

We plan to collect opinions via e-mail, you have three options:

 

·         Send an e-mail to the public list at [hidden email]

·         Send an e-mail to the internal STIX team ([hidden email]) to have us anonymize it and pass it on to the public list

·         Send an e-mail to the internal STIX team ([hidden email]) for us to track internally but not to pass on to the public list

 

While discussion questions and thoughts are always encouraged it’s also fine to send a simple +1/-1 or vote among the 5 options we outlined.

 

Note that the decision will be made based on rough consensus rather than a literal counting of the votes.

 

John

 

From: Foley, Alexander [mailto:[hidden email]]
Sent: Monday, September 22, 2014 1:31 PM
To: stix-discussion-list Structured Threat Information Expression/ST
Subject: Re: [STIX] Report Object Proposal

 

Is there a survey up or some sort of vote-taking apparatus on all of the options?

 

We definitely believe that creating a report object will help clear up the confusion / ambiguity created by placing full text analysis in the name / description fields.  It will be far easier to try to develop best practices if we have clear places to put things.  It might be nice to reach consensus on this issue before trying to figure out when exactly to make the change.

 

Thanks,

 

Alex

 

From: Terry MacDonald [[hidden email]]
Sent: Saturday, September 20, 2014 9:07 AM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal

 

Hi All,

 

I must say I was originally of the opinion that things should stay the same... that effectively the current version can convey the 'Report'  information. I was very skeptical. But after listening to both sides during the last call, I'm a convert.

 

On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

 

I don't see the addition of a Report object as adding too much complexity. To me, it cleans things up. Its a delineation between the the container that the STIX information rides in, and extra information about other objects within that container. Having the new Report object will allow consumers to look for the existence of the Report object, and the mere existence of the Report object proves that the producer was providing an explicit report. At present there is no easy way to determine if the STIX package header information that a consumer provides is just an automatically generated or contains a name that describes all the package. 

 

I don't see how the use of a profile will make it easier for new participants to understand where "Report-like" information goes. Creating a new separate Report object on the other hand will. New participants in this space will know where Report nformation goes, without having to know the whole backstory about why it goes where it goes. If they want to write a report, then it goes in the Report object. Job done. 

 

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

 

Which is exactly spelt out in the STIX versioning scheme listed here: http://stix.mitre.org/language/versioning_policy.html. Major version updates will break your code. It just will. That's why having the migration period will allow the best of both worlds. If you don't want to add the report object processing/generation, then don't. Just use the existing functionality and set the STIX version to the 1.1.1. 

 

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

 

If you are a producer and don't want to generate the new content then you need to advertise that you only support STIX 1.1.1 (or whatever version you wish to generate). Same for a client. If a consumer/producer does want to support the latest standards then of course it will require code modification to do so, and you are right that it will require understanding report data in both places (at least in the transition timeframe), but any support of a new version of STIX will require code changes. The fact that a new STIX version has been released indicates modification is required to support the new STIX version. Its always been that way in any standard I can think of.

 

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

 

It's exactly this ambiguity that I think the Report object fixes. Having an object called Report is exactly the place that people will look to put information about report data. 

 

Having the ability for that report object to span across STIX packages I think increases flexibility for transport mechanisms. It then supports long running communication sessions (which I believe is a core part of why FS-ISAC want this).

 

And having a separate Report object gives us a place to expand the information in the report to be more structured in the future if required. 

 

Cheers
Terry MacDonald

 

On 20 September 2014 06:57, Katz, Gary Contractor DC3 <[hidden email]> wrote:

Aharon,
   Appreciate your response.  I believe there may be additional ways to view
the outcome of these changes which may have a more adverse effect than what
you are predicting.


On complexity: A STIX_Package in itself is a report.  It's a report that
contains all of the data and relationships together, rather than breaking
them apart.  As such the distinction between a report and the raw data can
currently be achieved with the STIX framework and using a Profile as
proposed in Option 4.  Incorporating a new structure (Report Object) and
severely limiting the current structure (STIX_Package) is a major change and
therefore increases complexity for the current participants.  It also
requires an alignment between information in the STIX_Package and a new
Report Object, which I would argue is an increase in overall complexity.

On backwards compatibility: This is a minor release, yes individuals would
still be able to create a STIX_Package object in the current format, while
also being able to create a limited STIX_Package and a Report object, but
this does not mean it is backwards compatible, in fact in means the
opposite.
First, the 'backwards compatibility' would only exist until the major
revision was released, at which time the STIX_Package structure, currently
in implementation, would become deprecated, and therefore would not be
backwards compatible.

Second, and most importantly, in order for organizations to ensure they
could read all STIX documents, they would need to be able to read documents
using the current STIX_Package structure and documents using your proposed
structure.  Basically this would double the amount of work for all consumers
of STIX documents and increase the chance of errors.  To be clear, up until
the major release (and for those wishing to ingest information from
producers still working from a minor release) consumers would need to be
able to accept documents using the current STIX_Package format and ingest
documents using the proposed new feature limited STIX_Package and from the
new Report Object.  The consumers could make no assumptions that the
producer was using one format over the other.

The STIX language was carefully designed to minimize the ways in which data
could be represented to standardize the representation and reduce ambiguity
in implementation.  This minimization is what allows consumers to build
systems that can understand the data being shared.  A major change such as
this is not something that a consumer could adapt with through a simple rule
or by coding up the ingest in two ways for a particular object.  A change
such as this requires two separate ingest systems to be built.  One which
uses the STIX_Package in its current form and a second ingest system to
parse the proposed Report Object and associate that information with the
data within the associated STIX_Package.

Before making such a change, I would suggest that the MITRE team reaches out
to the current list of STIX users and survey them to determine whether they
are currently have the funding and are able to rebuild their infrastructure
to support this type of change.  As an ESSA leader, this change would put us
back months in our development cycle and most likely would result in an even
larger delay coordinating with our participating organizations on how to
adapt our overall infrastructure to these changes.

Decreased reporting: You are correct, it is hard to predict whether future
reporting would increase or decrease. I would disagree that the document is
somehow crippled due to a machines inability to determine the type of
context.  The machine can determine the type of context.  The profile
provides the context.  The profile construct is what enables someone to
create tools with STIX and do things with the data other than display it on
the page.  The profile is the instrument that allows us to achieve the
functionality that you have requested.

Your organization could create a profile of STIX that would restrict a
document down to the raw data and create another profile that would only
contain the context (i.e. the proposed Report object). I believe it is much
simpler to have one document, but the current STIX framework does allow for
what you are asking without breaking backwards compatibility.

Limiting the usability of STIX: Taking a look at the points relating to this
item that are listed below, all of these can currently be achieved with
STIX.  The point I was making, which I did not see addressed in the
response, is that the proposed structure changes assumes how STIX is to be
used.  This inherently restricts future use cases.  Profiles for example are
a basic construct which can be molded to fit new use cases, such as a Report
profile.  In contrast, the proposed changes restrict the usage of STIX and
therefore restrict the future uses of STXI.

Based on the below response I did not see how a profile would not suit the
use cases described.

Respectfully,
   Gary Katz



-----Original Message-----
From: Chernin, Michael A. [mailto:[hidden email]]
Sent: Friday, September 19, 2014 6:55 AM
To: Katz, Gary Contractor DC3; [hidden email]
Subject: RE: [STIX] Report Object Proposal

On complexity: The report object is an additional object that will need to
be used, and in turn will require that applications generating STIX content
will need to facilitate a method of interacting with it.



On backwards compatibility: All content created before the report object
will still function properly. Mitre and FS-ISAC agree that this is a
backwards compatible change. On another note, at this early stage of STIX,
let’s do the big changes now versus two years from now when our ability to
innovate and change the language is hindered due to mass adoption.



Decreased reporting: This is subjective. If we do not create a report
object, we could also make the argument that additional context provided
within the STIX_Header is crippled due to a machines inability to determine
the type of context being provided. If we put “Hello World” into the title
of a STIX_Header, all that I know is that Hello World should somehow be
implied to the objects in the STIX_Package. If we put Hello World in the
title of a report object, now the machines know that this is being used in a
report context and can react as such. I agree that some context is better
than no context, but the type of context allows us to create tools with STIX
that do things with the data other than display it on a page. The creation
of a report object also allows analysts to update the human readable
portions of a report, regardless of the STIX objects used within the
STIX_Package or the STIX_Package in general. This change may actually
increase reporting.



Limiting the usability of STIX: This is also subjective.

By allowing for raw STIX objects within the STIX_Package we increase the
flexibility and use cases of STIX:

1)      Objects can be moved from point a to point b without having to keep
original STIX_Packaging

2)      Single objects can be updated/revisioned without sending the entire
STIX_Package

3)      In my opinion, raw data is incredible powerful, not a limitation.

We also help out TAXII with raw STIX objects:

1)      TAXII multipart messages can now have more granular control of
message size

2)      TAXII can stream objects

3)      TAXII can recover easier on bad connections



Aharon





-----Original Message-----
From: Katz, Gary Contractor DC3 [mailto:[hidden email]]
Sent: Thursday, September 18, 2014 5:23 PM
To: [hidden email]
Subject: Re: [STIX] Report Object Proposal



STIX Community,

     I apologize for my late inputs into the discussion.  After reviewing

the Report object proposal, we recommend MITRE’s Option 4: Implementing the

proposal via a profile to restrict the fields that are allowed in the

top-level STIX_Package.  There are a number of reasons for not removing

context from STIX_Package and separating it into a new Report object.





1.            Increases Complexity: In the current STIX framework, the user
can

include any amount of context that they wish, without having to go through

creating a new Report object to link information together.  Having to create

a separate object to hold this context is an increase in complexity rather

than representing that information in the current constructs.  While the

creation of the Report object may reduce complexity for certain

implementations of a database, the STIX framework is implementation agnostic

and should not be significantly changed to meet certain users or groups of

users.



2.            Breaking backwards compatibility: While major releases are
allowed

to break backwards compatibility, such a change should still be avoided if

possible.  There are many systems currently deployed and many more still

that are currently in development, a real cost exists to changing these

systems that could be avoided through other options.  Performing a change to

the STIX structure that could otherwise be achieved through using the

current constructs is ill-advised.  If the community wishes to increase the

adoption of STIX then we need to show that the language is stable.

Increasing volatility will reduce adoption and be counterproductive to the

overall goal of STIX, increasing information sharing.



3.            Decreasing Reporting: Breaking relationships into a separate

construct creates additional work for the producer (and consumer).  If a

producer only has a small number of relationships in their data, they may

choose to simply leave the context out of the STIX document rather than

creating a separate Report object.  You also run the risk of individuals

viewing the Report construct as showing that you have compiled enough

information to make a formal ‘report’ and anything less than a formal report

should not include a Report object, resulting in recipients of the

information receiving less information than they otherwise would have.



4.            Limiting the usability of STIX:  The proposal makes the
assumption

that there are two and only two use cases for STIX.  This may be an

incorrect assumption.  By breaking out how STIX can be used, to convey raw

data or to convey a report, it reduces the ability for STIX to be applied to

new use cases.  If there is a new use case that organizations come up with,

does that imply that a new construct, similar to Report, must be created to

support that new use case?  In the current implementation of STIX, there is

no assumption about how the information will be used, it only states how

information is stored.  Similarly to the English language, if I needed to

say “Conversation” every time I started talking to someone and “Book” every

time I wrote a book, would it then discourage using English for a Blog?

What about a Twitter message?



An example of this issue relates to STIX responding to a TAXII query.

Currently a user can respond to a TAXII query by simply including any

information (within a profile) that fits the parameter of the query.  With

the proposed changes, I am not sure how I would respond to a TAXII query.

The response to a TAXII query is not a ‘report’ but can contain more than

raw data.  Categorizing it as a “Report” object, may imply certain

characteristics to the data, which may not actually exist. Limiting the

usage of STIX based upon the use cases that we have devised during the

initial years of its creation, will stunt future creativity in how STIX can

be used to support the cyber security community.



I hope this provides some additional perspective on some of the issues with

the proposed Report object.  While I do not speak for the national cyber

centers, I have engaged with multiple counterparts at other agencies who

have similar concerns with the proposal.  I would suggest leveraging some of

the current constructs within STIX that meet the needs this proposal hopes

to address, rather than introducing the Report object into STIX.



Thank you,



    Gary Katz

    Chief Architect Ctr.

    Technology Solutions Development

    Defense Cyber Crime Center







-----Original Message-----

From: Barnum, Sean D. [mailto:[hidden email] <mailto:[hidden email]> ]


Sent: Thursday, September 18, 2014 12:37 PM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal



Hi Joep,



I just wanted to offer some clarification on something that may not be clear

to some.

That is that the current structure in STIX does actually support explicit

report content in addition to implicit.

I have been seeing some misunderstanding on the list regarding this point

during our discussion of this proposal.



Just to clarify:



*              A STIX_Package of content coming from a single producer at a
given

time has implicit context in that it all came from that producer at that

time.

*              The STIX_Package structure also lets you specify explicit
“report”

context through the existing Package_Intent, Title, Description,

Short_Description fields (these are the exact fields that are proposed to be

moved from STIX_Package to a new Report object). If these are present, they

are specifying explicit “report” content in that STIX_Package just as they

would do in a separate Report object.

*              The current structure also lets you specify STIX_Packages
that

define a “report” context but only contain references to other content

rather than defining new content within them. We typically refer to these as

“Manifest” Packages. This is the same use structure as is being proposed for

the new Report object. The only difference is that it is called

STIX_Package, not Report.

*              The current structure also lets you specify a STIX_Package as
a

“wrapper” without any specific context that contains STIX content

(Indicators, TTPs, etc.) and one or more “Manifest” Packages that define

explicit context and reference the content in the “wrapper” Package. This is

again, the same use structure as is being proposed for the new Report

object. The only difference is that it is called STIX_Package, not Report.





So, in summary, the Report Object proposal is not about adding new

capability or filling some existing gap (you are able to do everything now

that you would be able to do under the proposal). Rather, it is about a

desire to clearly distinguish for human beings the difference between the

use cases of STIX_Package as an “envelope” and STIX_Package as a “report”.

For machines, this would currently be deterministically clear based on the

presence or absence of the contextual fields on the STIX_Package but FS-ISAC

feels humans may still be confused and potentially use the structure in ways

they do not feel are appropriate. They are proposing that the outlined

structural changes (along with identified implications outlined in the

proposal document

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release> ) are desirable to address this issue they feel

strongly about.



Each stakeholder should weigh this proposal with careful consideration of

their current and future needs, what capabilities and limitations exist in

the current structure, what capabilities and limitations exist in the

proposed structure, how the identified implications are likely to affect

them and the community and all identified potential options

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> > .
Based

on these considerations they should form an opinion to support the proposal

or not and let us all know what they think.



We are definitely interested in hearing everyone’s opinions.

We just want to make sure that such considerations are based on clear and

accurate information with as little misunderstandings as possible.





Aharon, feel free to correct anywhere I have mischaracterized FS-ISAC intent

in my summary paragraph above.





Hopefully, this helps.



Sean

From: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Reply-To: Joep Gommers <[hidden email] <mailto:[hidden email]> >

Date: Thursday, September 18, 2014 at 9:11 AM

To: stix-discussion-list Structured Threat Information Expression/ST

<[hidden email]
<mailto:[hidden email]> >

Subject: Re: [STIX] Report Object Proposal





Agree on the need for explicit rather then implicit report content. In that

respect, we fully support the creation of this object. This will allow us to

“transport” information in STIX_Package and “transport” relationships within

an Report Object.



J-



From: <Chernin>, "Michael A." <[hidden email] <mailto:[hidden email]>
>

Date: Wednesday, September 17, 2014 at 4:00 PM

To: Joep Gommers <[hidden email] <mailto:[hidden email]> >,

"[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >


Subject: RE: [STIX] Report Object Proposal







I can see how users can easily be confused about the need for the report

object. The functionality exists today within the STIX_Header, primarily

within the Title and Description field. Our opinion is that this is easy for

content creators to abuse (they don’t have to think about using the correct

STIX object), and doesn’t make sense given the high level object pattern

already in use by STIX today. We also believe that report content should be

explicit instead of implicit, which is how report context is done today

using STIX_Package. Technically this allows us to split explicit

relationships of objects  from the STIX_Package and allow us to use the

STIX_Package just as a container for our STIX “object soup”.



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



I would think of it less as a contextual wrapper and more like a way to

explicitly reference report context between STIX objects without having to

infer it from a STIX_Package. Adding additional fields to the report object

at the same time as we are adding the report object increases complexity and

confusion for the community. At this stage of the game we are just trying to

get “buy-in” from the community that a report object should exist. Once we

succeed, I think it would be appropriate to discuss adding the elements to

the object that you are proposing.



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.



Adding additional fields to the report object at the same time as we are

adding the report object increases complexity and confusion for the

community. If agreed upon by the community, the report object could support

this type of functionality in the future.



*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



The incident object can only reference TTP, Course of Action, and Indicators

(don’t sue me if I forgot one) and focuses on providing incident detail

only. The report object can reference any STIX high level object and provide

any report like context that you wish to provide. In the future we can

continue to expand the functionality of the report object so that it further

differentiates itself from the other objects.



DTCC Non-Confidential (White)

---------------------------------------------------

Michael “Aharon” Chernin



Security Automation



DTCC Tampa



813-470-2173 | [hidden email] <mailto:[hidden email]>

<mailto:[hidden email] <mailto:[hidden email]> >





<a href="cid:image002.jpg@01CF111C.3642D5E0">cid:image002.jpg@01CF111C.3642D5E0





From: Joep Gommers [mailto:[hidden email] <mailto:[hidden email]>
]

Sent: Wednesday, September 17, 2014 8:51 AM

To: [hidden email]
<mailto:[hidden email]>


Subject: Re: [STIX] Report Object Proposal





Dear list,





Feedback and some questions (pardon my ignorance, we’ve just got started

with STIX);





In our view STIX allows for a conceptual graph-like representation of,

predominantly, “red” (vs “blue”), components of a target model and its

intended or realized impact (and possibly course of action). If we take the

time to “deconstruct” and “construct” from our graph to STIX traffic. It

allows us to share STIX components and how they inter-relate. One of the

problems we’re struggling with is exactly what “Report Object” is here to

solve. A wrapper for some of the components in a target model and their

relationships, together with the analysis of how we came about those

estimations/conclusions. We strongly support its use-case.





With regards to impact of changing current systems to comply with these

changes. STIX has a long way to go and we would prefer bigger changes (not

rushed) as soon as possible, before the ecosystem of software (at Intelworks

or elsewhere) grows much bigger.





Some clarifications/questions/comments:



*              Are we understanding correctly that the Report object would
carry

contextual meta-data itself, and reference other STIX components as being

“part of” that contextual wrapper. We’d look to be able to add to its META:



                *              Title(s)

                *              Key-Points (could be embedded in analysis)

                *              Analysis/Description

                *              Tags (some free-form way of assigning
different dimensions

for software use such as ‘part of which category of problem’, ‘has to do

with..’, etc.)

                *              Confidence statements (not on source, but
analysis/analyst)

                *              Information cut-off (as apposed to “publish”
or

“distribution” dates (could be embedded in analysis)

                *              External references



*              We foresee that confidence statements, estimate statements
and

handling constraints that become relevant on paragraphs rather then

“reports”. Are we correct in saying that we can “abuse” multiple “report”

objects for this use-case? Would there be opportunities to create “analysis

paragraphs” with their own META inside a STIX report object.

*              If the Report Object is a contextual wrapper (with a specific

purpose) of a group of STIX components, isn’t the Incident Object the same?

If we look at the workflows of the key “actors”/“user types” that are

working with cyber intelligence in large enterprises we identify:



                *              Security Operations

                *              CERT (usually network related investigations)

                *              Revenue Assurance / Anti-Fraud

                *              Investigations (in context of revenue
assurance/fraud)

                *              Intelligence Analysts

                *              Warfare Commanders (cyber or otherwise)

                *              Risk Analysts / Managers

                *              Decision makers

                *              Executives



                It seems that “Report Object” might be the same for an
intelligence

analysts as “Incident Object” would be for an incident handler. Might there

be other “Contextual wrappers” relevant for other types of consumers that

are currently out-of-scope. Would simple a “wrapper” that can be of

different META and of different purpose be an option? Without having to

extent STIX every time there is a new “contextual” concept required.



*              If the “Report Object” is to represent an “Intelligence
Report” of

sorts. It might, depending on the type of conflict it covers, have relevance

to different use-cases and in “storing it for later use” not be conflated

with other information. For example strategic intelligence for the purposes

of budget planning or tactical current intelligence for the purposes of

crisis management or immediate detection. Widely different use-cases and

we’d want to ensure that we can earmark “Reports” (contextual meta related

to STIX objects) as such. Current intelligence is something that is relevant

for integration in detection tools, some information mentioned in a

strategic report – far from. We don’t want humans as the bottleneck, so as

much inclusion of similar types of meta would be enormously beneficial.





There might be more then will come to mind which we’ll share at that time.





All the best,



Joep







From: <Wunder>, "John A." <[hidden email] <mailto:[hidden email]> >

Reply-To: "Wunder, John A." <[hidden email] <mailto:[hidden email]> >

Date: Tuesday, September 16, 2014 at 9:44 PM

To: "[hidden email]
<mailto:[hidden email]> "

<[hidden email]
<mailto:[hidden email]> >

Subject: [STIX] Report Object Proposal





All,





During the September community call and at different times during the past

year or so FS-ISAC has brought up the idea of adding a new “Report Object”

to STIX (note: this not a CybOX object, it would be a STIX major construct

at the same level of Indicator, Incident, etc.).





In the interest of finalizing a decision so people know where the language

is headed, we’d like to continue that discussion with one final list thread

where we hopefully come to rough consensus on the way forward. So, to that

end:





·         Read the proposal:

https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Obj
<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob
j>


ect-as-Minor-Release

<https://github.com/STIXProject/schemas/wiki/FS-ISAC-Proposal:-Add-Report-Ob

ject-as-Minor-Release>



o   Look at the samples, evaluate the advantages and disadvantages to the

current state



o   Consider the impact of changing your systems to the proposed state,

including advantages as pointed out by FS-ISAC but also costs in terms of

implementation time, compatibility, etc.



·         If you have any thoughts, concerns, questions, please respond!

Hopefully this e-mail kicks off a discussion on the proposal itself.



·         Look through the options that we put together:

https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options>

<https://github.com/STIXProject/schemas/wiki/Report-Object-Options
<https://github.com/STIXProject/schemas/wiki/Report-Object-Options> >



o   Consider these hypotheticals:



§  Assuming there is no STIX major release in the next 6 months, what’s your

preferred option? Is it worth the added capabilities to implement the

FS-ISAC proposal now or should it wait to the major release to minimize the

minor release implications? When would you like to see the process for the

minor release started?



§  In your ideal world, what course of action would you take? Implement it

as a minor release now? Not implement it at all? Implement it as a major

release now? Do something completely different?





We want to hear your opinions, in particular if you as a vendor or user

organization are currently producing or consuming STIX.





Thanks,





John Wunder



STIX Project Team





DTCC DISCLAIMER: This email and any files transmitted with it are

confidential and intended solely for the use of the individual or entity to

whom they are addressed. If you have received this email in error, please

notify us immediately and delete the email and any attachments from your

system. The recipient should check this email and any attachments for the

presence of viruses.  The company accepts no liability for any damage caused

by any virus transmitted by this email.


DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses.  The company accepts no liability for any damage caused
by any virus transmitted by this email.

 


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

 


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