Subject: Re: [mile] Describing the time window during which an indicator should be used

From: "Harrington, Christopher" <[email-masked]>
Date: Mon, 13 Jan 2014 08:17:57 -0500

Roman,

>From what I have seen the aging is usually up to the recipient. I would say
that option #1 would be better. 

For purposes of deciding to stop looking for an indicator there is another
data point that is used far more frequently, Last Seen time. For the
majority of indicators we use the time it was last "seen". For us the "seen"
means that either we have seen it being used or we have intel from a 3rd
party or open source that it is still in use. The only time we use the
stime-etime paradigm is when there is an infection (delivery stage of the
Kill Chain) that was valid but later cleaned up. Nbc.com was compromised
last year for about 4 hours then cleaned up. In that case we would use
stime-etime. There are indicators that we call persistent. These are
indicators that we will never stop looking for. These could be indicators
that are used exclusively by a specific threat actor (like a domain
registered by an actor) or something that we used in a previous incident at
our organization, like RSA breech related indicators. A construct to flag an
indicator as persistent would be helpful as this is information is something
we routinely share. 

Thanks,

--Chris

From: Roman D. Danyliw [mailto:[email-masked]] 
Sent: Thursday, January 09, 2014 4:59 PM
To: Harrington, Christopher; Stoecker, Paul
Cc: [email-masked]
Subject: RE: [mile] Describing the time window during which an indicator
should be used

Hello!

Chris: Thanks for the background!

To date, the message traffic suggests interest in per-indicator annotation
of validity.  That would suggest something as follows:

<Assessment indicator-uid="foo-12345" indicator-stime="2013/12/01 12:00:00">

Or 

<Assessment indicator-uid="foo-12345" indicator-stime="2013/12/01 12:00:00"
indicator-etime="2013/12/01 13:00:00"-->

The follow-up discuss asked if organizations really every stop looking for
indicators they have.  One answer was yes.

How do we want to handle that?  Ideas might include:

(1) provide only an @indicator-stime and @indicator-etime, and these are the
best guess of the reporter of how long to make it valid.  The recipient can
decide how and if to honor these.

(2) provide another attribute that would suggest an aging policy that the
recipient can choose to honor.  What would we those aging policies?

Roman

From: Harrington, Christopher [ <mailto:[email-masked]>
mailto:[email-masked]] 
Sent: Monday, December 23, 2013 10:46 AM
To: Stoecker, Paul
Cc: Roman D. Danyliw;  <mailto:[email-masked]> [email-masked]
Subject: RE: [mile] Describing the time window during which an indicator
should be used

Yes we do stop looking. A good example is when NBC.com got hacked a few
months ago. We watched for people hitting it while the URL was malicious.
Once it was cleaned up we stopped watching for it since it was a somewhat
popular  URL that would fire all the time and bury us in false positives. 

Indicator aging is an area that nobody has a good handle one. Each
organization seems to have their own way of doing things with aging, if they
do anything at all. Some commercial threat intel providers use a
decrementing counter based on the last time the indicator was seen. At EMC
we make the aging calculation based on time since last seen, attribution (if
known), kill chain stage, confidence in the source  and other factors. It's
not automated at this point. 

We can't keep all indicators forever. At some point the watch lists and
block lists on your Proxy, firewall, etc get too large and the devices start
having issues. We ran into this at EMC and had to switch from Proxy blocks
for domains to DNS RPZ with a sinkhole web servers. There were too many
domains in the proxy block list. We have tens of thousands. There are
indicators that we consider "persistent". These are indicators that we
always want to be alerted about. Generally these are advanced threat / APT
and have either been seen in activity involving EMC or they belong to threat
actor groups that we have seen at EMC. 

Thanks,

--Chris

From: Stoecker, Paul 
Sent: Monday, December 23, 2013 10:26 AM
To: Harrington, Christopher
Cc: Roman D. Danyliw;  <mailto:[email-masked]> [email-masked]
Subject: Re: [mile] Describing the time window during which an indicator
should be used

I have a question...Do we really stop looking for IOCs whose time has
expired?  Like a malicious URL whose time has expired...do you stop looking
for that URL?  Let's say that Paul the malware dude got a hold of the IODEF
document...I shutdown my web server and after the time expired I turned it
back on?

Just wondering how IOC aging is actually handled?

Sent from my iPhone

On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher"
<[email-masked]> wrote:

