Subject: [mile] Less is More

From: "Stoecker, Paul" <[email-masked]>
Date: Thu, 7 Mar 2013 12:44:02 +0000

As we have gone through this process of changing IODEF to essentially morph it from something used to share incidents to something used to share indicators, I have been getting the feeling that we are trying to make it everything to everybody.

I had thought that the goal was to be able to share IOCs so that the adage of "my detection becomes your prevention" will ring true.  If that is our goal isn't there a design paradigm that for efficiency you do the minimum needed to effectively solve the problem?  To that end, what is the minimum amount of context that we need to share IOCs?  Do we really need to pull in ARF, RFC 5901, etc.?  

Is IODEF really the solution as it was based on sharing Incident Information rather than IOCs?  Should IODEF become the Indicator Object Definition Exchange Format?  If so, aren't there better ways to handle some of the indicator data..like the System and Node classes being rewritten to handle multiple IPs better?  I guess what I am saying is, if you had to design a schema for the purpose of sharing IOCs starting from nothing would it turn out to look like IODEF or would it be something fundamentally different?

I am not being critical of the work to date or of some of the ideas being put forward, but I do like to do these types of thought experiments during a design process to make sure that we are happy with the direction and don't need to make any course corrections.  I see all of the discussion about adding more context and it starts me thinking that we are adding "complexity" and moving away from "less is more".  

One of the things about me, having spent time in a SOC is that I want to get immediately down to the issue.  Just tell me what I need to know to detect the malicious activity.  Once I find it I can take some very coarse, rudimentary actions to protect my environment while it gets escalated to a team to research it and gather the context needed to create effective long-term permanent solutions.  Hence my concerns about trying to do too much with IODEF.

Anyway, this is what happens when I am on holiday and my mind frees up to think about things ;-). 

Regards,

Paul

Sent from my iPad

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 7 Mar 2013 08:49:37 -0500

Hi Paul & others,

Do you have some suggestions of what you would like to see change?  I personally agree that it would be nice to be able to handle multiple IPs better.  The watchlist-souce and watchlist-dest in examples doesn't really help over what was in place, although it does let you see that the grouping provided is an OR with the rest of the content in the EventData container.  As you or others come up with alternatives, please discuss them!

As for DNS and email, this data is exchanged today to help with the phishing, mail abuse, and other attacks.  If we use ARF for those use cases, then only the parties and products interested in sharing that data will invoke the use of ARF.  The rest may send a message to say the schema isn't supported, but be able to parse the IODEF core of the document.  For the DomainData, I am working on a use case that asks for domain data to be exchanged in case the dns information changed (fraudulent).  This is used today by the APWG when they track down anti-phishing and other CIRT teams use this data as well (from interviews, etc.).  Either ARF or RFC5901 is needed to represent all of the fields needed for email.  We have the common actionable ones in the schema now (up for review), then extend out for more detailed information.  Do you have a different approach that should be considered?

You brought up two other concerns.  One was on the size, doesn't the use of extensions or other schemas address that concern?  You would only use the other schemas or extensions you need and wouldn't have to support all of them.  My understanding of the changes is that we are trying to represent all of the commonly exchanged indicators in the core and then extend out.  If supporting Domain information is not common enough, then it should be an extension (either RFC5901 or another schema).  If it is, then how do we handle it?  These are questions for the list to guide the direction.  We are just at a draft stage.

I'd like to hear from others, but when I work with people to look at what they want to exchange, the data isn't useful unless you have some context.  This may have to do with the way we are sharing data in sharing groups versus how you might send updates to a product that helps with detection/prevention.  You can be very targeted in the latter case as the system can interpret and take actions as opposed to when indicator data is received today where context is needed to make decisions about your mitigating actions.  If you don't know enough about an indicator, you don't know what mitigations you can put in place.  If an IP is a command and control server versus a botnet, your actions will vary.

Any ideas?  It's good to get this discussion going as we iterate through a few changes and meet next week.  What lines do we draw for the core schema, what needs to change and doesn't work well today, what does work well today, and what recommendations do folks want to make?

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stoecker, Paul
Sent: Thursday, March 07, 2013 7:44 AM
To: [email-masked]
Subject: [mile] Less is More

Regards,

Paul

Sent from my iPad
_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: "Pinkerton, Scott C." <[email-masked]>
Date: Thu, 7 Mar 2013 13:56:09 +0000

I very much like this term "my detection becomes your prevention".

Here in the Department of Energy - we were using "Detect locally, Protect
globally".

With that said, we have often talked about the need for a very rich set of
suggested actions to accompany indicators. Many people think that we
(within DOE) are merely trying to pass around a "block list."

At times, we would like to be able to suggest a wide range of actions,
such as:

- route IP as normal, but do full packet capture
- route IP to a Honeypot
- block IP

Another thing that we have found over time - it was important for our
information/indicator sharing infrastructure to include a "revocation"
capability.

Over the years, we have had our fair share of ooops - where someone
detected something, and advertised it as being hostile. Then came to find
out the error was internal with their tools, and that the IP wasn't really
hostile. For us, it was important to be able to re-distribute an alert on
that same IP, but with a new suggested action being to revoke the
blocking, revoke the packet capture, etc.

-scott

On 3/7/13 6:44 AM, "Stoecker, Paul" <[email-masked]> wrote:

