CTI STIX Subcommittee

Even if we don’t choose to issue a new one for STIX 1.2.1 (I’m unclear on how that would work implementation-wise…it seems to be asking for compatibility issues)
it would be awesome to come up with a more coherent and comprehensive list. So yeah, I say go for it.


Thinking longer term, another option would be a simpler implementation of the concepts that we cover now. For example, we could just choose to have an unvalidated
vocabulary: we would define the vocabulary and provide an ability to indicate which vocabulary has been chosen (including no vocab), but would not validate it via schema.


I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more
complicated.


John




On Oct 23, 2015, at 9:38 AM, Jason Keirstead < Jason.Keirstead@CA.IBM.COM > wrote:



Note, I have made this reply to CTI-STIX from CTI-Users

I agree pretty much 100% with what you say Bernd. I see there is a bit of a conflict here

- There is obviously a need to have a controlled vocabulary, so that tools and researchers can share categorized intelligence efficiently; however...

- The current vocabulary list is seemingly arbitrary - and has many gaps, and also redundancies, as you mentioned. Off the top of my head it should have 2x - 3x as many options, and like you mention, some are redundant. I totally agree that it makes no sense
to have different Watchlist types when that can be inferred easily from the data.

Due to how STIX 1.X is constructed, we can easily revision this vocabulary as a non-breaking change. I would propose that the STIX TC undertake a work product to revision this vocabulary. This is a "quick win" that the TC can provide.

If desired - I would volunteer to take the initial stab at extending the vocabulary.

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif> "Grobauer, Bernd" ---2015/10/23 07:50:32 AM---Hi, > I heard a recent proposal to remove it entirely. What would be the

From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com >
To: " jwunder@mitre.org " < jwunder@mitre.org >, Jason Keirstead/CanEast/IBM@IBMCA, " Cliff.Palmer@gd-ms.com "
< Cliff.Palmer@gd-ms.com >
Cc: " cti-users@lists.oasis-open.org " < cti-users@lists.oasis-open.org >
Date: 2015/10/23 07:50 AM
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
Sent by: < cti-users@lists.oasis-open.org >





Hi,

> I heard a recent proposal to remove it entirely. What would be the
> impact of that?

I had made the suggestion to remove the IncidentType entirely in
my somewhat provocative mail a few weeks ago, in which I wanted
to explore how much potential for simplification in going towards
STIX 2.0 there might be.

Why had I suggested to remove it?

The main reason is that I do not find the values that are currently part of the
standard vocabulary particularly useful:

- Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'
 into the Indicator Type? I could understand "Watchlist", which tells you
 to watch for whatever Observable Patterns are indicated in the indicator.

- Another type is 'C2' -- at the same time I have the ability to reference
 in the indicator a kill chain phase ... and if the referenced kill chain
 is of any use, it will have something corresponding to 'C2'.

 Now I have (again) two ways of expressing the same thing ... we have
 just stumbled over this issue a few days ago in a sharing group we
 are part of: we use the reference to the killchain phase to indicate
 C2-activity, others use the indicator type.

 Similarly, "Exfiltration" -- should that not be described with a reference
 from the indicator to an TTP "Exfiltration"?

Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics")
seem like there would be no end to the list of allowed vocabulary (think
"Malicious <enter CybOX object type here>" as pattern for generating vocabulary...)

My suggestion to get rid of the indicator type was really a bit of a calculated
provocation -- I have no trouble with keeping it in STIX. But we should
ensure that the standard vocabulary is defined such that it really adds
value rather than adding confusion by allowing yet more ways to describe
the same thing in different ways.

Kind regards,

Bernd

----------------

Bernd Grobauer, Siemens CERT

