attachment.htm
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 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 10:54 AM, <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">I haven't seen any security certification
requirement that requires onboard antivirus on MFP yet. Not sure
what's the basis of your prediction. Antivirus software vendors of course
will try to push their products on any platform. If you have not implemented
MFP security standard, properly configure the system to secure it, antivirus
might be a good idea to have. But once you have proper security instrumented,
antivirus is not that critical. It's nice to have of course.</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/13/2009 06:20 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>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>
</tt></font>
<br><font size="2"><tt>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>
</tt></font>
<br><font size="2"><tt>MFDs running Linux or other general-purpose operating
systems<br>
are just too dangerous anymore without antivirus (or firewalls).<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 Wed, May 13, 2009 at 5:49 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>
> 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
is<br>
> safe to execute. There are many other techniques to verify the integrity
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 for -<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 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.
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
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 an<br>
> > Imaging System to have such software implemented which involves
constant<br>
> > maintenance of upto-date virus signatures by external systems.
At the<br>
> > abstract level, we can provide some good security objectives
to 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 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
which<br>
> > should also be protected for alteration. Therefore, not only
storage or<br>
> > retrieval operations on Resources must be restricted, other operations
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>
> > 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 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
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 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: <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>
></tt></font>
<br>
<br>
<br></div></div></blockquote></div><br>