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 <blueroofmusic@gmail.com></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 <blueroofmusic@gmail.com></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 "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>
</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 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, <nchen@okidata.com>
wrote:<br>
</tt></font>
<br><font size=2><tt>><br>
> Hi Ira,<br>
><br>
> I haven't seen any security certification requirement that requires
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 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 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 <blueroofmusic@gmail.com>*<br>
><br>
> 05/13/2009 06:20 PM<br>
> To<br>
> nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com> cc<br>
> mfd@pwg.org 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: blueroofmusic@gmail.com<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, <nchen@okidata.com> 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 an<br>
> > MFD or HCD to verify whether the stored or retrieved Executable
Resources<br>
> is<br>
> > safe to execute. There are many other techniques to verify the
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 <blueroofmusic@gmail.com>*<br>
> ><br>
> > 05/13/2009 05:01 PM<br>
> > To<br>
> > nchen@okidata.com, Ira McDonald <blueroofmusic@gmail.com><br>
> > cc<br>
> > mfd@pwg.org 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: blueroofmusic@gmail.com<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, <nchen@okidata.com> 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 for<br>
> -<br>
> > > 1) storing Executable Resources at an external storage location
that<br>
> > > involves an external system for storing the resource, and
the 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
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 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, but<br>
> > > rarely existent in Imaging Systems. It's simply not that
practical 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 integrity<br>
> > of<br>
> > > the resources and their related metadata. Like case 1),
the storage 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 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 or<br>
> > > retrieval operations on Resources must be restricted, other
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>
> > > 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: nchen@okidata.com<br>
> > ><br>
> > ><br>
> > ><br>
> > > *Ira McDonald <blueroofmusic@gmail.com>*<br>
> > ><br>
> > > 05/12/2009 03:15 PM<br>
> > > To<br>
> > > mfd@pwg.org, NancyChen <nchen@okidata.com>, Ira McDonald
<<br>
> > > blueroofmusic@gmail.com> 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 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 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 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>
> > ><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
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>
> > ><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: blueroofmusic@gmail.com<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>
></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.