attachment-0001


<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'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%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Ira McDonald &lt;blueroofmusic@gmail.com&gt;</b>
</font>
<p><font size=1 face="sans-serif">05/14/2009 01:56 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">nchen@okidata.com, Ira McDonald &lt;blueroofmusic@gmail.com&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">mfd@pwg.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Resource Service updates for Security</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Hi Nancy,<br>
</tt></font>
<br><font size=2><tt>OK - I'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'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: blueroofmusic@gmail.com<br>
winter:</tt></font>
<br><font size=2><tt>579 Park Place &nbsp;Saline, MI &nbsp;48176<br>
734-944-0094</tt></font>
<br><font size=2><tt>summer:<br>
PO Box 221 &nbsp;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;nchen@okidata.com&gt;
wrote:<br>
</tt></font>
<br><font size=2><tt>&gt;<br>
&gt; Hi Ira,<br>
&gt;<br>
&gt; I haven't seen any security certification requirement that requires
onboard<br>
&gt; antivirus on MFP yet. &nbsp;Not sure what'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's nice to have of course.<br>
&gt;<br>
&gt; -Nancy<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &nbsp;*Ira McDonald &lt;blueroofmusic@gmail.com&gt;*<br>
&gt;<br>
&gt; 05/13/2009 06:20 PM<br>
&gt; &nbsp; To<br>
&gt; nchen@okidata.com, Ira McDonald &lt;blueroofmusic@gmail.com&gt; &nbsp;cc<br>
&gt; mfd@pwg.org &nbsp;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: blueroofmusic@gmail.com<br>
&gt; winter:<br>
&gt; 579 Park Place &nbsp;Saline, MI &nbsp;48176<br>
&gt; 734-944-0094<br>
&gt; summer:<br>
&gt; PO Box 221 &nbsp;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;nchen@okidata.com&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'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; &nbsp;*Ira McDonald &lt;blueroofmusic@gmail.com&gt;*<br>
&gt; &gt;<br>
&gt; &gt; 05/13/2009 05:01 PM<br>
&gt; &gt; &nbsp; To<br>
&gt; &gt; nchen@okidata.com, Ira McDonald &lt;blueroofmusic@gmail.com&gt;<br>
&gt; &gt; &nbsp;cc<br>
&gt; &gt; mfd@pwg.org &nbsp;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. &nbsp;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'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'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: blueroofmusic@gmail.com<br>
&gt; &gt; winter:<br>
&gt; &gt; 579 Park Place &nbsp;Saline, MI &nbsp;48176<br>
&gt; &gt; 734-944-0094<br>
&gt; &gt; summer:<br>
&gt; &gt; PO Box 221 &nbsp;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;nchen@okidata.com&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 &nbsp;- Security Threats from Executable Resources<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; It'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'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'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's case 2) - I don'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'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: nchen@okidata.com<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &nbsp;*Ira McDonald &lt;blueroofmusic@gmail.com&gt;*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 05/12/2009 03:15 PM<br>
&gt; &gt; &gt; &nbsp; To<br>
&gt; &gt; &gt; mfd@pwg.org, NancyChen &lt;nchen@okidata.com&gt;, Ira McDonald
&lt;<br>
&gt; &gt; &gt; blueroofmusic@gmail.com&gt; &nbsp;cc<br>
&gt; &gt; &gt; &nbsp; 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, &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; &nbsp;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 'Executable' MUST be
handled with<br>
&gt; &gt; &gt; special care by implementations of the Resource Service.
&nbsp;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. &nbsp;In particular, such Resources
can be used<br>
&gt; &gt; &gt; to introduce Trojan Horses to the Imaging System. &nbsp;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 'Static' SHOULD be treated
with<br>
&gt; &gt; &gt; special care by implementations of the Resource Service.
&nbsp;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. &nbsp;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: blueroofmusic@gmail.com<br>
&gt; &gt; &gt; winter:<br>
&gt; &gt; &gt; 579 Park Place &nbsp;Saline, MI &nbsp;48176<br>
&gt; &gt; &gt; 734-944-0094<br>
&gt; &gt; &gt; summer:<br>
&gt; &gt; &gt; PO Box 221 &nbsp;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><br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.