attachment.htm

Hi Nancy,<br><br>Trusted path for firmware merely means you know which<br>upstream server was corrupted - at least, if you CHECK<br>the content of the firmware before blindly executing it.<br><br>And user scripts (and PostScript-like PDL jobs) can be<br>
highly effective Denial-of-Service attacks (by crashing the<br>entire MFD or just the Print Service) unless scanned by <br>antivirus/antimalware tools.<br><br>Those are real threats.<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 Thu, May 14, 2009 at 2:42 PM,  <span dir="ltr">&lt;<a href="mailto:nchen@okidata.com">nchen@okidata.com</a>&gt;</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">P2600 covers the security threats that
you mentioned here.</font>
<br>
<br><font size="2" face="sans-serif">In short, firmware update must be through
trusted path.</font>
<br>
<br><font size="2" face="sans-serif">User&#39;s document if needed (depending
on site security requirement), must be protected from disclosure and/or
alteration.</font>
<br>
<br><font size="2" face="sans-serif">There are many techniques to protect
document disclosure and alteration. We think the best techniques to prevent
from disclosure is by encryption, to detect alteration is by signing digital
signature. </font>
<br>
<br><font size="2" face="sans-serif">Many MFPs today do not have these security
in place, but they will eventually when they comply to the security standard.</font>
<br>
<br><font size="2" face="sans-serif">-Nancy</font>
<br>
<br>
<br>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="40%"><div class="im"><font size="1" face="sans-serif"><b>Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;</b>
</font>
</div><p><font size="1" face="sans-serif">05/14/2009 01:56 PM</font></p><div><div></div><div class="h5">
</div></div></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:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td><font size="1" face="sans-serif"><a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a></font>
</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">Re: 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,<br>
</tt></font>
<br><font size="2"><tt>OK - I&#39;m fascinated.<br>
</tt></font>
<br><font size="2"><tt>What conceivable system security could replace the<br>
need for onboard antivirus software?<br>
</tt></font>
<br><font size="2"><tt>Especially given that many MFDs now update firmware<br>
via a &quot;special&quot; Print Job - and do NOT have digitally<br>
signed firmware packages with an unbroken, network-<br>
accessible chain of authority to a major public Certificate<br>
Authority.<br>
</tt></font>
<br><font size="2"><tt>Certainly scripts and macros invoked in ordinary<br>
Print Jobs are very easily corrupted - users create<br>
them, so they aren&#39;t digitally signed - verification of<br>
source does NOT remove the need for verification<br>
that the source system was not in fact corrupted.<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</tt></font>
<br>
<br>
<br><font size="2"><tt>On Thu, May 14, 2009 at 10:54 AM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt;
wrote:<br>
</tt></font>
<br><font size="2"><tt>&gt;<br>
&gt; Hi Ira,<br>
&gt;<br>
&gt; I haven&#39;t seen any security certification requirement that requires
onboard<br>
&gt; antivirus on MFP yet.  Not sure what&#39;s the basis of your prediction.<br>
&gt; Antivirus software vendors of course will try to push their products
on any<br>
&gt; platform. If you have not implemented MFP security standard, properly<br>
&gt; configure the system to secure it, antivirus might be a good idea
to have.<br>
&gt; But once you have proper security instrumented, antivirus is not that<br>
&gt; critical. It&#39;s nice to have of course.<br>
&gt;<br>
&gt; -Nancy<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt;<br>
&gt; 05/13/2009 06:20 PM<br>
&gt;   To<br>
&gt; <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;  cc<br>
&gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>  Subject<br>
&gt; Re: Resource Service updates for Security<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Hi Nancy,<br>
&gt;<br>
&gt; Several vendors currently offer MFDs that incorporate virus<br>
&gt; scanning of all files and executable modules and that CAN<br>
&gt; integrate into enterprise antivirus update schemes.<br>
&gt;<br>
&gt; Anyway, it was only an EXAMPLE (not a requirement) - though<br>
&gt; I think you will find that network endpoint attachment protocols<br>
&gt; and architectures are ALL going to require that you certify<br>
&gt; that you have healthy onboard antivirus on your MFD in the<br>
&gt; very near future.<br>
&gt;<br>
&gt; MFDs running Linux or other general-purpose operating systems<br>
&gt; are just too dangerous anymore without antivirus (or firewalls).<br>
&gt;<br>
&gt; Cheers,<br>
&gt; - Ira<br>
&gt;<br>
&gt; Ira McDonald (Musician / Software Architect)<br>
&gt; Chair - Linux Foundation Open Printing WG<br>
&gt; Blue Roof Music/High North Inc<br>
&gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; winter:<br>
&gt; 579 Park Place  Saline, MI  48176<br>
&gt; 734-944-0094<br>
&gt; summer:<br>
&gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; 906-494-2434<br>
&gt;<br>
&gt;<br>
&gt; On Wed, May 13, 2009 at 5:49 PM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Ira,<br>
&gt; &gt;<br>
&gt; &gt; I agree that<br>
&gt; &gt;<br>
&gt; &gt; &quot;The threat is EXECUTING those Resources on an Imaging<br>
&gt; &gt; System (the one hosting the Resource Service or ANY other<br>
&gt; &gt; Imaging System) or even a desktop client system.&quot;<br>
&gt; &gt;<br>
&gt; &gt; and<br>
&gt; &gt;<br>
&gt; &gt; &quot;The Resource Service spec should NOT say anything,<br>
&gt; &gt; anywhere about internal versus external storage and<br>
&gt; &gt; should NEVER reference a Resource Repository.&quot;<br>
&gt; &gt;<br>
&gt; &gt; But I don&#39;t think &quot;virus scan&quot; is practical for an
Imaging System like an<br>
&gt; &gt; MFD or HCD to verify whether the stored or retrieved Executable
Resources<br>
&gt; is<br>
&gt; &gt; safe to execute. There are many other techniques to verify the
integrity<br>
&gt; of<br>
&gt; &gt; these type of resources that are more practical for an MFD or
HCD.<br>
&gt; &gt;<br>
&gt; &gt; Did I misunderstand something?<br>
&gt; &gt;<br>
&gt; &gt; -Nancy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt; &gt;<br>
&gt; &gt; 05/13/2009 05:01 PM<br>
&gt; &gt;   To<br>
&gt; &gt; <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;<br>
&gt; &gt;  cc<br>
&gt; &gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>  Subject<br>
&gt; &gt; Re: Resource Service updates for Security<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Nancy,<br>
&gt; &gt;<br>
&gt; &gt; Internal or external storage of the Resouces has NOTHING to<br>
&gt; &gt; do with the security threat in 11.4 below.<br>
&gt; &gt;<br>
&gt; &gt; The threat is EXECUTING those Resources on an Imaging<br>
&gt; &gt; System (the one hosting the Resource Service or ANY other<br>
&gt; &gt; Imaging System) or even a desktop client system.<br>
&gt; &gt;<br>
&gt; &gt; The Resource Service spec should NOT say anything,<br>
&gt; &gt; anywhere about internal versus external storage and<br>
&gt; &gt; should NEVER reference a Resource Repository.<br>
&gt; &gt;<br>
&gt; &gt; Every reference in 11.1 through 11.3 to Resource<br>
&gt; &gt; Repository should be deleted.  Users do NOT know<br>
&gt; &gt; where a Resource Service stores things - if a vendor<br>
&gt; &gt; does such an extension, then that vendor has broken<br>
&gt; &gt; good security practice in their system design and<br>
&gt; &gt; will justifiably fail independent security audits.<br>
&gt; &gt;<br>
&gt; &gt; The Resource Service is completely responsible *on its<br>
&gt; &gt; own* for every Resource that it stores (anywhere) or allows<br>
&gt; &gt; an authenticated user to retrieve (from the Resource<br>
&gt; &gt; Service, that is).<br>
&gt; &gt;<br>
&gt; &gt; Any network system that hosts a Resource Service<br>
&gt; &gt; is, by definition, an Imaging System - it may not be<br>
&gt; &gt; dedicated (single-purpose), but it&#39;s still an Imaging<br>
&gt; &gt; System.<br>
&gt; &gt;<br>
&gt; &gt; Another way of putting it is that &quot;Imaging System&quot;<br>
&gt; &gt; is NOT simply a synonym for &quot;Multifunction Device&quot;<br>
&gt; &gt; - it&#39;s a wider definition that includes Spoolers and<br>
&gt; &gt; network server-hosted Imaging Services.<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; - Ira<br>
&gt; &gt;<br>
&gt; &gt; Ira McDonald (Musician / Software Architect)<br>
&gt; &gt; Chair - Linux Foundation Open Printing WG<br>
&gt; &gt; Blue Roof Music/High North Inc<br>
&gt; &gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; &gt; winter:<br>
&gt; &gt; 579 Park Place  Saline, MI  48176<br>
&gt; &gt; 734-944-0094<br>
&gt; &gt; summer:<br>
&gt; &gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; &gt; 906-494-2434<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, May 13, 2009 at 12:16 PM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi Ira,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks for the text for the Security Consideration.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Here are something I need to clarify, and some comments.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 11.4  - Security Threats from Executable Resources<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; It&#39;s not clear to me whether the security problem described
here is for<br>
&gt; -<br>
&gt; &gt; &gt; 1) storing Executable Resources at an external storage location
that<br>
&gt; &gt; &gt; involves an external system for storing the resource, and
the Resource<br>
&gt; &gt; &gt; Service is hosted by an Imaging System. Or,<br>
&gt; &gt; &gt; 2) storing Executable Resources internally within the Imaging
System<br>
&gt; that<br>
&gt; &gt; &gt; hosts the Resource Service.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; In both cases the security threat is to the Imaging System.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If it&#39;s case 1) - I agree that the external system &quot;SHOULD
verify the<br>
&gt; &gt; &gt; safety of such resources (e.g., by virus scanning)&quot;.
But we agreed in<br>
&gt; &gt; last<br>
&gt; &gt; &gt; face-to-face meeting that it&#39;s out of scope of Resource
Service to<br>
&gt; &gt; consider<br>
&gt; &gt; &gt; anything related to the external storage system. What Resource
Service<br>
&gt; &gt; &gt; should consider is the restriction of the storage and retrieval<br>
&gt; &gt; operations<br>
&gt; &gt; &gt; on such resources to authorized users. How the external
storage system<br>
&gt; &gt; &gt; should protect the stored executable resources is out of
scope.<br>
&gt; Although<br>
&gt; &gt; I<br>
&gt; &gt; &gt; prefer to recommend some security objectives to be considered
by the<br>
&gt; &gt; &gt; external storage system.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If it&#39;s case 2) - I don&#39;t think we should give &quot;virus
scanning&quot; as an<br>
&gt; &gt; &gt; example to an Imaging System to protect the stored Executable<br>
&gt; Resources.<br>
&gt; &gt; &gt; Virus scanning or intrusion detection techniques are common
in PCs, but<br>
&gt; &gt; &gt; rarely existent in Imaging Systems. It&#39;s simply not that
practical for<br>
&gt; an<br>
&gt; &gt; &gt; Imaging System to have such software implemented which involves<br>
&gt; constant<br>
&gt; &gt; &gt; maintenance of upto-date virus signatures by external systems.
At the<br>
&gt; &gt; &gt; abstract level, we can provide some good security objectives
to<br>
&gt; consider<br>
&gt; &gt; for<br>
&gt; &gt; &gt; the Imaging System, such as protection of confidentiality
and integrity<br>
&gt; &gt; of<br>
&gt; &gt; &gt; the resources and their related metadata. Like case 1),
the storage and<br>
&gt; &gt; &gt; retrieval of operations on such resources must to restricted
to<br>
&gt; &gt; authorized<br>
&gt; &gt; &gt; users.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; A Resource Service could be hosted by a computer remote
to the Imaging<br>
&gt; &gt; &gt; System that is under security consideration. We should consider
this<br>
&gt; case<br>
&gt; &gt; &gt; too.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 11.5 - Security Threats from Static Resources<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Static resources that have associated Intellectual Property
rights or<br>
&gt; &gt; &gt; license rights that involves metadata such as DateTimeOfExpiration<br>
&gt; which<br>
&gt; &gt; &gt; should also be protected for alteration. Therefore, not
only storage or<br>
&gt; &gt; &gt; retrieval operations on Resources must be restricted, other
operations<br>
&gt; on<br>
&gt; &gt; &gt; resource metadata must be restricted too.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Aslo the security problem you described here is for storing
Static<br>
&gt; &gt; &gt; Resources internally in an Imaging System that hosts the
Resource<br>
&gt; &gt; Service.<br>
&gt; &gt; &gt; We should also consider the case when the Resource Service
could be<br>
&gt; &gt; hosted<br>
&gt; &gt; &gt; by a computer remote to the Imaging System.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; -Nancy<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; -----------------------------------------------------------------------------<br>
&gt; &gt; &gt; Principal Engineer<br>
&gt; &gt; &gt; Solutions and Technology<br>
&gt; &gt; &gt; Oki Data<br>
&gt; &gt; &gt; 2000 Bishops Gate Blvd.<br>
&gt; &gt; &gt; Mt. Laurel, NJ 08054<br>
&gt; &gt; &gt; Phone: (856) 222-7006<br>
&gt; &gt; &gt; Email: <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 05/12/2009 03:15 PM<br>
&gt; &gt; &gt;   To<br>
&gt; &gt; &gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>, NancyChen &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt;, Ira McDonald
&lt;<br>
&gt; &gt; &gt; <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;  cc<br>
&gt; &gt; &gt;   Subject<br>
&gt; &gt; &gt; Resource Service updates for Security<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi Nancy,              
                     
     Tuesday (12 May<br>
&gt; 2009)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Per my action from the Resource Service review during the
April PWG<br>
&gt; &gt; &gt; meeting, below is some text for the Security Considerations
section of<br>
&gt; &gt; &gt; the Resource Service.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 11.4 Security Threats from Executable Resources<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Resources with a ResourceCategory of &#39;Executable&#39; MUST be
handled with<br>
&gt; &gt; &gt; special care by implementations of the Resource Service.
 Such<br>
