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

From: "Roman D. Danyliw" <[email-masked]>
Date: Thu, 9 Jan 2014 21:58:58 +0000

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]]
Sent: Monday, December 23, 2013 10:46 AM
To: Stoecker, Paul
Cc: Roman D. Danyliw; [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?

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