[cti-users] Re: [cti-stix] [cti-users] Indicator Type / Vocabulary Implementation Questions

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[cti-users] Re: [cti-stix] [cti-users] Indicator Type / Vocabulary Implementation Questions

Jordan, Bret
Agreed.  But for those that really want to use their own list, and are just adamant about it, then they can publish their list on a web site or github or where ever.  The key is to have at least a fall back to a value that is "close enough" for tools that have no access to the extended vocabulary.  

Now along these lines, it might be possible to send a vocabulary in a STIX package, if someone was so inclined.  And the  vocab field would just contain an ID REF.  

I guess another hard question we really need to ask is, what is the scope of the problem we are trying to solve?

How many users are going to need this solution?
a) If the number is 0-5% maybe we do not do it until STIX 2.5 / STIX 3.0
b) If the number is between 5-20% then we should figure out a solution 
c) If between 20%-40% maybe we need 2-3 defined vocabularies
c) If greater than 40%, then we need to fix the default vocabulary so they do not need to use their own.


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 27, 2015, at 14:14, Jason Keirstead <[hidden email]> wrote:

RE:   "sub_type" : {     "vocab": "http://a.b.com/vocab-foo",     "type": "X-RAT-Downloader"   }, The problems with this are the same as with the current system... - As a tool, I likely do not have any internet access to publish a vocabulary list - Even if I did, I probably do not have access to a location on the corporate website to publish it. Sent from IBM Verse



Terry MacDonald --- [cti-stix] RE: [cti-users] Indicator Type / Vocabulary Implementation Questions --- 

From:"Terry MacDonald" <[hidden email]>
To:"Michael Hammer" <[hidden email]>, [hidden email], "Jason Keirstead" <[hidden email]>
Cc:[hidden email], [hidden email], [hidden email], [hidden email], [hidden email], [hidden email], [hidden email], [hidden email]
Date:Tue, Oct 27, 2015 1:15 PM
Subject:[cti-stix] RE: [cti-users] Indicator Type / Vocabulary Implementation Questions


Michael,
 
Never apologize for bringing an opinion to the table J. It’s the discussions and reasoning from many different viewpoints that will make STIX/TAXII and CybOX better – so throw out what ever you would like to J.
 
This similar idea was brought up on the CTI-STIX mailing list (where the discussion has migrated to) by Bret Jordan:
 
Perhaps this issue could be solved by a layered approach.....
 
Step 1: Greatly increase the default vocabulary, removing weirdness and things that are duplicate in nature. Try and get the default vocabulary to a 60/40 or 70/30 rule.  It would also be really nice if the terms were backed by a numerical element.  String matching in code in notoriously inefficient.  
 
Step 2: Provide a secondary entry point for an additional vocabulary for those groups that want or need to define their own.  We would obviously need an entry point in to the controlled vocabulary that can be a "fall back", something that is a lot higher up the food chain.  
 
