Think of it like we are stubbing in methods and functions, we know basically what they need to do and return, but the details are still a bit foggy...
I actually think we are 90+% there right now on finishing this.
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 Jul 30, 2015, at 11:53, Wunder, John A. <
> wrote:
FWIW I was mostly using that as a stand-in for some kind of producer construct.
I feel like we're running into a lot of fundamental issues here (versioning, producer, IDs, serialization, etc.) and was hoping to somewhat limit our topic of discussion in this thread to just the relationship object. Obviously that failed :)
John
From: <
> on behalf of Jason Keirstead
Date: Thursday, July 30, 2015 at 1:27 PM
To:
Jordan, Bret
Cc: Aharon Chernin,
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
I'd like to go into more detail on the producer field because I still don't feel the proposal John has solves my use case - maybe it does and he was just using MITRE as an example that could be expanded upon - and if so, please correct me. IE - I would like the producer to in the end be able to be tied all the way back to my TAXII authentication- the authority discussed on the list yesterday. This is more granular than just for example IBM - I would like to see a producer field than can be in the end be traced all the way back to Jason
inside the organization. Note, I am not saying that we should be sticking emails or user names in the producer field, but the producer should be able to have an ID that can be affiliated with a user, not restricted to simply an organization.
This gets very important as soon as you move outside the simple Corp to ISAO bubble where everyone has trust, and get into ISAO to ISAO or, ISAO to public to ISAO and vice-versa... these various entities will have various trust levels, and they won't all have access to some kind of internal audit trail to be able to say who at IBM did this bogus annotation? These makings have to be able to be tied to an identity...
- 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
<graycol.gif>
Jordan, Bret ---2015/07/30 02:15:34 PM---The reason why I like a top level Marking object is, I believe, and PLEASE correct me if my assumpti
From:
Jordan, Bret <
>
To:
Aharon Chernin <
>
Cc:
<
>
Date:
2015/07/30 02:15 PM
Subject:
Re: [cti-stix] Proposal - Top Level Relationship Object
Sent by:
<
>
The reason why I like a top level Marking object is, I believe, and PLEASE correct me if my assumptions are wrong, that we could build a small repository of simple markings that will work for say 70% to 80% of the market. Then people just need to use those ID values. They become well known markings and it makes it easier to understand and process.. Then for those groups that need really super elaborate markings, they can do that as well. The other reason for having a top level marking object, is that I think people will end up using them over and over in side of an trust-group or eco-system, or in other parts of a STIX document. If I am wrong, please correct me....
Updated based on John's comments... I think we are getting close to the point of being able to pull this out of email and make it an official proposal in a wiki document... Things outstanding from my view: 1) Start and End times, 2) What does Reliability/Confidence actually look like inside, 3) Marking, 4) Type. Anyone want to take a stab at those?
ID
[1]: The ID of the relationship, a simple random GUID
Marking
[0..n]: 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.
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.
[attachment signature.asc deleted by Jason Keirstead/CanEast/IBM]
<graycol.gif>
---------------------------------------------------------------------
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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
