Hi Nancy,
OK - I'm fascinated.
What conceivable system security could replace the
need for onboard antivirus software?
Especially given that many MFDs now update firmware
via a "special" Print Job - and do NOT have digitally
signed firmware packages with an unbroken, network-
accessible chain of authority to a major public Certificate
Authority.
Certainly scripts and macros invoked in ordinary
Print Jobs are very easily corrupted - users create
them, so they aren't digitally signed - verification of
source does NOT remove the need for verification
that the source system was not in fact corrupted.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Thu, May 14, 2009 at 10:54 AM, <nchen at okidata.com> wrote:
>> Hi Ira,
>> 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.
>> -Nancy
>>>> *Ira McDonald <blueroofmusic at gmail.com>*
>> 05/13/2009 06:20 PM
> To
>nchen at okidata.com, Ira McDonald <blueroofmusic at gmail.com> cc
>mfd at pwg.org Subject
> Re: Resource Service updates for Security
>>>>> Hi Nancy,
>> Several vendors currently offer MFDs that incorporate virus
> scanning of all files and executable modules and that CAN
> integrate into enterprise antivirus update schemes.
>> Anyway, it was only an EXAMPLE (not a requirement) - though
> I think you will find that network endpoint attachment protocols
> and architectures are ALL going to require that you certify
> that you have healthy onboard antivirus on your MFD in the
> very near future.
>> MFDs running Linux or other general-purpose operating systems
> are just too dangerous anymore without antivirus (or firewalls).
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic at gmail.com> winter:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> summer:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>>> On Wed, May 13, 2009 at 5:49 PM, <nchen at okidata.com> wrote:
>> >
> > Hi Ira,
> >
> > I agree that
> >
> > "The threat is EXECUTING those Resources on an Imaging
> > System (the one hosting the Resource Service or ANY other
> > Imaging System) or even a desktop client system."
> >
> > and
> >
> > "The Resource Service spec should NOT say anything,
> > anywhere about internal versus external storage and
> > should NEVER reference a Resource Repository."
> >
> > But I don't think "virus scan" is practical for an Imaging System like an
> > MFD or HCD to verify whether the stored or retrieved Executable Resources
> is
> > safe to execute. There are many other techniques to verify the integrity
> of
> > these type of resources that are more practical for an MFD or HCD.
> >
> > Did I misunderstand something?
> >
> > -Nancy
> >
> >
> >
> > *Ira McDonald <blueroofmusic at gmail.com>*
> >
> > 05/13/2009 05:01 PM
> > To
> > nchen at okidata.com, Ira McDonald <blueroofmusic at gmail.com>
> > cc
> > mfd at pwg.org Subject
> > Re: Resource Service updates for Security
> >
> >
> >
> >
> > Hi Nancy,
> >
> > Internal or external storage of the Resouces has NOTHING to
> > do with the security threat in 11.4 below.
> >
> > The threat is EXECUTING those Resources on an Imaging
> > System (the one hosting the Resource Service or ANY other
> > Imaging System) or even a desktop client system.
> >
> > The Resource Service spec should NOT say anything,
> > anywhere about internal versus external storage and
> > should NEVER reference a Resource Repository.
> >
> > Every reference in 11.1 through 11.3 to Resource
> > Repository should be deleted. Users do NOT know
> > where a Resource Service stores things - if a vendor
> > does such an extension, then that vendor has broken
> > good security practice in their system design and
> > will justifiably fail independent security audits.
> >
> > The Resource Service is completely responsible *on its
> > own* for every Resource that it stores (anywhere) or allows
> > an authenticated user to retrieve (from the Resource
> > Service, that is).
> >
> > Any network system that hosts a Resource Service
> > is, by definition, an Imaging System - it may not be
> > dedicated (single-purpose), but it's still an Imaging
> > System.
> >
> > Another way of putting it is that "Imaging System"
> > is NOT simply a synonym for "Multifunction Device"
> > - it's a wider definition that includes Spoolers and
> > network server-hosted Imaging Services.
> >
> > Cheers,
> > - Ira
> >
> > Ira McDonald (Musician / Software Architect)
> > Chair - Linux Foundation Open Printing WG
> > Blue Roof Music/High North Inc
> > email: blueroofmusic at gmail.com> > winter:
> > 579 Park Place Saline, MI 48176
> > 734-944-0094
> > summer:
> > PO Box 221 Grand Marais, MI 49839
> > 906-494-2434
> >
> >
> > On Wed, May 13, 2009 at 12:16 PM, <nchen at okidata.com> wrote:
> >
> > >
> > > Hi Ira,
> > >
> > > Thanks for the text for the Security Consideration.
> > >
> > > Here are something I need to clarify, and some comments.
> > >
> > > 11.4 - Security Threats from Executable Resources
> > >
> > > It's not clear to me whether the security problem described here is for
> -
> > > 1) storing Executable Resources at an external storage location that
> > > involves an external system for storing the resource, and the Resource
> > > Service is hosted by an Imaging System. Or,
> > > 2) storing Executable Resources internally within the Imaging System
> that
> > > hosts the Resource Service.
> > >
> > > In both cases the security threat is to the Imaging System.
> > >
> > > If it's case 1) - I agree that the external system "SHOULD verify the
> > > safety of such resources (e.g., by virus scanning)". But we agreed in
> > last
> > > face-to-face meeting that it's out of scope of Resource Service to
> > consider
> > > anything related to the external storage system. What Resource Service
> > > should consider is the restriction of the storage and retrieval
> > operations
> > > on such resources to authorized users. How the external storage system
> > > should protect the stored executable resources is out of scope.
> Although
> > I
> > > prefer to recommend some security objectives to be considered by the
> > > external storage system.
> > >
> > > If it's case 2) - I don't think we should give "virus scanning" as an
> > > example to an Imaging System to protect the stored Executable
> Resources.
> > > Virus scanning or intrusion detection techniques are common in PCs, but
> > > rarely existent in Imaging Systems. It's simply not that practical for
> an
> > > Imaging System to have such software implemented which involves
> constant
> > > maintenance of upto-date virus signatures by external systems. At the
> > > abstract level, we can provide some good security objectives to
> consider
> > for
> > > the Imaging System, such as protection of confidentiality and integrity
> > of
> > > the resources and their related metadata. Like case 1), the storage and
> > > retrieval of operations on such resources must to restricted to
> > authorized
> > > users.
> > >
> > > A Resource Service could be hosted by a computer remote to the Imaging
> > > System that is under security consideration. We should consider this
> case
> > > too.
> > >
> > > 11.5 - Security Threats from Static Resources
> > >
> > > Static resources that have associated Intellectual Property rights or
> > > license rights that involves metadata such as DateTimeOfExpiration
> which
> > > should also be protected for alteration. Therefore, not only storage or
> > > retrieval operations on Resources must be restricted, other operations
> on
> > > resource metadata must be restricted too.
> > >
> > > Aslo the security problem you described here is for storing Static
> > > Resources internally in an Imaging System that hosts the Resource
> > Service.
> > > We should also consider the case when the Resource Service could be
> > hosted
> > > by a computer remote to the Imaging System.
> > >
> > > Thanks,
> > > -Nancy
> > >
> > >
> >
> -----------------------------------------------------------------------------
> > > Principal Engineer
> > > Solutions and Technology
> > > Oki Data
> > > 2000 Bishops Gate Blvd.
> > > Mt. Laurel, NJ 08054
> > > Phone: (856) 222-7006
> > > Email: nchen at okidata.com> > >
> > >
> > >
> > > *Ira McDonald <blueroofmusic at gmail.com>*
> > >
> > > 05/12/2009 03:15 PM
> > > To
> > > mfd at pwg.org, NancyChen <nchen at okidata.com>, Ira McDonald <
> > > blueroofmusic at gmail.com> cc
> > > Subject
> > > Resource Service updates for Security
> > >
> > >
> > >
> > >
> > > Hi Nancy, Tuesday (12 May
> 2009)
> > >
> > > Per my action from the Resource Service review during the April PWG
> > > meeting, below is some text for the Security Considerations section of
> > > the Resource Service.
> > >
> > > 11.4 Security Threats from Executable Resources
> > >
> > > Resources with a ResourceCategory of 'Executable' MUST be handled with
> > > special care by implementations of the Resource Service. Such
> resources
> > > can pose serious threats to the integrity of the Imaging System that
> > > hosts the Resource Service. In particular, such Resources can be used
> > > to introduce Trojan Horses to the Imaging System. If an implementation
> > > of the Resource Service supports Executable resources, then that
> > > implementation MUST restrict the storage of such resources (e.g., to
> > > authorized administrators and manufacturers) and SHOULD verify the
> > > safety of such resources (e.g., by virus scanning).
> > >
> > > 11.5 Security Threats from Static Resources
> > >
> > > Resources with ResourceCategory of 'Static' SHOULD be treated with
> > > special care by implementations of the Resource Service. Fonts that
> > > have associated Intellectual Property rights (e.g., as part of their
> > > network licenses) can pose serious threats to the availability of the
> > > Imaging System that hosts the Resource Service - security audits can
> > > result in the shutdown or physical removal of the Imaging System. If
> an
> > > implementation of the Resource Service supports Static resources that
> > > have associated Intellectual Property rights, then that implementation
> > > SHOULD restrict the storage of such resources (e.g., to authorized
> > > administrators and manufacturers) and SHOULD restrict the retrieval of
> > > such resources (e.g., to a configured group of authorized users).
> > >
> > > Comments?
> > >
> > > Cheers,
> > > - Ira
> > >
> > > Ira McDonald (Musician / Software Architect)
> > > Chair - Linux Foundation Open Printing WG
> > > Blue Roof Music/High North Inc
> > > email: blueroofmusic at gmail.com> > > winter:
> > > 579 Park Place Saline, MI 48176
> > > 734-944-0094
> > > summer:
> > > PO Box 221 Grand Marais, MI 49839
> > > 906-494-2434
> > >
> > >
> > >
> >
> >
> >
>>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20090514/d6169fc5/attachment-0001.html>