I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. Validate against arbitrary schema definitions that a tool may  1) not be able to talk to get the XSDs in first place.   2) not know what to do with as it has no code to support it.  I build a new super great extension point (xsi-type=foo) and I start using it in my 10 million indicators a day that I generate.  Now if you do not go code in support for it in your tool, then POOF.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Oct 23, 2015, at 08:20, Wunder, John A. < jwunder@mitre.org > wrote: Even if we don’t choose to issue a new one for STIX 1.2.1 (I’m unclear on how that would work implementation-wise…it seems to be asking for compatibility issues) it would be awesome to come up with a more coherent and comprehensive list. So yeah, I say go for it. Thinking longer term, another option would be a simpler implementation of the concepts that we cover now. For example, we could just choose to have an unvalidated vocabulary: we would define the vocabulary and provide an ability to indicate which vocabulary has been chosen (including no vocab), but would not validate it via schema. I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. John On Oct 23, 2015, at 9:38 AM, Jason Keirstead < Jason.Keirstead@CA.IBM.COM > wrote: Note, I have made this reply to CTI-STIX from CTI-Users I agree pretty much 100% with what you say Bernd. I see there is a bit of a conflict here - There is obviously a need to have a controlled vocabulary, so that tools and researchers can share categorized intelligence efficiently; however... - The current vocabulary list is seemingly arbitrary - and has many gaps, and also redundancies, as you mentioned. Off the top of my head it should have 2x - 3x as many options, and like you mention, some are redundant. I totally agree that it makes no sense to have different Watchlist types when that can be inferred easily from the data. Due to how STIX 1.X is constructed, we can easily revision this vocabulary as a non-breaking change. I would propose that the STIX TC undertake a work product to revision this vocabulary. This is a quick win that the TC can provide. If desired - I would volunteer to take the initial stab at extending the vocabulary. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Grobauer, Bernd ---2015/10/23 07:50:32 AM---Hi, > I heard a recent proposal to remove it entirely. What would be the From: Grobauer, Bernd < Bernd.Grobauer@siemens.com > To: jwunder@mitre.org < jwunder@mitre.org >, Jason Keirstead/CanEast/IBM@IBMCA, Cliff.Palmer@gd-ms.com < Cliff.Palmer@gd-ms.com > Cc: cti-users@lists.oasis-open.org < cti-users@lists.oasis-open.org > Date: 2015/10/23 07:50 AM Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions Sent by: < cti-users@lists.oasis-open.org > Hi, > I heard a recent proposal to remove it entirely. What would be the > impact of that? I had made the suggestion to remove the IncidentType entirely in my somewhat provocative mail a few weeks ago, in which I wanted to explore how much potential for simplification in going towards STIX 2.0 there might be. Why had I suggested to remove it? The main reason is that I do not find the values that are currently part of the standard vocabulary particularly useful: - Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'  into the Indicator Type? I could understand Watchlist , which tells you  to watch for whatever Observable Patterns are indicated in the indicator. - Another type is 'C2' -- at the same time I have the ability to reference  in the indicator a kill chain phase ... and if the referenced kill chain  is of any use, it will have something corresponding to 'C2'.  Now I have (again) two ways of expressing the same thing ... we have  just stumbled over this issue a few days ago in a sharing group we  are part of: we use the reference to the killchain phase to indicate  C2-activity, others use the indicator type.  Similarly, Exfiltration -- should that not be described with a reference  from the indicator to an TTP Exfiltration ? Other entries in the standard vocabulary ( Malicious Email , Host Characteristics ) seem like there would be no end to the list of allowed vocabulary (think Malicious <enter CybOX object type here> as pattern for generating vocabulary...) My suggestion to get rid of the indicator type was really a bit of a calculated provocation -- I have no trouble with keeping it in STIX. But we should ensure that the standard vocabulary is defined such that it really adds value rather than adding confusion by allowing yet more ways to describe the same thing in different ways. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