By doing something like this, software that can only work with the default vocabulary can skip or throw away things it does not understand and have a fall back to something that is "close enough" for what they need.  In the second example below, the "sub_type" would be options and parsers could easily throw it away or skip it.  In fact most JSON parsers today naturally just skip things that do not map to a struct.  
 
 
{
  "stixtype": "indicator",
  "type": "IP Watchlist",
  ....
{
 
 
or 
 
{
  "stixtype": "indicator",
  "type": "Malware",
  "sub_type" : {
    "vocab": "http://a.b.com/vocab-foo",
    "type": "X-RAT-Downloader"
  },
  ....
{
 
It seems to me that this is a good in-between option.
 
I’d definitely suggest following the discussion on the CTI-STIX list. We’d really appreciate your involvement in the STIX Sub Committee if you have the time!
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | [hidden email]
 
 
From: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent: Wednesday, 28 October 2015 6:57 AM
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions
 
Pardon me if I am off base with this thought but throwing out to see what sticks.
 
In another group, they had similar problem of divergent lists of “vocabularies” or “dictionaries”.
Example was how many states are in a sequence of a work flow and what are they called.
Common problem seems to be that your list is not my list.
In the end, they used they used a:
DictionaryOwner:  e.g. one or another standards body or proprietary (e.g. OASIS-CTI)
DictionaryAttribute: e.g. the variable name (e.g. IndicatorType)
DictionaryValue: e.g. the variable value (of form string)
Where the Owner provided the context for what permissible Values could be used.
 
The hope in some cases was that a sufficiently well-defined standard set could obviate the need for proprietary ones.
Regularly updating the standard, could help minimize the other lists.
However, if a set needed to be “these and only these values”, then the need for multiple sets remains.
 
________________________________
Michael Hammer
Principal Engineer
Mobile: +1408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
 
From:[hidden email] [[hidden email]] On Behalf Of Jerome Athias
Sent: Saturday, October 24, 2015 9:19 AM
To: Jason Keirstead <[hidden email]>
Cc: Joep Gommers <[hidden email]>; Grobauer, Bernd <[hidden email]>; [hidden email]; [hidden email]; [hidden email]; John-Mark Gurney <[hidden email]>; Wunder, John A. <[hidden email]>; Barnum, Sean D. <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
 
What you're pointing there is another thing I thought about which is the relationships between different vocabularies.
While partially implemented in my tools in an effort to avoid inconstancy, it was not yet introduced in the mailinglists 
 
(Again, a structure à la CWE/CAPEC could be mid-term solution before a RDF/OWL ontology)

On Saturday, 24 October 2015, Jason Keirstead <[hidden email]> wrote:

Should be pretty self-explanatory....

Anomalous Activity <Could be any but usually Reconnaissance/Weaponization/Delivery>
Malicious Activity <Delivery / Exploitation>
Command and Control <Command and Control>
Anonymization <Actions>
Data Exfiltration <Actions>
Lateral Movement <Installation>
Privilege Escalation <Installation>
Reconnaissance <Reconnaissance >
Host/Process Compromise <Installation>
Watchlist <N/A>
Quantified Risk <N/A>
Policy Violation ** <N/A>
-
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 


Joep Gommers ---2015/10/24 06:33:42 AM---Jason, How would you feel this relates to killchain?

From: Joep Gommers <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: John-Mark Gurney <[hidden email]>, "Barnum, Sean D." <[hidden email]>, "Grobauer, Bernd" <[hidden email]>, "Wunder, John A." <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Date: 2015/10/24 06:33 AM
Subject: Re: [cti-users] Re: [cti-stix] Re: [cti-users] Indicator Type / Vocabulary Implementation Questions




Jason,

How would you feel this relates to killchain?

J

Sent from my iPhone


On 24 Oct 2015, at 11:05, Jason Keirstead <
[hidden email]> wrote:
I like the direction this is going
"Removing type information would reduce the IndicatorTypeVocab down to:
Compromised
Malicious
Watchlist
C2
Anonymization
Exfiltration
"
This is very similar to what I have been working through

This was my internal list so far - thoughts?
Anomalous Activity
Malicious Activity
Command and Control *
Anonymization
Data Exfiltration
Lateral Movement
Privilege Escalation
Reconnaissance
Host/Process Compromise
Watchlist
Quantified Risk
Policy Violation **


* I prefer descriptive names other than acronyms like "C2", it makes it easier for translation purposes.

** Not sure about this one... its kind of straying outside the CTI realm.. although i do see a great value / need for it in 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>John-Mark Gurney ---2015/10/23 03:57:30 PM---I have created an issue for this as when I was reviewing the vocab list, it did not cover our use ca

From: 
John-Mark Gurney <[hidden email]>
To: 
"Barnum, Sean D." <[hidden email]>
Cc: 
"Grobauer, Bernd" <[hidden email]>, "Wunder, John A." <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, [hidden email]
Date: 
2015/10/23 03:57 PM
Subject: 
[cti-stix] Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
Sent by: 
<[hidden email]>




I have created an issue for this as when I was reviewing the vocab list, it did not cover our use case.


The issue I created:

https://github.com/STIXProject/specifications/issues/35

I believe that this will help people use the Vocab better, and may reduce the need for custom vocabs.


Please comment on this issue to provide feed back.


Thanks.


I have included the text of the issue here for reference:
There is a discussion on cti-users and cti-stix about improving the IndicatorTypeVocab.


I believe that having a vocab is a useful thing. But I believe the existing vocab needs to be improved.


First off, type information, like e-mail, ip, file hash, domain, etc. should be removed. You should/must be able to get this information from the Observable that is part of the Indicator.


For one, there is no vocab to describe a malicious observiable, say network packet, stream, or other activity. Though if the e-mail type is removed from Malicious E-mail, and it just became Malicious (Observable), then we would have something.


Removing type information would reduce the IndicatorTypeVocab down to:
Compromised
Malicious
Watchlist
C2
Anonymization
Exfiltration


The first three are interesting, Compromised means that this Observable indicates that you ARE compromised. The Malicious means that you WILL be compromised by this Observable and Watchlist means that you MAY get compromised by this Observable.


Arguably, C2 should fall under Compromised, but as it probably requires further investigation to figure out the original compromised host, I'm fine leaving this as it's own separate type.


On Fri, Oct 23, 2015 at 7:19 AM, Barnum, Sean D. <
[hidden email]> wrote:
I think the first step would be to enter an issue in the tracker for this so that we can get it on the table. I also agree with an earlier statement that the issue of default vocab values has clear overlap with the interoperability SC so while we need to work internally within the STIX SC for ensuring our default vocabs have the appropriate values for STIX use cases it probably also makes sense to work at a higher level on the process by which we define and manage the various default controlled vocabs.

[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM] [attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]



signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[cti-users] RE: [cti-stix] [cti-users] Indicator Type / Vocabulary Implementation Questions

mdavidson

What I’m about to describe isn’t exactly the same idea, but it’s close.

 

In TAXII 1.0 and TAXII 1.1, we have the concept of a Status Type. Third parties can extend status types and specify whatever string they want, and TAXII doesn’t have a way of referencing a vocabulary defined somewhere.

The key text in TAXII 1.x that enables interoperability is this: “If the recipient [of a TAXII Status Message] does not recognize a third party Status Type, it SHOULD be treated as a Status Type of "Failure". For this reason, third parties MUST NOT define additional Status Types to indicate non-error conditions.” Effectively, Third Party status types are limited to more granular failure statuses.

 

IMO, the key is that processing systems are always able to return to a “known” state from an “unknown” state. I think with the ability to extend vocabularies, we need to either tell the processing system that it should fail on unknown values or provide logic for processing those unknown values (e.g., treat it as Some-Other-Value). I do not feel that we can expect systems to make decisions on previously unknown vocabularies on the fly, even if the schema can be downloaded at runtime.

For instance, how would a TAXII Status Message recipient know how to handle a Status Type of “Error – Please call 555-555-5555”? A downloadable schema will not solve this problem. On the other hand, if the field is intended as metadata, a tag, or a label (e.g., decisions are not based on it), then I think we do not need the same degree of specificity.


Thank you.
-Mark

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jordan, Bret
Sent: Tuesday, October 27, 2015 5:54 PM
To: Jason Keirstead <[hidden email]>
Cc: Terry MacDonald <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; Wunder, John A. <[hidden email]>; Barnum, Sean D. <[hidden email]>
Subject: Re: [cti-stix] [cti-users] Indicator Type / Vocabulary Implementation Questions

 

Agreed.  But for those that really want to use their own list, and are just adamant about it, then they can publish their list on a web site or github or where ever.  The key is to have at least a fall back to a value that is "close enough" for tools that have no access to the extended vocabulary.  

 

Now along these lines, it might be possible to send a vocabulary in a STIX package, if someone was so inclined.  And the  vocab field would just contain an ID REF.  

 

I guess another hard question we really need to ask is, what is the scope of the problem we are trying to solve?

 

How many users are going to need this solution?

            a) If the number is 0-5% maybe we do not do it until STIX 2.5 / STIX 3.0

            b) If the number is between 5-20% then we should figure out a solution 

            c) If between 20%-40% maybe we need 2-3 defined vocabularies

            c) If greater than 40%, then we need to fix the default vocabulary so they do not need to use their own.

 

 

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 27, 2015, at 14:14, Jason Keirstead <[hidden email]> wrote:

 

