| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
At the Lexington meeting (see comment #12 in
http://grouper.ieee.org/groups/2600/comment-tracking/P2600X_2008_10_v02.pdf.),
I brought up that we have not yet addressed the audit and management
requirements that are suggested in the Extended Component Definitions of
the NVS and SMI packages.
Please reply to the mailing list if you have any comments on these
items, and we will discuss them (and, I hope, make decisions) at the
Plantation meeting.
In case the mailing list processor messes up the formatting and makes it
unreadable, I have attached the rest of this message as a Word document.
For each item, the question to answer is: Should we require the
suggested management or audit item, or recommend it, or ignore it?
* If we require it, then all conforming STs must fulfill the
requirement.
* If we recommend it but it is not fulfilled in an ST, then an ST
evaluator will probably ask why the item is not fulfilled.
* If we ignore it, then the suggestion will remain in the Extended
Component Definition but it will not appear in either the Required
or Recommended tables.
_*NVS package, FTP_CIP_EXP.1 "Confidentiality and Integrity of Stored
Data"*_
This is the SFR that says we must protect the confidentiality and
integrity of data stored on removable devices (e.g., encrypt the HDD).
The management and audit suggestions are:
> *Management: FTP_CIP_EXP.1*
>
> The following actions could be considered for the management functions
> in FMT:
>
> a) management of the conditions under which the protection
> function is activated or used;
>
> b) management of potential restrictions on the allowance to use
> this function.
>
> *Audit: FTP_CIP_EXP.1*
>
> The following actions should be auditable if FAU_GEN Security Audit
> Data Generation is included in the PP/ST:
>
> a) Basic: failure condition that prohibits the function to work
> properly, detected attempts to bypass this functionality (e. g.
> detected modifications).
>
For the management items, I asked Helmut if he really meant that we
should consider managing the /use/ of the function. He said yes, there
are general cases where you might want to restrict the use of the
function. For example, if you have some encryption function, you might
want to make sure that function cannot be used unless the encryption key
has been safely stored somewhere. But I don't think we should require
this, or even recommend it. I think we should ignore the management items.
For the audit item, I think that the text might be re-worded to be more
clear. What Helmut meant was to suggest that audit records be created if
(1) there is some failure that prevents the protection mechanism from
working, and (2) it is detected that the protected data has been
compromised. I asked why we need to specify (2) because detection of
compromise is already part of the SFR itself, and he said that it is a
reminder to create an audit log record for such an occurrence. I think
that both items are worthwhile, but perhaps we should only recommend
them and not require them because the ability to perform (1) depends on
how the protection mechanism is implemented. Alternatively, we could
make the suggestions more clear by splitting it into two items (1) and
(2), and then recommend (1) but require (2).
_*SMI package, FMT_FDI_EXP.1 Restricted forwarding of data to external
interfaces*_
This is the SFR that requires some management function to restrict the
forwarding of data to external interfaces. Here are the management and
audit suggestions:
> *Management: FMT_FDI_EXP.1*
>
> The following actions could be considered for the management functions
> in FMT:
>
> a) definition of the role(s) that are allowed to perform the
> management activities;
>
> b) management of the conditions under which direct forwarding
> can be allowed by an administrative role;
>
> c) revocation of such an allowance.
>
> *Audit: FMT_FDI_EXP.1*
>
> The following actions should be auditable if FAU_GEN Security Audit
> Data Generation is included in the PP/ST:
>
> Basic: all management actions to modify the allowance for forwarding
> between external interfaces. The names or identifier of the interfaces
> should be included as additional information in the audit record.
>
Regarding the management items, I asked why we need to do (a) since
roles are already defined in FMT_SMR. Helmut said that even if the roles
are defined, (a) would indicate which roles are allowed to control this
particular function, and (b) and (c) place some restrictions on how the
function can be controlled. I also asked if (b) and (c) could be
combined, and he said yes they could. I am not certain what to say about
these items, but I think they may depend on implementation and so we
should not require them. It may be OK to recommend them. I am not sure.
The audit item seems very reasonable and I think we should at least
recommend it. I would say that we should require it, but maybe there are
some implementations where modification of allowance to forward between
interfaces is not possible.
--
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
Attachment:
audit-mgmt-for-ECDs.doc
Description: MS-Word document