To bound the scope of testing, and to make it more relevant to USG needs, we limit our list to attacks on vulnerabilities which are (a) relatively recent (within the last two years), (b) found in systems commonly deployed in government networks, (c) capable of being exploited over IPv6 networks, and (d) for which actual exploits are known to exist. Specifically, we select the following vulnerabilities from the National Vulnerability Database:
To keep the list of vulnerabilities current, it is regenerated every six months, beginning May 1, 2010. After generation, it is then open for review and editing for a one month period, becoming valid for testing at the end of that period. The following are the vulnerability lists generated to date:
|List generated||Valid from||Valid to|
|May 1, 2010||June 1, 2010||Jan 12, 2010|
|Dec 13, 2010||Jan 13, 2011||May 31, 2011|
Note that these are lists of all vulnerabilities meeting the criteria above which are theoretically exploitable over an IPv6 network. However, for many of them, no known exploits may as yet exist. Only those with known attack vectors will be used for IDS/IPS testing.
Hence, some sophistication in the testing procedures is required. On the other hand, it is to be expected that testing will be automated to the extent possible. Typically, attack traffic is generated (using exploit tools and the like) once, recorded, and then replayed (with possible minor modifications) when testing each system. While a testing lab would of course strive to make the pre-recorded traffic look as much like a live attack as possible, it may happen in some instances that a sophisticated IDS/IPS could differentiate the replay of recorded traffic from an actual attack, and not react in the case of the former.
This is a special case of a type of concern about the validity of testing that seems more likely to arise in the context of testing NPDs, with the greater complexities involved, than in other areas. As with all such concerns, they will have to be resolved on a case-by-case basis between the testing lab and the vendor. Where an actual issue with the validity of a test exists, the testing lab may need to use another approach, such as a live exploit test against a vulnerable system, in place of the automated test. For efficiency of testing, it is to be hoped that few such cases will exist.
In simple network setups, where for example a single combined firewall/IPS sits between the protected network and the outside world, obviously a system with this capability is required. However, in more complex setups, where the IDS/IPS is only one of several systems in the border to the outside, such a capability may not be relevant. IDS/IPS systems intended for the latter environment often offer other desirable features, such as the ability to coordinate with other network protection and monitoring devices, which are not covered by the requirements in the USGv6 profile. Hence, in some environments, the latter may be preferred, even with the lack of malformed packet detection.
Given this disparity in potential deployment scenarios and needs, in future versions of the profile, malformed packet detection/prevention will be factored out as a separate configuration option, which may be applicable to either firewalls or IDS/IPS systems. A secure IPv6 deployment should have this capability present somewhere, but the possible locations can vary with the specifics of the deployment.
In the near term, since 126.96.36.199.2 is not yet factored out as an option in the current profile, all IDS/IPS testing and vendor SDOCs coordinated with this version of the profile must of course report the presence or absence of this feature. But given that this will be made a separate configuration option in the future, this may be reported in a fashion essentially equivalent to that for the presence/absence of other configuration options - e.g., that the device passes all the requirements for IPS except 188.8.131.52.2, or that it passes all the requirements for IPS including 184.108.40.206.2. Government agencies may then, in their procurements, decide whether the 220.127.116.11.2 capability is needed in their environment.
While similar detailed reporting could theoretically be done on the presence or absence of other features, in practice this is unlikely to be useful; all the other requirements seem too integral to the nature of an IDS/IPS for their absence to be tolerable in any real deployment scenario.
Reflecting this, we anticipate that future versions of the profile will split the current "application firewall" category into a set of configuration options - web gateway, mail gateway, and possibly others.
Point Of Contact:
Last update: Mon Dec 13 2010.