I hate to be a downer but I have to point out that this probably won't work for U.S. government markings, which are much more complex. Whether that's a show-stopper for the TC I don't know. OTOH USG could internally do something more complicated by replacing
the "marking" string with an actual object, it just wouldn't work outside of that enclave.
Some industry groups are also working on more complicated marking structures (FIRST, for example). Might be smart to future-proof by supporting structured markings ahead of time, or just wait until they have something usable before doing that.
I'm kind of ambivalent, simpler is always better but I worry that strings are *too* simple.
John
Perfect, I agree a simple string would be good.... Do we need to provide a helper for those things that are not TLP? Something like:
{
ID: "12312312321312",
MarkingType: "TLP",
Marking: "Amber",
etc
}
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."
The most common used Marking today is TLP. Today we just use a string to describe the TLP. Below, we just say "Amber".
<marking:Marking_Structure color="AMBER" xsi:type="tlpMarking:TLPMarkingStructureType"/>
The next most used marking is simple marking type, which in the grand scheme of things is just a string.
I could see the creation of an object if there was more context or metadata around marking than just a string
Aharon Chernin
CTO
SOLTRA |
An FS-ISAC & DTCC Company
18301 Bermuda green Dr
Tampa, fl 33647
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."
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.
|