[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-stix] Top-level Sighting Object from last meeting
Ah ok.
The Alternative_ID was meant to reference something like an ID from an alerting tool. It was supposed to help record that mapping so
that you could go back to the original alert in the alerting tool that produced the sighting. 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]
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). No worries; upon re-reading my email I had to think about what I meant, so clearly I was unclear. I made an assumption that the Alternative ID field you proposed would be redundant with the Alternative ID from the referenced Indicator (or more generally, referenced
object). This assumption may have been in error. That said, I feel that redundant fields probably aren’t needed in sightings – a processing system can dereference the sighted object and get any necessary information from the dereferenced object. If Alternative ID means a sighting’s Alternative ID, then my previous paragraph doesn’t really apply. In that situation, I’d like raise an open question as to
why the Alternative ID is necessary (we don’t need to answer the question now). Thank you. -Mark |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]