PD-0154: Time Changes

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

Both VPN and Traffic-Filter PPs include FPT_STM.1 as follows.

FPT_STM.1.1 - The TSF shall be able to provide reliable time stamps for its own use.

Consider a product that records time stamps using an internal system clock that tracks the number of clock ticks since the device booted. It is not a calendar clock and is not modifiable by an administrator. This approach also ensures that audit entries remain in their original order regardless of any alteration of the system clock. When audit entries are displayed, the clock tick time stamp associated with each audit entry is converted to calendar time for usability, but the calendar time is never stored in the audit entry, nor is the time stamp ever modified after it is recorded. Changing the system calendar clock (which is restricted to administrators) does not alter the time stamp associated with an audit entry, because each audit entry is stamped with the number of clock ticks since boot. When the calendar time is changed from an incorrect to a correct value, the calendar time displayed for an audit entry is also displayed correctly.

Such an approach would appear to keep the order of audit events correct in the case of an incorrectly set system clock, and would appear to be a better way to address the rationale provided in both PPs to describe how FPT_STM.1 addresses the objective (O.TIME_STAMP) it is mapped to in section 6.3. The rationale is as follows:

"FPT_STM.1 requires that the TOE be able to provide reliable time stamps for its own use and therefore, partially satisfies this objective. Time stamps include date and time and are reliable in that they are always available to the TOE, and the clock must be monotonically increasing."

It appears that the common approach of using calendar time stamps violates the requirement for a monotonically increasing clock, because the administrator can change the clock and thus (at least from the point of view of what is recorded in the audit log) turn back time.

So would such an approach (i.e., recording time as the number of clock ticks since boot) be acceptable for FPT_STM?

Resolution

The fact that the TOE's audit mechanism has a reliable time source that uses a monotonically increasing clock ensures that the FPT_STM.1 and FPT_STM.1.1 are met and the TSF shall be able to provide reliable time stamps. The administrator's change of the system calendar clock should not obstruct this ability as long as the system clock change is a captured audit event that is clearly stated in the audit log. Furthermore, if the system requires a reboot then a mechanism should be in place that allows for the reconstruction of the sequence of audit events. That is, the boot should be recorded as an event in the audit log with a time-of-day included. If the above conditions are met, recording time as the number of clock ticks since boot is an acceptable method for recording time stamps in the audit log. Past precedent also supports this determination.

Support

Both the U.S. Government Traffic-filter Firewall Protection Profile for Medium Robustness, and the U.S. Government Virtual Private Network (VPN) Boundary Gateway Protection Profile for Medium Robustness had the following requirements:

TOE Security Objective: O.TIMESTAMPS

O.TIME_STAMPS: The TOE shall provide reliable time stamps and the capability for the administrator to set the time used for these time stamps.

Requirements Addressing the Objective: FPT_STM.1 and FMT_MTD.1 (3)

FPT_STM.1 requires that the TOE be able to provide reliable time stamps for its own use and therefore, partially satisfies this objective. Time stamps include date and time and are reliable in that they are always available to the TOE, and the clock must be monotonically increasing.

FMT_MTD.1(3) satisfies the rest of this objective by providing the capability to set the time used for generating time stamps to either the Security Administrator, authorized IT entity, or both, depending on the selection made by the ST author. The authorized IT entity was included as an option for the possible use of an NTP server to set the TOE's time.

However, the issue is larger than just these profiles; it equally applies to FPT_STM in general, for the purpose of the audit log is to ensure that an independent party can reconstruct the sequence of security relevant events if necessary. This requirement is outlined in DODI 8500.2:

DODI 8500.2, February 6, 2003 - 5.7.9.3.: Collect and retain audit data to support technical analysis relating to misuse, penetration reconstruction, or other investigations, and provide this data to appropriate law enforcement or other investigating agencies.

Note that there are equivalent goals in NIST 800-53 Rev 3.

Modification History:

2010-01-27

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

References:

• U.S. Government Virtual Private Network (VPN) Boundary Gateway Protection Profile For Medium Robustness Environments, Version 1.1, July 25, 2007.
• U.S. Government Traffic-Filter Firewall Protection Profile For Medium Robustness Environments, Version 1.1, July 25, 2007.

Related NIs:

• None

Related CCIMB-INTERPs:

• None

Source OD: 0285