OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cti-stix] Top-level Sighting Object from last meeting


I would tend to agree Terry (just feels cleaner and more focused), although I’m curious about your thoughts are on how we restrict that.  If the reference is just an ID, couldn’t anything be put in that field regardless of what we say the ‘rules’ are?

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Monday, October 26, 2015 6:57 PM
To: Terry MacDonald; Jason Keirstead
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Top-level Sighting Object from last meeting

 

Hi All,

 

One other thing I wanted to highlight was a point raised by Aharon late last week in the STIX meeting. We need to discuss what exactly we want the Sighting Object to be able to reference. As I understand it the available options are:

 

·         Should a Sighting Object only reference ‘detected’ information (e.g. Observable Instances only – most similar to an Indicator)

OR

·         Should a Sighting Object reference any other top-level Object (e.g. Threat Actor’s, TTPs, etc). This will be the most flexible and least restrictive for the future.

OR

·         Should a Sighting Object reference some top-level Objects based on STIX model  (e.g. Threat Actor’s, TTPs, Indicators, Incident, Report)

 

My personal preference is for the first option – but I am very interested in what others think. I think we need to scope the Sighting object and discuss its purpose fairly early on to work out exactly where it will fit in the model.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Tuesday, 27 October 2015 9:21 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Top-level Sighting Object from last meeting

 

Hi Jason

 

- What is "Alternative_ID" ?

 

The Alternative_ID was taken from the IndicatorType object.  From that object’s description it ‘Specifies an alternative identifier (or alias) for the cyber threat Indicator.’. The idea was to allow the Sighting to have a reference of some kind, referring back to the ID that the tool that identified it had given it. It may not be useful in the Sighting context but I wanted to include it just in case. TBH we may want to think more about how we handle ‘aliases’ in general across the whole STIX model…

 

- Can you add to the proposal, which fields would be mandatory, and which optional? It's unclear to me. I presume a subset is mandatory, but not all.

 

Yes, my thinking was that a subset of the Sighting fields would be mandatory. I’ve suggested some below but would really like to see what everyone else thinks.

 

Suggested Mandatory Fields

·         Version

·         Title

·         Timestamp / Time Period

·         One or more referenced objects (i.e. idref) – (This would be done via Top-level relationship object)

 

Suggested Optional Fields

·         Sighting Count

·         Timestamp / Time Period

·         Victim Organization information

·         Producer Organization information

·         Sighting Confidence

·         TLP / Data Markings

·         Alternative Sighting ID

·         Sighting Type

·         Description

·         Short Description

 

Mark’s other post earlier today reminded me that I had earlier requested a Sighting object last year (https://github.com/STIXProject/schemas/issues/306). In there I even drew a nice updated STIX model diagram to include where I personally saw the Sighting object located (thanks to Bret for the visio). But this may help provide more context?

 

stix_diagram_terry_v2 0_proposal

Please note this reflects my own personal viewpoint.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Tuesday, 27 October 2015 8:34 AM
To: Terry MacDonald <terry@soltra.com>
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Top-level Sighting Object from last meeting

 

Questions

 

- What is "Alternative_ID" ?

 

- Can you add to the proposal, which fields would be mandatory, and which optional? It's unclear to me. I presume a subset is mandatory, but not all.

 

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

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

 

 

----- Original message -----
From: Terry MacDonald <
terry@soltra.com>
Sent by: <
cti-stix@lists.oasis-open.org>
To: "
cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Cc:
Subject: [cti-stix] Top-level Sighting Object from last meeting
Date: Mon, Oct 26, 2015 2:00 PM
 

Hi All,

 

Given the flurry of discussions about features for STIX v2.0, it’s probably the right time to resend the top-level STIX Sighting Object conversation starter out again.  So here are the slides. Please feel free to comment/feedback/complain/call me names.

 

Please note – the strawman UML model is an abstraction based on the use of the Sighting Object only for Observable Instances; it assumes that Indicators will similarly be restricted to only allowing Observable Patterns. The idea being that Indicators = ‘things to look for’ and Sightings = ‘things we’ve found’.

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | terry@soltra.com

 

 

 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]