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.
Effective Date: |
2003-05-23 |
Last Modified |
2006-08-02 |
Issue
In the course of using performing an evaluation against the Peripheral
Sharing Switch (PSS) for Human Interface Devices Protection Profile (version
1.0, 8 August 2000), several questions arose:
-
The first section of Section 2, Paragraph 3: "In operation, the TOE
will be CONNECTED to only one computer at a time." This sentence when taken
literally, defeats the purpose of the device. A correctly written PP would not
have statements that require inference that the author meant this in a logical
manner versus a physical requirement statement.
-
The assumption A.PHYSICAL (Section 3.1) and the threat T.PHYSICAL
contradict each other. This is further confusing by the environmental objective
OE.PHYSICAL. NOTE: the whole section of environmental objectives mirrors that
of assumptions and makes the objectives those of the TOW. Additionally, the
lead in paragraph contradicts some of the objectives (e.g., the intro paragraph
states, "These objectives are to be satisfied without imposing technical
requirements
" yet there is OE.EMISSION: "The TOE shall
"
-
The assumption A.ISOLATE (Section 3.1) is a partial assumption of
the Data Separation Flow Policy - any issues regarding this channel and this
SFP are assumed.
-
The assumption A.MANAGE (Section 3.1) along with the assumption
A.NOEVIL, clearly contradict the threat T.INSTALL.
-
The assumption A.SCENARIO appears to contradict T.SPOOF.
-
The threat T.BYPASS can be taken to read that the threat is really a
matter of physical connections - e.g., the TOE is disconnected.
-
The threat T.SPOOF is worded such that it can be taken to mean that
the TOE can determine what is at the end of the physical connection.
-
The security objective O.INVOKE - "Upon switch selection, the TOE is
invoked." - is a ludicrous statement (the first paragraph of Section 2 says
(paraphrasing) "the TOE is the switch" how can a device be invoked.
-
The last statement in O.SELECT - ref. Automatic scanning -
contradicts the TOE description given in Section 2, paragraph 8.
-
The objectives O.NOPROG and O.ROM say basically the same thing -
this is either redundant objectives, or the point of the objectives is
obscured.
-
The SFR FDP_IFF.1-1 (Section 5.1.1.3) is an incorrect assignment.
-
The SFR FMT_MSA.3 (Section 5.1.2.2), obviously used because of the
dependency required by FDP_ITC.1, makes no sense, especially with the
application note. NOTE: if an application note is required, then the
requirement is flawed. The authors should have used an explicitly stated
requirement.
-
The rationale section has numerous logic flaws:
-
It is illogical that O.CONF can counter a physical threat to the
TOE;
-
O.INVOKE states that the TOE must be invoked
This
contradicts the first sentence of the TOE description, Section 2, where it
states that the TOE is a device;
-
It is not clear that O.NOPROG can counter a physical attack to
the TOE - a physical attack can circumvent programmed chips;
-
It is not clear that O.ROM can counter a physical attack to the
TOE - a physical attack can circumvent programmed chips;
-
It is illogical that O.SELECT can counter T.SPOOF;
-
The rationale provided for the Security Requirements Rationale,
Section 6.2 has logic flaws, (e.g., FPT_RVM.1 and FPT_SEP.1) in spite of the
argument that there are "no untrusted processes."
-
There are no SOF claims - ratings or otherwise (requirements).
Resolution
After consulting with the authors of the PP to understand their intent,
the CCEVS has decided upon a way forward for each of these questions. These are
to be used for all future evaluation against this Protection Profile.
-
Page 38 of the PP defines "connected" and "connection" in terms of
logical pathways, rather than the physical pathways that, we agree, would make
no sense in the context of this TOE. Given these definitions, there is nothing
in need of correction in the PP.
-
There seems to be a misunderstanding about the interrelationships
among threats and assumptions, undoubtedly due the lack of clarity in the CC.
The following explanation is therefore provided:
Threats may be two types: those to be addressed by the TOE (either
completely or partially), or those to be addressed by the environment. These
are the topic of ASE_ENV1.2C. (In theory, there might be a third type of threat
- residual threats not expected to be addressed at all - but for the purposes
of a TOE evaluation, these would be included as threats to be addressed by the
environment.)
Assumptions might also be of two types: assumptions made about the
TOE, and assumptions made by the TOE (about its environment). The CC does not
make any such distinction, but PP and ST writers often do.
Objectives are divided by the CC into those for the TOE and those
for the environment. Environment objectives are acknowledged, but then they are
not used again in the CC. The TOE objectives, on the other hand, are used as
the basis for the Security Requirements: meeting the objectives is the goal of
the selected requirements (i.e., if all of the requirements are met, then all
of the objectives will be met.)
Objectives for the TOE are derived directly from OSPs (which state
what the TOE must do), and indirectly from the Threats to be addressed by the
TOE (in terms of providing what the TOE must protect against).
It is worth pointing out that, although they are not mentioned
again, the Objectives for the environment are derived not only from the Threats
to be addressed by the environment (as one would expect), but also from the
Assumptions made by the TOE on its environment. The TOE's assumption of the
presence of something in its environment implies that there is an implicit
objective on that environment.
As was said earlier, a lot of the confusion comes about because the
CC provides no guidance on how Threats, Objectives, Assumptions, or OSPs are to
be written (any one of them could be recast into the form of any other one).
Likewise there is no guidance on what constitutes a good or worthwhile
assumption, etc. The result of this lack of guidance is that sometimes a PP
writer can create an assumption made by the TOE, which corresponds to a threat
to be countered by the environment. Sometimes (e.g., a threat that users will
gain access to the underlying environment without being authenticated and an
assumption that the environment will provide all necessary user
authentication), such a combination results in an objective for the environment
(i.e., the environment must authenticate all of its users). Other times,
however, the assumption made by the TOE and the corresponding threat to be
countered by the environment cancel out each other (e.g., an assumption that
the TOE will be physically protected and a threat that unauthorized physical
access can corrupt the TOE). In such cases, there would be no resulting
objectives for the environment; the threat and assumption could both be deleted
and nothing else would change. While there is nothing erroneous in including
both of them, it does lead to potential confusion and misunderstanding.
-
The wording of A.ISOLATE ("Only the selected computer's video
channel will be visible on the shared monitor") is not appropriate for an
assumption. It is written more like an Objective statement or an OSP. This
should be clarified in an update to the PP. However, the PP needs not be
corrected in order for it to be used in an evaluation.
-
As was discussed in issue 2, the situation is not one of
contradiction, but rather a case where the two assumptions mitigate the
expressed threat. This should be clarified in an update to the PP. However, the
PP needs not be corrected in order for it to be used in an evaluation.
-
As was discussed in issue 2, the situation is not one of
contradiction, but rather a case where the assumption mitigates the expressed
threat; both could be omitted from the ST and deleted from the PP with no
residual effect. This should be clarified in an update to the PP. However, the
PP needs not be corrected in order for it to be used in an evaluation.
-
This is an example of a threat to be addressed by the environment:
if the environment is not set up correctly, the TOE might be excluded from the
whole picture; this is not a concern for the TOE. This should be clarified in
an update to the PP. However, the PP needs not be corrected in order for it to
be used in an evaluation.
-
T.SPOOF ("Via intentional or unintentional actions, a user may think
the set of shared peripherals are connected to one computer when in fact they
are connected to a different one") is a threat to be addressed by the
environment. As was discussed under issue 2, it is acceptable to include such
threats, despite the fact that the TOE will not be completely addressing them.
This should be clarified in an update to the PP. However, the PP needs not be
corrected in order for it to be used in an evaluation.
-
This Objective statement ("Upon switch selection, the TOE is
invoked") is poorly worded. It should be understood as, "Upon switch selection,
the indicated output port will be the only connection from the input port". The
PP authors make a distinction between the TOE and the physical switch, which
(along with the indicator lights, etc.) is a part of the TOE. The path to the
device (i.e., the connection) is what is invoked by the physical switch.
-
The general description of switches on page 6 should include a note
that says which of the possibilities just outlined are outside the scope of the
PP. However, the statement in O.SELECT makes it clear that automatic scanning
is such a case. This should be clarified in an update to the PP. However, the
PP needs not be corrected in order for it to be used in an evaluation.
-
These two Objective statements seem to say the same thing. They even
map to the same set of requirements, but the differences depend upon the TOE
implementation. O.NOPROG applies to TOEs that use programmable logic arrays or
hardware-only TOEs; O.ROM applies to TOEs with microprocessors. The difference
between these two objectives can be clarified in a future version of this PP.
-
The explanations in parenthesis indicate which parts of the
assignments are being fulfilled. A clearer articulation of the rules being
enforced can be found in FDP_IFC.1. The rules that the PP authors are conveying
are:
The TOE shall enforce a transmission flow with the following
properties:
-
Data shall flow only between the input port and the indicated
output port.
-
There shall be sufficient electrical and physical isolation
between the multiple output ports to ensure that only the indicated output port
is connected to the input port.
-
FMT_MSA.3 makes sense in a software implementation because PPs
should be implementation independent. The authors could not presume that the
TOE would be a hardware-only solution therefore, the application note was
provided.
-
The relationship between threats and objectives is being
misunderstood here; these are cases of threats to be countered by the
environment being mapped to Objectives for the TOE (see Issue 2).
-
The objective for confidentiality will not completely counter
the physical threat; if the physical threat is realized, then the output ports
could be tied together thereby breaking confidentiality.
-
O.NOPROG and O.ROM (see also issue 10) are likewise objectives
that will not be completely met if the physical security threat is realized.
The environmental threat of T.SPOOF is not addressed by the TOE objective
O.SELECT. It is useful to note how the TOE contributes towards mitigating the
threats.
-
The O.INVOKE problems cited (the contradiction with the TOE
description and the mapping to FPT_RVM) result from the unclear objective
statement (see Issue 8).
-
As for the comment on the mapping of FPT_SEP and O.NOPROG/O.ROM:
the need for the separation requirement seems to be a straightforward
consequence of objectives dealing with protecting the logic from unauthorized
modification.
-
The rationale section currently is sufficient.
-
PD-0048 (dated July 17, 2000) notes that when there are no
permutational or combinational mechanisms, AVA_SOF.1 is satisfied vacuously.
(This is relevant only when an EAL is being claimed, because SOF is included in
EALs.) Section 6.2 of the PP explicitly states no SOF claim is being made.
However, if the ST would like to make an SOF claim (although it's not clear on
what mechanisms this claim would be made), there is nothing to prohibit them
from doing so and thereby exceed the PP.
Modification History:
- 2004-08-12
- Updated effective date to reflect the date the PD was issued.
(August 2004 NIB 6.c.xiv)
References:
Related NIs:
Related CCIMB-INTERPs:
Source OD: 0209
|