Re: [2600] action item 481 - removing data access control rules from Common PP and replicating those rules in the SFR packages
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éteil 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.
>
>
>
>
>