attachment.htm
Hi Nancy,<br><br>Internal or external storage of the Resouces has NOTHING to<br>do with the security threat in 11.4 below.<br><br>The threat is EXECUTING those Resources on an Imaging <br>System (the one hosting the Resource Service or ANY other <br>
Imaging System) or even a desktop client system.<br><br>The Resource Service spec should NOT say anything,<br>anywhere about internal versus external storage and<br>should NEVER reference a Resource Repository.<br><br>
Every reference in 11.1 through 11.3 to Resource<br>
Repository should be deleted. Users do NOT know<br>
where a Resource Service stores things - if a vendor<br>
does such an extension, then that vendor has broken<br>
good security practice in their system design and<br>
will justifiably fail independent security audits.<br><br>The Resource Service is completely responsible *on its<br>own* for every Resource that it stores (anywhere) or allows<br>an authenticated user to retrieve (from the Resource<br>
Service, that is).<br><br>Any network system that hosts a Resource Service<br>is, by definition, an Imaging System - it may not be<br>dedicated (single-purpose), but it's still an Imaging<br>System.<br><br>Another way of putting it is that "Imaging System"<br>
is NOT simply a synonym for "Multifunction Device"<br>- it's a wider definition that includes Spoolers and<br>network server-hosted Imaging Services.<br><br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>
Chair - Linux Foundation Open Printing WG<br>Blue Roof Music/High North Inc<br>email: <a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><br>winter:<br> 579 Park Place Saline, MI 48176<br> 734-944-0094<br>
summer:<br> PO Box 221 Grand Marais, MI 49839<br> 906-494-2434<br>
<br><br><div class="gmail_quote">On Wed, May 13, 2009 at 12:16 PM, <span dir="ltr"><<a href="mailto:nchen@okidata.com">nchen@okidata.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><font size="2" face="sans-serif">Hi Ira,</font>
<br>
<br><font size="2" face="sans-serif">Thanks for the text for the Security
Consideration. </font>
<br>
<br><font size="2" face="sans-serif">Here are something I need to clarify,
and some comments.</font>
<br><div class="im">
<br><font size="2" face="sans-serif">11.4 - Security Threats from Executable
Resources</font>
<br>
<br></div><font size="2" face="sans-serif">It's not clear to me whether the security
problem described here is for -</font>
<br><font size="2" face="sans-serif">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,</font>
<br><font size="2" face="sans-serif">2) storing Executable Resources internally
within the Imaging System that hosts the Resource Service. </font>
<br>
<br><font size="2" face="sans-serif">In both cases the security threat is
to the Imaging System. </font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br><div class="im">
<br><font size="2" face="sans-serif">11.5 - Security Threats from Static
Resources</font>
<br>
<br></div><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">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.</font>
<br>
<br><font size="2" face="sans-serif">Thanks,</font>
<br><font size="2" face="sans-serif">-Nancy</font>
<br><font size="2" face="sans-serif">-----------------------------------------------------------------------------</font>
<br><font size="2" face="sans-serif">Principal Engineer</font>
<br><font size="2" face="sans-serif">Solutions and Technology</font>
<br><font size="2" face="sans-serif">Oki Data</font>
<br><font size="2" face="sans-serif">2000 Bishops Gate Blvd.</font>
<br><font size="2" face="sans-serif">Mt. Laurel, NJ 08054</font>
<br><font size="2" face="sans-serif">Phone: (856) 222-7006</font>
<br><font size="2" face="sans-serif">Email: <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a></font>
<br>
<br>
<br>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="40%"><font size="1" face="sans-serif"><b>Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></b>
</font>
<p><font size="1" face="sans-serif">05/12/2009 03:15 PM</font>
</p></td><td width="59%">
<table width="100%">
<tbody><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td><font size="1" face="sans-serif"><a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>, NancyChen <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>,
Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Resource Service updates for Security</font></td></tr></tbody></table>
<br>
<table>
<tbody><tr valign="top">
<td>
</td><td></td></tr></tbody></table>
<br></td></tr></tbody></table><div><div></div><div class="h5">
<br>
<br>
<br><font size="2"><tt>Hi Nancy,
Tuesday (12 May 2009)<br>
</tt></font>
<br><font size="2"><tt>Per my action from the Resource Service review during
the April PWG<br>
meeting, below is some text for the Security Considerations section of<br>
the Resource Service.<br>
</tt></font>
<br><font size="2"><tt>11.4 Security Threats from Executable Resources<br>
</tt></font>
<br><font size="2"><tt>Resources with a ResourceCategory of 'Executable'
MUST be handled with<br>
special care by implementations of the Resource Service. Such resources<br>
can pose serious threats to the integrity of the Imaging System that<br>
hosts the Resource Service. In particular, such Resources can be
used<br>
to introduce Trojan Horses to the Imaging System. If an implementation<br>
of the Resource Service supports Executable resources, then that<br>
implementation MUST restrict the storage of such resources (e.g., to<br>
authorized administrators and manufacturers) and SHOULD verify the<br>
safety of such resources (e.g., by virus scanning).<br>
</tt></font>
<br><font size="2"><tt>11.5 Security Threats from Static Resources<br>
</tt></font>
<br><font size="2"><tt>Resources with ResourceCategory of 'Static' SHOULD
be treated with<br>
special care by implementations of the Resource Service. Fonts that<br>
have associated Intellectual Property rights (e.g., as part of their<br>
network licenses) can pose serious threats to the availability of the<br>
Imaging System that hosts the Resource Service - security audits can<br>
result in the shutdown or physical removal of the Imaging System. If
an<br>
implementation of the Resource Service supports Static resources that<br>
have associated Intellectual Property rights, then that implementation<br>
SHOULD restrict the storage of such resources (e.g., to authorized<br>
administrators and manufacturers) and SHOULD restrict the retrieval of<br>
such resources (e.g., to a configured group of authorized users).<br>
</tt></font>
<br><font size="2"><tt>Comments?<br>
</tt></font>
<br><font size="2"><tt>Cheers,<br>
- Ira<br>
</tt></font>
<br><font size="2"><tt>Ira McDonald (Musician / Software Architect)<br>
Chair - Linux Foundation Open Printing WG<br>
Blue Roof Music/High North Inc<br>
email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
winter:</tt></font>
<br><font size="2"><tt>579 Park Place Saline, MI 48176<br>
734-944-0094</tt></font>
<br><font size="2"><tt>summer:<br>
PO Box 221 Grand Marais, MI 49839<br>
906-494-2434<br>
</tt></font>
<br>
<br></div></div></blockquote></div><br>