Re: [STIX] Sightings object proposal

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

Re: [STIX] Sightings object proposal

Joep Gommers
Hi All,

Wanted to turn back around on this issue. I believe the sightings object, after the report object expansion into multi-paragraph/image inclusion/etc, is one of the biggest issues to be addressed in STIX right now. @Aharon/@Mitre team – has been there any more thinking or formal planning for this issue? Anything we can do to move this forward?

Best regards,
Joep

From: Aharon Chernin <[hidden email]>
Reply-To: Aharon Chernin <[hidden email]>
Date: Thursday, January 8, 2015 at 10:35 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Sightings object proposal

Current state of sighting affairs:


Sightings are embedded within the indicator object. For a community member to report back a sighting the member must issue a major revision to the indicator with a new sighting embedded.


Problem statements:

  1. Intent. The intent of the user is not to issue a new indicator revision. The intent of the user is to say, “hey I saw this”. However, in today’s implementation of sightings, the user is forced to issue an entire new indicator revision just to say +1.
  2. Sharing hubs could receive hundreds of thousands of major revisions to indicators for sighting purposes only. I predict that soon sharing hubs will have more indicators stored for sighting purposes than for detection/prevention purposes.
  3. Sighting indicators? An indicator is an assertion. What you saw could have been that indicator, or it could have been any other indicator with the same observables. Sighting observables makes more sense as observables are facts. You know exactly what you see, but you will never actually be 100% sure if the context is the same as what someone else told you.  

Proposal:

  1. Create a new sighting top level object. Similar to TTP, Indicators, Observables, etc.
  2. The sightings object can reference any other high level object type: Similar to TTP, Indicators, Observables, etc
  3. The sightings object may or may not be able to contain related observables <- we need to discuss as a group
  4. Depreciate embedded indicator sightings in STIX 2.x

Soltra can create an example STIX document using this new sighting method, as well as provide an in-depth description of the new sightings object format, if the proposal generates interest within the group.



Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Sightings object proposal

Jordan, Bret
I agree.  For something that seems so simple, basically a sightings +1, this is pretty hard to do. Following along this line, I would love to see us create a list of common user interface use cases and then document how they would be marked up in STIX.  I feel we have done a good job at the high level, but we have a lot to do with the day-2-day.   

I know myself and Terry have thrown out a lot of ideas for how the sighting +1 could look.  But I think we need to figure out the one best way to do it. 

When I think of the short term evolution of all of this, I really see an iOS/Android app that interfaces with a TAXII server and allows you to see and play with threat data, very similar to a facebook / instagram type feed.  People will follow items, comment on elements, add to them, enrich them with extra data, and then share them with different "communities" in their group. One specific example would be a group of researchers all working on the latest XYZ bot-net.  Imaging for a minute the back and forth communications that take place today over IM, Skype, Email, Phone, etc.  

Now image if we could build a tool, using STIX and TAXII to do this and then harvest the indicators, observables, COAs in real time and have it feed everyone's predictive and preventive tools.  This example also brings to light the massive hole we have today with trust and integrity.  We really need to figure out how to prevent the repos from getting poisoned.  If we can not solve this, then we will never share beyond very small and private groups which really hampers the long term objectives.  


Thanks,

Bret



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

On Feb 18, 2015, at 6:21 AM, Joep Gommers <[hidden email]> wrote:

Hi All,

Wanted to turn back around on this issue. I believe the sightings object, after the report object expansion into multi-paragraph/image inclusion/etc, is one of the biggest issues to be addressed in STIX right now. @Aharon/@Mitre team – has been there any more thinking or formal planning for this issue? Anything we can do to move this forward?

Best regards,
Joep

From: Aharon Chernin <[hidden email]>
Reply-To: Aharon Chernin <[hidden email]>
Date: Thursday, January 8, 2015 at 10:35 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Sightings object proposal

Current state of sighting affairs: 

Sightings are embedded within the indicator object. For a community member to report back a sighting the member must issue a major revision to the indicator with a new sighting embedded.

