> 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 mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
