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

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 3 Aug 2007 09:12:12 -0700

Greetings,

      I believe we're just going to have to agree to disagree on this one.

      We've been around and around on this issue and unless the consensus
in the group is that this is in scope, I am going to draw the line here.
You've heard my opinion and seem to understand it, I've heard yours but I
disagree with it.

      I guess this is why we vote on things.

Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

             "todd glassey"                                                
             <tglassey@earthli                                             
             nk.net>                                                    To 
                                       Frank Yeh Jr/Irvine/IBM@IBMUS       
             08/03/2007 08:01                                           cc 
             AM                        "Mike Fratto" <[email-masked]>,  
                                       <[email-masked]>, "Paul Sangster"     
                                       <[email-masked]>        
                                                                   Subject 
                                       Re: [Nea] 03 comments - IDS as      
                                       Posture Collecotr                   

                                                                           

Then the scope of the protocol is probably broken - that said, let me ask
what is the specific use of the service? - If it is just in establishing
what I refer to as a tentative-connection - that being one that is erected
to pre-qualify the use of the service then that needs to have some process
wherein it can assure the world that it separates the ability to transport
other IP traffic until that node is qualified.

No other fantasy about creating yet another protocol to do things that
other protocols already do makes sense here.

If the idea is the be able to qualify and constrain the 'access to the
IP/Network ' for a given system, then NEA doesn't seem to do that.
Personally - I was thinking that the NEA process to really meet the audit
requirements should be outside of TCP/IP itself, maybe be based on OSX/SPX
or XNS for instance. Or perhaps Mentat's modified IP Kernel, but making NEA
just another protocol running in a TCP/IP Network is more than a waste of
time IMHO, its a nightmare waiting to happen since NO ONE HERE can control
what code is written to run on those networks and as such NEA just doesn't
make sense.

If the intent is to provide proper messaging and control of access and
'readiness status' as well as 'integrity status' then we need to carefully
define the User Functions and the Constraints involved in the process PRIOR
to defining the protocol so we know what we are all trying to do - and that
doesn't seem to have happened from reading the NEA document set,
end-to-end.

Just my two cents.