Problem statements:
  1. Intent. The intent of the user is not to issue a new indicator revision. The intent of the user is to say, “hey I saw this”. However, in today’s implementation of sightings, the user is forced to issue an entire new indicator revision just to say +1.
  2. Sharing hubs could receive hundreds of thousands of major revisions to indicators for sighting purposes only. I predict that soon sharing hubs will have more indicators stored for sighting purposes than for detection/prevention purposes.
  3. Sighting indicators? An indicator is an assertion. What you saw could have been that indicator, or it could have been any other indicator with the same observables. Sighting observables makes more sense as observables are facts. You know exactly what you see, but you will never actually be 100% sure if the context is the same as what someone else told you.  
Proposal:
  1. Create a new sighting top level object. Similar to TTP, Indicators, Observables, etc.
  2. The sightings object can reference any other high level object type: Similar to TTP, Indicators, Observables, etc
  3. The sightings object may or may not be able to contain related observables <- we need to discuss as a group
  4. Depreciate embedded indicator sightings in STIX 2.x
Soltra can create an example STIX document using this new sighting method, as well as provide an in-depth description of the new sightings object format, if the proposal generates interest within the group.


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


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

Re: [STIX] Sightings object proposal

JA
In reply to this post by Joep Gommers
did you suggested this point to the topic agenda for the next meeting?

Cheers

2015-02-18 14:21 GMT+01:00 Joep Gommers <[hidden email]>:

> Hi All,
>
> Wanted to turn back around on this issue. I believe the sightings object,
> after the report object expansion into multi-paragraph/image inclusion/etc,
> is one of the biggest issues to be addressed in STIX right now.
> @Aharon/@Mitre team – has been there any more thinking or formal planning
> for this issue? Anything we can do to move this forward?
>
> Best regards,
> Joep
>
> From: Aharon Chernin <[hidden email]>
> Reply-To: Aharon Chernin <[hidden email]>
> Date: Thursday, January 8, 2015 at 10:35 PM
> To: "[hidden email]"
> <[hidden email]>
> Subject: [STIX] Sightings object proposal
>
> Current state of sighting affairs:
>
>
> Sightings are embedded within the indicator object. For a community member
> to report back a sighting the member must issue a major revision to the
> indicator with a new sighting embedded.
>
>
> Problem statements:
>
> Intent. The intent of the user is not to issue a new indicator revision. The
> intent of the user is to say, “hey I saw this”. However, in today’s
> implementation of sightings, the user is forced to issue an entire new
> indicator revision just to say +1.
> Sharing hubs could receive hundreds of thousands of major revisions to
> indicators for sighting purposes only. I predict that soon sharing hubs will
> have more indicators stored for sighting purposes than for
> detection/prevention purposes.
> Sighting indicators? An indicator is an assertion. What you saw could have
> been that indicator, or it could have been any other indicator with the same
> observables. Sighting observables makes more sense as observables are facts.
> You know exactly what you see, but you will never actually be 100% sure if
> the context is the same as what someone else told you.
>
> Proposal:
>
> Create a new sighting top level object. Similar to TTP, Indicators,
> Observables, etc.
> The sightings object can reference any other high level object type: Similar
> to TTP, Indicators, Observables, etc
> The sightings object may or may not be able to contain related observables
> <- we need to discuss as a group
> Depreciate embedded indicator sightings in STIX 2.x
>
> Soltra can create an example STIX document using this new sighting method,
> as well as provide an in-depth description of the new sightings object
> format, if the proposal generates interest within the group.
>
>
>
> Aharon Chernin
> CTO
> SOLTRA | An FS-ISAC & DTCC Company
> 18301 Bermuda green Dr
> Tampa, fl 33647
> 813.470.2173 | [hidden email]
> www.soltra.com
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Sightings object proposal

Don DeBolt
In reply to this post by Joep Gommers
+1 on report object expansion then sightings.

Don DeBolt
Product Architect

