[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Re: [EXT] [cti] Recap of Working Call
|
I would disagree with this assertion. There are definitely use cases for defining and using markings using STIX that may not have âpre-existingâ formal and explicit external definitions. Are some defined explicitly externally? Sure, things like TLP are obviously that way. That does not mean that ALL are. And it also does not mean that there is not clear value in providing the externally defined explicit descriptions for particular marking definitions as part of the STIX _expression_ of that marking.
The downside is potentially extra text for consumers that donât need it (though marking definitions are not typically heavily duplicated so the impact is minimal).
The upside is improved clarity and understanding for consumers not deeply familiar with the externally defined markings. I would suggest that the upside heavily outweighs the downside. I would also suggest we carefully avoid thinking of marking definitions as simply external references. The data marking approach in STIX was very intentionally designed to provide somewhat of a âclosedâ system where when given a set of
STIX content you have enough in hand to appropriately understand the content and how to handle it. It was explicitly designed to avoid situations where you got the content but had to try to go somewhere else to figure out how to handle it, often defined in
non-machine-processable forms. Sean Barnum Principal Architect FireEye M: 703.473.8262 E: sean.barnum@fireeye.com From: <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> "The point is marking definition objects are not defining a marking â they are expressing pre-existing markings - in STIX. Markings are external things â and should not be âdescribedâ in a STIX object." That is an interesting view, I wonder if everyone agrees with that? Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Piazza, Rich <rpiazza@mitre.org> âWe did not have consensus one way or another on adding a description to the Marking Definition Object. We will need to bring this back up next week. â I was trying to make a point about not adding a description to Marking Definitions, and explain my point of view about them in general, on the call. I might not have been clear so I wanted to
state my opinion in writing. First, the original argument against including a description property on Marking Definitions was that it could contain text that contradicts the content of the definition property. I still think
this is valid. Obviously, this is a data quality issue â but I think it becomes more important because marking definitions can be related to classification (S, TS, etc), and we want to make sure that there is no room for confusion. Second, I am in favor of the optional name property. Itâs useful to have a âhandleâ for a marking definition, other than its id. Knowing that the marking definition you want to use is named
âTLP:GREENâ will make it easier to assign a value to the marking ref properties of an object. However, Iâm not sure why the TLP:GREEN marking definition object needs a description. I donât think you should be learning about what TLP:GREEN means from a STIX
object. I could see adding an external_reference property to those objects â but that would require a change to the objects defined in the spec â so that could be an issue. Third, IMHO â I donât see there being a large variety of different marking definition objects.
As stated previous there is one and only one marking definition object for each of the TLP âcolorsâ â and those
MUST be used â according to the spec. Statement marking definitions â related to copyrights or terms of use, would probably be relatively finite in number. Iâm helping DHS develop a new type of marking definition for ACS â which is the standard markings used by the U.S. Government. They are very complex, but there is probably a lot of reuse, so
I would hope that there are no duplicate marking definition objects for a specific ACS marking. The definition is explicit in the full definition of the marking, and shouldnât be âsummarizedâ in a description property. Knowing how to interpret an ACS marking
should not be based on a summary description in a STIX object. The point is marking definition objects are not defining a marking â they are
expressing pre-existing markings - in STIX. Markings are external things â and should not be âdescribedâ in a STIX object. Rich P. From:
<cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com> All, Today we were able to discuss and get working call consensus on the following items: 1) SCO that have conflicting property names with common properties. The consensus on the call was to rename the conflicting properties on the following objects: Directory Object, File Object, Process Object, and Windowsâ
Registry Key Object. John-Mark pointed out that we may need to add some clarifying text to patterning to address this. Christian from NewContext said he would help identify any changes that are needed. 2) Language Content object and how it can be pinned to a specific version. This was a somewhat controversial topic. In the end we did a quick up/down vote. The choices were to remove the property or make it optional.
The consensus on the call was to leave the property on the object, but make it optional. The vote was 11-2. 3) Indicator to Observed Data relationship type. After talking about this for a few weeks, the consensus on the call today was to call this relationship "based-on". 4) A few weeks back we started a discussion about some inconsistencies in some of the objects. We discussed more of these on today's call and had working call consensus to do the following: a) Leave the property name "is_family" with the prefix "is_" on the Malware Object b) Leave the name property optional on the Grouping Object c) Add description to the Sighting Object d) Leave the name property optional on the Marking Definition Object e) Add an optional name property to the Location Object We did not have consensus one way or another on adding a description to the Marking Definition Object. We will ned to bring this back up next week. We did not have consensus one way or another on whether spec_version should be required on SCOs. We will bring this back up next week. There seems to be a slight preference for making it required. But there is
also a strong view that the extra on-the-wire bloat is too significant. 5) SCO external relationships. We had working call consensus to make the following SCO relationships (âresolves-to-refsâ and âbelongs-to-refsâ) external on the following SCOs: Domain Name, IPv4 Address, IPv6 Address.
The editors will need to do some work to make this happen. 6) The following text has been proposed for inclusion to section 3.4. If you have changes or further suggestions please send them to the email list. Deterministic IDs (UUIDv5) in the example SCOs contained in this specification were computed using the algorithm defined in section 2.x. Every attempt was made for these IDs to be accurate. Certain IDs which were
used in reference properties of the examples did not include the actual object, and therefore it was impossible to accurately compute the appropriate UUIDv5. In these cases, a UUIDv4 was generated and the "version" character of the UUID was changed from a
4 to a 5 7) The following text has been proposed for inclusion to section 3.6. If you have changes or further suggestions please send them to the email list. In STIX 2.1, SCO do not explicitly have those three versioning properties. Therefore, a SCO cannot be versioned unless custom properties (discussed in section 11.1) are used. Producers who plan on doing this SHOULD
use the property names created_by_ref, revoked, created, and modified. In the rest of this section "STIX objects" should be read to include SCOs customized in this way. Thanks Bret CAUTION: This email originated from outside of FireEye from a third party. Please take extra precaution clicking on any embedded links or downloading and opening file attachments. If you feel this is a suspicious email, please use the âReport
Phishingâ button in your Outlook toolbar. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]