Hi Mark,
Great points!
My thought would be that the Sighting
structure permit a reference to any other top level object, but for 2.0 we limit (in the spec) Sighting to only the use case(s) we know enough to solve (e.g., sightings of detected information).
This is in effect what I was thinking about for the top-level relationship object. If we used a top-level relationship object it would be possible
to have a relationship between any STIX ‘data’ objects; it would only be the restrictions of the STIX data model that would limit these from being legal. So we could gain that functionality fairly easily.
There’s probably also a variant of this use case where the sighting references something not in STIX (e.g., a signature that was not previously sent via STIX).
If we require that the Sighting reference a STIX object, then we are also requiring that the e.g., Indicator be previously sent via STIX.
I don’t necessarily agree here that we need to use an non-STIX ID to reference Sightings outside of STIX. Rather than allow external references using
non-STIX IDs, we could handle this one of two ways:
·
Require all STIX (including internal STIX) to have an externally resolvable namespace (i.e.
http://taxi.orgA.com-indicator- 421e7b7b-7db0-4a28-8bc5-03ff43c09de1). The problem with this is that the company needs to setup and use and externally referenceable URI in order to use the namespace.
The benefit is that if the producer decides to share the Sighting it is very easy to do so as the Sighting is ready to be shared by default.
·
Have an internal only namespace – the STIX version of RFC1918 – to allow internal only STIX IDs (i.e. internal -indicator-
421e7b7b-7db0-4a28-8bc5-03ff43c09de1). The problem with this is that I will require the STIX IDs to be translated into the externally resolvable namespace (i.e.
http://taxi.orgA.com-indicator- 421e7b7b-7db0-4a28-8bc5-03ff43c09de1) as it is being shared (kind of like STIX NAT). This translation
would need to be maintained for as long as the STIX objects are maintained within the internal system.
IMO source should be a required field, even if there is an explicit option for not disclosing the actual source (e.g., Unknown, Anonymous). I roughed out a quick
prototype the other day, and sighting info without a source just felt incomplete.
If the Source should be a required field then I would think the Victim information should too. As Pat and others have mentioned it is often important
to understand the traits of the victim in order to understand the aims of the attacker.
Alternative_ID makes sense for indicator, but IMO not as much for a sighting (minus the previous caveat). In theory, the processing software could dereference
the referenced ID then use any fields from that dereferenced object (like Alternative ID in the case of indicators). Or else we could have a “reference type” field.
·
Note: This dereferencing capability probably relies on the query discussion happening in the TAXII SC. A “get by ID” use case has been raised a few times.
Not sure I understand this. Can you please expand this a bit more. (Apologies).
Cheers
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com From: Davidson II, Mark S [mailto:
mdavidson@mitre.org]
Sent: Tuesday, 27 October 2015 10:39 PM
To: Jonathan Bush (DTCC) <
jbush@dtcc.com>; Terry MacDonald <
terry@soltra.com>; 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
My thought would be that the Sighting
structure permit a reference to any other top level object, but for 2.0 we limit (in the spec) Sighting to only the use case(s) we know enough to solve (e.g., sightings of detected information).
As a means of enforcing this rule, the spec could have text along the lines of “The reference field MUST reference an (e.g.,) Indicator. Note that
this rule may be expanded in future revisions of STIX”. This rule would give software an easy way to toss out non-conforming sightings.
There’s probably also a variant of this use case where the sighting references something not in STIX (e.g., a signature that was not previously sent
via STIX). If we require that the Sighting reference a STIX object, then we are also requiring that the e.g., Indicator be previously sent via STIX. I think that having everything done via STIX is the ideal case, and the one we should optimize for. But we
should consider the uneven progress that will be made toward STIX adoption. Say, for instance, somebody wants to add STIX code to an IDS. It would be great (IMO) if they could have the sensor output STIX sightings for signatures that were not sent via STIX
(perhaps they are sent by the IDS’ management console), then once a STIX source is hooked up to the sensor (maybe the management console gets upgraded later), just start populating the sightings more completely. The question for me is how to make the sighting
object useful without necessarily having a dereferencable STIX ID (maybe this is an argument for Alternative ID? And we say that people MAY use Alternative ID in lieu of a STIX object ID? If we did that, IMO the rules regarding the usage of Alternative ID
would have to be pretty strict). Anyway, this paragraph is turning into a ramble so I’ll end it.
A couple other shorter thoughts:
·
IMO source should be a required field, even if there is an explicit option for not disclosing the actual source (e.g., Unknown, Anonymous).
I roughed out a quick prototype the other day, and sighting info without a source just felt incomplete.
·
Alternative_ID makes sense for indicator, but IMO not as much for a sighting (minus the previous caveat). In theory, the processing software
could dereference the referenced ID then use any fields from that dereferenced object (like Alternative ID in the case of indicators). Or else we could have a “reference type” field.
o
Note: This dereferencing capability probably relies on the query discussion happening in the TAXII SC. A “get by ID” use case has been
raised a few times.
·
I agree that for Sightings, the “inside the org” use case overlaps significantly with the “org to org” use case. I suspect this is the
case with many other use cases also.
Thank you.
-Mark
From:
cti-stix@lists.oasis-open.org [ mailto:
cti-stix@lists.oasis-open.org ]
On Behalf Of Bush, Jonathan
Sent: Monday, October 26, 2015 7:01 PM
To: 'Terry MacDonald' <
terry@soltra.com >; 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
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?
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.