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

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 20 Dec 2013 21:25:33 +0000

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">

** 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>

** Could it be at the Incident level?
Example 4: <Incident>  ... <IndicatorStartTime>2013/12/01 12:00:00</IndicatorStartTime> ... many domain indicators </Flow> ... </Incident>

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.

Roman

---

From: "Harrington, Christopher" <[email-masked]>
Date: Fri, 20 Dec 2013 16:56:58 -0500

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]] On Behalf Of Roman D. Danyliw
Sent: Friday, December 20, 2013 4:26 PM
To: [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.

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. 

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

---

From: "Stoecker, Paul" <[email-masked]>
Date: Mon, 23 Dec 2013 15:26:12 +0000

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]<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!

** 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.

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: "Harrington, Christopher" <[email-masked]>
Date: Mon, 23 Dec 2013 10:45:46 -0500

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]
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]> wrote:

Hello,

Answers inline below. 

Thanks,

--Chris

Christopher Harrington

Hello!

Roman

[email-masked]