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] STIX 2.0 - Sightings object


I have to admit I am still a fan of a separate Sightings object and Relationship object. The reason is specifically 'graph' based - nodes and edges. As I've said for more than a year now we need to separate the 'data' nodes describing 'things' from the edge nodes (the assertions that people make). If we conflate these things together as we do currently with the Sightings within the Indicator object, we lose flexibility, and the ability to do some interesting things in the future, such as:

-----

Use Case:

Company A now has more information about the attacker that is attacking it. It now has additional Indicators that will allow it to check if this is really an attack from that ThreatActor, and if so, CompanyA will be able to send out a STIX Package (broadcast) out to the TrustGroupAlpha indicating that the CompanyA Incident is related to the CompanyB Incident and that CompanyA thinks it was the same ThreatActor in both cases.

This also allows all organizations listening to the TrustGroupAlpha trust group to keep track of this conversation and compile their own lists of Indicators/Incidents/ThreatActors/etc such that they are better prepared if the ThreatActor targets them.

-----

Keeping relationships completely separate from data objects will allow us to retain flexibility for the future, and will allow producers and consumers to describe relationships that we haven't even thought of yet. STIX should provide people the building blocks to describe what they are seeing in the real world. Just like Legotm  people should be able to build what they want out of those building blocks. We just need to provide enough building blocks to be useful, and the ability to put those building blocks together (i.e relationships).


Cheers

Terry MacDonald | STIX, TAXII, CybOX Consultant




Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.

On 21 August 2015 at 06:04, Aharon Chernin <achernin@soltra.com> wrote:

Bret, I agree. I personally am not a fan of embedded content.


Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | achernin@soltra.com



From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Thursday, August 20, 2015 2:58 PM
To: Jonathan Bush (DTCC)
Cc: Wunder, John A.; Aharon Chernin; Davidson II, Mark S; cti-stix@lists.oasis-open.org

Subject: Re: [cti-stix] STIX 2.0 - Sightings object
 
Sorry my bad.....  

I am hoping we can get rid of the idea of things like the report object having either embedded data or referenced data.  I think it should be one or the other, and I would lean to the idea of the report object just using referenced data.  



Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Aug 20, 2015, at 11:36, Bush, Jonathan <jbush@dtcc.com> wrote:

Bret – Can you explain this a little? 
 
Going from a database design perspective, wouldn’t you have objects that have primary keys and also foreign keys that relate it to other objects?  What am I missing?
 
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, August 20, 2015 12:36 PM
To: Wunder, John A.
Cc: Aharon Chernin; Davidson II, Mark S; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX 2.0 - Sightings object
 
And my hope is that in in STIX 2.0 we can get rid of the idea of having both ID and IDREF in the same object.  It is either one or the other.  It is either a container of data, thus having an ID.  Or it is an object like Report that just contains IDREFs.  

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
 
On Aug 20, 2015, at 10:27, Wunder, John A. <jwunder@mitre.org> wrote:
 
As a place to start, how about in the current STIX model anything that extends from Related___Type is a relationship object, anything with a normal @idref is not? 
 
Sighting wasn’t top-level before so we get to make it up.
 
On Aug 20, 2015, at 12:19 PM, Aharon Chernin <achernin@soltra.com> wrote:
 
We need to make sure it's very clear where the relationship object starts and ends. If I am not forced to use the relationship object for a sighting relationship, then I go back to supporting an atomic sighting object.

Aharon 

Sent using OWA for iPhone 

From: Wunder, John A. <jwunder@mitre.org>
Sent: Thursday, August 20, 2015 12:07:08 PM
To: Aharon Chernin
Cc: Jordan, Bret; Davidson II, Mark S; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX 2.0 - Sightings object
 
Are you actually forced to use the relationship object to have sighting work there? I see that as a separate use case from relationships, and in cases like this we can still have the target_id field directly there without the need for a new object. Same thing for an indicator pattern, for example.
 
While those are references between top-level constructs they seem different than the normal type of relationships we’ve been discussing.
 
John
 
BTW: Any thoughts on setting up a slack channel for STIX dev discussions? Sometimes I think that would be more conducive to these questions than e-mail.
 
On Aug 20, 2015, at 11:58 AM, Aharon Chernin <achernin@soltra.com> wrote:
 
Bret, I almost always prefer atomic objects.
 
If we do both a relationship object and a Sightings atomic object together, it just seems... well weird.... (not very scientific I know)
 
Example Sightings Object - 
ID: Sighting GUID
Marking: Sighting TLP
Producer: Who made the sighting
Timestamp:
Target_ID: Replaced by Relationship Object
 