RE:
 
  "sub_type" : {
    "vocab": "http://a.b.com/vocab-foo",
    "type": "X-RAT-Downloader"
  },
 
The problems with this are the same as with the current system...
 
- As a tool, I likely do not have any internet access to publish a vocabulary list
- Even if I did, I probably do not have access to a location on the corporate website to publish it.
 
Sent from IBM Verse



Terry MacDonald --- [cti-stix] RE: [cti-users] Indicator Type / Vocabulary Implementation Questions --- 

 

From:

"Terry MacDonald" <[hidden email]>

To:

"Michael Hammer" <[hidden email]>, [hidden email], "Jason Keirstead" <[hidden email]>

Cc:

[hidden email], [hidden email], [hidden email], [hidden email], [hidden email], [hidden email], [hidden email], [hidden email]

Date:

Tue, Oct 27, 2015 1:15 PM

Subject:

[cti-stix] RE: [cti-users] Indicator Type / Vocabulary Implementation Questions


 

Michael,

 

Never apologize for bringing an opinion to the table J. It’s the discussions and reasoning from many different viewpoints that will make STIX/TAXII and CybOX better – so throw out what ever you would like to J.

 

This similar idea was brought up on the CTI-STIX mailing list (where the discussion has migrated to) by Bret Jordan:

 

