Subject: [Nea] Status of "due diligence" effort on posture attributes

From: "Susan Thomson (sethomso)" <[email-masked]>
Date: Fri, 14 Nov 2008 17:18:15 -0500

At the last IETF, our AD, Tim Polk, encouraged the WG to put real effort
into ensuring that the set of posture attributes is as complete as
possible prior to standardization of the protocol I-Ds. 

Joel Snyder has volunteered to drive  a "due diligence" effort in this
regard.

In a forthcoming email, he will forward preliminary results of this
effort to the mailing list. The next step is for the editors of the
protocol documents to work with Joel and the working group to analyze
these results and their applicability to the protocol I-Ds. 

Please assist with this effort and respond with feedback regarding both
methodology and content.

Thank you
Susan and Steve
_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea

---

From: Joel Snyder <[email-masked]>
Date: Fri, 14 Nov 2008 19:03:46 -0500

Folks:

At the request of the working group chairs, I investigated a number of 
existing commercial NAC and NAC-like products to see which posture 
attributes were included in these products.  The obvious goal is to see 
if there are some common posture attributes which are present in 
commercial products which are not present in the existing WG drafts.

I want to emphasize that this work is entirely DEscriptive, and not at 
all PREscriptive.  I am only reporting the posture attributes that I 
found; I am not offering any opinion as to which ones should go into the 
IETF documents, and I have no opinion on which ones would violate the 
privacy aspects of the IETF charter in this area.  I'm simply telling 
you what I found.

This task was slightly complicated because the actual set of posture 
attributes is not generally exposed in the products or product 
documentation.  Instead, products generally provide documentation on the 
PDP (policy decision point, to use TNC terminology) policy that operates 
on the posture attributes, rather than the posture attributes themselves.

In the report, I express the results based on the policy that they 
support, rather than a 'guess' of what the actual on-the-wire posture 
attribute might be.

An example of the difference might be instructive.  Most products have 
the ability to verify presence of a particular Microsoft patch (usually 
referred to by a "KB" or "Q" number, or called a "hotfix") on the system 
being posture checked.  Thus, the PDP policy might have a grammar 
similar to:
	"KB12345 is required if OS is Windows 2003 or later"

This policy is what is exposed in the documentation and product 
interfaces that I surveyed, not the actual posture attributes.  What we 
can't tell is whether this policy causes:

	- a specific query to the AR (access requestor, client) to determine 
whether KB12345 is installed
or
	- a query to the AR for all patches installed
or
	- a general transmission from the AR to the PDP of all patches just in 
case the PDP wants to look at them

Thus, the results of this research don't actually reflect the posture 
attribute grammar or syntax as much as they do the elements which can be 
tested in the PDP policy.

With that caveat, I have some preliminary results from an analysis of 
eleven different products from seven different vendors (McAfee, F5, 
Symantec, Cisco, Nortel, SonicWALL, and Nokia).

I have specifically excluded one product from my results, the latest 
version of McAfee's EPO product.  This NAC tool uses the OVAL framework 
to define vulnerability checks.  OVAL, a project being run out of Mitre, 
uses a series of XML data types and definitions to describe system 
characteristics which can be used to infer the presence of very specific 
vulnerabilities in systems.  The OVAL schemas alone include, literally, 
hundreds of pages of documentation.

Rather than try and make sense of this framework and how it might affect 
the IETF WG posture attributes, I chose to put it aside with a specific 
suggestion that it be considered as a  special case framework of its 
own.  Unfortunately, as with all the commercial NAC products I looked 
at, OVAL vulnerabilities are expressed in terms of policies which might 
exist on a PDP of some sort.  While they include a wide variety of 
posture attributes, these attributes are so complex and product-specific 
(for example, there is an OVAL schema element used to decompose three 
sub-pieces of a Cisco Catalyst OS version number, a different element 
for decomposing four pieces of Cisco PIX OS version numbers, and a third 
element that decomposes eight pieces of a Cisco IOS OS version number) 
that they represent a whole new world of posture attributes beyond those 
which are in the existing IETF WG documents.

In the attached list, I have listed attributes or policy elements that 
are all in AT LEAST 2 products from the list I evaluated.  I have 
grouped them, somewhat arbitrarily, into categories and expressed each 
attribute as a query.  In some cases, I have made comments to help in 
understanding the attribute or the context that it is being given in 
existing commercial NAC products.

I apologize for including the attachment as a PDF; if anyone cannot read 
it and would prefer a CSV version for whatever spreadsheet tool they 
use, please let me know and I'll get you a copy.

jms

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One       Phone: +1 520 324 0494
[email-masked]                http://www.opus1.com/jms
_______________________________________________
Nea mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nea