Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

From: Todd Glassey <[email-masked]>
Date: Tue, 24 Jul 2007 09:04:26 -0700 (GMT-07:00)

Alan - again my push back is in the role of Devil's Advocate...

more inline below -

-----Original Message-----
>From: Alan DeKok <[email-masked]>
>Sent: Jul 24, 2007 8:40 AM
>To: todd glassey <[email-masked]>
>Cc: Frank Yeh Jr <[email-masked]>, [email-masked], Paul Sangster <[email-masked]>
>Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr
>
>todd glassey wrote:
>> Alan - and Frank - the key issue is in creating a USE MODEL for the
>> actual NEA package and its components which performs the collection and
>> dissemination processes. Without these end-user guidance models we wont
>> know what functions are critical and what are not.
>
>  The requirements document does a good job of describing many use
>models.  

The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protocol for that use's operations and that is totally missing from the work now IMHO.

> The discussion here is about additional use models that should
>be permitted under NEA.  Those additional use models are being deployed
>*now* using existing protocols, precisely because administrators see
>those functions as being critical.

Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'...

>
>  My proposal is that the NEA WG recognize that other use models exist,
>and that those use models should not be prevented by the NEA design.  

This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established. 

> I
>do NOT want to spend time standardizing them in NEA, as I see them as
>being out of scope of the charter.  We should concentrate on endpoints,
>rather than additional posture collection points.

This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality of NEA is a key part of what NEA is and does, and its that it seems you want to expand.

I would put it that this expansion requires a new use model for each expansion and that these use models need proper 'release engineering' done on them, not just the core-engineering that the IETF likes to apply to something and then quickly call it a standard.

>
>> I propose that NEA actually put forth the effort to build these rather
>> than spending thousands of the collectives hours designing 'yet another
>> solution in search of a problem' which most other IETF initiatives are
>> shackled down by.
>
>  I'm not sure what you mean by that.  All of the use models discussed
>here are:
>
>  * requested by network administrators

For what purpose?

>  * deployed today in non-standard protocols

to accomplish what purpose?

>  * deployed today in non-NEA protocols.

Which means that NEA-WG may be replicating features and functionality already codified inside the IETF too eh? Isnt that a violation of the IETF's charter - to reinvent the wheel in a new color or type of rubber for each new car?

>  Alan DeKok.

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: Alan DeKok <[email-masked]>
Date: Tue, 24 Jul 2007 14:49:40 -0400

> The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protoc…

  The existing requirements document has (relatively) clear descriptions
of use models.  If those aren't clear, there are many examples.

> Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'...

  Thank you for correcting me about the point I was trying to make.

> This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established. 

  I MAY OR MAY NOT have something bad happen to me.

  Talking about anything that MAY OR MAY NOT happen means you can avoid
talking about the message I was trying to communicate: NEA interaction
with IDS is out of scope.  We should not design NEA to require an IDS.
We should not design NEA to require interaction with an IDS.  We MAY
design NEA to be capable of interacting with an IDS.

  I was sure I had said that already.

> This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality…

  Hmm... I say I want to concentrate on charter activities, and you
conclude that I want to expand the scope of NEA.

  Playing devils advocate is one thing.  Inventing straw men is another.

> I would put it that this expansion requires a new use model 

  What expansion?  I pointedly said I didn't want one.  I said I didn't
want to spend much time discussing out of charter activities.

  Therefore, my best approach is to ignore the FUD around IDS.

  Alan DeKok.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 21:05:55 +0200

>   Therefore, my best approach is to ignore the FUD around IDS.
I think the impact on the model is minor to negligible but I
concede I could be wrong on that point and that consensus
doesn't seem clearly in favor of my suggestion.

However in that case I do claim that the acronym "IDS" should
_not_ occur in the draft since it is clearly misleading.

    Cheers Leif

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 24 Jul 2007 15:11:39 -0400

Let me step in here with my WG Chair hat on.

Having the NEA Server consult with an IDS is not
in scope for the NEA WG at the current time.
Our job is to agree on protocols for assessing
endpoint posture. Monitoring endpoint behavior
via an IDS and integrating that with a NEA Server
may be a very good thing but it is not in scope
for the NEA WG.

Thanks,

