Re: PD 0130:Clarification of Alert requirement in Basic Robustness

["Observation Decisions Review Board" <faigin@aero.org>]

In response to an email received on PD 0130, the ODRB would like to
respond with a modification to PD 0130 and a clarification of an aspect
of the issue being addressed.

PD 0130 addresses administrator notification of impending exhaustion of
audit storage capacity.  There are several references to excessive
alerts resulting in system crashes; these will be revised to reflect
reduced availability as a more realistic outcome.

The difficulty being addressed by the deletion or normalization of
administrator alerts is the requirement in FAV_ALR_EXP.1.4 of the BR AV
PP that alerts be acknowledged by the administrator.  Without
normalization or deletion of largely duplicate alerts, this would
potentially require the administrator to acknowledge enormous numbers of
alerts.

Lastly, a reference to OD 0253 has been corrected.

The revised PD 0130 is as follows: 

PD 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[Deleted: ". Therefore, enforcement of these requirements would likely
result in the sudden failure (crash) of the operating system on the
computer that acts as the server component of the ant-virus software"],
thereby incapacitating the anti-virus protection system at the time it
is most needed. 

PD 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 [deleted: "sudden system"] failure due to the enormous
    number of generated alerts exhausting system [added: "or
    administrator "]resources. [added: "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 [deleted: "0253"][added: "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.

PD SUPPORT

Deletion of generated alerts is indeed necessary in some cases to
prevent [deleted: "sudden "]system failure. However, although it is
acceptable and necessary to delete alerts in some scenarios to prevent
the system from [added: "becoming unavailable"][deleted: "crashing"],
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[deleted:" in order to prevent the server
from crashing"]. 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.

PD 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]