[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Add last_seen to campaign and intrusion set
+1 on John’s comments. Paul Patrick From:
<cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> Yeah I’m thinking the same thing here…it still seems like different types of data to me. A sighting is low-level data about what people thought they saw, why the
Campaign object itself or the Intrusion Set object itself is more finished intel backed by the producer creating the object. Many orgs will not have the capacity or skillbase to evaluate Sightings coming from many different producers and will just rely on
their vendors or more capable partners to tell them stuff…and IMO STIX should support that. I know we need to enable the ability for people to “show their work” and provide raw data so that more advanced organizations can do something with it, but I also
worry that we’re assuming every org has the skillbase to analyze that data when in reality many do not and just need people to tell them the summaries.
John From:
"Bret Jordan (CS)" <Bret_Jordan@symantec.com> Sorry for being late to this discussion. When I first proposed the sighting object, it was not my intent for it to replace the information that exists in other objects. So lets back up a sec: 1) A piece of intel that is generated by company X may gather the knowledge for that intel from who knows where. They may even infer certain parts based on past analysis. So there may NEVER be a "sighting".
It may just be intel. 2) Since on the Object Creator can update an object, I though a Sighting would be a great way for a producer to get feedback about things they produced. Thus the "sighting object" was proposed. So in a normal work flow I see people producing content about things, and people responding to that intel in the form of Sightings. Now, a producer may also through like an Incident release a bunch of Sighting
objects as well, to certain people, but I do not think that will be the norm. A sighting object in my mind is really saying something different than the content that may exist in other objects. At least that is how I originally proposed it. Bret From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of
Wunder, John A. <jwunder@mitre.org> I agree with Allan here…though there is a bit of overlap I think there’s sufficient difference to keep both.
1.
A sighting indicates that something is seen, but not that it was *first* seen. So having a campaign with a sighting at 8pm doesn’t mean the campaign was first seen at 8pm…it means
it was seen at 8pm. Same for last_seen.
2.
Both campaign and intrusion set are pretty high level analytic objects and I would agree that in general an analyst will be manually setting first_seen (to be honest I had not really
imagined the same with last_seen but I can see why some might want to). John From:
<cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> I would suggest the problem of updating the campaign/intrusion_set object or the sighting object exists regardless of adding the field or not. As first_seen is
duplicative of sighting attribute first_seen. So should an implementation create a sighting object each time they create a campaign or intrusion set? Currently the specification does not state one way or another either. Your question on whether a ‘user’ updates 1 object or 2 objects is really a product question on whether the product exposes the STIX model directly to the UI or
attempts to abstract some of the model in preference to exposing a simpler UI/workflow to the user. I would say that what a user sees is a product question not a STIX exchange question. So the question should be, “is it easier for a product to be implemented to send 1 object or 2 objects when 1 attribute changes”.
I would suggest in this specific case adding the last_seen attribute to campaign/intrusion_set is easier than always requiring sighting to be used for time-based
observations of intelligence objects such as campaigns/intrusions_sets….etc. But if the community disagrees and we want consistent behavior for when a sighting object is created then we should remove first_seen from campaign/intrusion_set
and *always* require sighting to be used for those time elements. As previously communicated, I’m not a fan of that approach as it seems extreme but is at least consistent. Allan From:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Right but what happens when that user sees the next instance of that campaign. Allan Thomson --- Re: [cti] Add last_seen to campaign and intrusion set ---
A sighting would seem unnecessary given that campaign and intrusion set already have the attributes for first_seen.
If we want to remove first_seen from campaign/intrusion_set and solely rely on sighting to convey first_seen/last_seen in a consistent manner for all objects then
that might work. But I was proposing a slightly more incremental approach than that. The thought was this. “Campaign by Threat Actor Group XXXX was originally started in Jan 2015 and we last saw the campaign used Aug 2016”. This is useful context. If you don’t know the information or don’t want to have to publish an update then you just state “Campaign by Threat Actor Group XXXX was originally started in Jan 2015” The former adds useful context and the later provides a little less. This is not a big ask. Just the ability to have some additional context without having to use sighting objects to represent this information. Allan From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> I am confused on the purpose of this field - Isn't that the purpose of the sighting object?
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and
attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]