Steve

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 1:50 PM
To: Todd Glassey
Cc: [email-masked]; Paul Sangster
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Todd Glassey wrote:
> The point is that each USE MODEL has its own constraints and that is
what is not defined. Also defining a "USE MODEL" is not just
illustrating a potential use, but rather building a flow and protocol
for that use's operations and that is totally missing from the work now
IMHO.

> Not really - the discussion here is whether the undocumented uses
existing today should be expanded to meet more 'ideas of how to use
NEA'...

> 
> This MAY OR MAY NOT make severe changes in the underlying
functionality of the NEA suite. That's the problem too - some of the new
uses may be contraindicated from those already established. 

> This is the basic flaw in much of the IETF's operations - the "We want
to build something that is everything to everyone" mindset and its what
screws up most of these initiatives. The Functionality of NEA is a key
part of what NEA is and does, and its that it seems you want to expand.

  Alan DeKok.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 21:17:32 +0200

> may be a very good thing but it is not in scope
Good clarification. That seems to imply we need
to update 03 to remove references to "IDS" to avoid
confusion.

    Cheers Leif

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Jul 2007 12:32:45 -0700

Steve - let me ask - If the device is an appliance and not an OS based 
instance, this may change I would think,  any thoughts on this?

Also for some more detail how does this apply to devices like the new 
'network co-processors' that integrate the Stack, Stream Head, and TLI for 
instance into a silicon device? It would be totally reasonable for a SNORT 
type stack-enhancement to one of these to be queried by NEA prior to a 
connection's establishment, but for OS based systems, I agree with you 
totally.

Todd

----- Original Message ----- 
From: "Stephen Hanna" <[email-masked]>
To: "Alan DeKok" <[email-masked]>; "Todd Glassey" 
<[email-masked]>
Cc: <[email-masked]>; "Paul Sangster" <[email-masked]>
Sent: Tuesday, July 24, 2007 12:11 PM
Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr

Thanks,

Steve

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Tuesday, July 24, 2007 1:50 PM
To: Todd Glassey
Cc: [email-masked]; Paul Sangster
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

  Alan DeKok.

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 24 Jul 2007 15:45:13 -0400

If the endpoint does not support NEA protocols,
it is not addressed by the current scope of the
NEA WG. Some appliances might support the NEA
protocols. Some might not.

If an endpoint includes a built-in IDS capability
whose posture can be reported by a Posture Collector
on the NEA Client and queried by the NEA Server as
part of the NEA protocol exchange, then that should
be OK. My email was primarily referring to network
Intrusion Detection Systems.

Thanks,

Steve

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 2:33 PM
To: Stephen Hanna; Alan DeKok
Cc: [email-masked]; Paul Sangster
Subject: Re: [Nea] 03 comments - IDS as Posture Collector

Also for some more detail how does this apply to devices like the new 
'network co-processors' that integrate the Stack, Stream Head, and TLI
for 
instance into a silicon device? It would be totally reasonable for a
SNORT 
type stack-enhancement to one of these to be queried by NEA prior to a 
connection's establishment, but for OS based systems, I agree with you 
totally.

Todd

----- Original Message ----- 
From: "Stephen Hanna" <[email-masked]>
To: "Alan DeKok" <[email-masked]>; "Todd Glassey" 
<[email-masked]>

Thanks,

Steve

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Tuesday, July 24, 2007 1:50 PM
To: Todd Glassey
Cc: [email-masked]; Paul Sangster
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

  Alan DeKok.

---

From: "Paul Sangster" <[email-masked]>
Date: Tue, 24 Jul 2007 12:53:23 -0700

I'm not trying to continue this thread but would like to see if any
changes are needed as a result of this discussion.  Clearly this
discussion is out of scope for our *current* charter.  Leif mentioned
removing the mention of IDS.  The current spec uses of IDS include:

5.1.1.1 (one in question) which is referring to a host-based IDS ... Its
says:
"Typical examples include Posture Collectors that provide information
about Operating System (OS) patch levels, anti-virus software, and
security mechanisms on the endpoint such as host firewall or an
Intrusion Detection System (IDS)."

I'm ok with dropping the "or an Intrusion Detection System (IDS)" if
folks find this confusing.  This phrase was not referring to network
based IDS which this thread focused upon.

