RE: PD 0107: IDSSPP v1.4: FPT_STM.1 Must Be Met by the TOE
On Tue, 20 Jul 2004 07:47:19 -0400 (EDT), "Arnold, James L. Jr."
> 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.
To answer the second comment first. The PD was created because there was an OD
on the question, and the answer was felt to apply broader than just the single
evaluation that asked the original question.
As for the question of TOE vs. IT environment requirements. Please note that
is not the question here. You're right: that has been, and is still being,
addressed, elsewhere. Rather, the question is simply what is required to claim
compliance with a particular version of a particular profile.
> 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.
Did the Harris IDS product claim compliance with the particular profile in question?
> 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
> (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).
That's fine and dandy, but that's not the question of the PD. The question in
the PD is whether such a TOE can claim compliance with the IDSSPP v1.4.
> 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?
My understanding is that the issue will be addressed in a future PP, but as
other validations had been given the answer that in order be compliant, the
TOE must provide the timestamps, the same answer was given here. To do
otherwise would have elicited screams from those that had been required to
comply in the past.
I'll note the issue here is ONLY PP compliance, which has real significance
only for DoD Acquisitions that require PP compliance. I think the best
solution to this would be to push for issuing of a revised PP that addresses
the application-style systems better. That's the win-win answer for everyone,
and probably less work.
> 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.
Yup. There are. Sometimes you're on the winning side, and sometimes you're
Date Index |
Thread Index |
Problems or questions? Contact firstname.lastname@example.org