Perhaps this issue could be solved by a layered approach.....

 

Step 1: Greatly increase the default vocabulary, removing weirdness and things that are duplicate in nature. Try and get the default vocabulary to a 60/40 or 70/30 rule.  It would also be really nice if the terms were backed by a numerical element.  String matching in code in notoriously inefficient.  

 

Step 2: Provide a secondary entry point for an additional vocabulary for those groups that want or need to define their own.  We would obviously need an entry point in to the controlled vocabulary that can be a "fall back", something that is a lot higher up the food chain.  

 

By doing something like this, software that can only work with the default vocabulary can skip or throw away things it does not understand and have a fall back to something that is "close enough" for what they need.  In the second example below, the "sub_type" would be options and parsers could easily throw it away or skip it.  In fact most JSON parsers today naturally just skip things that do not map to a struct.  

 

 

{

  "stixtype": "indicator",

  "type": "IP Watchlist",

  ....

{

 

 

or 

 

{

  "stixtype": "indicator",

  "type": "Malware",

  "sub_type" : {

    "vocab": "http://a.b.com/vocab-foo",

    "type": "X-RAT-Downloader"

  },

  ....

{

 

It seems to me that this is a good in-between option.

 

I’d definitely suggest following the discussion on the CTI-STIX list. We’d really appreciate your involvement in the STIX Sub Committee if you have the time!

 

Cheers

 

Terry MacDonald

Senior STIX Subject Matter Expert

SOLTRA | An FS-ISAC and DTCC Company

+61 (407) 203 206 | [hidden email]

 

 

From: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent: Wednesday, 28 October 2015 6:57 AM
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]
Subject: RE: [cti-users] Indicator Type / Vocabulary Implementation Questions

 

Pardon me if I am off base with this thought but throwing out to see what sticks.

 

In another group, they had similar problem of divergent lists of “vocabularies” or “dictionaries”.

Example was how many states are in a sequence of a work flow and what are they called.

Common problem seems to be that your list is not my list.

In the end, they used they used a:

DictionaryOwner:  e.g. one or another standards body or proprietary (e.g. OASIS-CTI)

DictionaryAttribute: e.g. the variable name (e.g. IndicatorType)

DictionaryValue: e.g. the variable value (of form string)

Where the Owner provided the context for what permissible Values could be used.

 

The hope in some cases was that a sufficiently well-defined standard set could obviate the need for proprietary ones.

Regularly updating the standard, could help minimize the other lists.

However, if a set needed to be “these and only these values”, then the need for multiple sets remains.

 

________________________________

Michael Hammer

Principal Engineer

Mobile: +1408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

 

From:[hidden email] [[hidden email]] On Behalf Of Jerome Athias
Sent: Saturday, October 24, 2015 9:19 AM
To: Jason Keirstead <[hidden email]>
Cc: Joep Gommers <[hidden email]>; Grobauer, Bernd <[hidden email]>; [hidden email]; [hidden email]; [hidden email]; John-Mark Gurney <[hidden email]>; Wunder, John A. <[hidden email]>; Barnum, Sean D. <[hidden email]>
Subject: Re: [cti-users] Indicator Type / Vocabulary Implementation Questions

 

What you're pointing there is another thing I thought about which is the relationships between different vocabularies.

While partially implemented in my tools in an effort to avoid inconstancy, it was not yet introduced in the mailinglists 

 

(Again, a structure à la CWE/CAPEC could be mid-term solution before a RDF/OWL ontology)

On Saturday, 24 October 2015, Jason Keirstead <[hidden email]> wrote:

Should be pretty self-explanatory....

Anomalous Activity <Could be any but usually Reconnaissance/Weaponization/Delivery>
Malicious Activity <Delivery / Exploitation>
Command and Control <Command and Control>
Anonymization <Actions>
Data Exfiltration <Actions>
Lateral Movement <Installation>
Privilege Escalation <Installation>
Reconnaissance <Reconnaissance >
Host/Process Compromise <Installation>
Watchlist <N/A>
Quantified Risk <N/A>
Policy Violation ** <N/A>

-
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 


Joep Gommers ---2015/10/24 06:33:42 AM---Jason, How would you feel this relates to killchain?

From: Joep Gommers <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA
Cc: John-Mark Gurney <[hidden email]>, "Barnum, Sean D." <[hidden email]>, "Grobauer, Bernd" <[hidden email]>, "Wunder, John A." <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Date: 2015/10/24 06:33 AM
Subject: Re: [cti-users] Re: [cti-stix] Re: [cti-users] Indicator Type / Vocabulary Implementation Questions





Jason,

How would you feel this relates to killchain?

J

Sent from my iPhone


On 24 Oct 2015, at 11:05, Jason Keirstead <
[hidden email]> wrote:

I like the direction this is going

"Removing type information would reduce the IndicatorTypeVocab down to:

Compromised
Malicious
Watchlist
C2
Anonymization
Exfiltration

"

This is very similar to what I have been working through

This was my internal list so far - thoughts?

Anomalous Activity
Malicious Activity
Command and Control *
Anonymization
Data Exfiltration
Lateral Movement
Privilege Escalation
Reconnaissance
Host/Process Compromise
Watchlist
Quantified Risk
Policy Violation **



* I prefer descriptive names other than acronyms like "C2", it makes it easier for translation purposes.

** Not sure about this one... its kind of straying outside the CTI realm.. although i do see a great value / need for it in 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>John-Mark Gurney ---2015/10/23 03:57:30 PM---I have created an issue for this as when I was reviewing the vocab list, it did not cover our use ca

From: 
John-Mark Gurney <[hidden email]>
To: 
"Barnum, Sean D." <[hidden email]>
Cc: 
"Grobauer, Bernd" <[hidden email]>, "Wunder, John A." <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>, [hidden email]
Date: 
2015/10/23 03:57 PM
Subject: 
[cti-stix] Re: [cti-users] Indicator Type / Vocabulary Implementation Questions
Sent by: 
<[hidden email]>





I have created an issue for this as when I was reviewing the vocab list, it did not cover our use case.


The issue I created:

https://github.com/STIXProject/specifications/issues/35

I believe that this will help people use the Vocab better, and may reduce the need for custom vocabs.


Please comment on this issue to provide feed back.


Thanks.


I have included the text of the issue here for reference:
There is a discussion on cti-users and cti-stix about improving the IndicatorTypeVocab.


I believe that having a vocab is a useful thing. But I believe the existing vocab needs to be improved.


First off, type information, like e-mail, ip, file hash, domain, etc. should be removed. You should/must be able to get this information from the Observable that is part of the Indicator.


For one, there is no vocab to describe a malicious observiable, say network packet, stream, or other activity. Though if the e-mail type is removed from Malicious E-mail, and it just became Malicious (Observable), then we would have something.


Removing type information would reduce the IndicatorTypeVocab down to:
Compromised
Malicious
Watchlist
C2
Anonymization
Exfiltration


The first three are interesting, Compromised means that this Observable indicates that you ARE compromised. The Malicious means that you WILL be compromised by this Observable and Watchlist means that you MAY get compromised by this Observable.


Arguably, C2 should fall under Compromised, but as it probably requires further investigation to figure out the original compromised host, I'm fine leaving this as it's own separate type.


On Fri, Oct 23, 2015 at 7:19 AM, Barnum, Sean D. <
[hidden email]> wrote:

I think the first step would be to enter an issue in the tracker for this so that we can get it on the table. I also agree with an earlier statement that the issue of default vocab values has clear overlap with the interoperability SC so while we need to work internally within the STIX SC for ensuring our default vocabs have the appropriate values for STIX use cases it probably also makes sense to work at a higher level on the process by which we define and manage the various default controlled vocabs.

[attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM] [attachment "graycol.gif" deleted by Jason Keirstead/CanEast/IBM]

 

Loading...