Now I am going to be forced to use the relationship object to make the Sighting work. I am also going to be forced to make a potentially large number of new Sighting Objects (since there is a timestamp). Also, a sighting by itself, without the looking into the Relationship object is kind of useless. 
 
We can eliminate this extra complexity by eliminating the atomic Sightings object and replacing it with a relationship type.
 
Just debating <OutlookEmoji-😊.png>
 
Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | achernin@soltra.com

 


From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Thursday, August 20, 2015 11:33 AM
To: Davidson II, Mark S
Cc: Aharon Chernin; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] STIX 2.0 - Sightings object
 
One thing to keep in mind is that we want the objects as small and simple as possible.  Some times to make them more broad you have to add a lot of extra fields.  This should be avoided.  We want them to be as atomic as possible.  Also, if they are separate then they can grow and evolve independently.  
 
This is one of the many things I do not like about how STIX and CybOX is done today.  The excessive use of object oriented reuse makes it nearly impossible to fix or change certain things as that would have adverse effects on other areas that can not take those changes.  
 
Object reuse is not always a good thing.  

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
 
On Aug 20, 2015, at 07:16, Davidson II, Mark S <mdavidson@MITRE.ORG> wrote:
 
Great discussion topic!
 
There has been some previous discussion on the STIX Schemas GitHub on this topic: https://github.com/STIXProject/schemas/issues/291
 
The conversation seemed (to me) to settle on the idea that there were three concepts that are related in some way:
1.       Relationships – A link between objects (e.g., this TTP is related to that Indicator)
2.       Assertions – The +1/-1 concept
3.       Sightings – “I saw that, too!”
 
It seems that the structures are similar across the three concepts (e.g., id, from, to, assertion, source/confidence/rationale) and that the larger open question is whether humans are benefitted by these things being variations of the same concept or three different concepts (or something else).
 
I personally think there is a single set of common properties that can do Relationships, Assertions, and Sightings, and that it looks roughly like what Aharon posted. However, there was a counter-point that this combining of concepts makes it more difficult to understand.
 
I’ll leave the group with these questions:
1.       Is there a single set of properties that makes sense for Relationships, Assertions, and Sightings?
2.       If there is a single set of properties, does it make sense to combine them, as Aharon has mentioned?
3.       What clarifying questions, if any, do you have that will help you answer #1 or #2?
a.       Note that this might be the most important of the three questions!
 
Thank you.
- Mark
 
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Aharon Chernin
Sent: Thursday, August 20, 2015 8:25 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] STIX 2.0 - Sightings object
 
This should be "sightings object rethought". While coming up with a proposal, I spotted a different way of thinking about Sightings. In my opinion, the most important thing is determining which STIX object is being sighted. However, there is some other bits of information that is useful: sightings producer and date/time of sighting.
 
Now take a look at the recent relationship object discussions:
 
Relationship Object Discussion:
ID [1]: The ID of the relationship, a simple random GUID
Marking[1]:  The ID of the marking object that you should reference 
Version [1]: The version of the relationship; a simple number to be used with the ID for version control 
Type [1]: The “type” of relationship being expressed.  (Not sure of how this works yet)
Description [1]: A single simple and short description
Source [1] : The ID of one or more source entities in the relationship as a URI (not QName)
Targets [1..N]: The ID of one or more targets in the relationship as a URI (not QName)
Start [1]: A timestamp in UTC stating when the relationship between the objects started, or the text 'unknown'.
End [1]: A timestamp in UTC stating when the relationship between the objects ended, or the text 'ongoing', or the text 'unknown'.
Reliability/Confidence [1]: A measure of confidence in the relationship using the Information Reliability scale.
Producer [1]:  A simple producer object like what John calls out
Timestamp [1]: A timestamp in UTC stating when the relationship object was created.
 
 
Idea:
 
Could a sighting be a type of Relationship? 
 
Relationship Object Discussion:
ID [1]: <GUID>
Marking[1]:  TLP Green
Version [1]: 1
Type [1]: Sighting
Description [1]: Soltra Edge reported Sighting
Source [1] : Soltra
Targets [1..N]: soltra:indicator-<GUID>
Start [1]: 
End [1]: 
Reliability/Confidence [1]: 
Producer [1]:  Soltra
Timestamp [1]: <timestamp>
 
 
Or is there more meta data we need to collect regarding sightings that a sighting deserves it's own object?
 
 
Aharon Chernin
CTO
SOLTRA | An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
813.470.2173 | achernin@soltra.com
 

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]