| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Brian - I have several comments on the latest P2600.1.D29 PP draft now that I actually
have time to review the document. Note that many of the comments cover multiple
PPs but I’ll only bring it up for the first instance I found it; you know
what is repetitive better than I do anyway. I know you probably will not be able to address these before next
week's meeting; I'm hoping we can discuss them at the meeting or off-line as
necessary: 1. User
Entity Definitions – The wording for the U.ORIGINATOR entity doesn’t
seem to be correct. Do you mean to say “A User (you forgot to capitalize ‘user’)
who is permitted to perform Normal User Document processing function…”.
By the way, I believe we deleted the concept of a ‘normal user’ last
meeting; if you are going to use that term here doesn’t that mean you now
have to define what you mean by a ‘normal user’? 2. User
Entity Definitions – Remove the word ‘Administrator’ from the
definition of the TU.ADMINISTRATOR entity. 3. Object
(Assets) Entity Definitions, line 15 – You seem to inconsistently refer
to ‘states’ and ‘object-states’ here. Are these meant
to be the same thing (if so use consistent terminology) or are they two
different things (if so you’ll need to define what they both mean)? 4. Object
(Assets) Entity Definitions Table – I’m having a hard time
understanding what you mean by ‘pending’ in this definition. I
think you are trying to convey the concept that the job is being stored in the
TOE either waiting to be processed or is being processed; if it’s being
processed there is nothing ‘pending’ about the job. If this
interpretation is correct, then I think a better definition might “Contained
in the TOE either waiting for (awaiting?) or during performance of a job”.
What do you think? 5. Along
the same lines, I don’t understand in all of the entity definitions why
you use the term “contained in the TOE”. Documents and data are
stored either temporarily or permanently in the TOE but that doesn’t mean
that the TOE contains these documents or data (I am assuming you mean “contain”
in the context of “hold” rather that “incorporate”). You
could argue contain fits when you are talking about persistent storage, but it certainly
doesn’t make sense when you are talking about temporary storage. I think
you need to come up with a better term here that conveys both the temporary and
permanent nature of the data being stored (I don’t have any good
candidates at the moment but maybe I can give it some thought before next
Tuesday). 6. I
have the same type of comment like #5 for data items being “present”
in the TOE. I’m not sure what that really means. Seems to me in comparing
D.PROT.atRest with D.PROT.atRest except for the data being protected the two
data items are the same. In that case why wouldn’t they be in the same
state – why create two different states here? 7. P2600.1-PRT
PP, page 14 – I think in your rationale for not including D.DOC.onServer
you meant to say “This TOE does not
store documents…” 8. P2600.1-PRT
PP, page 15 – Minor nit – to be consistent with the main P2600
body, in the rational for D.DOC.isDeleted you should use the term ‘nonvolatile’
instead of ‘non-volatile’. 9. P2600.1-PRT
PP, page 15 – The example for the TSF Asset D.PROT.atRest indicates that
we are protecting this TSF data from “unauthorized alteration”.
This seems to contradict the definition of D.PROT.atRest on page 10 which
states that this data must be protected from “unauthorized modification”.
10.P2600.1-PRT PP, page
16 – The description of the P.SOFTWARE.VERIFICATION OSP doesn’t
make sense to me. What you should be verifying here in my view is that the currently
installed software in the TOE, and not the currently installed TOE, has
remained consistent with the delivered and (initially) installed software. Suggest
changing the wording to say “…verify that the currently installed
software in the TOE has remained consistent with the delivered and initially
installed software.” 11. P2600.1-PRT PP, page
20 – In the PRT Audit data requirements table, it’s not clear to me
what an audit storage failure is in the context of FAU_STG.4. As I read this
SFR, what we probably should be reporting each time the audit log becomes full –
this is not an audit log failure which I would associate with something like not
recording an event it was supposed to record or not writing the audit log file properly
in a readable format when requested to do so. 12.
P2600.1-PRT PP, page 20 – Some additional suggested minimum audit log
entries: ·
FAU_SAR.1 – Also record when
the audit log is downloaded and by whom (user_id) ·
FMT_SMR.1 – record administrator
log-in attempts ·
FMT_SMF.1 – record whenever
someone changes (or attempts to change) the SA password/PIN ·
FDP_ACF.1 - you should also record
the job type so the job initiation and completion information makes sense and
can be properly analyzed ·
FTA.SSL.3 - you should also record
when a TSF-initiated session is first initiated ·
FIA_AFL.1 - you should also record
the user id of anyone who reaches the failure limit (took me a couple of times
before the wording of this element made sense) plus the number of log-in
attempts by user id. 13. P2600.1-PRT PP, page
28 – I think it makes more sense that the definition of the PRT Management
function for FAU_UID.1 should be management of “user actions” instead of “user
identities”. I also am not sure I understand for FAU_SAR.1 who an “authorized
audit user” is because this is the first time you use that term. Do you
mean an “authorized audit record User” here (paraphrasing what is
in FAU_SAR.1)? 14. For the P2600.1-DSR
PP, can you provide a rationale why the software verification requirements and
associated objectives/policy needs to be included? I understand why it was
added to P2600.-PRT, -SCN, -CPY & -FAX but in this case we are talking
about document storage and retrieval – why would we worry that the TOE
software is verified as being correct when our concern here is around ensuring
proper access and control of documents stored in the TOE – I just don’t
see the connection. By the way, in the definition for the DSR PP, given the
distinction you made in the previous PPs about data stored before, during or
after processing of a job I think you need to clarify for DSR what stored documents
the PP is referring to. From previous conversations my understanding was that
the DSR PP only applies to documents stored after processing of a job; whether
or not that is true the description of the DSR PP has to clarify what documents
it applies to. 15. P2600.1-NVS PP, page
115 – Under the NVS TOE Model I’m curious why this PP only applies
to User Document Data that is stored in NVS; that may be of primary concern here
but we also have to be concerned that Confidential and Protected data like secrets
that might be stored in NVM isn’t retrieved either. 16. P2600.1-NVS PP, page
118 – The NVS OSP section in the application note refers to the P.ADMIN
and P.AUDIT policies; you probably should use the full names for the two
referenced OSPs; otherwise it would imply there are other missing Admin and
Audit OSPs. Same comment holds for the NVS Assumptions and NVS Security
Objectives. 17. P2600.1-NVS PP, page
122 – I was wondering why you didn’t include any minimum audit data
requirements associated with FDP_RIP.1 and the cryptography SFRs – these
are the real SFR differences between NVS and the other PPs. As a minimum I
would think you would want to include in the audit log some event associated
with deletion of the applicable data in NVS and some event associated with the
use of encryption (like “use of crypto libraries”). I’ll give
some thought as to how to word these for next week’s meeting. 18. P2600.1-NVS PP, page
130 – Similar to the previous comment and for the same basic rationale, I
was wondering why you didn’t include a management function recommendation
associated with FDP_RIP.1 like ‘Management of User Document Data
deletions’ and with the cryptographic SFRs such as “. 19. P2600.1-NVS PP, page
134 – The table on page 133 indicates that for O.DOC.atRest.NO_DIS SFRs FIA_UID.1,
FMT_MSA.2, FMT_MTD.1 & FMT_SMR.1 help satisfy this objective. However, in
the associated table on page 134 only the FMT_MTD.1 & FMT_SMR.1 are
included in the discussion of O.DOC.atRest.NO_DIS. Same comment applies to O.PROT.atRest.NO_ALT
& O.CONF.atRest.NO_ALT. 20. P2600.1-SMI PP, page
137 – There seems to be an type here in Item b) under ‘Major
Security Features’ – shouldn’t that item read “The SMI
TOE can protect Assets from disclosure or alteration when such Assets are exchanged…” 21. P2600.1-SMI PP, page
141 – In the table on this page you forgot to include the check for
P.SMI.MEDIATE to satisfy O.SMI.MEDIATE. By the way, is it permissible that an
OSP and associated security objective be exactly the same; to me the wording
should be different to reflect the difference between a policy and an
objective. Curious why they were worded the same. 22. P2600.1-SMI PP, page
154 – The table on page 154 indicates that for O.SMI.MEDIATE SFRs FDP_IFC.1
& FDP_IFF.1 help satisfy this objective. However, in the associated table
on page 155 only the FDP_IFC.1 SFR is included in the discussion of O.SMI.MEDIATE. 23. P2600.1-SMI PP, page
154 – The table on page 154 indicates that for O.CONF.atRest.NO_DIS SFRs FIA_UID.1,
FMT_MSA.1, FMT_MSA.3, FMT_MTD.1, FMT_SMF.1 & FMT_SMR.1 help satisfy this
objective. However, in the associated table on page 134 only the FMT_MTD.1
& FMT_SMR.1 are included in the discussion of O.CONF.atRest.NO_DIS. Same
comment applies to O.CONF.atRest.NO_ALT & O.PROT.atRest.NO_ALT. 24. P2600.1-SMI PP, page
154 – The O.USER_AUTHORIZED objective shown on the table on page 54 is
not covered in the associated table on page 155. I’ll check the Annex A
Glossary later to see if anything is missing. I hope these comments help. By
the way, can you send me the word version of your latest draft so I can incorporate
the applicable changes into the PP-E draft? See you in Al Sukert Product Security Specialist - XOG Product Security Office XOG Export Control Coordinator Xerox Certified Green Belt Device Administration Program Manager 8*227-1413 or 585-427-1413 FAX: 585-427-6599 Alan.Sukert@xerox.com -----Original Message----- An updated FoPP-A has been posted here (with lots of change marks): http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.1-29a. pdf And here (without change marks): http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/P2600.1-29a_ ncb.pdf You can also see the master asset/threat/objective/SFR worksheet here: http://grouper.ieee.org/groups/2600/presentations/Toronto2007/P2600master- 29a.xls There is much more blood on the pages than I had imagined, but nearly
all of it is the result of comments and action items from Here is a summary of the changes: AI#362 Added policy, objective, and SFRs for self test per Carmen's
"case 2" proposal. I took the liberty of changing P.SOFTWARE.INTEGRITY
to P.SOFTWARE.VERIFICATION, and O.SOFTWARE.INTEGRITY to
O.SOFTWARE.VERIFIED, for consistency with the parts of speech in other P's and O's. The policy/etc was added to all TOEs, even though it is somewhat redundant
to do so, because that will ensure that the verification function applies
to the software in each TOE. I think this will apply to environments A, B, and C, but we didn't discuss that at the AI#368 Moved T.FUNC.STORED (job logs) out of User Function Data and
into TSF Protected Data. This seemed to work OK. AI#369 Added an app note to the General model to say that not all
assets and asset-states defined in the General model apply to all TOEs. Added
a table in each TOE giving a rationale for which asset-states are not considered in that TOE. AI#371 Changed the wording of SFPs to say that a TOE _requires_ identification and authentication, not that it necessarily performs it. This (I hope) leaves the door open to either perform I&A in the TOE
or outside of the TOE. AI#372, #374, #375 Changed state names and state structure to reduce confusion about what is temporary and what is stored. Refer to http://grouper.ieee.org/groups/2600/email/msg00879.html for details. AI#377 Added some clarification to the SMI TOE (and also the NVS TOE, which had a similar issue) which says that their operations are being performed on behalf of other Subjects. However, I think that the data
is inside of the TOE boundary. AI#378 Removed P.COMMS.NO_BRIDGE and P.COMMS.NO_PROXY (and their objectives) and replaced with P.SMI.MEDIATION and O.SMI.MEDIATED (same
set of SFRs). AI#379 Removed FIA_UAU.6 from all TOEs. I could not think of a good justification to keep it. AI#382 Added back "detection" to FAU_STG.1.2 by restoring the
original unmodified SFR. AI#383 Split DIS and ALT into different rows in all rationale tables. AI#384 Created audit requirement and recommendation tables, and
modified FAU_GEN.*. AI#385 Created management recommendation tables, and modified
FMT_SMF.1. AI#390 Audit event tables were created and should provide enough clarification. One item was NOT completed: AI#380 I think that the need for SSL.3 does not need to be explicitly stated in P*.AUTHORIZATION. Its supporting role is described in the SFR-Objective rationale tables. The same thing also applies to
FIA_AFL.1, FIA_UAU.7, and others. Adding specific requirements would make those policies (and their objectives) unwieldly. Regards, -- Brian Smithson Project Manager PMP, SSCP, CISSP, CISA, ISO 27000 PA Advanced Imaging and Network Technologies Ricoh Americas Corporation (408)346-4435 New address: |