iSIGHT Partners Inc.

14151 Newbrook Drive, Suite 450
Chantilly, VA 20151

571-335-6958 mobile



From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <[hidden email]>
Date: Wednesday, February 18, 2015 at 8:21 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: [STIX] Sightings object proposal

Hi All,

Wanted to turn back around on this issue. I believe the sightings object, after the report object expansion into multi-paragraph/image inclusion/etc, is one of the biggest issues to be addressed in STIX right now. @Aharon/@Mitre team – has been there any more thinking or formal planning for this issue? Anything we can do to move this forward?

Best regards,
Joep

From: Aharon Chernin <[hidden email]>
Reply-To: Aharon Chernin <[hidden email]>
Date: Thursday, January 8, 2015 at 10:35 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Sightings object proposal

Current state of sighting affairs:


Sightings are embedded within the indicator object. For a community member to report back a sighting the member must issue a major revision to the indicator with a new sighting embedded.


Problem statements:

  1. Intent. The intent of the user is not to issue a new indicator revision. The intent of the user is to say, “hey I saw this”. However, in today’s implementation of sightings, the user is forced to issue an entire new indicator revision just to say +1.
  2. Sharing hubs could receive hundreds of thousands of major revisions to indicators for sighting purposes only. I predict that soon sharing hubs will have more indicators stored for sighting purposes than for detection/prevention purposes.
  3. Sighting indicators? An indicator is an assertion. What you saw could have been that indicator, or it could have been any other indicator with the same observables. Sighting observables makes more sense as observables are facts. You know exactly what you see, but you will never actually be 100% sure if the context is the same as what someone else told you.  

Proposal:

  1. Create a new sighting top level object. Similar to TTP, Indicators, Observables, etc.
  2. The sightings object can reference any other high level object type: Similar to TTP, Indicators, Observables, etc
  3. The sightings object may or may not be able to contain related observables <- we need to discuss as a group
  4. Depreciate embedded indicator sightings in STIX 2.x

Soltra can create an example STIX document using this new sighting method, as well as provide an in-depth description of the new sightings object format, if the proposal generates interest within the group.



Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Sightings object proposal

Collie, Byron S.

+1 J

 

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: Don DeBolt [mailto:[hidden email]]
Sent: Wednesday, February 18, 2015 2:15 PM
To: [hidden email]
Subject: Re: [STIX] Sightings object proposal

 

+1 on report object expansion then sightings.

 

Don DeBolt

Product Architect

iSIGHT Partners Inc.

14151 Newbrook Drive, Suite 450
Chantilly, VA 20151

571-335-6958 mobile

 

 

From: Joep Gommers <[hidden email]>
Reply-To: Joep Gommers <[hidden email]>
Date: Wednesday, February 18, 2015 at 8:21 AM
To: "[hidden email]" <[hidden email]>
Subject: Re: [STIX] Sightings object proposal

 

Hi All,

 

Wanted to turn back around on this issue. I believe the sightings object, after the report object expansion into multi-paragraph/image inclusion/etc, is one of the biggest issues to be addressed in STIX right now. @Aharon/@Mitre team – has been there any more thinking or formal planning for this issue? Anything we can do to move this forward?

 

Best regards,

Joep

 

From: Aharon Chernin <[hidden email]>
Reply-To: Aharon Chernin <[hidden email]>
Date: Thursday, January 8, 2015 at 10:35 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Sightings object proposal

 

Current state of sighting affairs:

 

Sightings are embedded within the indicator object. For a community member to report back a sighting the member must issue a major revision to the indicator with a new sighting embedded.

 

Problem statements:

  1. Intent. The intent of the user is not to issue a new indicator revision. The intent of the user is to say, “hey I saw this”. However, in today’s implementation of sightings, the user is forced to issue an entire new indicator revision just to say +1.
  2. Sharing hubs could receive hundreds of thousands of major revisions to indicators for sighting purposes only. I predict that soon sharing hubs will have more indicators stored for sighting purposes than for detection/prevention purposes.
  3. Sighting indicators? An indicator is an assertion. What you saw could have been that indicator, or it could have been any other indicator with the same observables. Sighting observables makes more sense as observables are facts. You know exactly what you see, but you will never actually be 100% sure if the context is the same as what someone else told you.  

