[MFD] Re: Resource Service updates for Security

[MFD] Re: Resource Service updates for Security

[MFD] Re: Resource Service updates for Security

Ira McDonald blueroofmusic at gmail.com
Thu May 14 20:09:00 UTC 2009


Hi Nancy,

Right - my point is, after you verify the digital signature,
prudent security implementation is to SCAN the firmware
before making it your next boot image - what if the correct
digital signature comes from an enterprise server that has
ITSELF become corrupted?  Digital signature's no help.

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 3:00 PM, <nchen at okidata.com> wrote:

>
> Hi Ira,
>
> Yes, trusted path, with encryption and signature whenever necessary. In
> your case, you need to check the signature before executing.
>
> -Nancy
>
>
>
>  *Ira McDonald <blueroofmusic at gmail.com>*
>
> 05/14/2009 02:55 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,
>
> 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/63570873/attachment-0001.html>


More information about the mfd mailing list