Hello,

Answers inline below. 

Thanks,

--Chris

Christopher Harrington
Consulting Security Engineer
GSO - Critical Incident Response Center
EMC
174 Middlesex Turnpike
Bedford, MA 01730
781-515-5862 (work)
603-583-1585 (cell)

From: mile [ <mailto:[email-masked]> mailto:[email-masked]] On
Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [mile] Describing the time window during which an indicator should
be used

Hello!

Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking
the need to convey the valid time during which to apply an indicator.  I
wanted to solicit from the community the degree of flexibility desired.  For
the purposes of this discussion an indicator is defined as a class that has
an @indicator-uid attribute.

** Does this flexibility need to exist on a per indicator basis?

Example 1, <Assessment indicator-uid="foo-12345"
indicator-valid-stime="2013/12/01 12:00:00">

Yes, a malicious URL would be valid only as long as it is live.

** Could it be at the EventData level (and the time window cascades to all
indicators that are children)?

Example 2:, <EventData indicator-stime="2013/12/01 12:00:00"> . <Flow> .
many domain indicators </Flow> . </EventData>

Example 3: <EventData>  . <IndicatorStartTime>2013/12/01
12:00:00</IndicatorStartTime> . <Flow> . many domain indicators </Flow> .
</EventData>

Yes, you could have multiple malware delivery URLs that are all on the same
domain. If the Domain is specified at EvenData level then when it is no
longer valid the children would no longer be valid. I hope I explained that
right J  I am not sure how it would differ between Example 2 and 3. 

** Could it be at the Incident level?

Example 4: <Incident>  . <IndicatorStartTime>2013/12/01
12:00:00</IndicatorStartTime> . many domain indicators </Flow> . </Incident>

If there was only one Indicator in an incident it could be. In practical
terms this is very unlikely. 

Per indicator time information would provide the most flexibility but would
require duplication of the same information.

A time window for indicator validity specified at the Incident level would
not allow for multiple time windows per indicator.

A time window for indicator validity specified in the EventData class would
require nested EventData instances to convey different time period.  Also,
some indicators are only in the Incident class so this approach would be
insufficient.  Perhaps a hybrid approach where this timing information is in
the EventData and IncidentData classes could be possible.

Personally I think the safest approach is validity per Indicator.  Validity
for parent / child would be rare and validity per Incident even rarer. 

One question, how do we represent "still valid"? If I have an indicator that
is valid when I send the message how do I know what that time represents?
If I put "12/20/2013 13:00" as the time can you tell if I mean that it was
still valid when I sent the message at that time or that its validity period
ended at that time. Those are very different scenarios and critically
important for searching / responding to indicator hits. 

Roman

_______________________________________________
mile mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mile>
https://www.ietf.org/mailman/listinfo/mile

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 15 Jan 2014 16:02:48 +0000

Hi,

I'd like to explore the community thinking on how to implement a flag as Chris suggested to note that an indicator is persistent.  Assuming that the convention of @indicator-stime and -etime was adopted, a few possibilities to add a "persistence flag" would be:

(1) Add a boolean attribute, say @indicator-persistent, to convey to always look for this indicator.  No @indicator-etime would be required.

(2) Define a particular date far into the future for @indicator-etime that conveys persistence.  For example, when @indicator-etime="3000/12/01 12:00:00"  is seen, this indicator is persistent.

Option #1 is most intuitively self-describing but adds another attribute, now the fifth, to the list of "special indicator attributes".

Option #2 reduces the number of additional attributes.

Personally, I prefer #2.  Your thoughts?

Roman

From: Harrington, Christopher [mailto:[email-masked]]
Sent: Monday, January 13, 2014 8:18 AM
To: Roman D. Danyliw; Stoecker, Paul
Cc: [email-masked]
Subject: RE: [mile] Describing the time window during which an indicator should be used

Roman,

>From what I have seen the aging is usually up to the recipient. I would say that option #1 would be better.

For purposes of deciding to stop looking for an indicator there is another data point that is used far more frequently, Last Seen time. For the majority of indicators we use the time it was last "seen". For us the "seen" means that either we have seen it being used or we have intel from a 3rd party or open source that it is still in use. The only time we use the stime-etime paradigm is when there is an infection (delivery stage of the Kill Chain) that was valid but later cleaned up. Nbc.com was compromised last year for about 4 hours then cleaned up. In that case we would use stime-etime. There are indicators that we call persistent. These are indicators that we will never stop looking for. These could be indicators that are used exclusively by a specific threat actor (like a domain registered by an actor) or something that we used in a previous incident at our organization, like RSA breech related indicators. A construct to flag an indicator as persistent would be helpful as this is information is something we routinely share.

