[2600] PP drafts updated to 40a
All four PP drafts have been updated according to comments approved at
the Lexington meeting (with one exception, see below). The change-bar
versions are available here:
P2600.1-40a.pdf
http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.1-40a.pdf
P2600.2-40a.pdf
http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.2-40a.pdf
P2600.3-40a.pdf
http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.3-40a.pdf
P2600.4-40a.pdf
http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.4-40a.pdf
No-change-bar versions and .DOC version are also available as usual,
here: http://grouper.ieee.org/groups/2600/techdocs.html
There were not many comments (which is good!). The resolved comments are
here:
http://grouper.ieee.org/groups/2600/comment-tracking/P2600X_2008_10_v02.pdf
#7 done in A,B,C
#13 withdrawn
#4 withdrawn
#8 done in A,B
#9 done in A,B
#5 done in A,B,C,D
#10 done in A,B
#11 postponed for further discussion, see below
#14 done in A,B,C,D
#15 withdrawn
#1 done in A,B,C,D
#2 done in A,B,C,D
#3 done in A,B,C,D
#6 done in A,B,C
Regarding comment #11, the proposal was to change FTP_CIP_EXP.1 so that
confidentiality and integrity could be selected instead of (both)
required. It was accepted in principle. However, there were two
problems: (1) If we allow selection of confidentiality and integrity in
FTP_CIP_EXP.1.1, then the need for FTP_CIP_EXP.1.2 becomes dependent
upon that selection. (2) There was a note in the comment response to
look for other precedents where an objective requires only
confidentiality but the fulfilling SFR requires both, and FTP_ITC.1 is
such a precedent. Unfortunately, we have no ability to change FTP_ITC.1
unless we make a less restrictive version as an extended component.
Therefore, I propose that we leave FTP_CIP_EXP.1 as is and let the SFRs
over-fulfill some of the objectives.
There were three withdrawn items that were intended to be discussed and
perhaps decided via email:
Action item #480 (referring to October comment #13): In access control
rules that refer to D.FUNC, we were considering changing the way rules
are specified from "his/her own documents" to "his/her own jobs". This
turned out to be a problem because we would need to define "job" as an
object. Even then, it would be a problem because function data can refer
to information about a document and/or to information about a job (we
allow either or both). Therefore, I did not implement anything in the
40a drafts, but will propose at the Plantation meeting that we change it
to "his/her own function data".
Action item #481 (referring to October comment #4): There was a proposal
to remove the tabular access control rules from the Common PP and
replicate them in each of the applicable SFR packages. There was support
for the idea, and Carmen pointed out that the replicated rules would
each need to be evaluated, often redundantly. Therefore, I didn't
implement anything in the 40a drafts and don't plan to submit further
comment. If someone else has a strong opinion in support of the
proposal, please feel free to submit a comment!
Action item #482 (referring to October comment #12): There was some
discussion about specifying which (if any) of the audit and management
suggestions that are in our extended components should be required or
recommended in the SFR packages. Alas, this never quite made it to the
email list for discussion. Please take a look at the audit and
management parts of the extended component definitions and see what you
think. I will probably submit a comment that requires none and maybe
recommends one or two. I think that the suggestions themselves could use
a little re-write to make their intention more clear.
For those of you in the US, happy T-day!
--
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