PD-0147: CCEVS Policy #15 Applicability to Flash Drives

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

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.

Support

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.

Modification History:

2009-01-29:

PD issued. (December 2008 ODRB Agenda Item 3.a.vii)

References:

• None

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0279