Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 11 Oct 2006 10:30:24 -0700

Hi Darryl,
Your email indicates that you would: 

a) somehow require that a visitor's laptop run an NEA client, 
b) expect the device to support PAs that the server requires to be
checked, and 
c) trust data coming out of it,

rather than treat that endpoint as an unknown endpoint and do IDS/IPS in
the network. 

Other than finding this a rather bizzarre trust model, I have to say
that there will be a very small set of such endpoints where the owner of
that endpoint is going to be thrilled to allow you to place such clients
on his/her device and perform updates on it. 

In short, this is exactly the type of endpoint I wouldn't imagine NEA
being useful for! 

Vidya 

> -----Original Message-----
> From: Darryl (Dassa) Lynch [mailto:[email-masked]] 
> Sent: Wednesday, October 11, 2006 2:56 AM
> To: Narayanan, Vidya; [email-masked]; [email-masked]
> Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
> 
> Narayanan, Vidya wrote:
> <SNIP>
> >> I continue to remain puzzled on the above points!
> 
> Hello Vidya
> 
> Perhaps if I put forward an example of how NEA may benefit me 
> it would go some way to clear the puzzle.
> 
> I run a very closed network, ports are closed and not opened 
> unless there is a validated request, external drives are 
> disabled etc etc.  A contractor comes in with a notebook and 
> needs to work on some files located on our internal secure 
> network.  A trusted staff member rings in with the request to 
> open a specified port.  The port is opened and the contractor 
> hooks up the laptop to it.  NEA does it's thing and if the 
> laptop doesn't match the requirements of the internal network 
> policy it is directed to a sandbox network for remediation.  
> If the laptop does meet the policy then it allowed onto the 
> internal network.  I have not had to physically interface 
> with the laptop or needed to allow it onto the internal 
> network before some basic checks have been carried out.  If 
> the laptop met the policy requirements it was quickly allowed 
> into the internal network and the contractor hasn't had to 
> prove to me their device could be trusted except through 
> automated means using NEA.  If I wish, I can run some more 
> checks as the laptop joins the internal network including 
> additional authentication and other hoops to ensure the 
> system hasn't lied through NEA.
> 
> Really I see NEA as providing additional information to a 
> network administrator so they automate more decisions on the 
> network.  In the above situation, if I felt NEA provided all 
> the information I needed I'd leave ports open and be 
> reasonably confident there was little risk in doing so as 
> unknown systems would be directed to the sandbox network if 
> necessary and if a lying system was able to make it to the 
> internal network my normal protection/security measures would 
> catch it out or warn me of the possibility within a reasonable time.
> 
> Just another tool to give network administrators information 
> and systems they can use to ensure the majority of users get 
> their requirements met in a reasonable and timely manner.
> 
> Darryl (Dassa) Lynch 
> 
> 

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

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Thu, 12 Oct 2006 07:13:13 +1000

Hi Vidya

Comments inline as appropriate.

Narayanan, Vidya wrote:

>> checked, and c) trust data coming out of it,
>> 
>> rather than treat that endpoint as an unknown endpoint and do
>> IDS/IPS in the network. 

You are limiting my options to a small subset of what I would have
available.  I may sandbox systems that don't have an NEA client and are
unwilling to install one, they would be treated as an unknown node and given
very limited access, they wouldn't be allowed onto the trusted network for
instance.  I would expect some information to be available which I would
then be able to check against my policy.  I would assume a limited amount of
trust but would continue to have other mechanisms in place to be informed
where that limited trust has been abused.

>> Other than finding this a rather bizzarre trust model, I
>> have to say that there will be a very small set of such
>> endpoints where the owner of that endpoint is going to be
>> thrilled to allow you to place such clients on his/her
>> device and perform updates on it.

If they wish to join my network they have to abide by the policies I have in
place, they don't like it, they don't get to play.

>> In short, this is exactly the type of endpoint I wouldn't imagine
>> NEA being useful for! 

NEA is a means to automate the information gathering about this endpoint, if
they don't agree to the policies, they will have options to.  If a person or
device doesn't agree with the policies in place, it doesn't mean I should
still provide full access for them.  Risk management will dictate what will
or will not be allowed.

Darryl (Dassa) Lynch