Hirota-san,
This is my understanding, which I hope is correct:
The SFPs specify the minimum access control capability that must be
available in a conforming TOE. For example, the data access control SFP
requires that the TOE must be capable of denying document access to any
normal user except for the owner of the document. Similarly, the
function access control SFP requires that the TOE must be capable of
denying function access to any user who is not
identified/authenticated/authorized.
FMT_MSA allows an authorized person to change the default rules. For
example, an administrator may want to disable secure/locked/PIN
printing. Similarly, an administrator may want to allow anonymous users
to perform the Copy function.
If an administrator removes the restrictions that are specified in the
SFPs, that is OK. That is a customer decision or site policy matter.
However, the TOE must be capable of being configured to restrict access
as specified in the SFPs. That is what is being evaluated and certified.
--
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
HIROTA Satoshi wrote:
Hi Brian,
I prefer "PROPOSED SFP TABLES AND APP NOTES", because Access Control SFP
to D.DOC and D.FUNC should exist together in each package.
And more I indicate another point.
Now Access Control SFP is defined as DEFAULT DENY RULE like "Denied,
except for his/her own documents".
But FMT_MSA.3.2 says that "The TSF shall allow the [assignment: the
authorized identified roles] to specify alternative initial values to override the default values when an object or information is created."
DENY RULE may conflict FMT_MSA.3.2 at this PP.
DEFAULT RULE of Access Control SFP could be changed by the Administrator,
depending on the customer operation.
Access Control SFP may not need to be defined in detail in the PP, like TOE
Function Access Control SFP are not.
How do you think ?
Thanks.
S.Hirota
On Fri, 14 Nov 2008 13:56:25 -0800
Brian Smithson <brian.smithson@xxxxxxxxxxxxx> wrote:
Carmen,
(Again, I hope you don't mind that I cc'd the P2600 mailing list)
I agree that replicating the common access control rules among the
packages would multiply the places where those rules must be evaluated.
I don't think that there would be any multiplication of SFRs, however.
The Common PP would still have the same SFRs that it does now, but they
would no longer refer to an SFP table, but instead they would refer to
an SFP that is composed of a set of SFRs (like FDP_ACC.1(b) does now).
The various dependencies would be satisfied in the Common PP and would
not need to be replicated in the packages. The packages would only need
to contain the SFRs that are needed to identify the SFP table in each
package, and the effected packages already have those SFRs. For example,
the PRT package has FDP_ACC.1 and FDP_ACF.1. FDP_ACF.1 depends on
FMT_MSA.3, but it is satisfied by the Common PP and so it does not need
to be included in the PRT package. All of that would remain the same.
But your first point, evaluating common access rules redundantly for
each package, is a valid point and worth considering.
--
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
Aubry, Carmen wrote:
Brian,
I don't think that with this re-organization it is easier to understand. I prefer the current version (with the rules in the common PP). Depending on print mailbox implementation, it is more simple to have these access control requirements in the common PP: no longer required to multiply the places where the access control rules are evaluated (for the same feature, the same access control rule will need to be instantiated once for Print and then again for DSR).
Furthermore, the CC evaluation with this re-organization will be more painful because we are going to multiply the places where these SFRs are evaluated. And if we are going to move the SFRs we will move also the dependencies... If I remember correctly, at the beginning the access control rules were spread in packages and NIAP (and ATSEC) advised against.
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騁eil Cedex - FRANCE
_________________________________________________________
-----Original Message-----
From: Brian Smithson [mailto:brian.smithson@xxxxxxxxxxxxx]
Sent: Thursday, November 13, 2008 10:26 PM
To: STDS-2600@xxxxxxxxxxxxxxxxx
Subject: [2600] action item 481 - removing data access control rules from Common PP and replicating those rules in the SFR packages
At the Lexington meeting (see comment #4 in http://grouper.ieee.org/groups/2600/comment-tracking/P2600X_2008_10_v02.pdf),
I identified two issues with the data access control rules that are in an SFP table in the Common PP.
One issue was that I thought there were some configurations in which the common rules would be difficult to satisfy, but on further review, I no longer think that is an issue.
The other issue was identified by Mr. Hirota of Canon who suggested that the data access control rules would be more clearly stated and understandable if we took the two rules out of the Common PP and replicated them in each of the applicable SFR packages (PRT, SCN, CPY, FAX, and DSR). If you would like to see how that would look, I created a snippet of the current tables and the proposed reorganization, here:
http://grouper.ieee.org/groups/2600/presentations/Plantation2008/ProposedDataACSFPs-40a.doc.
Since I no longer believe that there is a technical issue with the rules in the Common PP, I don't think that the structural change is necessary and it is preferable to avoid making changes to the PPs since they are already in the evaluation process. On the other hand, this would not represent a technical change, so if it really improves understanding of the PP, then perhaps it is worth doing.
I promised to discuss this on the email list, so... what do you all think?
--
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.
+--------------------------------------------------------+
Satoshi HIROTA
Canon IT Solutions Inc.
E-mail:hirota.satoshi@xxxxxxxxxxxxxxx
Tel:03-6719-9880
|