8.1.1 also lists IDS/IPS as an example of an endpoint security mechanism
which could be removed without impact if helpful.

8.1.2 is the final mention (also in security consideration) which is the
only part which seems relevant to this thread:

"Fourth, many networks include infrastructure such as IDS/IPS devices
which monitor and take corrective action when suspicious behavior is
observed on the network.  These devices may have a relationship with the
NEA Server which is not within scope for this specification.  Devices
trusted by the NEA Server to provide security information that might
affect the NEA Server's decisions are trusted to operate properly and
not cause the NEA Server to make incorrect decisions."

Do we need to remove IDS from any other these sections?

Paul

> From: Leif Johansson [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 12:18 PM
> To: Stephen Hanna
> Cc: Paul Sangster; [email-masked]
> > Having the NEA Server consult with an IDS is not in scope 
> for the NEA 
> > WG at the current time.
> > Our job is to agree on protocols for assessing endpoint posture. 
> > Monitoring endpoint behavior via an IDS and integrating that with a 
> > NEA Server may be a very good thing but it is not in scope 
> for the NEA 
> > WG.
> >   
> Good clarification. That seems to imply we need to update 03 
> to remove references to "IDS" to avoid confusion.
> 
>     Cheers Leif
> 
> 
>

---

From: "Paul Sangster" <[email-masked]>
Date: Tue, 24 Jul 2007 13:02:31 -0700

> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 12:45 PM
> To: todd glassey; Alan DeKok
> Subject: RE: [Nea] 03 comments - IDS as Posture Collector
> 
> If the endpoint does not support NEA protocols, it is not 
> addressed by the current scope of the NEA WG. Some appliances 
> might support the NEA protocols. Some might not.
> 
> If an endpoint includes a built-in IDS capability whose 
> posture can be reported by a Posture Collector on the NEA 
> Client and queried by the NEA Server as part of the NEA 
> protocol exchange, then that should be OK. My email was 
> primarily referring to network Intrusion Detection Systems.

Just to be extra clear because their has been some confusion about this.
This topic is about 3rd parties (such as an network-based IDS/IDP)
providing posture for an endpoint instead of a local NEA Client.

If an IDS is running on the same system as the NEA Client, there is no
problem with the NEA Client reporting the local host-based IDS's
posture.  This is what section 5.1.1.1 was referring to.

> Steve - let me ask - If the device is an appliance and not an 
> OS based instance, this may change I would think,  any 
> thoughts on this?
> 
> Also for some more detail how does this apply to devices like 
> the new 'network co-processors' that integrate the Stack, 
> Stream Head, and TLI for instance into a silicon device? It 
> would be totally reasonable for a SNORT type 
> stack-enhancement to one of these to be queried by NEA prior 
> to a connection's establishment, but for OS based systems, I 
> agree with you totally.
> 
> Todd
>

---

From: Leif Johansson <[email-masked]>
Date: Tue, 24 Jul 2007 22:44:00 +0200

> posture.  This is what section 5.1.1.1 was referring to.
In that case this needs to be cleared up in the text.
   
    Cheers Leif

---

From: "Paul Sangster" <[email-masked]>
Date: Tue, 24 Jul 2007 14:21:34 -0700

> Sent: Tuesday, July 24, 2007 1:44 PM
> To: Paul Sangster
> Cc: Stephen Hanna; todd glassey; Alan DeKok; [email-masked]
> addressed 
> >> by the current scope of the NEA WG. Some appliances might 
> support the 
> >> NEA protocols. Some might not.
> >>
> posture can 
> >> be reported by a Posture Collector on the NEA Client and 
> queried by 
> >> the NEA Server as part of the NEA protocol exchange, then 
> that should 
> >> be OK. My email was primarily referring to network Intrusion 
> >> Detection Systems.
> >>     
> >

Ok, suggest we add this to section 3.1 where we discuss topics which are
out of scope.

Thanks,

Paul

---

From: Leif Johansson <[email-masked]>
Date: Wed, 25 Jul 2007 01:44:33 +0200

> removing the mention of IDS.  The current spec uses of IDS include:
Maybe you only need to clarify that you are talking about
host-based IDS:en rather than network-based IDS:en (which
from my background are the "traditional" ones, which may
be the source of my confusion about the text).

    Cheers Leif