Thanks,

--Chris

From: Roman D. Danyliw [mailto:[email-masked]]
Sent: Thursday, January 09, 2014 4:59 PM
To: Harrington, Christopher; Stoecker, Paul
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [mile] Describing the time window during which an indicator should be used

Hello!

To date, the message traffic suggests interest in per-indicator annotation of validity.  That would suggest something as follows:

<Assessment indicator-uid="foo-12345" indicator-stime="2013/12/01 12:00:00">
Or
<Assessment indicator-uid="foo-12345" indicator-stime="2013/12/01 12:00:00" indicator-etime="2013/12/01 13:00:00"-->

The follow-up discuss asked if organizations really every stop looking for indicators they have.  One answer was yes.

(1) provide only an @indicator-stime and @indicator-etime, and these are the best guess of the reporter of how long to make it valid.  The recipient can decide how and if to honor these.

(2) provide another attribute that would suggest an aging policy that the recipient can choose to honor.  What would we those aging policies?

Roman

From: Harrington, Christopher [mailto:[email-masked]]
Sent: Monday, December 23, 2013 10:46 AM
To: Stoecker, Paul
Cc: Roman D. Danyliw; [email-masked]<mailto:[email-masked]>
Subject: RE: [mile] Describing the time window during which an indicator should be used

Yes we do stop looking. A good example is when NBC.com got hacked a few months ago. We watched for people hitting it while the URL was malicious. Once it was cleaned up we stopped watching for it since it was a somewhat popular  URL that would fire all the time and bury us in false positives.

Indicator aging is an area that nobody has a good handle one. Each organization seems to have their own way of doing things with aging, if they do anything at all. Some commercial threat intel providers use a decrementing counter based on the last time the indicator was seen. At EMC we make the aging calculation based on time since last seen, attribution (if known), kill chain stage, confidence in the source  and other factors. It's not automated at this point.

We can't keep all indicators forever. At some point the watch lists and block lists on your Proxy, firewall, etc get too large and the devices start having issues. We ran into this at EMC and had to switch from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. There were too many domains in the proxy block list. We have tens of thousands. There are indicators that we consider "persistent". These are indicators that we always want to be alerted about. Generally these are advanced threat / APT and have either been seen in activity involving EMC or they belong to threat actor groups that we have seen at EMC.

Thanks,

--Chris

From: Stoecker, Paul
Sent: Monday, December 23, 2013 10:26 AM
To: Harrington, Christopher
Cc: Roman D. Danyliw; [email-masked]<mailto:[email-masked]>
Subject: Re: [mile] Describing the time window during which an indicator should be used

I have a question...Do we really stop looking for IOCs whose time has expired?  Like a malicious URL whose time has expired...do you stop looking for that URL?  Let's say that Paul the malware dude got a hold of the IODEF document...I shutdown my web server and after the time expired I turned it back on?

Sent from my iPhone

On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

Answers inline below.

Thanks,

--Chris

Christopher Harrington

From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [mile] Describing the time window during which an indicator should be used

Hello!

Ticket #28 (http://trac.tools.ietf.org/wg/mile/trac/ticket/28) is tracking the need to convey the valid time during which to apply an indicator.  I wanted to solicit from the community the degree of flexibility desired.  For the purposes of this discussion an indicator is defined as a class that has an @indicator-uid attribute.

** Does this flexibility need to exist on a per indicator basis?
Example 1, <Assessment indicator-uid="foo-12345" indicator-valid-stime="2013/12/01 12:00:00">
Yes, a malicious URL would be valid only as long as it is live.

** Could it be at the EventData level (and the time window cascades to all indicators that are children)?
Example 2:, <EventData indicator-stime="2013/12/01 12:00:00"> ... <Flow> ... many domain indicators </Flow> ... </EventData>
Example 3: <EventData>  ... <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> ... <Flow> ... many domain indicators </Flow> ... </EventData>
Yes, you could have multiple malware delivery URLs that are all on the same domain. If the Domain is specified at EvenData level then when it is no longer valid the children would no longer be valid. I hope I explained that right :)  I am not sure how it would differ between Example 2 and 3.