&gt; resources<br>
&gt; &gt; &gt; can pose serious threats to the integrity of the Imaging
System that<br>
&gt; &gt; &gt; hosts the Resource Service.  In particular, such Resources
can be used<br>
&gt; &gt; &gt; to introduce Trojan Horses to the Imaging System.  If
an implementation<br>
&gt; &gt; &gt; of the Resource Service supports Executable resources, then
that<br>
&gt; &gt; &gt; implementation MUST restrict the storage of such resources
(e.g., to<br>
&gt; &gt; &gt; authorized administrators and manufacturers) and SHOULD
verify the<br>
&gt; &gt; &gt; safety of such resources (e.g., by virus scanning).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 11.5 Security Threats from Static Resources<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Resources with ResourceCategory of &#39;Static&#39; SHOULD be treated
with<br>
&gt; &gt; &gt; special care by implementations of the Resource Service.
 Fonts that<br>
&gt; &gt; &gt; have associated Intellectual Property rights (e.g., as part
of their<br>
&gt; &gt; &gt; network licenses) can pose serious threats to the availability
of the<br>
&gt; &gt; &gt; Imaging System that hosts the Resource Service - security
audits can<br>
&gt; &gt; &gt; result in the shutdown or physical removal of the Imaging
System.  If<br>
&gt; an<br>
&gt; &gt; &gt; implementation of the Resource Service supports Static resources
that<br>
&gt; &gt; &gt; have associated Intellectual Property rights, then that
implementation<br>
&gt; &gt; &gt; SHOULD restrict the storage of such resources (e.g., to
authorized<br>
&gt; &gt; &gt; administrators and manufacturers) and SHOULD restrict the
retrieval of<br>
&gt; &gt; &gt; such resources (e.g., to a configured group of authorized
users).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Comments?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt; - Ira<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ira McDonald (Musician / Software Architect)<br>
&gt; &gt; &gt; Chair - Linux Foundation Open Printing WG<br>
&gt; &gt; &gt; Blue Roof Music/High North Inc<br>
&gt; &gt; &gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; &gt; &gt; winter:<br>
&gt; &gt; &gt; 579 Park Place  Saline, MI  48176<br>
&gt; &gt; &gt; 734-944-0094<br>
&gt; &gt; &gt; summer:<br>
&gt; &gt; &gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; &gt; &gt; 906-494-2434<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;</tt></font>
<br>
<br>
<br></div></div></blockquote></div><br>