PD-0130: Clarification of Alert requirement in Basic Robustness Anti-Virus PP

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

FAV_ALR_EXP.1.3 requires that "Upon receipt of an audit event from a workstation indicating detection of a virus, the TSF shall display an alert on the screen of the Central Administrator if a session is active. The alert shall identify the workstation originating the audit event, the virus that was detected, and the action taken by the TOE."

Additionally, FAV_ALR_EXP.1.4 states that "The TSF shall continue to display the alerts on the screen of the Central Administrator until they are acknowledged by the Central Administrator, or the Central Administrator session ends."

In the event of an outbreak of virus infection in an enterprise environment, the requirements to generate and continue to display an alert per instance of the virus could generate an enormous number of alerts, thereby incapacitating the anti-virus protection system at the time it is most needed.

Resolution

The following Application note will be added to the FAV_ALR_EXP.1.3 and FAV_ALR_EXP.1.4 elements of the Basic Robustness Anti Virus PP:

Application Note: The deletion of such audit alerts is necessary in some scenarios (e.g. a rampant outbreak of virus infection) to prevent failure due to the enormous number of generated alerts exhausting system or administrator resources. FAV_ALR_EXP.1.4 requires the administrator acknowledge the alerts generated. A large number of alerts requiring acknowledgement, particularly during a short period of time, may prevent the administrator from adequately responding to the overall incident. If deletion of alerts is deemed necessary, the vendor must analyze the different scenarios that could occur in order to derive a comprehensive justification for deleting alerts. The solution must take into account such factors as the type of alerts, whether to delete the oldest or the newest alerts generated, and any other relevant factors based on the scenarios that might occur. PD 0129 provides guidance regarding the acceptable type and amount of audit record deletion.

Application Note: The analysis used to determine which alerts are deleted should be publicly documented in the Security Target and noted in the associated Validation Report.

Support

Deletion of generated alerts is indeed necessary in some cases to prevent system failure. However, although it is acceptable and necessary to delete alerts in some scenarios to prevent the system from becoming unavailable, the particular situation causing the alerts must be considered prior to deletion. For example, if there are duplicates of an alert, as would be the case if the virus-replicating scenario occurs, then deletion of duplicate alerts should occur. Furthermore, there are likely to be situations where the newest alerts should be deleted, rather than the oldest. For example, if one is looking for the root cause of a denial of service attack, it is preferred to know about the first systems that were infected rather than the last ones.

Although it is not explicitly stated in the PP, given these problematic scenarios, it may be necessary to delete alerts to prevent the system from crashing. This necessary mitigation is not in violation of the PP and still upholds the intent of the PP and associated alert requirements, namely FAV_ALR_EXP.1.3 and FAV_ALR_EXP.1.4.

Modification History:

2006-10-30

PD Created. [October 2006 ODRB Agenda Item 3.a.iii]

2007-02-16

PD Updated to remove references to system crashes, and to fix a reference. [February 2007 ODRB Agenda Item 4.d.i]

References:

• Common Criteria for Information Technology Security Evaluation - Part 2: Security functional requirements, August 2005, Version 2.3, CCIMB-2005-08-002
• Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance requirements, August 2005, Version 2.3, CCIMB-2005-08-003

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0254