** Could it be at the Incident level?
Example 4: <Incident>  ... <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> ... many domain indicators </Flow> ... </Incident>
If there was only one Indicator in an incident it could be. In practical terms this is very unlikely.

Per indicator time information would provide the most flexibility but would require duplication of the same information.

A time window for indicator validity specified at the Incident level would not allow for multiple time windows per indicator.

A time window for indicator validity specified in the EventData class would require nested EventData instances to convey different time period.  Also, some indicators are only in the Incident class so this approach would be insufficient.  Perhaps a hybrid approach where this timing information is in the EventData and IncidentData classes could be possible.

Personally I think the safest approach is validity per Indicator.  Validity for parent / child would be rare and validity per Incident even rarer.

One question, how do we represent "still valid"? If I have an indicator that is valid when I send the message how do I know what that time represents?  If I put "12/20/2013 13:00" as the time can you tell if I mean that it was still valid when I sent the message at that time or that its validity period ended at that time. Those are very different scenarios and critically important for searching / responding to indicator hits.

Roman

_______________________________________________
mile mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mile

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jan 2014 11:44:34 -0500

Say what we mean. We are already paying the XML tax, so a fifth attribute does not really ‘cost’ us anything. I can guarantee that we will have more problems than a Year 3000 problem if we overload indicator-etime.

On Jan 15, 2014, at 11:02 AM, Roman D. Danyliw <[email-masked]> wrote:

> Hi,
>  
> I’d like to explore the community thinking on how to implement a flag as Chris suggested to note that an indicator is persistent.  Assuming that the convention of @indicator-stime and –etime was adopted, a few possibilities to add a “persistence flag” would be:
>  
> (2) Define a particular date far into the future for @indicator-etime that conveys persistence.  For example, when @indicator-etime=”3000/12/01 12:00:00”  is seen, this indicator is persistent.
>  
> Option #1 is most intuitively self-describing but adds another attribute, now the fifth, to the list of “special indicator attributes”.
>  
> For purposes of deciding to stop looking for an indicator there is another data point that is used far more frequently, Last Seen time. For the majority of indicators we use the time it was last “seen”. For us the “seen” means that either we have seen it being used or we have intel from a 3rd party or open source that it is still in use. The only time we use the stime-etime paradigm is when there is an infection (delivery stage of the Kill Chain) that was valid but later cleaned up. Nbc.com was compromised last year for about 4 hours then cleaned up. In that case we would use stime-etime. There are indicators that we call persistent. These are indicators that we will never stop looking for. These could be indicators that are used exclusively by a specific threat actor (like a domain registered by an actor) or something that we used in a previous incident at our organization, like RSA breech related indicators. A construct to flag an indicator as persistent would be helpful as this is information is something we routinely share.
>  
> Thanks,
>  
> --Chris
>  
> <Assessment indicator-uid=”foo-12345” indicator-stime=”2013/12/01 12:00:00”>
> Or
> <Assessment indicator-uid=”foo-12345” indicator-stime=”2013/12/01 12:00:00” indicator-etime=”2013/12/01 13:00:00”-->
>  
> Cc: Roman D. Danyliw; [email-masked]
> Indicator aging is an area that nobody has a good handle one. Each organization seems to have their own way of doing things with aging, if they do anything at all. Some commercial threat intel providers use a decrementing counter based on the last time the indicator was seen. At EMC we make the aging calculation based on time since last seen, attribution (if known), kill chain stage, confidence in the source  and other factors. It’s not automated at this point.
>  
> We can’t keep all indicators forever. At some point the watch lists and block lists on your Proxy, firewall, etc get too large and the devices start having issues. We ran into this at EMC and had to switch from Proxy blocks for domains to DNS RPZ with a sinkhole web servers. There were too many domains in the proxy block list. We have tens of thousands. There are indicators that we consider “persistent”. These are indicators that we always want to be alerted about. Generally these are advanced threat / APT and have either been seen in activity involving EMC or they belong to threat actor groups that we have seen at EMC.
>  
> Thanks,
>  
> --Chris
>  
> From: Stoecker, Paul 
> Cc: Roman D. Danyliw; [email-masked]
> On Dec 20, 2013, at 4:57 PM, "Harrington, Christopher" <[email-masked]> wrote:
> 
> Hello,
>  
> Answers inline below.
>  
> Thanks,
>  
> --Chris
>  
> Christopher Harrington
> To: [email-masked]
> Example 1, <Assessment indicator-uid=”foo-12345” indicator-valid-stime=”2013/12/01 12:00:00”>
> Example 2:, <EventData indicator-stime=”2013/12/01 12:00:00”> … <Flow> … many domain indicators </Flow> … </EventData>
> Example 3: <EventData>  … <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> … <Flow> … many domain indicators </Flow> … </EventData>
> Yes, you could have multiple malware delivery URLs that are all on the same domain. If the Domain is specified at EvenData level then when it is no longer valid the children would no longer be valid. I hope I explained that right J  I am not sure how it would differ between Example 2 and 3.
>  
> Example 4: <Incident>  … <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> … many domain indicators </Flow> … </Incident>
> One question, how do we represent “still valid”? If I have an indicator that is valid when I send the message how do I know what that time represents?  If I put “12/20/2013 13:00” as the time can you tell if I mean that it was still valid when I sent the message at that time or that its validity period ended at that time. Those are very different scenarios and critically important for searching / responding to indicator hits.
>  
> Roman
>  
> [email-masked]
> [email-masked]

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 24 Jan 2014 02:19:48 +0000