Todd Glassey, CISM, CIFI
as an Auditor
 ----- Original Message -----
 From: Frank Yeh Jr
 To: TS Glassey
 Cc: Mike Fratto ; [email-masked] ; Paul Sangster
 Sent: Thursday, August 02, 2007 2:46 PM
 Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

 Greetings,

 I understand your points but consider them to be out of scope for NEA,
 which is about establishing and using a tunnel to pass data. What happens
 to the data outside of the tunnel, how it is collected, etc are outside
 the scope of the protocol.

 What you want is a standard way of dealing with the data once it is passed
 through the tunnel. NEA is purposely generic about this to make it as
 flexible as possible. If you want to define a standard way to then pass
 that data to an IDS and figure out what to do, great. That would require
 another specification which would use NEA as transport and as a network
 admission control point.

 Regards,
 Frank Yeh
 Sr. Security & Privacy Integration Architect
 IBM Global Technology Services
 Security & Privacy Technology Integration Team

 Second Life: Yehoo Newall

 Inactive hide details for "TS Glassey" <[email-masked]>"TS
 Glassey" <[email-masked]>

                         "TS                                               
                         Glasse                                            
                         y"                                                
                         <tglas                                            
                         sey@ea                                         To 
                         rthlin                                            
                         k.net>        Frank Yeh Jr/Irvine/IBM@IBMUS       
                                                                           
                                                                        cc 
                         08/02/                                            
                         2007          "Mike Fratto" <[email-masked]>,  
                         09:52         <[email-masked]>, "Paul Sangster"     
                         AM            <[email-masked]>        
                                                                           
                                                                   Subject 
                                                                           
                                       Re: [Nea] 03 comments - IDS as      
                                       Posture Collecotr                   

                                                                           

 pardon the blue-sky rant here but... The real value from a philosophical
 point I see for NEA is that it could be a collection point for a number of
 Policy Service tools, and that it can tie this in with a set of
 attestation practice models for running secured and reliable
 infrastructure. That said, the point is that there keenly is a need to
 handle the stateful compliance with 'pre-specified policy and
 configuration management' and that this is specific not only to just
 plugging a system into a network but in prefacing the connections of two
 distributed systems from untrusted networks together.

 OK -- so what does all that really mean? - Simple - it means that there in
 the IETF's bag of tricks needs to be a really cool messaging and policy
 communication language and protocol which can be used not only to qualify
 a machine for action in an environment, but also for operations as a
 pre-event transaction qualification as well. This possibly makes NEA it.
 The one and only qualifer and setup infrastructure needed to bring
 machines in or take them out, and to have applications use.

 t.
 ----- Original Message -----
 From: Frank Yeh Jr
 To: TS Glassey
 Cc: Mike Fratto ; [email-masked] ; Paul Sangster
 Sent: Thursday, August 02, 2007 9:44 AM
 Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

 Greetings,

 Perhaps it would be useful to separate things based on what is being
 measured and where the measurements are taken and validated.

 For our purposes, there are essentially two types of measurement_
 state-based and behavior-based. The traditional IDS is behavior-based. It
 does not really tell you anything about the state of an endpoint but tells
 you what it is doing on the network. Recent introduction of host-based IDS
 (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention System)
 technology does not change the fact that behavior is being measured.

 Integrity measurements are traditionally about state from a configuration
 standpoint. What software is installed, how it is configured, what values
 are found in the system registry or environment variables are examples of
 state. This is the traditional thinking in the various camps that are
 feeding the NEA effort.

 So there seems to be some confusion over the fact that some are proposing
 a tighter coupling with IDS's be built into the protocol.

 IMHO, this would be a useless extension for which existing protocols will
 serve perfectly well. There is no constraint on what is being measured,
 transported and verified. It is all simply data that relates to a single
 endpoint. If an endpoint has invalid state or is performing illegal
 actions, either of these should cause the endpoint to be kicked off or
 denied access to the network. There is nothing in the protocol that
 specifies what content is to be transferred in the tunnel created between
 the measurement collectors and the verifiers.

 Furthermore, there is nothing in the current approach that precludes using
 an IDS on the verifier side and it will be just as easy to build an
 integrity verifier on an IDS as to build a new interface to a new
 protocol. In either case the code has to be written but will only have to
 be done once. So an endpoint could simply be queried for its MAC Address
 which could be sent to an IDS with a simple "are there any violations
 found for this MAC" query. Based on what the IDS reports, the decision can
 be made. Why do we need anything else in the context of a network
 admission (or post admission) decision?

 Regards,
 Frank Yeh
 Sr. Security & Privacy Integration Architect
 IBM Global Technology Services
 Security & Privacy Technology Integration Team

 Second Life: Yehoo Newall

 Inactive hide details for "TS Glassey" <[email-masked]>"TS
 Glassey" <[email-masked]>
                                                                           
     "TS Glassey" <[email-masked]>                                 

     08/02/2007 07:41 AM                                                   
                                                                        To 
                                                                           
                                                     "Mike Fratto"         
                                                     <[email-masked]>   
                                                                           
                                                                        cc 
                                                                           
                                                     [email-masked], Paul    
                                                     Sangster              
                                                     <Paul_Sangster@symant 
                                                     ec.com>               
                                                                           
                                                                   Subject 
                                                                           
                                                     Re: [Nea] 03 comments 
                                                     - IDS as Posture      
                                                     Collecotr             

                                                                           

 Mike - I agree with the idea... conceptually there are two very different
 things going on here, and one of them is IDS centric and the other isnt,
 that being the 'footprint' verification functionality of some 'change
 management/control' service. As to amending the wording, I think NEA will
 need to do both functions since they are both key aspects of an ongoing
 Integrity Of Operations constrol set which this clearly is one.

 Todd
 ----- Original Message -----
 From: "Mike Fratto" <[email-masked]>
 To: "TS Glassey" <[email-masked]>
 Cc: "Stefan Winter" <[email-masked]>; <[email-masked]>; "Paul
 Sangster" <[email-masked]>
 Sent: Thursday, August 02, 2007 7:25 AM
 Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

 > Why not just clarify the language to indicate a "Host Based IDS"
 > instead of "IDS"?
 >
 > Host based stuff is certainly within the charter. There are such
 > beasties on the market and as part of posture validation, can be used
 > in assessments in the same way an anti-virus or patch management
 > product can.
 >
 > Besides, there is nothing to be gained by removing the reference and
 > if removed, leaves a gap that is open to interpretation.
 >
 > On 8/2/07, TS Glassey <[email-masked]> wrote:
 >> This is then about Configuration Management as well as Integrity?
 >>
 >> T
 >> ----- Original Message -----
 >> From: "Stefan Winter" <[email-masked]>
 >> To: <[email-masked]>
 >> Cc: "Paul Sangster" <[email-masked]>
 >> Sent: Thursday, August 02, 2007 2:02 AM
 >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr
 >>
 >>
 >> > _______________________________________________
 >> > Nea mailing list
 >> > [email-masked]
 >> > https://www1.ietf.org/mailman/listinfo/nea
 >> >
 >>
 >>
 >> _______________________________________________
 >> Nea mailing list
 >> [email-masked]
 >> https://www1.ietf.org/mailman/listinfo/nea
 >>

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 3 Aug 2007 12:27:29 -0400

