Hi Ira,
I am not sure why Health Assessment does not detect a server that has been
attacked and had its antivirus compromised. I certainly hope that the
situation would have been detected before MFD needed to scan virus.
What I want to say is that if a server has good security on guard, has
antivirus, and Health Assessment, and MFD has its P2600 standard level of
security on guard, then I don't think MFD's antivirus is that necessary.
-Nancy
Ira McDonald <blueroofmusic at gmail.com>
05/14/2009 04:46 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,
The MFD does NOT have access to the current Health Assessment
for the upstream enterprise server - if that server has been attacked
and had its antivirus compromised, then it behooves the MFD NOT
to trust the firmware blindly - the essence of security is "trust nobody
more than you have to" - desktops (and now mobile devices) need
antivirus because sometimes the INFRASTRUCTURE systems get
corrupted too.
That was my point.
If an MFD doesn't have sufficient free-standing self-defense, then
sooner or later that MFD will be quarantined during Network
Endpoint Attachment and Health Assessment by a site policy that
doesn't accept the premise that "security is out-of-scope".
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 4:31 PM, <nchen at okidata.com> wrote:
>> Hi Ira,
>> I hope the enterprise server itself already has antivirus software that
can
> detect the corruption before MFD retrieve the file. Otherwise, the
antivirus
> does not work well on the enterprise server. If that's the case, what's
the
> use to install antivirus software on MFD then?
>> -Nancy
>>>> *Ira McDonald <blueroofmusic at gmail.com>*
>> 05/14/2009 04:09 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,
>> 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/4d752770/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20090514/4d752770/attachment.htm>