attachment-0001
Hi Nancy,<br><br>Right - my point is, after you verify the digital signature,<br>prudent security implementation is to SCAN the firmware<br>before making it your next boot image - what if the correct<br>digital signature comes from an enterprise server that has<br>
ITSELF become corrupted?� Digital signature's no help.<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 3:00 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">Yes, trusted path, with encryption and
signature whenever necessary. In your case, you need to check the signature
before executing.</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 <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></b>
</font>
</div><p><font size="1" face="sans-serif">05/14/2009 02:55 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 <<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><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>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>
</tt></font>
<br><font size="2"><tt>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>
</tt></font>
<br><font size="2"><tt>Those are real threats.<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 2:42 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>
wrote:<br>
</tt></font>
<br><font size="2"><tt>><br>
> Hi Ira,<br>
><br>
> P2600 covers the security threats that you mentioned here.<br>
><br>
> In short, firmware update must be through trusted path.<br>
><br>
> User's document if needed (depending on site security requirement),
must be<br>
> protected from disclosure and/or alteration.<br>
><br>
> There are many techniques to protect document disclosure and alteration.
We<br>
> think the best techniques to prevent from disclosure is by encryption,
to<br>
> detect alteration is by signing digital signature.<br>
><br>
> Many MFPs today do not have these security in place, but they will<br>
> eventually when they comply to the security standard.<br>
><br>
> -Nancy<br>
><br>
><br>
><br>
> �*Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
><br>
> 05/14/2009 01:56 PM<br>
> � To<br>
> <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>> �cc<br>
> <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> �Subject<br>
> Re: Resource Service updates for Security<br>
><br>
><br>
><br>
><br>
> Hi Nancy,<br>
><br>
> OK - I'm fascinated.<br>
><br>
> What conceivable system security could replace the<br>
> need for onboard antivirus software?<br>
><br>
> Especially given that many MFDs now update firmware<br>
> via a "special" 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>
><br>
> 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>
><br>
> Cheers,<br>
> - Ira<br>
><br>
> 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:<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>
> On Thu, May 14, 2009 at 10:54 AM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>> wrote:<br>
><br>
> ><br>
> > Hi Ira,<br>
> ><br>
> > I haven't seen any security certification requirement that requires<br>
> onboard<br>
> > antivirus on MFP yet. �Not sure what's the basis of your
prediction.<br>
> > Antivirus software vendors of course will try to push their products
on<br>
> any<br>
> > platform. If you have not implemented MFP security standard,
properly<br>
> > configure the system to secure it, antivirus might be a good
idea to<br>
> have.<br>
> > But once you have proper security instrumented, antivirus is
not that<br>
> > critical. It's nice to have of course.<br>
> ><br>
> > -Nancy<br>
> ><br>
> ><br>
> ><br>
> > �*Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> ><br>
> > 05/13/2009 06:20 PM<br>
> > � To<br>
> > <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>>
�cc<br>
> > <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> �Subject<br>
> > Re: Resource Service updates for Security<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Hi Nancy,<br>
> ><br>
> > Several vendors currently offer MFDs that incorporate virus<br>
> > scanning of all files and executable modules and that CAN<br>
> > integrate into enterprise antivirus update schemes.<br>
> ><br>
> > Anyway, it was only an EXAMPLE (not a requirement) - though<br>
> > I think you will find that network endpoint attachment protocols<br>
> > and architectures are ALL going to require that you certify<br>
> > that you have healthy onboard antivirus on your MFD in the<br>
> > very near future.<br>
> ><br>
> > MFDs running Linux or other general-purpose operating systems<br>
> > are just too dangerous anymore without antivirus (or firewalls).<br>
> ><br>
> > Cheers,<br>
> > - Ira<br>
> ><br>
> > 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:<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>
> > On Wed, May 13, 2009 at 5:49 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>> wrote:<br>
> ><br>
> > ><br>
> > > Hi Ira,<br>
> > ><br>
> > > I agree that<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>
> > > and<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>
> > > But I don't think "virus scan" is practical for
an Imaging System like<br>
> an<br>
> > > MFD or HCD to verify whether the stored or retrieved Executable<br>
> Resources<br>
> > is<br>
> > > safe to execute. There are many other techniques to verify
the<br>
> integrity<br>
> > of<br>
> > > these type of resources that are more practical for an MFD
or HCD.<br>
> > ><br>
> > > Did I misunderstand something?<br>
> > ><br>
> > > -Nancy<br>
> > ><br>
> > ><br>
> > ><br>
> > > �*Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> > ><br>
> > > 05/13/2009 05:01 PM<br>
> > > � To<br>
> > > <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>><br>
> > > �cc<br>
> > > <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> �Subject<br>
> > > Re: Resource Service updates for Security<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > 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>
> > > 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:<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>
> > > On Wed, May 13, 2009 at 12:16 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>
wrote:<br>
> > ><br>
> > > ><br>
> > > > Hi Ira,<br>
> > > ><br>
> > > > Thanks for the text for the Security Consideration.<br>
> > > ><br>
> > > > Here are something I need to clarify, and some comments.<br>
> > > ><br>
> > > > 11.4 �- Security Threats from Executable Resources<br>
> > > ><br>
> > > > It's not clear to me whether the security problem described
here is<br>
> for<br>
> > -<br>
> > > > 1) storing Executable Resources at an external storage
location that<br>
> > > > involves an external system for storing the resource,
and the<br>
> Resource<br>
> > > > Service is hosted by an Imaging System. Or,<br>
> > > > 2) storing Executable Resources internally within the
Imaging System<br>
> > that<br>
> > > > hosts the Resource Service.<br>
> > > ><br>
> > > > In both cases the security threat is to the Imaging
System.<br>
> > > ><br>
> > > > If it's case 1) - I agree that the external system
"SHOULD verify the<br>
> > > > safety of such resources (e.g., by virus scanning)".
But we agreed in<br>
> > > last<br>
> > > > face-to-face meeting that it's out of scope of Resource
Service to<br>
> > > consider<br>
> > > > anything related to the external storage system. What
Resource<br>
> Service<br>
> > > > should consider is the restriction of the storage and
retrieval<br>
> > > operations<br>
> > > > on such resources to authorized users. How the external
storage<br>
> system<br>
> > > > should protect the stored executable resources is out
of scope.<br>
> > Although<br>
> > > I<br>
> > > > prefer to recommend some security objectives to be
considered by the<br>
> > > > external storage system.<br>
> > > ><br>
> > > > If it's case 2) - I don't think we should give "virus
scanning" as an<br>
> > > > example to an Imaging System to protect the stored
Executable<br>
> > Resources.<br>
> > > > Virus scanning or intrusion detection techniques are
common in PCs,<br>
> but<br>
> > > > rarely existent in Imaging Systems. It's simply not
that practical<br>
> for<br>
> > an<br>
> > > > Imaging System to have such software implemented which
involves<br>
> > constant<br>
> > > > maintenance of upto-date virus signatures by external
systems. At the<br>
> > > > abstract level, we can provide some good security objectives
to<br>
> > consider<br>
> > > for<br>
> > > > the Imaging System, such as protection of confidentiality
and<br>
> integrity<br>
> > > of<br>
> > > > the resources and their related metadata. Like case
1), the storage<br>
> and<br>
> > > > retrieval of operations on such resources must to restricted
to<br>
> > > authorized<br>
> > > > users.<br>
> > > ><br>
> > > > A Resource Service could be hosted by a computer remote
to the<br>
> Imaging<br>
> > > > System that is under security consideration. We should
consider this<br>
> > case<br>
> > > > too.<br>
> > > ><br>
> > > > 11.5 - Security Threats from Static Resources<br>
> > > ><br>
> > > > Static resources that have associated Intellectual
Property rights or<br>
> > > > license rights that involves metadata such as DateTimeOfExpiration<br>
> > which<br>
> > > > should also be protected for alteration. Therefore,
not only storage<br>
> or<br>
> > > > retrieval operations on Resources must be restricted,
other<br>
> operations<br>
> > on<br>
> > > > resource metadata must be restricted too.<br>
> > > ><br>
> > > > Aslo the security problem you described here is for
storing Static<br>
> > > > Resources internally in an Imaging System that hosts
the Resource<br>
> > > Service.<br>
> > > > We should also consider the case when the Resource
Service could be<br>
> > > hosted<br>
> > > > by a computer remote to the Imaging System.<br>
> > > ><br>
> > > > Thanks,<br>
> > > > -Nancy<br>
> > > ><br>
> > > ><br>
> > ><br>
> ><br>
> -----------------------------------------------------------------------------<br>
> > > > Principal Engineer<br>
> > > > Solutions and Technology<br>
> > > > Oki Data<br>
> > > > 2000 Bishops Gate Blvd.<br>
> > > > Mt. Laurel, NJ 08054<br>
> > > > Phone: (856) 222-7006<br>
> > > > Email: <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > �*Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> > > ><br>
> > > > 05/12/2009 03:15 PM<br>
> > > > � To<br>
> > > > <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 <<br>
> > > > <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> �cc<br>
> > > > � Subject<br>
> > > > Resource Service updates for Security<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > Hi Nancy, � � � � � �
� � � � � � � � � � �
� � � �Tuesday (12 May<br>
> > 2009)<br>
> > > ><br>
> > > > Per my action from the Resource Service review during
the April PWG<br>
> > > > meeting, below is some text for the Security Considerations
section<br>
> of<br>
> > > > the Resource Service.<br>
> > > ><br>
> > > > 11.4 Security Threats from Executable Resources<br>
> > > ><br>
> > > > Resources with a ResourceCategory of 'Executable' MUST
be handled<br>
> with<br>
> > > > special care by implementations of the Resource Service.
�Such<br>
> > 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<br>
> used<br>
> > > > to introduce Trojan Horses to the Imaging System. �If
an<br>
> 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>
> > > ><br>
> > > > 11.5 Security Threats from Static Resources<br>
> > > ><br>
> > > > 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<br>
> > an<br>
> > > > implementation of the Resource Service supports Static
resources that<br>
> > > > have associated Intellectual Property rights, then
that<br>
> implementation<br>
> > > > SHOULD restrict the storage of such resources (e.g.,
to authorized<br>
> > > > administrators and manufacturers) and SHOULD restrict
the retrieval<br>
> of<br>
> > > > such resources (e.g., to a configured group of authorized
users).<br>
> > > ><br>
> > > > Comments?<br>
> > > ><br>
> > > > Cheers,<br>
> > > > - Ira<br>
> > > ><br>
> > > > 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:<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>
> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
></tt></font>
<br>
<br>
<br></div></div></blockquote></div><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.