PD-0153: Automatic Update Mechanisms

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Issue

Many products, including IDS, IPS, and anti-viral products, provide an automatic update facility. These updates are downloaded regularly from a centrally-controlled site trusted by the system operator (such as the vendor's site or a central agency site).

These updates not only have the ability to update signatures but may also have the ability to update scanning engines, processing capabilities, or deliver patches.

The issue is when such updating mechanisms may be incorporated into a validated product. This is significant because the validated product paradigm is different than the signature update paradigm: the validated product paradigm assumes a standard code base that doesn't change without revalidation. But receiving such regular updates is important: they allow the products to keep up to date with current threats, allow incremental improvements in scanning engines, and allow corrections of vulnerabilities.

The issue is whether there is a way to permit such updates within the bounds of the validation paradigm.

Resolution

Automatic updates can be divided into two categories: updates to static signature files and updates to processing algorithms. The latter category would include both updates to scanning engines, as well as downloaded patch updates.

If the update mechanism can be limited to updates of static signature files only (such as virus signatures or intrusion detection pattern signatures), such files may be updated without triggering the assurance maintenance process. The evaluation/validation team must examine the life-cycle of the update process to ensure that the vendor process adequately tests the TOE with the new signature file before release, that the design of the update mechanism restricts the updates to the signature files only, and that the update mechanism has provisions to ensure the authenticity and integrity of downloaded signature files.

With respect to updates to processing algorithms, including scanning engine updates and downloaded patches, the ultimate resolution to the issue touches on areas of reciprocity and mutual recognition, as well as the full assurance continuity process. As such, CCEVS will be developing a more formal policy for coordination, and will consider such update mechanisms on a case-by-case basis. When building a case for consideration by CCEVS, please provide the following information:

• The types of updates that are possible through the mechanism, including any limitations to the process.

• The amount of new executable code introduced into the product, how it integrates with the existing code, and under what limitations it executes.

• The interaction of the update mechanism with the CM mechanism: the interaction of such updates with product version numbers, the review that such updates receive before release to production, and the forms of testing that such updates receive.

• The mechanism used to ensure the authenticity and integrity of such updates, and how the process is designed to prevent introduction of malicious code.

Support

Simple signature updates are essentially updates to an operational database. These types of updates have one way of introducing vulnerabilities: omission of an applicable malware signature. It should not be possible to alter how the scan engine operates, who gets alerts, or what is logged. Signature updates are unlikely to alter the configuration or operation of the security controls of the system. Patches, updates to the scanning engine and major code updates have the potential to alter TSF behavior, and need to be reviewed before application in a certified configuration.

Modification History:

2010-01-27

PD Created. (November 2009 ODRB Meeting Agenda Item 3.a.i)

References:

• None

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0283