Subject: [I2nsf] The defense 'ecosystem' paradigm

From: Robert Moskowitz <[email-masked]>
Date: Wed, 25 Mar 2015 12:35:41 -0500

I have been looking at i2nsf, dots, sacm, and mile and how they SHOULD 
fit together (in my world view).  I was also told to look at supa, but I 
had a conflict for that bof...

There is a taxonomy here of 'security enforcement points' along with 
information nexii and communications protocols.

If we can come to some reasonable concensus on such a taxonomy, we can 
have each doing the best they can and all pulling together.

Bob

---

From: Melinda Shore <[email-masked]>
Date: Fri, 27 Mar 2015 21:01:24 -0500

I'm rather surprised that nobody has answered this!

I think this is a very reasonable approach, with the
caveat that what's needed *here* is not so much an architecture
but an actual protocol conveying actual data between actual
network elements.  This may be why other middlebox protocols
<rimshot> have been able to move forward, even while being
redundant, while this effort has been stuck.  It seems to
me, based on discussions during the week and on both the
input to and the output from the dots BOF, that there's
still room for a good backend protocol to convey requests
to what used to be called policy enforcement points based
on the active threat data being shared through a dots-like mechanism.
But that's a very narrow example.

So, I think to the extent that a taxonomy can help this
effort develop a narrow focus, it would be a very helpful
thing indeed.  But it's got to be very applied - I am
skeptical about the value of high-level architectures in
the IETF.

Melinda

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 27 Mar 2015 21:38:54 -0500

I'd suggest looking at the XMPP grid protocol proposed to SACM for the exchange of formatted data.  It provides a really nice federated model that allows for negotiate of other appropriate transports for the actual data sent depending on requirements.  This will work across each of the WGs mentioned, but won't solve all problems.  The ROLIE draft in MILE is a RESTful interface for the exchange of formatted data (again any format can be used).  REST is used by a lot of products in the incident response space - especially within an internal network at the moment.

Both of these could use review sent to the respective mailing list.

I put a table up on the MILE wiki over a year ago with the transports being discussed in that space.

DOTS will have to stick to very specific requirements to be effective with a transport during a DDoS attack.  IPFIX was consistent across proposals, but the choice of UDP may change once Brian Trammel's analysis is shared.  It won't necessarily be feasible for them to use the same protocol as the other three groups.

ROLIE
http://www.ietf.org/id/draft-ietf-mile-rolie-00.txt
http://www.ietf.org/proceedings/92/slides/slides-92-mile-4.pdf

XMPP Grid
https://datatracker.ietf.org/doc/draft-salowey-sacm-xmpp-grid/

IF-MAP from TCG may come to the IETF as well.  I haven't read that in a while, so I don't have comments nor any firm commitment that it will come here.

Best regards,
Kathleen 

Sent from my iPhone

> On Mar 27, 2015, at 9:01 PM, Melinda Shore <[email-masked]> wrote:
> 
> _______________________________________________
> I2nsf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

---

From: "Adam W. Montville" <[email-masked]>
Date: Sat, 28 Mar 2015 07:41:15 -0500

Having a cross-group understanding of the relationship between i2nsf, sacm, mile, and dots would be beneficial.  I’m less familiar with i2nsf and dots (in the details). 

sacm is, at its core, primarily interested in assessing endpoint attributes.  This means expressing the desired attribute to collect, collecting it, and evaluating it against some expressed expectation.  The assessment result is provided for downstream use, irrespective of what that use might be.  Additionally, collection could be the only results provided (if no evaluation piece is needed).

It seems that mile, i2nsf, and dots would all benefit from sacm in some way, as they are largely downstream from the core problem sacm intends to solve.  

i2nsf seeks to express and evaluate network service related information, which will ultimately need to identify specific endpoints (virtual or otherwise) to collect specific attributes, evaluate them against some expressed expectation, then make sense of that at the i2nsf level.

mile could benefit from sacm by leveraging the attribute expression and evaluation formats.  Additionally, the “ad hoc” exploratory tools often favored during incident response could use sacm as a means of that exploration.

dots is my least understood domain, but after speaking with Ana Hedanping for a brief time, it seems that dots will have some need to express endpoint attributes, collect values, and evaluate them against some expectation as well.  Only, this will be more of a “real time” circumstance (I presume).

As Bob pointed out, these are all parts of a whole - the “defense ecosystem paradigm”.   And, while deriving a specific taxonomy could be useful, it’s already done in a way.  The “defense ‘ecosystem’ paradigm" seems to me like a synonym for “security program”, and those are well covered.  Think ISO 27000 series, NIST 800-53, PCI DSS, COBIT, 20 Critical Security Controls, and the like.  In fact, I used a similar perspective (I called it “frame of reference”) at a sacm BoF (back in Atlanta during IETF 85 [1]) to frame the “space” in which sacm plays.  I think mile  , i2nsf, and dots all play in this same space (see the second, third, and fourth slides).  

What seems important is that we recognize (and name) the different business processes we are supporting.  This should help us recognize the relationships between our work.

Thoughts?

Regards,

Adam

[1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf <https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 28 Mar 2015 09:15:29 -0500

There's two separate questions here, Bob's original and Melinda's which is more focused on protocol relationships.  My first response was to Melinda's question to help that discussion and Adam's is more focused on Bob's.

I'll follow up to Bob's as well as this is in my head as I've needed to make sure the groups don't overlap.  For DOTS, it's similar to the very early versions of RID before it was changed in the IETF to use SNMP then XML, so I will want to make sure their requirements are not morphed by other related areas or it won't solve their problems.  

I'm taking a few days off, but will try to get a picture out soon unless someone beats me to it (and sees it in a similar enough way).

This is a good set of discussions to have and I do think more eyes on the existing protocol drafts in these groups will be very helpful.

Best regards,
Kathleen 

Sent from my iPhone

> On Mar 28, 2015, at 7:41 AM, "Adam W. Montville" <[email-masked]> wrote:
> 
> [1] https://www.ietf.org/proceedings/85/slides/slides-85-sacm-2.pdf
> 
> 
>