Thanks for updates. It now clearly define
what asset categories should be concerned in each TOE. I think it also
has solved the problem I had with "persistent data" that each
TOE (other than NVS) has to deal with in the previous version. What is
still missing is we still lack of definition on the minimum set of data
should be included in each category of assets in each environment.
For example, on page 10 -
"Confidential Data" is "security
relevant configuration, credential or log information, which must be protected
from unauthorized disclosure in transit through any TOE interface,
or contained in the TOE."
"Protected Data" is "security
relevant configuration, credential or log information, which must be protected
from unauthorized modification but not disclosure in transit
through any TOE interface, or contained in the TOE.
But on page 16 -
There are threats against both "DISCLOSURE"
and "ALTERATION" of Confidential Data atRest.
I think you mean data like secrets (encryption
keys, credentials, passwords) contained in the TOE must be protected from
both disclosure and modification. Therefore secrets (encryption keys, credentials,
passwords) are both Confidential Data and Protected Data. But other data
such as IP addresses, address books, job logs, audit logs, must be
protected from alteration, but disclosure maybe okay depending on the environment
the HCD is in.
Therefore I think we should define the
minimum set of data for the data categories you have defined for each environment,
especially for SFR to consider.
-Nancy
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Principal Engineer
Solutions and Technology
GMC, Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
email: nchen@okidata.com
Brian Smithson <Brian.Smithson@RICOH-USA.COM>
08/14/2007 10:11 PM
Please respond to
Brian.Smithson@RICOH-USA.COM
To
STDS-2600@listserv.ieee.org
cc
Subject
[2600] Updated FoPP-A version 29a
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 Bellevue's meeting.
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 Bellevue meeting.
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:
10460 Bubb Road Cupertino, CA 95014-4150