PD 0147: CCEVS Policy #15 Applicability to Flash Drives

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

During its December 2008 meeting, the ODRB developed the following PD
based on a recent OD. Comments on this PD are welcomed and will be
considered at the next ODRB meeting. 

TITLE

CCEVS Policy #15 Applicability to Flash Drives

ISSUE

CCEVS Policy #15 requires that TOEs must generate audit records for
security events.  The march of technology has enabled some devices that
are normally thought of as being rather simple to have significant
processing power.  Since it would be *possible* for such devices to
generate audit records the question becomes: should they be required to? 

RESOLUTION

This question will need to be resolved on a case-by-case basis using the
following criteria: 

1. Is the device making any security decisions?
2. Does the device have enough information to generate meaningful audit
   records? 
3. Of what use would the generated audit records be?

To take a simple example:  if the device requires a password (and not a
user ID) in order to use the device, would that functionality trigger
the audit requirement?  In the strictest sense the device is making a
decision.  It could generate an audit record containing a count of
failed password attempts before a success.  An administrator, in
reviewing the audit log, could notice that there was a failed password
attempt on the device.  Is any of that meaningful or useful?  The device
is not identifying any user so any authentication capability is very
weak.  The audit record will show an administrator some number of failed
attempts with timestamps and device identification.  Without any kind of
user identification mentioned therein the admin is left to look at other
sources. 

These "other sources" would include the rest of the audit log.  If
auditing is enabled on the system it should show every device coming
online with failed access attempts - and user ID.  This is far more
useful than what the device itself will generate.   

To summarize: The following conditions must hold for Policy #15 to
apply: 

1. The device must make some kind of security decisions as defined in
   FDP_ACC.1. 
2. Any audit records generated must include the audit data listed in
   FAU_GEN.1.2. 


RATIONALE

As computing power becomes smaller, more powerful, and cheaper, we move
ever closer toward realizing the paradigm of "ubiquitous computing".  As
we do so we confront computer security situations in ever more
challenging circumstances 

The Audit Requirement of Policy #15 states:

   Every TOE must provide the capability to generate audit records for
   all security events associated with security relevant actions whose
   result depends upon user input, or that are the result of an access
   decision made by the TOE. 

Unspoken in policy is some idea that the audit data recorded must
actually be useful.  A small device with limited functionality and
especially limited knowledge of user identity, time-of-day, and
environment in general is unlikely to be able to generate audit records
of any great utility. 

Decision-making capability is also at issue.  Without user identity, a
security policy, or any concept of subject and object, the device is not
going to make very informed decisions.