Actually, we don't vote in IETF. We use rough consensus. But our charter
states clearly that enforcement is out of scope for NEA and as co-chair,
I believe we have rough consensus to stick with that charter. So this
discussion is out of scope.
 
There are many interesting topics that are out of scope for NEA but
they're not pertinent for discussion on this list. Let's try to focus on
topics that are in scope. Could everyone please review the latest NEA
requirements document and send comments to the list? The requirements
document is in Working Group Last Call so now's the time to do this
review.
 
Thanks,
 
Steve

________________________________

From: Frank Yeh Jr [mailto:[email-masked]] 
Sent: Friday, August 03, 2007 12:12 PM
To: todd glassey
Cc: [email-masked]; Paul Sangster
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Greetings,

We've been around and around on this issue and unless the consensus in
the group is that this is in scope, I am going to draw the line here.
You've heard my opinion and seem to understand it, I've heard yours but
I disagree with it.

Regards,
Frank Yeh

 "todd glassey" <[email-masked]>

				"todd glassey" <[email-masked]> 

				08/03/2007 08:01 AM

To

cc

"Mike Fratto" <[email-masked]>, <[email-masked]>, "Paul Sangster"
<[email-masked]>	

Subject

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

Then the scope of the protocol is probably broken - that said, let me
ask what is the specific use of the service? - If it is just in
establishing what I refer to as a tentative-connection - that being one
that is erected to pre-qualify the use of the service then that needs to
have some process wherein it can assure the world that it separates the
ability to transport other IP traffic until that node is qualified. 

If the idea is the be able to qualify and constrain the 'access to the
IP/Network ' for a given system, then NEA doesn't seem to do that.
Personally - I was thinking that the NEA process to really meet the
audit requirements should be outside of TCP/IP itself, maybe be based on
OSX/SPX or XNS for instance. Or perhaps Mentat's modified IP Kernel, but
making NEA just another protocol running in a TCP/IP Network is more
than a waste of time IMHO, its a nightmare waiting to happen since NO
ONE HERE can control what code is written to run on those networks and
as such NEA just doesn't make sense.

If the intent is to provide proper messaging and control of access and
'readiness status' as well as 'integrity status' then we need to
carefully define the User Functions and the Constraints involved in the
process PRIOR to defining the protocol so we know what we are all trying
to do - and that doesn't seem to have happened from reading the NEA
document set, end-to-end.

Just my two cents.

Todd Glassey, CISM, CIFI
as an Auditor
----- Original Message ----- 
From: Frank Yeh Jr <mailto:[email-masked]>  
To: TS Glassey <mailto:[email-masked]>  
Cc: Mike Fratto <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  ; Paul Sangster
<mailto:[email-masked]>  
Sent: Thursday, August 02, 2007 2:46 PM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Greetings,

I understand your points but consider them to be out of scope for NEA,
which is about establishing and using a tunnel to pass data. What
happens to the data outside of the tunnel, how it is collected, etc are
outside the scope of the protocol.

What you want is a standard way of dealing with the data once it is
passed through the tunnel. NEA is purposely generic about this to make
it as flexible as possible. If you want to define a standard way to then
pass that data to an IDS and figure out what to do, great. That would
require another specification which would use NEA as transport and as a
network admission control point.

Regards,
Frank Yeh

					"TS Glassey"
<[email-masked]> 

					08/02/2007 09:52 AM

To

cc

"Mike Fratto" <[email-masked]>, <[email-masked]>, "Paul Sangster"
<[email-masked]>	
 
Subject

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

pardon the blue-sky rant here but... The real value from a philosophical
point I see for NEA is that it could be a collection point for a number
of Policy Service tools, and that it can tie this in with a set of
attestation practice models for running secured and reliable
infrastructure. That said, the point is that there keenly is a need to
handle the stateful compliance with 'pre-specified policy and
configuration management' and that this is specific not only to just
plugging a system into a network but in prefacing the connections of two
distributed systems from untrusted networks together.

