Brian,
I'm a little bit lost: what is the status for this Canon
comment (making NVS applicable only to TSF Data in OpEnv B)?
Based on the email exchange and comments resolution
document, I thought that in OpEnvB P2600.2 we are going have the same
approach for FTP_CIP_EXP.1 and FTP_ITC.1 .
As in OpEnvB we have:
FTP_ITC.1.3 The TSF shall initiate communication via the
trusted channel for communication of D.PROT and D.CONF over any Shared-medium
Interface.
I thought that we are going to have something
like
FTP_CIP_EXP.1.2 The TSF shall provide a function that
[selection: prevents, detects and performs [assignment: list of actions] when it
detects] alteration of TSF data written to a Removable Nonvolatile Storage
device.
When reviewing
http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.2-39b.pdf
I see:
FTP_CIP_EXP.1.2 The TSF shall provide a function that
[selection: prevents, detects and performs [assignment: list of actions]
when it detects] alteration of user and TSF data when either are written to a Removable
Nonvolatile Storage device.
To summarize, my question is:
1)
are we going to implement the
comment later during
re-circulation
2)
are we going to re-consider the
?accept in principle? status
3)
something else
Thanks in advance,
Best
regards,
_________________________________________________________
Carmen AUBRY,
GSNA, CISSP
Oce
Print Logic Technologies S.A. -R&D -http://www.oce.com
Phone: +33 (0)1 48
98 80 22 - Fax: +33 (0)1 48 98 54 50
1, rue Jean Lemoine - BP
113 - 94015 Créteil Cedex -
FRANCE
_________________________________________________________
Lee,
No problem, I don't think that my original message was
very clear.
The objectives (e.g., O.CONF.NO_DIS...) are part of the
common PP. Requirements (e.g., FTP_FDI.EXP.1) implement those objectives, and
while some of those requirements are in the common PP, others are part of the
option-specific packages like SMI and NVS.
The question that came up in
the WG meeting was that the SFR for protecting data in NVS required protection
for user and TSF data, and the same SFR was used in both OpEnv A and OpEnv B.
That seemed inconsistent with the view that we've had for a long time, which is
that protection of user data in motion is not required for OpEnv B. The problem
is that the SFR we're using in the SMI package (FTP_ITC) doesn't distinguish
between user and TSF data. Well, the same problem exists with the SFR that we're
using in the NVS package (FTP_FDI_EXP).
We can change the SFR in the NVS
package, because it is an SFR that we defined outside of CCpart2. However, we
can't change the SFR in the SMI package, because it is an SFR that is defined by
CCpart2 and there is no option to refine that part of the SFR.
So, if we
leave FTP_FDI_EXP as it is, it is consistent with FTP_ITC, but in OpEnvB, both
SFRs require more than the objectives that they fulfill.
I hope this
makes more sense...
--
Regards,
Brian Smithson
Project Manager, Security Research
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435
Farrell, Lee wrote:
Sorry Brian, maybe I misunderstood the point of this
thread. I thought you requested us to "Please consider whether you think it is important to restrict the NVS
protection requirement in OpEnv B to apply only to TSF
Data."
It was my impression that the people at the WG
meeting thought it was important, based on the discussion and agreement that
took place at that time. In response to your request, I'm only conveying that
the folks at Canon also think it is important.
I'm also a bit lost at
your logic that claims it's "consistent" to have the NVS package require
protection for *both* TSF data and user data, but the objective only
requires protection for the TSF data. Why again do you think that is
consistent?
lee
Lee,
I understand the issue of
consistency, and I can't think of a good rationale for having different
objectives for data in motion on a network versus data in motion on a
fleeing disk drive. So I agree that the objectives should remain the same
(i.e. unchanged in the PP): User and TSF data are protected in OpEnv A, but
only TSF data are protected in OpEnv B.
However, the issue is whether
an SFR in the NVS package should reflect the difference between OpEnv A and
OpEnv B.
The SFR in the SMI package (for data in motion on a network)
is FTP_ITC, and that SFR does not make a distinction between user data and
TSF data. It's a standard CCpart2 SFR. So even in OpEnv B, we are requiring
a trusted path that provides confidentiality and integrity for both kinds of
data in the SMI package, even though there is only an objective for TSF
data. Therefore, I think it's consistent in the NVS package for our extended
component to require protection for both kinds of data even if the objective
that it is fulfilling only requires protection for one of those kinds.
Does that help?
--
Regards,
Brian Smithson
Project Manager, Security Research
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies
Ricoh Americas Corporation
(408)346-4435
Farrell, Lee wrote:
Hi Brian,
Just as a matter of consistency, Canon prefers to restrict the NVS
requirement in PP-B to apply *only* to TSF Data as agreed by the WG.
Because the SMI requirement already differentiates the treatment of User
Data between PP-A and PP-B, it's not clear that there is any good reason
not to require User Data protection on SMI -- but to require it on NVS.
lee
-----Original Message-----
From: Brian Smithson [mailto:brian.smithson@xxxxxxxxxxxxx]
Sent: Friday, September 12, 2008 3:53 PM
To: STDS-2600@xxxxxxxxxxxxxxxxx
Subject: [2600] a small problem with one of the comment
resolutions from Arlington
This is a comment and resolution for P2600.2:
Cl 17 SC 17 P 46 L 1 56
Comment Type TR
Comment Status A
Response Status C
Farrell, Lee Individual
Comment:
The NVS SFR Package is unnecessary. It is redundant with the
requirements set out by
A.ACCESS.MANAGED and OE.PHYSICAL.MANAGED--which
collectively address any
threat scenario identified for "Confidentiality and Integrity of
Stored Data". Because the
NVS device is assumed to be under adequate physical security that
prevents unauthorized
individuals access to the physical components of the TOE *and* the
NVS device is
considered a physical components of the TOE, the necessary
protection is already covered
without the need for additional SFRs.
Suggested Remedy:
Remove the NVS SFR Package.
Response:
ACCEPT IN PRINCIPLE.
After significant discussion and a straw poll, the WG decided to
leave the NVS package in
the PP. If during the evaluation process, significant issues arise
with this package that can
be only solved by the removing the package we will reconsider this
decision. (straw poll
results 11-2-1)
However, to be consistent with how TSF and User Data is protected
over the network, the
group decided to leave in the NVS SFR package but make it only
applicable to TSF Data
stored on removable non-volatile storage.
There is a problem with making NVS applicable only to TSF
Data in OpEnv B:
As written, the extended component FTP_CIP_EXP.1 applies to
user data and TSF data "when either are written" to NVS. To
make it apply to both user and TSF data in OpEnv A, and only
to TSF data in OpEnv B, I could put a selection statement in
the extended component definition and then refine it to apply
to both in OpEnv A and only to TSF data in OpEnv B.
The problem is then that a previous clarification ("when either are
written") would not make sense if preceded only by "TSF
data". It only makes sense if preceded by "user data and TSF data".
There are some other ways that this could be handled, but in
general, implementation of this resolution is more complex
than I think we anticipated it would be. Since this
resolution was an afterthought that does not address the
original comment, I am leaving it unimplemented in draft 39a.
Please consider whether you think it is important to restrict
the NVS protection requirement in OpEnv B to apply only to
TSF Data. If it is important, let's discuss over email and
submit a proposed change during recirculation.
--
Regards,
Brian Smithson
Project Manager, Security Research
PMP, SSCP, CISSP, CISA, ISO 27000 PA
Advanced Imaging and Network Technologies Ricoh Americas Corporation
(408)346-4435
This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message.
Thank you for your co-operation.
|