I see your perspective Eric. Let's talk through a little more about how we could use this fifth indicator attribute, perhaps calling it "indicator-persistent" for the moment.  It seems like we'd end up in one of the following situations:

(1) known start time and end time for an indicator (i.e., only look for the indicator during the described interval)
(2) known start time for an indicator (i.e., look for the indicator indefinitely after the start time)
(3) known end time (i.e., an indicator won't be valid after a certain time so look for it only before an end time)
(4) unknown start or end time (i.e., look for the indicator on any data you have)

Do we want to deal with all of them?  Are there others?  If we did want to cover all cases perhaps we could define @indicator-persistent as an ENUM:

"start" = assume that the indicator is valid up to the provided @indicator-end-time.  If this value is selected, @indicator-end-time must be set and @indicator-start must not be set.
"end" = assume that the indicator is valid indefinitely starting from the provided @indicator-start-time.  If this value is selected, @indicator-start-time value must be set and @indicator-end-time value must not be set.
"defined" = assume that the indicator is valid between the specified @indicator-start-time and @indicator-end-time.  If this value is selected both the @indicator-start-time and @indicator-end-time must be set.
"unknown" = assume that the indicator can be valid during any time period.  If this value is selected both @indicator-start-time and @indicator-end-time must not be set.  This is the default.

Roman

From: Eric Burger [mailto:[email-masked]]
Sent: Thursday, January 23, 2014 11:45 AM
To: Roman D. Danyliw
Cc: [email-masked]
Subject: Re: [mile] Describing the time window during which an indicator should be used

Say what we mean. We are already paying the XML tax, so a fifth attribute does not really 'cost' us anything. I can guarantee that we will have more problems than a Year 3000 problem if we overload indicator-etime.

On Jan 15, 2014, at 11:02 AM, Roman D. Danyliw <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Roman

Roman,

>From what I have seen the aging is usually up to the recipient. I would say that option #1 would be better.

For purposes of deciding to stop looking for an indicator there is another data point that is used far more frequently, Last Seen time. For the majority of indicators we use the time it was last "seen". For us the "seen" means that either we have seen it being used or we have intel from a 3rd party or open source that it is still in use. The only time we use the stime-etime paradigm is when there is an infection (delivery stage of the Kill Chain) that was valid but later cleaned up. Nbc.com<http://nbc.com/> was compromised last year for about 4 hours then cleaned up. In that case we would use stime-etime. There are indicators that we call persistent. These are indicators that we will never stop looking for. These could be indicators that are used exclusively by a specific threat actor (like a domain registered by an actor) or something that we used in a previous incident at our organization, like RSA breech related indicators. A construct to flag an indicator as persistent would be helpful as this is information is something we routinely share.

Thanks,

--Chris

Hello!

Roman

Yes we do stop looking. A good example is when NBC.com<http://nbc.com/> got hacked a few months ago. We watched for people hitting it while the URL was malicious. Once it was cleaned up we stopped watching for it since it was a somewhat popular  URL that would fire all the time and bury us in false positives.

Thanks,

--Chris

From: Stoecker, Paul

Sent from my iPhone

Answers inline below.

Thanks,

--Chris

Christopher Harrington

Hello!

Roman