OK -- so what does all that really mean? - Simple - it means that there
in the IETF's bag of tricks needs to be a really cool messaging and
policy communication language and protocol which can be used not only to
qualify a machine for action in an environment, but also for operations
as a pre-event transaction qualification as well. This possibly makes
NEA it. The one and only qualifer and setup infrastructure needed to
bring machines in or take them out, and to have applications use.

t.
----- Original Message ----- 
From: Frank Yeh Jr <mailto:[email-masked]>  
To: TS Glassey <mailto:[email-masked]>  
Cc: Mike Fratto <mailto:[email-masked]>  ; [email-masked]
<mailto:[email-masked]>  ; Paul Sangster
<mailto:[email-masked]>  
Sent: Thursday, August 02, 2007 9:44 AM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr 

Greetings,

For our purposes, there are essentially two types of measurement_
state-based and behavior-based. The traditional IDS is behavior-based.
It does not really tell you anything about the state of an endpoint but
tells you what it is doing on the network. Recent introduction of
host-based IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion
Prevention System) technology does not change the fact that behavior is
being measured.

Integrity measurements are traditionally about state from a
configuration standpoint. What software is installed, how it is
configured, what values are found in the system registry or environment
variables are examples of state. This is the traditional thinking in the
various camps that are feeding the NEA effort.

So there seems to be some confusion over the fact that some are
proposing a tighter coupling with IDS's be built into the protocol.

IMHO, this would be a useless extension for which existing protocols
will serve perfectly well. There is no constraint on what is being
measured, transported and verified. It is all simply data that relates
to a single endpoint. If an endpoint has invalid state or is performing
illegal actions, either of these should cause the endpoint to be kicked
off or denied access to the network. There is nothing in the protocol
that specifies what content is to be transferred in the tunnel created
between the measurement collectors and the verifiers.

Furthermore, there is nothing in the current approach that precludes
using an IDS on the verifier side and it will be just as easy to build
an integrity verifier on an IDS as to build a new interface to a new
protocol. In either case the code has to be written but will only have
to be done once. So an endpoint could simply be queried for its MAC
Address which could be sent to an IDS with a simple "are there any
violations found for this MAC" query. Based on what the IDS reports, the
decision can be made. Why do we need anything else in the context of a
network admission (or post admission) decision?

Regards,
Frank Yeh

					"TS Glassey"
<[email-masked]> 

					08/02/2007 07:41 AM

To

"Mike Fratto" <[email-masked]>	
 
cc

[email-masked], Paul Sangster <[email-masked]>	
 
Subject

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

Mike - I agree with the idea... conceptually there are two very
different 
things going on here, and one of them is IDS centric and the other isnt,

that being the 'footprint' verification functionality of some 'change 
management/control' service. As to amending the wording, I think NEA
will 
need to do both functions since they are both key aspects of an ongoing 
Integrity Of Operations constrol set which this clearly is one.

Todd
----- Original Message ----- 
From: "Mike Fratto" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "Stefan Winter" <[email-masked]>; <[email-masked]>; "Paul 

>> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr
<https://www1.ietf.org/mailman/listinfo/nea> 
<https://www1.ietf.org/mailman/listinfo/nea> 

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 3 Aug 2007 13:29:00 -0400

Todd suggested that I send the URL for the requirements document to make
it convenient to review. That is
http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt
 
Thanks,
 
Steve

From: Stephen Hanna 
Sent: Friday, August 03, 2007 12:27 PM
To: Frank Yeh Jr; todd glassey
Cc: [email-masked]; Paul Sangster
Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr

 
Thanks,
 
Steve

Greetings,

Regards,
Frank Yeh

				08/03/2007 08:01 AM

To

cc

Subject

Just my two cents.

Todd Glassey, CISM, CIFI
as an Auditor
----- Original Message ----- 
From: Frank Yeh Jr <mailto:[email-masked]>  
To: TS Glassey <mailto:[email-masked]>  
Cc: Mike Fratto <mailto:[email-masked]>  ; [email-masked]

Greetings,

Regards,
Frank Yeh

					"TS Glassey"
<[email-masked]> 

					08/02/2007 09:52 AM

To

cc

Subject

t.
----- Original Message ----- 
From: Frank Yeh Jr <mailto:[email-masked]>  
To: TS Glassey <mailto:[email-masked]>  
Cc: Mike Fratto <mailto:[email-masked]>  ; [email-masked]

Greetings,

Regards,
Frank Yeh

					"TS Glassey"
<[email-masked]> 

					08/02/2007 07:41 AM

To

cc

Subject

Todd