Re: [2600] FPT_TST self-test -- I need a volunteer
Carmen,
Thank you for these proposals. I think either one would work. I like the
policy-based proposal a little better because it is easier to add to the
PP :-). I haven't actually added either one to the draft PP because I
think we need to discuss and reach consensus in Bellevue, but I have no
objection to either of them.
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
> -----Original Message-----
> From: Aubry, Carmen [mailto:carmen.aubry@OCE.COM]
> Sent: Wednesday, June 20, 2007 2:28 AM
> To: STDS-2600@listserv.ieee.org
> Subject: Re: [2600] FPT_TST self-test -- I need a volunteer
>
> Brian,
> I have included hereafter a proposal for this issue (as a
> threat and as a policy).
>
> Case 1: Derive objective from threat
>
> Include in each PP asset table:
> TSF Code Persistently stored D.CODE.STORED Stored
> executable code
>
> Include in each PP threat table:
> T.CODE.STORED.ALT D.CODE.STORED TOE code may be altered
> by unauthorized persons while stored on the TOE
>
> O.CODE.STORED.ALT: Prevent unauthorized changes to TOE code.
> The SFRs [FIA_UAU, FIA_UID. FAU_GEN, FAU_SAR, FMT_SMF,
> FMT_MSA, FMT_SMR, FMT._MTD, FPT_STM.1, FPT_AMT.1, FPT_TST.1]
> are sufficient to satisfy the objective because:
> 1. The FIA_UAU family supports the requirement for user
> authentication mechanisms before any actions are carried out
> on the TSF;
> 2. The FIA_UID family supports the requirement to identify
> the user before any actions are taken on that user's behalf;
> 3. The requirements for recording the occurrence of
> security relevant events that take place under TSF control
> and the identification of the level of auditing are provided
> by the FAU_GEN family, and the ability for authorized users
> to review this audit information is provided by FAU_SAR;
> 4. Authorized users' control over the management of the
> security attributes is allowed by the FMT_MSA family;
> 5. The FMT_SMF.1 requirement specifies the required
> management functions of the TOE
> 6. Control over the assignment of the administrator role
> to different users is provided by the FMT_SMR family. No user
> will be able to assume the role of privileged administrator
> without explicitly requesting and being authenticated as
> having permission. Users will not be able to assume
> privileged administrator role unless they have first assumed
> the administrator role
> 7. The requirement to restrict the ability to query,
> modify, delete and clear the TSF configuration to privileged
> administrators is provided by FMT_MTD.1;
> 8. The requirement for reliable time-stamps is satisfied
> by FPT_STM.1;
> 9. The requirement for the self-testing of the abstract
> machine upon which the security functions rely is satisfied
> by FPT_AMT.1.;
> 10. The requirement for self-testing upon startup to verify
> the proper operation of the TSF code is satisfied by FPT_TST.1
>
> Case 2: Derive objective from Organizational Security Policies
>
> Include in each PP policy table:
> P.SOFTWARE.INTEGRITY Procedures, e.g. use of modification
> dates, checksums etc., shall exist that make it possible to
> verify that the currently installed TOE has remained
> consistent with the delivered and installed software
>
>
> O.SOFTWARE.INTEGRITY The TOE must provide procedures to
> verify the integrity of the TOE.
>
> FPT_TST.1 TSF testing
> FPT_TST.1.1 The TSF shall run a suite of self tests
> [selection: during initial start-up, periodically during
> normal operation, at the request of the authorized user,
> under the conditions [assignment: conditions at which self
> test should occur]] to demonstrate the correct operation of the TSF.
> FPT_TST.1.2 The TSF shall provide authorized users with the
> capability to verify the integrity of TSF data.
> FPT_TST.1.3 The TSF shall provide authorized users with the
> capability to verify the integrity of stored TSF executable code.
>
> 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@RICOH-USA.COM]
> Sent: Thursday, June 14, 2007 1:07 AM
> To: STDS-2600@listserv.ieee.org
> Subject: [2600] FPT_TST self-test -- I need a volunteer
>
> At the DC meeting, there were a number of people who were in
> favor of including a threat (or OSP) and objective that
> requires the HCD to perform some kind of self-test to
> validate its executable code, at least on power-up.
>
> We didn't reach an official decision about it, but I wouldn't
> object to including it in the PP. However, I don't have
> suitable threat and objective descriptions for it. I did find
> some examples from other PPs that we could look at, I just
> haven't had time to see if those examples are appropriate for
> our kind of product, EAL, etc.
>
> Would someone who wants this requirement please volunteer to
> come up with the threat description (or perhaps an OSP is
> better), objective statement, and figure out what if anything
> to select/assign in the SFR statements? I can give you a list
> of example PPs to look at if you'd like. Then make your
> proposal on the mailing list, let's discuss, and decide.
> Otherwise, I don't think this one will make it into the next draft.
>
> Regards,
> --
> Brian Smithson
> Project Manager
> 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.
>
>