Hi Ira,
I agree that
"The threat is EXECUTING those Resources on an Imaging
System (the one hosting the Resource Service or ANY other
Imaging System) or even a desktop client system."
and
"The Resource Service spec should NOT say anything,
anywhere about internal versus external storage and
should NEVER reference a Resource Repository."
But I don't think "virus scan" is practical for an Imaging System like an
MFD or HCD to verify whether the stored or retrieved Executable Resources
is safe to execute. There are many other techniques to verify the
integrity of these type of resources that are more practical for an MFD or
HCD.
Did I misunderstand something?
-Nancy
Ira McDonald <blueroofmusic at gmail.com>
05/13/2009 05:01 PM
To
nchen at okidata.com, Ira McDonald <blueroofmusic at gmail.com>
cc
mfd at pwg.org
Subject
Re: Resource Service updates for Security
Hi Nancy,
Internal or external storage of the Resouces has NOTHING to
do with the security threat in 11.4 below.
The threat is EXECUTING those Resources on an Imaging
System (the one hosting the Resource Service or ANY other
Imaging System) or even a desktop client system.
The Resource Service spec should NOT say anything,
anywhere about internal versus external storage and
should NEVER reference a Resource Repository.
Every reference in 11.1 through 11.3 to Resource
Repository should be deleted. Users do NOT know
where a Resource Service stores things - if a vendor
does such an extension, then that vendor has broken
good security practice in their system design and
will justifiably fail independent security audits.
The Resource Service is completely responsible *on its
own* for every Resource that it stores (anywhere) or allows
an authenticated user to retrieve (from the Resource
Service, that is).
Any network system that hosts a Resource Service
is, by definition, an Imaging System - it may not be
dedicated (single-purpose), but it's still an Imaging
System.
Another way of putting it is that "Imaging System"
is NOT simply a synonym for "Multifunction Device"
- it's a wider definition that includes Spoolers and
network server-hosted Imaging Services.
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
On Wed, May 13, 2009 at 12:16 PM, <nchen at okidata.com> wrote:
>> 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/9cf24a66/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20090513/9cf24a66/attachment.htm>