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] Small changes from 2.0 - 2.1 - dates on relationships


Do we really have to go to a ballot at all already? We’ve had less than a full day of discussion to try to get to consensus.

 

I’m guessing my start_time / stop_time proposal is not acceptable. Anybody have any other ideas on this for meeting in the middle and avoiding divergent data?

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Wednesday, August 30, 2017 at 11:08 PM
To: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Cc: John Wunder <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sean Barnum <sean.barnum@fireeye.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, 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

 

But they are not final Bret. That's my concern. Why do two polls when we can do one and get a final answer?


Cheers

 

Terry MacDonald | Chief Product Officer

 

 

 

 

 

 

On Thu, Aug 31, 2017 at 1:32 PM, Bret Jordan <Bret_Jordan@symantec.com> wrote:

Do you really want to ballot on everything?  Everyone can easily respond here via email if they do not have access to Slack. We have done a lot of informal polls in the past 6 months to gauge where people sit.  They are very valuable. 

 

Bret


From: Terry MacDonald <terry.macdonald@cosive.com>
Sent: Wednesday, August 30, 2017 7:27:32 PM


To: Bret Jordan
Cc: Wunder, John A.; Allan Thomson; Sean Barnum; Jason Keirstead; 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

 

Is it that much more work to do this through the official polling platform that everyone gets access to? Surely having a higher percentage of the STIX population replying is a good thing? We'll get a wider viewpoint, and a definitive answer if we do the official polling, and then we can put this behind us.


Cheers

 

Terry MacDonald | Chief Product Officer

 

 

 

 

 

 

On Thu, Aug 31, 2017 at 1:20 PM, Bret Jordan <Bret_Jordan@symantec.com> wrote:

Lets do an informal poll first.  To this end I setup a poll in Slack in #polls.  If you do not have access to slack, please respond here.  However, if you can, PLEASE respond in slack. 

 

Please see the screen shot for the poll:

 

Which time elements should the relationship object have?

1: valid_from/valid_until

2: first_seen/last_seen

3: three: both

4: neither

5: abstain

 

 

Bret


From: Terry MacDonald <terry.macdonald@cosive.com>
Sent: Wednesday, August 30, 2017 7:12:02 PM
To: Bret Jordan
Cc: Wunder, John A.; Allan Thomson; Sean Barnum; Jason Keirstead; 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

 

Then I think it is time for a ballot :).

  • One where its valid_*
  • One where it is first_*
  • One where its both of the above and consumers get confused

As a separate discussion we should also talk about how we will handle 'summarising' relationships in the future, so we have an STIX-wide architectural plan for doing summarisation.


Cheers

 

Terry MacDonald | Chief Product Officer

 

 

 

 

 

 

On Thu, Aug 31, 2017 at 12:51 PM, Bret Jordan <Bret_Jordan@symantec.com> wrote:

Yeah, I see that now. It was a bad idea.  I was just trying to find a solution.  I still really dislike the idea of first and last seen on general purpose relationships.  

 

Bret 

 



Sent from my iPhone


On Aug 30, 2017, at 6:43 PM, Terry MacDonald <terry.macdonald@cosive.com> wrote:

I agree with John. I would be very concerned if we make major structural changes to how STIX relationships work and how summarised STIX relationships work just because it might make sense for one potential confusion.


Cheers

 

Terry MacDonald | Chief Product Officer

 

 

 

 

 

 

On Thu, Aug 31, 2017 at 10:48 AM, Wunder, John A. <jwunder@mitre.org> wrote:

I don’t think so. Sighting indicates that you saw an SDO. Doing that would significantly change the meaning to “I saw a relationship between this SDO and that SDO”…aka, a sighting of a relationship. It would also create even further divergence in STIX, in that you could use either Sighting or Relationship to indicate that two SDOs are related (vs. now where the Sighting relationship is just saying that a thing was seen based on some optional evidence).

 

From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>
Date: Wednesday, August 30, 2017 at 6:37 PM
To: John Wunder <jwunder@mitre.org>, Allan Thomson <athomson@lookingglasscyber.com>, Sean Barnum <sean.barnum@FireEye.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: 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

 

Or do we change Sighting to allow it to point to not just observed_data and an identity, but also another SDO? Because the use case that Allan brings up really feels like a sighting.  The use case that Sean brings up really feels different. The more we make a general purpose relationship look and feel like a sighting, the more problems we are going to have.

 

For example, if we add first_seen and last_seen to the general purpose relationship, then you could just make a sighting out of it, but linking a Threat Actor to Observed Data. 

 

Bret


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

 

You’re right, it doesn’t support this now. It points to a thing and says that that thing was seen…so I think to use it for this you would need to have a relationship plus a sighting of that relationship, which seems awkward.

 

Maybe if we stick with start_time and stop_time as the field names we can craft a description that’s agreeable to everyone? I would focus on what the consumer should think when they see that field. Maybe something like:

 

Start_time: The time at which this relationship first came to exist. For some relationships this might be obvious or factual (MITRE is located in the United States) while for other relationships this might be when the relationship was first observed.”

Stop_time: The time at which this relationship last existed. (Same caveat as above). If this property is omitted, the producer considers the relationship ongoing (i.e. it is still being observed).”

 

I doubt those are good as-is, but I do wonder if we can get there in a way that we don’t conflate terms yet give consumers something consistent they can look for and understand across all producers.

 