Proposal:

  1. Create a new sighting top level object. Similar to TTP, Indicators, Observables, etc.
  2. The sightings object can reference any other high level object type: Similar to TTP, Indicators, Observables, etc
  3. The sightings object may or may not be able to contain related observables <- we need to discuss as a group
  4. Depreciate embedded indicator sightings in STIX 2.x

Soltra can create an example STIX document using this new sighting method, as well as provide an in-depth description of the new sightings object format, if the proposal generates interest within the group.

 

 

Aharon Chernin
CTO

SOLTRA | An FS-ISAC & DTCC Company

18301 Bermuda green Dr

Tampa, fl 33647

813.470.2173 | [hidden email]

JA
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Sightings object proposal

JA
In reply to this post by Jordan, Bret
I'm confident that some already thought about sharing stuff from their
iPad in a private room ;p

More seriously, regarding the trust and integrity, we would need to
focus, work on the use case/requirements, and this could be a good
first target for publication:
https://stixproject.github.io/documentation/security/

My 2c

2015-02-18 17:53 GMT+01:00 Jordan, Bret <[hidden email]>:

> I agree.  For something that seems so simple, basically a sightings +1, this
> is pretty hard to do. Following along this line, I would love to see us
> create a list of common user interface use cases and then document how they
> would be marked up in STIX.  I feel we have done a good job at the high
> level, but we have a lot to do with the day-2-day.
>
> I know myself and Terry have thrown out a lot of ideas for how the sighting
> +1 could look.  But I think we need to figure out the one best way to do it.
>
> When I think of the short term evolution of all of this, I really see an
> iOS/Android app that interfaces with a TAXII server and allows you to see
> and play with threat data, very similar to a facebook / instagram type feed.
> People will follow items, comment on elements, add to them, enrich them with
> extra data, and then share them with different "communities" in their group.
> One specific example would be a group of researchers all working on the
> latest XYZ bot-net.  Imaging for a minute the back and forth communications
> that take place today over IM, Skype, Email, Phone, etc.
>
> Now image if we could build a tool, using STIX and TAXII to do this and then
> harvest the indicators, observables, COAs in real time and have it feed
> everyone's predictive and preventive tools.  This example also brings to
> light the massive hole we have today with trust and integrity.  We really
> need to figure out how to prevent the repos from getting poisoned.  If we
> can not solve this, then we will never share beyond very small and private
> groups which really hampers the long term objectives.
>
>
> Thanks,
>
> Bret
>
>
>
> Bret Jordan CISSP
> Director of Security Architecture and Standards | Office of the CTO
> Blue Coat Systems
> PGP Fingerprint: 62A6 5999 0F7D 0D61 4C66 D59C 2DB5 111D 63BC A303
> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
> not be unscrambled is an egg."
>
> On Feb 18, 2015, at 6:21 AM, Joep Gommers <[hidden email]> wrote:
>
> Hi All,
>
> Wanted to turn back around on this issue. I believe the sightings object,
> after the report object expansion into multi-paragraph/image inclusion/etc,
> is one of the biggest issues to be addressed in STIX right now.
> @Aharon/@Mitre team – has been there any more thinking or formal planning
> for this issue? Anything we can do to move this forward?
>
> Best regards,
> Joep
>
> From: Aharon Chernin <[hidden email]>
> Reply-To: Aharon Chernin <[hidden email]>
> Date: Thursday, January 8, 2015 at 10:35 PM
> To: "[hidden email]"
> <[hidden email]>
> Subject: [STIX] Sightings object proposal
>
> Current state of sighting affairs:
>
> Sightings are embedded within the indicator object. For a community member
> to report back a sighting the member must issue a major revision to the
> indicator with a new sighting embedded.
>
> Problem statements:
>
> Intent. The intent of the user is not to issue a new indicator revision. The
> intent of the user is to say, “hey I saw this”. However, in today’s
> implementation of sightings, the user is forced to issue an entire new
> indicator revision just to say +1.
> Sharing hubs could receive hundreds of thousands of major revisions to
> indicators for sighting purposes only. I predict that soon sharing hubs will
> have more indicators stored for sighting purposes than for
> detection/prevention purposes.
> Sighting indicators? An indicator is an assertion. What you saw could have
> been that indicator, or it could have been any other indicator with the same
> observables. Sighting observables makes more sense as observables are facts.
> You know exactly what you see, but you will never actually be 100% sure if
> the context is the same as what someone else told you.
>
> Proposal:
>
> Create a new sighting top level object. Similar to TTP, Indicators,
> Observables, etc.
> The sightings object can reference any other high level object type: Similar
> to TTP, Indicators, Observables, etc
> The sightings object may or may not be able to contain related observables
> <- we need to discuss as a group
> Depreciate embedded indicator sightings in STIX 2.x
>
> Soltra can create an example STIX document using this new sighting method,
> as well as provide an in-depth description of the new sightings object
> format, if the proposal generates interest within the group.
>
>
> Aharon Chernin
> CTO
> SOLTRA | An FS-ISAC & DTCC Company
> 18301 Bermuda green Dr
> Tampa, fl 33647
> 813.470.2173 | [hidden email]
> www.soltra.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [STIX] Sightings object proposal

