 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
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 jms at Opus1.COM http://www.opus1.com/jms
Attachment:
IETF-Posture-Attributes-Research.pdf
Description: Adobe PDF document
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 jms at Opus1.COM http://www.opus1.com/jms
Attachment:
IETF-Posture-Attributes-Research.pdf
Description: Adobe PDF document
_______________________________________________ Nea mailing list Nea at ietf.org https://www.ietf.org/mailman/listinfo/nea