John

 

From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, August 30, 2017 at 5:58 PM
To: John Wunder <jwunder@mitre.org>, Sean Barnum <sean.barnum@FireEye.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, 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

 

John – I agree that if companies interpret the fields differently then that’s not a good situation either.

 

You raise a good point that if one company uses valid_from/until and another uses first_seen/last_seen for the same concept then we have incompatibility.

 

To that point, Bret’s suggesting that a sighting already has first_seen/last_seen but looking at Sighting again it appears that it only points to one specific SDO that it was sighting on. What about the sighting of a connection between 2 disparate SDOs?

 

If sighting supports that (from my quick review I didn’t see that) then we might have a good path for both use cases.

 

Allan Thomson,

CTO, Lookingglass Cyber Solutions

This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed.  If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited

 

 

From: "Wunder, John" <jwunder@mitre.org>
Date: Wednesday, August 30, 2017 at 2:45 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, Sean Barnum <sean.barnum@FireEye.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, 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

 

I agree with Allan that it’s really not productive to appeal to which company has more experience here.

 

I do want to strongly disagree with the statement that there’s no harm in trying to support all use cases and add both sets of fields, even though everyone will probably get everyone angry with me. Let’s take this exact discussion as an example…so, we add both sets of fields. Clearly, FireEye will be primarily populating valid_form and valid_until, while IBM and LookingGlass will be populating first_seen and last_seen. But do these organizations really mean to be describing different things here, especially in a way that’s important to a consumer of this data? As a visualization tool that just wants to show relationships that are “current” or were important to know in March of 2013, which field do I look in? Do I just have to look in both? Every new field we add, especially when there’s this degree of semantic overlap, adds additional cognitive cost and increases the complexity of STIX. Maybe it’s worth it in this case because the distinction is that critical, but it definitely does not come without cost.

 

This is a lesson we learned well in STIX 1. I think sometimes people have this impression that a bunch of MITRE folks sat in a room and tried to dream up multiple ways of doing something. Believe it or not, we didn’t…it’s that we would come up with some use case and then would identify some very real distinction between it and another use case. The perfect example is composite indicators vs. composite observables…yes, there’s a difference, and I can explain it to you…but when viewed by the wider community it was just multiple ways of doing something, and so it was a mistake for us to put that difference in the standard. So here, I would really strongly urge us to find some common ground, even if it’s hard, and try to agree on what we’re representing and how we’re representing it so that consumers can rely on some degree of standardization in what they get.

 

John

 

From: <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Wednesday, August 30, 2017 at 5:22 PM
To: Sean Barnum <sean.barnum@FireEye.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: "Bret Jordan (CS)" <Bret_Jordan@symantec.com>, John Wunder <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

 

Sean – I suggest that we don’t debate in a public forum whether you have more legitimate background vs anyone else. I certainly could start doing so but it would not move our community forward and would waste everyone’s time.

 

I suggest for the purposes of bringing the community together and building a standard that works for *all* that we have a mindset that supports *all our use cases*.

 

By your own words you understand that both capabilities support different use cases.

 

I suggest that there is no harm in supporting both in the standard.

 

Regards

 

Allan

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Wednesday, August 30, 2017 at 2:17 PM
To: Allan Thomson <athomson@lookingglasscyber.com>, Jason Keirstead <jason.keirstead@ca.ibm.com>
Cc: Bret Jordan <bret_jordan@symantec.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: [cti-stix] Re: [EXT] Re: [cti-stix] Small changes from 2.0 - 2.1 - dates on relationships

 

My assertions were based on FireEye/iSight's extensive experience with the sorts of advanced (relating things to each other with temporal windows for the assertions) threat intel and the many, many parties I have interacted with over the years of development of STIX.

Very roughly I would say in something like 98% of cases they meant valid_from/to and not last/first_seen.

 

That being said I am in no way saying that there is no use case for last/first_seen or that it should never be supported. Not at all.

 

I am asserting that the common use case is "valid", not "seen" and we should explicitly not use last/first_seen to try to mean valid_from/to.

Also, I am suggesting as a more edge case that first/last_seen should be added as an extension rather than base properties and maybe not necessarily in this release. If everyone else wants them strongly, I have no objections to adding them now but the semantics need to be clear.

 

I apologize if I did not make my intention clear.

 


From: Allan Thomson <athomson@lookingglasscyber.com>
Sent: Wednesday, August 30, 2017 5:05:52 PM
To: Sean Barnum; Jason Keirstead
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

 

Sean – I’m not sure anyone is in a position to state that there’s a core set of use cases for either capability or not. I certainly am not.

 

I believe there are use cases that both property terms support. My prior email was suggesting that I (and therefore our company) would care more about the last_seen over valid_until.

 

I was not suggesting that others might find value in valid_until.

 

So if we agree as a community that both are valuable for different reasons then I suggest we not try to stop other business use cases being supported by STIX.

 

In summary, it sounds like we might want both concepts as optional parameters provided (and it seems like there are) valid semantic descriptions for both.

 

Allan

 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Wednesday, August 30, 2017 at 1:58 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Allan Thomson <athomson@lookingglasscyber.com>
Cc: Bret Jordan <Bret_Jordan@symantec.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: [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

 

Error! Filename not specified.

       Error! Filename not specified.    Error! Filename not specified.   Error! Filename not specified.    Error! Filename not specified.

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.

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]