Re: [2600] FPP-A draft 28a posted
Carmen,
Thank you for your comments and questions. I've included some responses
within your original message, below.
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: Thursday, June 28, 2007 7:17 AM
> To: Brian Smithson; STDS-2600@listserv.ieee.org
> Subject: RE: [2600] FPP-A draft 28a posted
>
> Brian,
> As usual, you've done a lot of work between the meetings!
> Please find bellow my remarks concerning
> http://grouper.ieee.org/groups/2600/drafts/ProtectionProfiles/
> P2600.1-28a.pdf
>
>
> Page 10:
> You say
> D.FUNC.TEMP:Job instructions or job status inquiries
> D.FUNC.STORED: Job logs
> From your models one may deduce that the difference between
> D.FUNC.TEMP and D.FUNC.STORED is the state.
> I think job instructions and job logs should not be mixed
> under D.FUNC.
> The user can decide which are his job instructions but he is
> not allowed to modify accounting data.
>
I agree that there is a difference between job instructions/status and job
logs. However, I put them both under the same category of User Data
because (1) I think you'll agree that it is User Data according to CC
definition, and (2) it is all job metadata but in different states.
However, I also agree that the user shouldn't be able to modify accounting
data. That's why the access control SFPs permit a user to modify job
metadata while in the TEMP state (job in process) but only an
administrator can modify job metadata in the STORED state (job completed).
See Table 13 on page 19 for an example.
Do you think that's OK? If not, let's discuss in Bellevue and see what we
can work out.
> Line 17, page 16:
> why you consider only D.FUNC.TEMP. We can also have D.DOC.TEMP
I didn't consider D.DOC.TEMP because I thought that a user would not
normally have any access to documents in a TEMP state, and it only becomes
a security concern in the nonvolatile storage (NVS) TOE. Perhaps I am
wrong about that? It does seem like a user could have access to a TEMP
document in the sense that they could request that a job be deleted from
the device queue, which would effectively delete the TEMP document. Maybe
we should talk about this one in Bellevue.
> why you consider only D.FUNC.STORED? You can also have D.DOC.STORED
The definition I used for the STORED state is for data that is intended to
persist after job completion, and in the PRT TOE (and SCN, CPY, and FAX
TOEs), documents are not supposed to persist. In the PRT TOE, a document
that is either waiting to be printed or waiting to be released to output
would be considered TEMP, according to the definitions that I'm using.
>
> Page 20:
> For D.FUNC.TEMP you allow U.DELEGATE but not for D.FUNC.STORED. Why?
> why you consider that S.PRT may write on behalf of
> U.ORIGINATOR if data was created on behalf of
> U.ORIGINATOR for D.FUNC.TEMP and you allow only read for
> D.FUNC.STORED?
> I think that the problem comes from the fact that you mix job
> logs with job instructions.
See my response to Page 10, above... It's the same issue. Users (or in
some cases, their delegates) can modify job metadata for live jobs but
can only read metadata for completed jobs.
>
> page 36:
> why you consider only D.FUNC.TEMP. We can also have D.DOC.TEMP
> why you consider only D.FUNC.STORED? You can also have D.DOC.STORED
Same answers as for Line 17 Page 16, above.
>
> page 39
> why you consider that S.SCN may write on behalf of
> U.ORIGINATOR if data was created on behalf of
> U.ORIGINATOR for D.FUNC.TEMP and you allow only read for
> D.FUNC.STORED? Same for the other models (DSR, for instance)
Same answer as for Page 20 and Page 10.
> page 133?
> In the SMI model you consider only the Administrator? I
> suppose that the regular user can use this interface?
I am thinking of the SMI TOE as a channel through which users bind with
subjects, but they don't bind with the SMI subject directly. The only user
who really interacts directly with the SMI subject is an administrator
(when performing administrative things, like setting up MAC address white
lists for example). So an external device might make a connection to a
network interface and be permitted to do so by the SMI Information Flow
Control SFP, and then the regular user is identified/authenticated when
trying to bind with some other subject like PRT.
I am not entirely certain this the best approach, but it makes some sense
if we can assume that the user ID/auth mechanism is the same regardless of
which interface is being employed by the user. This TOE was one of the
more difficult ones and I hope we can discuss this more in Bellevue to
make sure that the model works for our purposes.
> 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
> _________________________________________________________
>
Thank you for reading/understanding/questioning so much of this PP!
- Brian