Hi Nancy,
Trusted path for firmware merely means you know which
upstream server was corrupted - at least, if you CHECK
the content of the firmware before blindly executing it.
And user scripts (and PostScript-like PDL jobs) can be
highly effective Denial-of-Service attacks (by crashing the
entire MFD or just the Print Service) unless scanned by
antivirus/antimalware tools.
Those are real threats.
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 2:42 PM, <nchen at okidata.com> wrote:
>> Hi Ira,
>> P2600 covers the security threats that you mentioned here.
>> In short, firmware update must be through trusted path.
>> User's document if needed (depending on site security requirement), must be
> protected from disclosure and/or alteration.
>> 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.
>> Many MFPs today do not have these security in place, but they will
> eventually when they comply to the security standard.
>> -Nancy
>>>> *Ira McDonald <blueroofmusic at gmail.com>*
>> 05/14/2009 01:56 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,
>> 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/64e48e68/attachment-0001.html>