>As we have gone through this process of changing IODEF to essentially
>morph it from something used to share incidents to something used to
>share indicators, I have been getting the feeling that we are trying to
>make it everything to everybody.
>
>I had thought that the goal was to be able to share IOCs so that the
>adage of "my detection becomes your prevention" will ring true.  If that
>is our goal isn't there a design paradigm that for efficiency you do the
>minimum needed to effectively solve the problem?  To that end, what is
>the minimum amount of context that we need to share IOCs?  Do we really
>need to pull in ARF, RFC 5901, etc.?
>
>Is IODEF really the solution as it was based on sharing Incident
>Information rather than IOCs?  Should IODEF become the Indicator Object
>Definition Exchange Format?  If so, aren't there better ways to handle
>some of the indicator data..like the System and Node classes being
>rewritten to handle multiple IPs better?  I guess what I am saying is, if
>you had to design a schema for the purpose of sharing IOCs starting from
>nothing would it turn out to look like IODEF or would it be something
>fundamentally different?
>
>I am not being critical of the work to date or of some of the ideas being
>put forward, but I do like to do these types of thought experiments
>during a design process to make sure that we are happy with the direction
>and don't need to make any course corrections.  I see all of the
>discussion about adding more context and it starts me thinking that we
>are adding "complexity" and moving away from "less is more".
>
>One of the things about me, having spent time in a SOC is that I want to
>get immediately down to the issue.  Just tell me what I need to know to
>detect the malicious activity.  Once I find it I can take some very
>coarse, rudimentary actions to protect my environment while it gets
>escalated to a team to research it and gather the context needed to
>create effective long-term permanent solutions.  Hence my concerns about
>trying to do too much with IODEF.
>

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Thu, 7 Mar 2013 14:58:03 +0000

If IOC can describe NameServers and phishing email fields that are needed, I also concur to reuse them withi IODEF potentially using Take's draft.
I am not sure it can though.
Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Moriarty, Kathleen
Sent: Thursday, March 07, 2013 8:50 AM
To: Stoecker, Paul; [email-masked]
Subject: Re: [mile] Less is More

Hi Paul & others,

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stoecker, Paul
Sent: Thursday, March 07, 2013 7:44 AM
To: [email-masked]
Subject: [mile] Less is More

Regards,

Paul

Sent from my iPad

---

From: "Harrington, Christopher" <[email-masked]>
Date: Thu, 7 Mar 2013 10:21:38 -0500

Taking a step back I have less of an issue with the approach to the problem
as I see it defined. On that note what problem are we trying to solve? Are
we sharing IoCs or more generic sharing of threat data? The use cases seem
to support the latter. There is an important distinction between the two as
Paul pointed out. Let's take the phishing email as an example. We share
indicators of that activity, with the purpose of detection and potential
mitigation, on a daily basis. The actual email is never shared as the email
isn't an IoC. The discrete elements of the email that can be used to detect
and block the activity are the IoCs.  Similarly with the DDoS use case there
is data being shared that are not IoCs. To complicate things there is no way
to denote what should be considered an IoC and what isn't. 

If we have to support the more generic information sharing that includes
data from those use cases that are not IoCs then pulling in external schemas
is probably a requirement. Unless we want to rewrite IODEF to support it all
natively which I don't think we do.  If the goal is to share IoCs only then
we could extend IODEF natively to cover the vast majority of indicator types
with minimal external schemas. This is where Paul and I are getting hung up
as practitioners. We are talking about IoCs but also discussing sharing data
that is not IoCs. Supporting both types of data is going to be complicated
and probably a bit ugly. 

Thanks,

--Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stoecker, Paul
Sent: Thursday, March 07, 2013 7:44 AM
To: [email-masked]
Subject: [mile] Less is More

As we have gone through this process of changing IODEF to essentially morph
it from something used to share incidents to something used to share
indicators, I have been getting the feeling that we are trying to make it
everything to everybody.

I had thought that the goal was to be able to share IOCs so that the adage
of "my detection becomes your prevention" will ring true.  If that is our
goal isn't there a design paradigm that for efficiency you do the minimum
needed to effectively solve the problem?  To that end, what is the minimum
amount of context that we need to share IOCs?  Do we really need to pull in
ARF, RFC 5901, etc.?  

Is IODEF really the solution as it was based on sharing Incident Information
rather than IOCs?  Should IODEF become the Indicator Object Definition
Exchange Format?  If so, aren't there better ways to handle some of the
indicator data..like the System and Node classes being rewritten to handle
multiple IPs better?  I guess what I am saying is, if you had to design a
schema for the purpose of sharing IOCs starting from nothing would it turn
out to look like IODEF or would it be something fundamentally different?

I am not being critical of the work to date or of some of the ideas being
put forward, but I do like to do these types of thought experiments during a
design process to make sure that we are happy with the direction and don't
need to make any course corrections.  I see all of the discussion about
adding more context and it starts me thinking that we are adding
"complexity" and moving away from "less is more".  

One of the things about me, having spent time in a SOC is that I want to get
immediately down to the issue.  Just tell me what I need to know to detect
the malicious activity.  Once I find it I can take some very coarse,
rudimentary actions to protect my environment while it gets escalated to a
team to research it and gather the context needed to create effective
long-term permanent solutions.  Hence my concerns about trying to do too
much with IODEF.

Anyway, this is what happens when I am on holiday and my mind frees up to
think about things ;-). 

Regards,

Paul

Sent from my iPad