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

From: yinhan 34728 <[email-masked]>
Date: Tue, 10 Oct 2006 11:27:07 +0800

> I have a very basic fear that this working group is getting chartered
> with a bunch of aims added by people who will not take on the
> task of doing the work.  After private discussion with folks
> involved, my sense is that the very core of this work is a 
> perceived 
> need to be able to pass opaque strings between a host and the 
> network 
> prior to the host attaching.  Those opaque strings are, essentially,
> the vendor-specific strings currently associated with posture 
> assessment.The standard protocol carrying these strings would 
> connect on the network
> side to a system that has plug-ins which understand the vendor-
> specificstrings.  
> 
> With a charter that clarified that this was intended to assist the end
> systems with vulnerabilities prior to attachment because the
> network they are attaching to might be filled with danger, I 
> think this work would get done reasonably quickly. (As a control
> mechanism to protect the network, I agree with the point made
> clearly by others that this is not appropriate).
> 
> I am less sure of the task of standardizing attributes.
> 
> I am not sure that the number of attributes which can be standardized
> will ever be high enough to be truly useful, and I am pretty sure
> that all of these will be already covered by vendor-specific 
> attributes.Since there must be an assessor in place on the client 
> for those few
> standardized attributes to be assessed and that assessor will 
> likely already
> have these covered by vendor-specific attributes, in other words,
> we seem to be standardizing redundancy.  On the network attachment
> side, it is possible, of course, that an offer of remediation 
> could be made
> based on just the standard attributes, but it seems far more 
> likely that
> it would be a two step process (assess standard attributes, then pass
> vendor-specific attributes to vendor plug-in).  Again, if the vendor's
> attributes cover the standard attributes, then this is largely 
> redundantand may add measurable latency; it seems far more likely 
> that 
> step one would simply be skipped if there were a vendor-specific 
> stringand an available plug-in. Since there has to be an assessor, 
> the first
> seems very likely to me.  If you don't have a vendor's plug-in, then
> I suppose there is some chance that you will trust and act based 
> on the standard
> attributes, but the chance of getting the right remediation seems
> pretty slight in those circumstances.  Especially when many 
> vulnerabilitiesare a combination of conditions, (Browser version 
> Foo on OS patch level Bar) 
> that you could remediate by upgrading either one, checking for and
> acting on the attributes which could be standardized seems of 
> very, very 
> limited utility.

  I think that most function should  be completed through vendor-specific attributes and 
  standard attributes are only basic information.

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 17 Oct 2006 09:30:13 -0400

Ted,

As I understand your concerns expressed below, you are concerned
that standardizing attributes for NEA would be redundant and
pointless: redundant because vendor-specific attributes will
cover the same information in more detail and pointless because
remediation will not be possible given the limited information
available through the standardized attributes. Is that right?

If so, maybe it would help to explain why we want to have
standardized attributes. The goal is to ensure that any NEA
endpoint and server can interoperate in a meaningful manner
without making the assumption that endpoint and server have
the same vendor "plug-ins" installed. For this to be true,
we must ensure that every NEA endpoint provides a basic set
of information to the NEA server. That basic set of information
will be the standardized attributes. If the endpoint and server
both understand vendor-specific attributes that provide more
information, that's great. But we want to ensure a base level
of interoperability.

Yes, remediation may be difficult using only the information
in the standardized attributes. But a captive portal technique
can be used to provide information to the endpoint user about
how to remediate.

Thanks,

Steve

Ted Hardie wrote:
> involved, my sense is that the very core of this work is a perceived 
> need to be able to pass opaque strings between a host and the network 
assessment.
> The standard protocol carrying these strings would connect on the
network
> side to a system that has plug-ins which understand the
vendor-specific
> strings.  
attributes.
> Since there must be an assessor in place on the client for those few
> standardized attributes to be assessed and that assessor will likely
already
> side, it is possible, of course, that an offer of remediation could be
made
> based on just the standard attributes, but it seems far more likely
that
> attributes cover the standard attributes, then this is largely
redundant
> and may add measurable latency; it seems far more likely that 
string
> and an available plug-in. Since there has to be an assessor, the first
> I suppose there is some chance that you will trust and act based on
the standard
> pretty slight in those circumstances.  Especially when many
vulnerabilities
> are a combination of conditions, (Browser version Foo on OS patch
level Bar) 
> acting on the attributes which could be standardized seems of very,
very