STIX is a language If one word is missing in a language, it is added to the dictionary (single official reference) If some words are removed from the dictionary however, it makes the language poorer On Friday, 23 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. Validate against arbitrary schema definitions that a tool may  1) not be able to talk to get the XSDs in first place.   2) not know what to do with as it has no code to support it.  I build a new super great extension point (xsi-type=foo) and I start using it in my 10 million indicators a day that I generate.  Now if you do not go code in support for it in your tool, then POOF.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."  On Oct 23, 2015, at 08:20, Wunder, John A. < jwunder@mitre.org > wrote: Even if we don’t choose to issue a new one for STIX 1.2.1 (I’m unclear on how that would work implementation-wise…it seems to be asking for compatibility issues) it would be awesome to come up with a more coherent and comprehensive list. So yeah, I say go for it. Thinking longer term, another option would be a simpler implementation of the concepts that we cover now. For example, we could just choose to have an unvalidated vocabulary: we would define the vocabulary and provide an ability to indicate which vocabulary has been chosen (including no vocab), but would not validate it via schema. I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. John On Oct 23, 2015, at 9:38 AM, Jason Keirstead < Jason.Keirstead@CA.IBM.COM > wrote: Note, I have made this reply to CTI-STIX from CTI-Users I agree pretty much 100% with what you say Bernd. I see there is a bit of a conflict here - There is obviously a need to have a controlled vocabulary, so that tools and researchers can share categorized intelligence efficiently; however... - The current vocabulary list is seemingly arbitrary - and has many gaps, and also redundancies, as you mentioned. Off the top of my head it should have 2x - 3x as many options, and like you mention, some are redundant. I totally agree that it makes no sense to have different Watchlist types when that can be inferred easily from the data. Due to how STIX 1.X is constructed, we can easily revision this vocabulary as a non-breaking change. I would propose that the STIX TC undertake a work product to revision this vocabulary. This is a "quick win" that the TC can provide. If desired - I would volunteer to take the initial stab at extending the vocabulary. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> "Grobauer, Bernd" ---2015/10/23 07:50:32 AM---Hi, > I heard a recent proposal to remove it entirely. What would be the From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " jwunder@mitre.org " < jwunder@mitre.org >, Jason Keirstead/CanEast/IBM@IBMCA, " Cliff.Palmer@gd-ms.com " < Cliff.Palmer@gd-ms.com > Cc: " cti-users@lists.oasis-open.org " < cti-users@lists.oasis-open.org > Date: 2015/10/23 07:50 AM Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions Sent by: < cti-users@lists.oasis-open.org > Hi, > I heard a recent proposal to remove it entirely. What would be the > impact of that? I had made the suggestion to remove the IncidentType entirely in my somewhat provocative mail a few weeks ago, in which I wanted to explore how much potential for simplification in going towards STIX 2.0 there might be. Why had I suggested to remove it? The main reason is that I do not find the values that are currently part of the standard vocabulary particularly useful: - Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'  into the Indicator Type? I could understand "Watchlist", which tells you  to watch for whatever Observable Patterns are indicated in the indicator. - Another type is 'C2' -- at the same time I have the ability to reference  in the indicator a kill chain phase ... and if the referenced kill chain  is of any use, it will have something corresponding to 'C2'.  Now I have (again) two ways of expressing the same thing ... we have  just stumbled over this issue a few days ago in a sharing group we  are part of: we use the reference to the killchain phase to indicate  C2-activity, others use the indicator type.  Similarly, "Exfiltration" -- should that not be described with a reference  from the indicator to an TTP "Exfiltration"? Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics") seem like there would be no end to the list of allowed vocabulary (think "Malicious <enter CybOX object type here>" as pattern for generating vocabulary...) My suggestion to get rid of the indicator type was really a bit of a calculated provocation -- I have no trouble with keeping it in STIX. But we should ensure that the standard vocabulary is defined such that it really adds value rather than adding confusion by allowing yet more ways to describe the same thing in different ways. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT

An example is the amazing job done by MAEC (credits to Ivan), and others ongoing like  https://www.owasp.org/index.php/File:Automated-threat-handbook.pdf Efforts of collaboration (interoperability) would help also. I.e. The suggested synchronization of controlled vocabularies (now defined by an RFC) with IETF IODEF, where enumerations will be maintained by IANA On Friday, 23 October 2015, Jerome Athias < athiasjerome@gmail.com > wrote: STIX is a language If one word is missing in a language, it is added to the dictionary (single official reference) If some words are removed from the dictionary however, it makes the language poorer On Friday, 23 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. Validate against arbitrary schema definitions that a tool may  1) not be able to talk to get the XSDs in first place.   2) not know what to do with as it has no code to support it.  I build a new super great extension point (xsi-type=foo) and I start using it in my 10 million indicators a day that I generate.  Now if you do not go code in support for it in your tool, then POOF.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."  On Oct 23, 2015, at 08:20, Wunder, John A. < jwunder@mitre.org > wrote: Even if we don’t choose to issue a new one for STIX 1.2.1 (I’m unclear on how that would work implementation-wise…it seems to be asking for compatibility issues) it would be awesome to come up with a more coherent and comprehensive list. So yeah, I say go for it. Thinking longer term, another option would be a simpler implementation of the concepts that we cover now. For example, we could just choose to have an unvalidated vocabulary: we would define the vocabulary and provide an ability to indicate which vocabulary has been chosen (including no vocab), but would not validate it via schema. I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. John On Oct 23, 2015, at 9:38 AM, Jason Keirstead < Jason.Keirstead@CA.IBM.COM > wrote: Note, I have made this reply to CTI-STIX from CTI-Users I agree pretty much 100% with what you say Bernd. I see there is a bit of a conflict here - There is obviously a need to have a controlled vocabulary, so that tools and researchers can share categorized intelligence efficiently; however... - The current vocabulary list is seemingly arbitrary - and has many gaps, and also redundancies, as you mentioned. Off the top of my head it should have 2x - 3x as many options, and like you mention, some are redundant. I totally agree that it makes no sense to have different Watchlist types when that can be inferred easily from the data. Due to how STIX 1.X is constructed, we can easily revision this vocabulary as a non-breaking change. I would propose that the STIX TC undertake a work product to revision this vocabulary. This is a "quick win" that the TC can provide. If desired - I would volunteer to take the initial stab at extending the vocabulary. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> "Grobauer, Bernd" ---2015/10/23 07:50:32 AM---Hi, > I heard a recent proposal to remove it entirely. What would be the From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " jwunder@mitre.org " < jwunder@mitre.org >, Jason Keirstead/CanEast/IBM@IBMCA, " Cliff.Palmer@gd-ms.com " < Cliff.Palmer@gd-ms.com > Cc: " cti-users@lists.oasis-open.org " < cti-users@lists.oasis-open.org > Date: 2015/10/23 07:50 AM Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions Sent by: < cti-users@lists.oasis-open.org > Hi, > I heard a recent proposal to remove it entirely. What would be the > impact of that? I had made the suggestion to remove the IncidentType entirely in my somewhat provocative mail a few weeks ago, in which I wanted to explore how much potential for simplification in going towards STIX 2.0 there might be. Why had I suggested to remove it? The main reason is that I do not find the values that are currently part of the standard vocabulary particularly useful: - Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'  into the Indicator Type? I could understand "Watchlist", which tells you  to watch for whatever Observable Patterns are indicated in the indicator. - Another type is 'C2' -- at the same time I have the ability to reference  in the indicator a kill chain phase ... and if the referenced kill chain  is of any use, it will have something corresponding to 'C2'.  Now I have (again) two ways of expressing the same thing ... we have  just stumbled over this issue a few days ago in a sharing group we  are part of: we use the reference to the killchain phase to indicate  C2-activity, others use the indicator type.  Similarly, "Exfiltration" -- should that not be described with a reference  from the indicator to an TTP "Exfiltration"? Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics") seem like there would be no end to the list of allowed vocabulary (think "Malicious <enter CybOX object type here>" as pattern for generating vocabulary...) My suggestion to get rid of the indicator type was really a bit of a calculated provocation -- I have no trouble with keeping it in STIX. But we should ensure that the standard vocabulary is defined such that it really adds value rather than adding confusion by allowing yet more ways to describe the same thing in different ways. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT

(Semi jokingly:) The problem is having to be guys implementing the thesaurus ;) Sent from my iPhone On 23 Oct 2015, at 18:19, Jerome Athias < athiasjerome@gmail.com > wrote: STIX is a language If one word is missing in a language, it is added to the dictionary (single official reference) If some words are removed from the dictionary however, it makes the language poorer On Friday, 23 October 2015, Jordan, Bret < bret.jordan@bluecoat.com > wrote: I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. Validate against arbitrary schema definitions that a tool may  1) not be able to talk to get the XSDs in first place.   2) not know what to do with as it has no code to support it.  I build a new super great extension point (xsi-type=foo) and I start using it in my 10 million indicators a day that I generate.  Now if you do not go code in support for it in your tool, then POOF.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."  On Oct 23, 2015, at 08:20, Wunder, John A. < jwunder@mitre.org > wrote: Even if we don’t choose to issue a new one for STIX 1.2.1 (I’m unclear on how that would work implementation-wise…it seems to be asking for compatibility issues) it would be awesome to come up with a more coherent and comprehensive list. So yeah, I say go for it. Thinking longer term, another option would be a simpler implementation of the concepts that we cover now. For example, we could just choose to have an unvalidated vocabulary: we would define the vocabulary and provide an ability to indicate which vocabulary has been chosen (including no vocab), but would not validate it via schema. I think in STIX 1.x we were a bit too strict about trying to get everything to validate in schema and in the end we just made things that should be simple much more complicated. John On Oct 23, 2015, at 9:38 AM, Jason Keirstead < Jason.Keirstead@CA.IBM.COM > wrote: Note, I have made this reply to CTI-STIX from CTI-Users I agree pretty much 100% with what you say Bernd. I see there is a bit of a conflict here - There is obviously a need to have a controlled vocabulary, so that tools and researchers can share categorized intelligence efficiently; however... - The current vocabulary list is seemingly arbitrary - and has many gaps, and also redundancies, as you mentioned. Off the top of my head it should have 2x - 3x as many options, and like you mention, some are redundant. I totally agree that it makes no sense to have different Watchlist types when that can be inferred easily from the data. Due to how STIX 1.X is constructed, we can easily revision this vocabulary as a non-breaking change. I would propose that the STIX TC undertake a work product to revision this vocabulary. This is a "quick win" that the TC can provide. If desired - I would volunteer to take the initial stab at extending the vocabulary. - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> "Grobauer, Bernd" ---2015/10/23 07:50:32 AM---Hi, > I heard a recent proposal to remove it entirely. What would be the From: "Grobauer, Bernd" < Bernd.Grobauer@siemens.com > To: " jwunder@mitre.org " < jwunder@mitre.org >, Jason Keirstead/CanEast/IBM@IBMCA, " Cliff.Palmer@gd-ms.com " < Cliff.Palmer@gd-ms.com > Cc: " cti-users@lists.oasis-open.org " < cti-users@lists.oasis-open.org > Date: 2015/10/23 07:50 AM Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions Sent by: < cti-users@lists.oasis-open.org > Hi, > I heard a recent proposal to remove it entirely. What would be the > impact of that? I had made the suggestion to remove the IncidentType entirely in my somewhat provocative mail a few weeks ago, in which I wanted to explore how much potential for simplification in going towards STIX 2.0 there might be. Why had I suggested to remove it? The main reason is that I do not find the values that are currently part of the standard vocabulary particularly useful: - Why would I put 'IP Watchlist' or 'Domain Watchlist' or 'File Hash Watchlist'  into the Indicator Type? I could understand "Watchlist", which tells you  to watch for whatever Observable Patterns are indicated in the indicator. - Another type is 'C2' -- at the same time I have the ability to reference  in the indicator a kill chain phase ... and if the referenced kill chain  is of any use, it will have something corresponding to 'C2'.  Now I have (again) two ways of expressing the same thing ... we have  just stumbled over this issue a few days ago in a sharing group we  are part of: we use the reference to the killchain phase to indicate  C2-activity, others use the indicator type.  Similarly, "Exfiltration" -- should that not be described with a reference  from the indicator to an TTP "Exfiltration"? Other entries in the standard vocabulary ("Malicious Email", "Host Characteristics") seem like there would be no end to the list of allowed vocabulary (think "Malicious <enter CybOX object type here>" as pattern for generating vocabulary...) My suggestion to get rid of the indicator type was really a bit of a calculated provocation -- I have no trouble with keeping it in STIX. But we should ensure that the standard vocabulary is defined such that it really adds value rather than adding confusion by allowing yet more ways to describe the same thing in different ways. Kind regards, Bernd ---------------- Bernd Grobauer, Siemens CERT

On 23.10.2015 19:01:52, Joep Gommers wrote: > (Semi jokingly:) > The problem is having to be guys implementing the thesaurus ;) > +100 -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra An FS-ISAC & DTCC Company www.soltra.com -- "One size never fits all." --RFC 1925 Attachment: signature.asc Description: PGP signature