[MFD] Re: Resource Service updates for Security

[MFD] Re: Resource Service updates for Security

[MFD] Re: Resource Service updates for Security

nchen at okidata.com nchen at okidata.com
Wed May 13 16:16:23 UTC 2009


Hi Ira,

Thanks for the text for the Security Consideration. 

Here are something I need to clarify, and some comments.

11.4  - Security Threats from Executable Resources

It's not clear to me whether the security problem described here is for -
1) storing Executable Resources at an external storage location that 
involves an external system for storing the resource, and the Resource 
Service is hosted by an Imaging System. Or,
2) storing Executable Resources internally within the Imaging System that 
hosts the Resource Service. 

In both cases the security threat is to the Imaging System. 

If it's case 1) - I agree that the external system "SHOULD verify the 
safety of such resources (e.g., by virus scanning)". But we agreed in last 
face-to-face meeting that it's out of scope of Resource Service to 
consider anything related to the external storage system. What Resource 
Service should consider is the restriction of the storage and retrieval 
operations on such resources to authorized users. How the external storage 
system should protect the stored executable resources is out of scope. 
Although I prefer to recommend some security objectives to be considered 
by the external storage system.

If it's case 2) - I don't think we should give "virus scanning" as an 
example to an Imaging System to protect the stored Executable Resources. 
Virus scanning or intrusion detection techniques are common in PCs, but 
rarely existent in Imaging Systems. It's simply not that practical for an 
Imaging System to have such software implemented which involves constant 
maintenance of upto-date virus signatures by external systems. At the 
abstract level, we can provide some good security objectives to consider 
for the Imaging System, such as protection of confidentiality and 
integrity of the resources and their related metadata. Like case 1), the 
storage and retrieval of operations on such resources must to restricted 
to authorized users.

A Resource Service could be hosted by a computer remote to the Imaging 
System that is under security consideration. We should consider this case 
too.

11.5 - Security Threats from Static Resources

Static resources that have associated Intellectual Property rights or 
license rights that involves metadata such as DateTimeOfExpiration which 
should also be protected for alteration. Therefore, not only storage or 
retrieval operations on Resources must be restricted, other operations on 
resource metadata must be restricted too.

Aslo the security problem you described here is for storing Static 
Resources internally in an Imaging System that hosts the Resource Service. 
We should also consider the case when the Resource Service could be hosted 
by a computer remote to the Imaging System.

Thanks,
-Nancy
-----------------------------------------------------------------------------
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856) 222-7006
Email: nchen at okidata.com




Ira McDonald <blueroofmusic at gmail.com> 
05/12/2009 03:15 PM

To
mfd at pwg.org, NancyChen <nchen at okidata.com>, Ira McDonald 
<blueroofmusic at gmail.com>
cc

Subject
Resource Service updates for Security






Hi Nancy,                                          Tuesday (12 May 2009)

Per my action from the Resource Service review during the April PWG
meeting, below is some text for the Security Considerations section of
the Resource Service.

11.4 Security Threats from Executable Resources

Resources with a ResourceCategory of 'Executable' MUST be handled with
special care by implementations of the Resource Service.  Such resources
can pose serious threats to the integrity of the Imaging System that
hosts the Resource Service.  In particular, such Resources can be used
to introduce Trojan Horses to the Imaging System.  If an implementation
of the Resource Service supports Executable resources, then that
implementation MUST restrict the storage of such resources (e.g., to
authorized administrators and manufacturers) and SHOULD verify the
safety of such resources (e.g., by virus scanning).

11.5 Security Threats from Static Resources

Resources with ResourceCategory of 'Static' SHOULD be treated with
special care by implementations of the Resource Service.  Fonts that
have associated Intellectual Property rights (e.g., as part of their
network licenses) can pose serious threats to the availability of the
Imaging System that hosts the Resource Service - security audits can
result in the shutdown or physical removal of the Imaging System.  If an
implementation of the Resource Service supports Static resources that
have associated Intellectual Property rights, then that implementation
SHOULD restrict the storage of such resources (e.g., to authorized
administrators and manufacturers) and SHOULD restrict the retrieval of
such resources (e.g., to a configured group of authorized users).

Comments?

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place  Saline, MI  48176
734-944-0094
summer:
PO Box 221  Grand Marais, MI 49839
906-494-2434



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20090513/e17b34fb/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20090513/e17b34fb/attachment.htm>


More information about the mfd mailing list