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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]