RE: PD 0107: IDSSPP v1.4: FPT_STM.1 Must Be Met by the TOE

["Arnold, James L. Jr." <JAMES.L.ARNOLD.JR@saic.com>]

I think I have previously presented position on TOE vs. IT environment
requirements and conformance therewith. But I don't really understand why a
PD like this would be created.

First, there are other Schemes that apparently disagree with this position.
For example, the Harris IDS product was evaluated in the U.K. and seems to
rely on the OS for time and other supporting functions.

Second, while it seems that an application cannot provide time stamps
unaided by hardware, there are numerous examples where TOEs rely in varying
degrees upon the support of their IT environments. While an application TOE
might query a time value from an OS for its own use, it is not the case that
the TOE plays no role in the implementation of FPT_STM.1. Hence, I believe
that the TOE should get credit for FPT_STM.1 provided that the required
support is clearly identified and the mechanism is accurately described and
the mechanism is subject to testing and other applicable assurance
requirements
(i.e., it is evaluated). Alternately, a TOE should not get credit if it
doesn't play a part (e.g., it doesn't collect and affix time stamps to its
own audit records).

Third, I thought there was consideration being given to interpreting PPs and
I also thought PP conformance decisions were based on PP owner intentions.
Hence, given that the PP owner has evidently acknowledged a problem (and the
current PP clearly indicates it is intended for broad application) and
intends to change it, why is the current PP not simply interpreted to
resolve the problem?

Fourth, on the topic of fairness. I think I'll exercise restraint here,
except to say there are plenty of unfair things in this business.



> -----Original Message-----
> From: cc-cmt@nist.gov [mailto:cc-cmt@nist.gov] On Behalf Of 
> Observation Decisions Review Board
> Sent: Monday, July 19, 2004 1:36 PM
> To: Multiple recipients of list
> Subject: PD 0107: IDSSPP v1.4: FPT_STM.1 Must Be Met by the TOE
> 
> 
> The ODRB is in the process of issuing the following PD. 
> Please give this PD a few days to propagate to the CCEVS website.
> 
> ISSUE:
> 
> The Intrusion Detection System System Protection Profile 
> (IDSSPP) includes
> FPT_STM.1 on the TOE. As such, compliance cannot be claimed 
> for TOEs that obtain their time information from an external 
> source, such as an underlying operating system in the IT 
> environment (in the case of an application) or a network time signal.
> 
> The text of the PP claims to be "generally applicable to 
> products regardless of whether they are embedded, 
> stand-alone, centralized, or distributed" [last paragraph, 
> section 1.3].Yet as noted above, the placement of FPT_STM.1 
> contradicts this statement. To eliminate this inconsistency, 
> is it acceptable to move the FPT_STM.1 requirement to IT 
> Environment and still claim PP Compliance?
> 
> STATEMENT:
> 
> In the IDSSPP, Version 1.4, the TOE must provide reliable 
> time stamps. 
> Compliance with the cited PP cannot be claimed if the IT 
> environment is providing the reliable time stamps.
> 
> SUPPORT:
> 
> Although from a purely technical standpoint and in the 
> absence of any PP concerns, one could reasonably imagine a 
> scenario whereby the timestamp is provided by the IT 
> environment. Such an approach is no less sound than requiring 
> the TOE to provide the timestamps. However, when the question 
> of PP compliance comes into play, one must look at the intent 
> of the PP author and how compliance with the profile in 
> question has been enforced in the past.
> 
> In the case of the IDSSPP v1.4, the PP owner is aware of the 
> confusion caused in the past by the IDS family of PPs; future 
> versions of the IDSSPP will support a broader range of 
> implementations, including ones that obtain reliable 
> timestamps from the IT environment. Yet the precedent for the 
> IDSPP v1.4 has been to enforce the words as written; i.e., it 
> is the TOE's responsibility to provide the timestamps. It 
> would be unfair to those IDS developers who complied with the 
> more restrictive requirements to loosen those requirements 
> now. Thus, CCEVS will uphold the existing precedent for 
> products claiming compliance with this version (1.4) of the IDSSPP.
> 
> 
> 
>