OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships


I agree with Sean on all his points as outlined below. First_seen and Last_seen seem more appropriate for a Sighting Relationship which ALREADY has first_seen and last_seen.


Bret


From: Sean Barnum <sean.barnum@FireEye.com>
Sent: Wednesday, August 30, 2017 2:58:40 PM
To: Jason Keirstead; Allan Thomson
Cc: Bret Jordan; Wunder, John A.; Sarah Kelley; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships
 

I would suggest that in the vast majority of cases for Relationships, "valid_from/valid_to" is what is intended and appropriate rather than “first_seen/last_seen”.

I can see the use for “first_seen/last_seen” but they are the edge case and not the core case.

 

 

Consider a case where Org A has “seen” several instances of (really this would be observations/sightings) Malware X being used by ThreatActor Y during the 2016 calendar year.

More specifically, they saw it being used heavily from Jan to Mar, not used at all between Mar to Sep, then heavily used Sep to Dec.

If they want to share to any internal or external party useful info about ThreatActor Y using Malware X, they would convey each of those objects along with two “uses” (or whatever official value means that) Relationship objects relating them, one with valid_from=jan and valid_to=Mar and the other with valid_from=sep and valid_to=dec. This is asserting that ThreatActor Y was using Malware X from jan to mar and sep to dec.

They would not convey a relationship object between the actor and malware with first_seen=jan and last_seen=dec. That would accurately reflect the first time and last time it was observed by Org A but does not tell the story that should really be conveyed in the common case.

There is also the possibility that the overall window for the assertion is based on sub-windows asserted by other parties and shared to Org A rather than Org A seeing the actual use. This would not be appropriate to assert as first_seen or last_seen as there is confidence associated with any of the sub-assertions. The information could also have come from sources other than observation such as a human source within ThreatActor either acting as an informant or talking about using the malware on a hacker board. Again, first_seen or last_seen would not be appropriate.

FireEye sees all of these variations in the real-world all the time.

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Wednesday, August 30, 2017 at 4:42 PM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, Sean Barnum <sean.barnum@FireEye.com>, "Wunder, John A." <jwunder@mitre.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

Agree, this is the point I was making.

"valid_from/to" means something very different. If we don't care to capture it, OK, but we should just re-use the terms when we actually mean first/last seen.

Sent from IBM Verse

Allan Thomson --- [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships ---

 

From:

"Allan Thomson" <athomson@lookingglasscyber.com>

To:

"Bret Jordan" <Bret_Jordan@symantec.com>, "Sean Barnum" <sean.barnum@FireEye.com>, "Wunder, John A." <jwunder@mitre.org>, "Sarah Kelley" <Sarah.Kelley@cisecurity.org>, cti-stix@lists.oasis-open.org

Date:

Wed, Aug 30, 2017 5:03 PM

Subject:

[cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships


 

Agreed that we should be clear on what we are trying to communicate.

 

Valid_until suggests to me that somehow the relationship will expire after X hours/mins/days.

 

Last_seen suggests to me that the last time the reporting entity saw the connection between those entities.

 

I prefer the later because it’s a statement in fact whereas valid_until is an estimate by the producer on when they “think” something is no longer connected. That later aspect is subjective at best.

 

Allan

 

From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Wednesday, August 30, 2017 at 12:43 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sean Barnum <sean.barnum@FireEye.com>, "Wunder, John" <jwunder@mitre.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

well it depends on what we are saying and what use-case we are trying to solve. If we are saying that this relationship between this Malware and COA for example is only valid for these time frames, then valid_from and valid_until are the better choice, just like what we did with Indicators.

 

If we are saying that this relationship was seen  between these time frames, that seems like a "sighting".  Remember Sighting is just a relationship with an extra property and the ability to have them be one-armed relationships.

 

So what is the use-cases we are trying to solve with this request???

 

Bret

 


From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Sent: Wednesday, August 30, 2017 1:13:43 PM
To: Sean Barnum; Wunder, John A.; Sarah Kelley; cti-stix@lists.oasis-open.org
Subject: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

We’ve used first_seen and last_seen in other objects.

 

I suggest we be consistent with both terminology and semantics of these properties with prior SDOs.

 

Regards

 

Allan

 

 

From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com>
Date: Wednesday, August 30, 2017 at 10:53 AM
To: "Wunder, John" <jwunder@mitre.org>, Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

I could support “valid_from” and “valid_to”

 

Sean Barnum

Principal Architect

FireEye

M: 703.473.8262

E: sean.barnum@fireeye.com

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Wednesday, August 30, 2017 at 10:26 AM
To: Sarah Kelley <Sarah.Kelley@cisecurity.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

I support this change, which I believe was originally suggested by Allan. You can think of many use cases in real intelligence:

 

  • This threat actor tended to use this particular RAT in 2016, but moved on to a different one in 2017
  • The intrusion set targeted the US in 2016, but expanded to also target South America in 2017.

 

I would say that the big question here is whether we call the fields “valid_from” and “valid_to” or “first_seen” and “last_seen”. I think I have a slight preference for valid_from and valid_to because of some of the connotations of “last_seen” being present vs. absent. Like if last_seen is not on the object, what does it mean, vs. if last_seen is on the object set to yesterday. Valid_from on the other hand makes it clear that if the producer feels like the relationship is still valid they don’t provide the field.

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of Sarah Kelley <Sarah.Kelley@cisecurity.org>
Date: Wednesday, August 30, 2017 at 10:18 AM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

I’m going to be sending a series of emails regarding small changes that have been requested in moving from STIX 2.0 to STIX 2.1. The hope is that these won’t be particularly controversial, but if anyone has any objections to these changes, please speak up.

 

GITHUB issue #11 (https://github.com/oasis-tcs/cti-stix2/issues/11 )

 

There has been a suggestion to add “first_seen” and “last_seen” properties onto the relationship object.  The Relationship object would then look something like this (with the suggested changes highlighted in yellow):

 

3.1.2   Properties

Common Properties

type, id, created_by_ref, created, modified, revoked, labels, confidence, lang, external_references, object_marking_refs, granular_markings

Relationship Specific Properties

relationship_type, description, source_ref, target_ref

Property Name

Type

Description

type (required)

string

The value of this property MUST be relationship.

relationship_type (required)

string

The name used to identify the type of Relationship. This value SHOULD be an exact value listed in the relationships for the source and target SDO, but MAY be any string. The value of this property MUST be in ASCII and is limited to characters a–z (lowercase ASCII), 0–9, and hyphen (-).

description (optional)

string

A description that provides more details and context about the Relationship, potentially including its purpose and its key characteristics.

first_seen (optional)

timestamp

 

The beginning of the time window during which the relationship should be considered valid.

 

last_seen (optional)

timestamp

 

The end of the time window during which the relationship should be considered valid.

 

source_ref (required)

identifier

The id of the source (from) object. The value MUST be an ID reference to an SDO (i.e., it cannot point to an SRO, Bundle, or Marking Definition).

target_ref (required)

identifier

The id of the target (to) object. The value MUST be an ID reference to an SDO (i.e., it cannot point to an SRO, Bundle, or Marking Definition).

 

Does anyone have any objections to making this change?

 

 

Sarah Kelley

Senior Cyber Threat Analyst

Multi-State Information Sharing and Analysis Center (MS-ISAC)                   

31 Tech Valley Drive

East Greenbush, NY 12061

 

sarah.kelley@cisecurity.org

518-266-3493

24x7 Security Operations Center

SOC@cisecurity.org - 1-866-787-4722

 

                  

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.

. . . . .

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

 

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]