Aharon Chernin
In reply to this post by Joep Gommers

There hasn't been much movement on the sightings object front. I think the thread went the direction of revamping relationships in STIX instead of adding a sightings object. I am still pro-sightings object as it is a concept that will be easy to use and wont impact backwards compatibility.


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

From: Joep Gommers <[hidden email]>
Sent: Wednesday, February 18, 2015 8:21 AM
To: Aharon Chernin; [hidden email]
Subject: Re: [STIX] Sightings object proposal
 
Hi All,

Wanted to turn back around on this issue. I believe the sightings object, after the report object expansion into multi-paragraph/image inclusion/etc, is one of the biggest issues to be addressed in STIX right now. @Aharon/@Mitre team – has been there any more thinking or formal planning for this issue? Anything we can do to move this forward?

Best regards,
Joep

From: Aharon Chernin <[hidden email]>
Reply-To: Aharon Chernin <[hidden email]>
Date: Thursday, January 8, 2015 at 10:35 PM
To: "[hidden email]" <[hidden email]>
Subject: [STIX] Sightings object proposal

Current state of sighting affairs:


Sightings are embedded within the indicator object. For a community member to report back a sighting the member must issue a major revision to the indicator with a new sighting embedded.


Problem statements:

  1. Intent. The intent of the user is not to issue a new indicator revision. The intent of the user is to say, “hey I saw this”. However, in today’s implementation of sightings, the user is forced to issue an entire new indicator revision just to say +1.
  2. Sharing hubs could receive hundreds of thousands of major revisions to indicators for sighting purposes only. I predict that soon sharing hubs will have more indicators stored for sighting purposes than for detection/prevention purposes.
  3. Sighting indicators? An indicator is an assertion. What you saw could have been that indicator, or it could have been any other indicator with the same observables. Sighting observables makes more sense as observables are facts. You know exactly what you see, but you will never actually be 100% sure if the context is the same as what someone else told you.  

Proposal:

  1. Create a new sighting top level object. Similar to TTP, Indicators, Observables, etc.
  2. The sightings object can reference any other high level object type: Similar to TTP, Indicators, Observables, etc
  3. The sightings object may or may not be able to contain related observables <- we need to discuss as a group
  4. Depreciate embedded indicator sightings in STIX 2.x

Soltra can create an example STIX document using this new sighting method, as well as provide an in-depth description of the new sightings object format, if the proposal generates interest within the group.



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