the Ieee 2600 Series

Transcription

the Ieee 2600 Series
ISSA
Preeminent Trusted Global
Information Security Community
ISSA Journal | November 2009
Working with Standards – Special Section
In this section we will be presenting articles from information security professionals in the trenches and working with a wide variety
of national and international standards.
The IEEE 2600 Series
An introduction to new security standards
for hardcopy devices
By Brian Smithson – ISSA member, Silicon Valley, USA Chapter
This article describes the IEEE 2600-series of standards for Hardcopy Device and System
Security that has been developed by major hardcopy device manufacturers.
Abstract
This article describes the IEEE 2600-series of standards for
Hardcopy Device and System Security that has been developed by major hardcopy device manufacturers. It includes
the purpose, outline of content, intended use, and availability of the standards, and concludes with information about
how they can be used by customers for selection and procurement, and by security professionals for secure configuration
and use.
O
nce upon a time, printers were unsophisticated
peripherals connected to host computers through
unidirectional interfaces, and copy machines connected only to a power outlet. Unless you count the CIA’s “alleged” cold war installation of secret cameras in Soviet embassy copiers,1 the main security issue for such devices was
that users would leave their input on the copier glass or forget
to retrieve their printed output.
Today’s hardcopy devices (HCD) have enough processing,
storage, and communications capabilities to have become
enticing targets for misuse. Since HCDs are used to print,
scan, copy, and fax important and sensitive documents, an
unprotected HCD can be an effective channel for information theft. And since HCDs are shared resources, often not as
closely monitored as workstations and servers, unprotected
HCDs can be used with impunity as a platform for network
attacks.
1 Dawn Stover, “Spies in the Xerox Machine,” Popular Science (January, 1997, pp.
68-70); Ron Laytner, “Xerox Helped Win The Cold War”, (Edit International, 2006) –
editinternational.com/read.php?id=47ddf19823b89.
28
Motivated by an increase in security requirements from industry and government agencies and by the enactment of
privacy and governance regulations, a presentation2 given at
a NIST workshop in 2003 led major HCD manufacturers to
form the IEEE P2600 working group.3 The working group’s
purpose was to create security standards for HCDs, drawn
from the collective experience of dozens of individuals from
major hardcopy device manufacturers, test labs, government
agencies, and other organizations.
The result of this effort is a series of five IEEE standards for
hardcopy device security:
1. IEEE 2600™-2008 “Standard for Information Technology: Hardcopy Device and System Security”
2. IEEE 2600.1™-2009 “Standard for a Protection Profile
in Operational Environment A”
3. IEEE 2600.2™ (not yet published) “Standard Protection Profile for Hardcopy Devices in IEEE Std. 2600™2008 Operational Environment B”
4. IEEE 2600.3™ (not yet published) “Standard Protection Profile for Hardcopy Devices in IEEE Std. 2600™2008 Operational Environment C”
5. IEEE 2600.4™ (not yet published) “Standard Protection Profile for Hardcopy Devices in IEEE Std. 2600™2008 Operational Environment D”
This article will explore what is in these standards, how they
relate to one another, how they are used by manufacturers,
2 Don Wright, “Hardcopy Device Security: An Open Door,” presented at the
Workshop on Building Security Checklists for IT Products, (NIST, September 25-26,
2003) – grouper.ieee.org/groups/2600/presentations/nist-09-2003.pdf.
3 For more information, visit the IEEE P2600 Working Group web site at grouper.ieee.
org/groups/2600.
©2009 Information Systems Security Association • www.issa.org • [email protected] • Permission for author use only.
The IEEE 2600 Series of Security Standards | By Brian Smithson
and how they can be used by customers and security professionals.
Security in the eye of the stakeholder
Individual HCDs are relatively straightforward devices, but
it is challenging to write a general security standard for any
broad class of devices that are so widely used in so many different environments. What are the assets to be protected, and
what value should be assigned to each asset? What are the
threats? What mitigations are appropriate, both technical
and non-technical? And who should answer those questions:
the data owner, device administrator, or network administrator?
The most obvious assets of an HCD are the documents being printed, scanned, copied, faxed, or stored. Among the
other assets to be considered are user and administrator credentials, credentials used by the HCD to communicate with
other devices on the network, the utility of the HCD itself
(its physical resources, permission to use it, and denial of service), and indirectly, other devices on the network that might
be compromised if the HCD is used to attack them.
The relative value of these assets depends on who you ask,
what purpose the HCD is being used for, and in what environment it is being used.
The P2600 working group’s approach was to define four common operational environments, based on a concept used by
the NIST national checklist program for IT products,4 named
Operational Environments A, B, C, and D:
A –For handling documents that are highly proprietary
or subject to legal or regulatory requirements
B – For general enterprise use
C –For use in public-facing environments like self-service copy/print shops or hotel business centers
ISSA Journal | November 2009
• Clauses 1-3 introduce the standard and hardcopy devices.
• Clause 4 defines and provides examples of the four operational environments upon which the 2600-series standards are based.
• Clause 5 defines the assets of an HCD that are considered
by the standard.
• Clause 6 describes threats against those assets.
• Clause 7 describes mitigation techniques that may be used
to address each threat described in Clause 6. When appropriate, mitigation techniques are provided for manufacturers, administrators, and users.
• Clause 8 is the Compliance Clause, which specifies security objectives for each operational environment that is
required to claim compliance with the standard. It also
provides example mitigation techniques that may be used
to accomplish these objectives.
• Annex A contains a lengthy collection of security best
practices for manufacturers, administrators, and users.
• Annex B is a bibliography.
A copy of IEEE 2600-2008 may be obtained on the IEEE website.5
HCDs and the Common Criteria
A manufacturer can claim that its product complies with
IEEE 2600-2008 without any independent testing or confirmation. However, many customers require independent testing as a matter of policy; this is particularly true of government agencies. A widely accepted way to fulfill such policies is
to use the Common Criteria,6 which is an internationally recognized methodology for expressing security requirements
for IT products and for evaluating products to determine if
they fulfill their stated security claims.
Once a set of operational environments had been defined, it
became possible to make assumptions about each environment and make generalizations about the assets to be protected, threats associated with those assets, and objectives to
mitigate those threats. This formed the basis for IEEE 26002008, the Standard for Information Technology: Hardcopy Device and System Security.
Many HCD manufacturers have obtained Common Criteria
certification for products, but unless certification is based on
a standard set of security requirements, it only assures that
a manufacturer’s claims have been faithfully implemented
in its product. Historically, Common Criteria certification
of HCDs has varied widely with security claims of hard disk
secure erasure or encryption, user or administrator authentication, network port control, prevention of fax modems misuse, and the like.
IEEE 2600-2008
Protection Profiles for HCDs
D –For use in small offices or home offices
IEEE 2600-2008 serves two audiences: for HCD manufacturers, it provides guidance on secure architecture, design, and
default configuration of their products; for HCD administrators and users, it provides guidance on secure installation,
configuration, and use of those products.
The standard is composed of eight clauses and two annexes:
4 Stephen D. Quinn, Karen Scarfone, and Murugiah Souppaya, “National Checklist
Program for IT Products – Guidelines for Checklist Users and Developers,” (NIST,
2008) – csrc.nist.gov/publications/drafts/800-70-rev1/Draft-SP800-70-r1.pdf.
A common standard for evaluating HCD product
security
By itself, the Common Criteria is an evaluation methodology, not a prescriptive security standard. However, Common
Criteria can prescribe security requirements if a protection
5 To obtain a copy of IEEE 2600-2008, go to standards.ieee.org. There is a fee.
6 For more information, visit the Common Criteria Portal at www.
commoncriteriaportal.org.
©2009 Information Systems Security Association • www.issa.org • [email protected] • Permission for author use only.
29
The IEEE 2600 Series of Security Standards | By Brian Smithson
profile is used as the basis for product evaluation. A protection profile is a document that expresses an information security problem for a class of IT products, describes the security objectives that solve that problem, and specifies security
requirements that fulfill those objectives. The P2600 working
group developed one Common Criteria protection profile for
each of the four operational environments that it defined in
IEEE 2600-2008. Those protection profiles are IEEE 2600.1,
2600.2, 2600.3, and 2600.4.
One standard that applies to many HCD
configurations
Among the challenges faced during the development of those
protection profiles is that they cover a wide variety of HCDs,
from a simple parallel-port printer, USB scanner, standalone
copier, or fax machine, to a complex networked multifunctional device with hard disk storage, document storage, and
retrieval features. The Common Criteria does not provide a
standard way to handle product configurations or options.
To accommodate a variety of configurations, the 2600.n profiles are composed of two parts:
1. A common profile that describes the generic security
problem, security objectives, and security requirements that must be fulfilled by all HCDs
2. A collection of seven packages of additional security
requirements that apply only to certain configurations
The additional packages define requirements for HCD s that
have the following features:
• Printing
• Scanning
• Copying
ISSA Journal | November 2009
• The threats against HCD assets
• Assumptions about the environment, users, or usage
of the HCD
• Additional security-related policies that are addressed
by the protection profile
• Three types of security objectives to mitigate the threats,
uphold the assumptions, and enforce the policies of the
Security Problem Definition:
• Security objectives that must be met by the HCD itself
• IT-related security objectives that are expected to be
met by the operational environment
• Non-IT-related security objectives that are expected
to be met by the operational environment
• Security Functional Requirements that apply to all HCDs
to fulfill the first type of security objectives.
• One or more packages of additional Security Functional
Requirements that apply only to specific HCD configurations
All of the HCD protection profiles conform to Common Criteria version 3.1, revision 2.
Differences between the four profiles
Examining the security needs of each operational environment that was defined in IEEE 2600-2008, a certain hierarchy
emerged. Although it may be correct to say that the Environment A needs higher security than Environment B (and so
forth), the main distinction among the four environments
emerged: Environment A needs a higher level of user accountability than Environment B (and so forth), as shown in Figure 1.
• Faxing
• Document storage and retrieval
• Removable non-volatile system storage
• Network interfaces
A product under evaluation must always conform to the common profile. It must also conform to any and all packages that apply to that
product’s configuration. For example, if a particular product has a network interface, then
that product must fulfill the network interface
requirements package.
Contents of the profiles
Each of the 2600.n protection profiles contains the following information:
• An overview of HCDs that describes what
the devices do and how they are used and
defines user roles, information assets, information operations, and interfaces
• A Security Problem Definition that defines:
30
Figure 1 – Operational Environments and User Accountability
©2009 Information Systems Security Association • www.issa.org • [email protected] • Permission for author use only.
The IEEE 2600 Series of Security Standards | By Brian Smithson
To further illustrate this hierarchy, consider the accountability required for an unprivileged user who uses a printer. If it is
in an environment (“A”) that is subject to HIPAA regulation,
then each print job may need to be fully auditable to record
who printed what. If it is in a more general enterprise office
environment (“B”), then who printed what may not matter,
but user identity in unsuccessful operations or other security-relevant events should be auditable. If it is in a self-service
public environment (“C”), then user identity is not important, but authorization and usage accounting is still useful.
And finally, if it is in a small office environment (“D”), then
accountability is not required for unprivileged users, but as in
the other environments, privileged users must still be identified and authorized.
Security and assurance requirements
Taking into consideration the accountability and other distinguishing characteristics of each environment, the P2600
working group developed a set of security and assurance
requirements for each protection profile. These are summarized in Table 1, and each category is described below:
ISSA Journal | November 2009
Evaluation Assurance Level (EAL) and flaw remediation
EAL and flaw remediation are defined by the Common Criteria, part 3. In environments A, B, and C, the standard EALs
are augmented by flaw remediation requirements that are satisfied by policies and procedures for detecting and correcting security flaws. The primary differences between levels 1
and 2 flaw remediation are that level 2 requires procedures
for accepting flaw reports from users and regression testing
of remediation.
User identification, authentication, authorization
Users are identified and authenticated to authorize their use
of the HCD. A user’s identity can then be associated with jobs
and documents to protect them from unauthorized access.
User identity is also associated with event logging in profiles
that require logging. It is required in environments A and
B. It is optional in environment C, because in some publicfacing environments, users may be implicitly authorized by
physical access. Users are not identified at all in environment
D. Manufacturers can define more detailed user roles and
authorization rules that may be supported by their product.
Profile
Requirement
2600.1
2600.2
2600.3
2600.4
Environment
A
B
C
D
3+
2+
2+
1
Additional flaw remediation
assurance
Level 2
Level 2
Level 1
None
User identification, authentication, authorization
Yes
Yes
Optional
None
Administrator identification,
authentication, authorization
Yes
Yes
Yes
Yes
User document security
At rest, in
motion,
residual
At rest,
residual
Residual
None
Job data security
At rest, in
motion
At rest
None
None
Security data protection/confidentiality
Yes
Yes
Yes
Yes
Managed interfaces
Yes
Yes
Yes
Yes
Software self-verification
Yes
Yes
Yes
Yes
Complete
audit
Exception/
violation
Exception/
violation
None
7
7
1
1
Evaluation assurance level
Logging
Applicable requirements
packages
Table 1 – Security and Assurance Requirements
Administrator identification, authentication,
authorization
Administrators are identified and authenticated
to authorize their access to management of the
HCD. Administrator identity is also associated
with event logging in profiles that require logging.
User document
User documents can be secured in electronic form
while in motion (transmitted over a network) and
at rest (persistently stored on the HCD), and residual data can be made inaccessible after documents have been logically deleted. All such modes
are required in environment A. In environment
B, security is required for documents at rest and
for residual data. In the public-facing environment of environment C, there is no assumption of
document confidentiality while a user is present,
but residual data security is provided after the
user has finished a job. Since users are not identified in environment D, user document security is
not provided.
Job data
Job data consists of information about documents and document processing jobs. In environment A, it is secured at rest and in motion. In
environment B, job data security is required for
documents at rest. There is no assumption of job
data confidentiality in environment C. Since users are not identified in environment D, job data
security is not provided.
Security data
Security data is categorized as either protected or
confidential. Protected data are data that can be
©2009 Information Systems Security Association • www.issa.org • [email protected] • Permission for author use only.
31
The IEEE 2600 Series of Security Standards | By Brian Smithson
disclosed but must not be modified without appropriate authorization. Examples of protected data include user names
and the names or addresses of destination servers. Confidential data are data that must not be disclosed or modified without appropriate authorization. Examples of confidential data
include user passwords and credentials for accessing destination servers. The 2600-series standards provide guidance for
manufacturers to identify and categorize security data that is
present in their product.
Managed interfaces
Interface management is intended to protect other devices on
a customer’s network by ensuring that those interfaces can
only be used by controlled functions of the HCD and that
one interface cannot be bridged to another interface without
administrative permission.
Software self-verification
Software self-verification is intended to ensure that the operating software has not been corrupted by some kind of
malfunction. Since software is being used to verify itself, it
does not provide complete assurance that the software has
not been maliciously altered.
Logging
Event logging can be used for auditing usage, recording security events, and accounting. Although accounting is a
common feature of HCDs, it is not a security feature and is
therefore not required by the profiles. In environment A, successful (audit) and unsuccessful (security) events are logged.
In environments B and C, only unsuccessful (security) events
are logged. There is no logging requirement in environment
D.
Requirements packages
In addition to a common set of security requirements that
apply to all HCDs, additional requirements apply to particular configurations. Depending on a particular product’s configuration, all seven requirements packages can be applied
in environments A and B. However, except for the network
interface requirements package, the requirements contained
in those packages are not used in environments C and D, and
therefore only the network interface package is applicable to
environments C and D.
Relationship between IEEE 2600 and the
2600.n protection profiles
The Compliance Clause of IEEE 2600-2008 contains security
objectives that closely parallel those found in the protection
profiles. The differences are a result of idiosyncrasies of the
Common Criteria that are beyond the scope of this article.
IEEE 2600.1-2009
IEEE 2600.1 is the protection profile for HCDs that handle
information that is highly proprietary or subject to legal or
regulatory requirements. It has been accepted as the U.S.
ISSA Journal | November 2009
Government Protection Profile for Hardcopy Devices in Basic
Robustness Environments. It was certified by NIAP CCEVS7
in June, 2009. It is free of charge from the IEEE,8 NIAP,9 and
from the Common Criteria Portal.10
IEEE 2600.2
IEEE 2600.2 is the protection profile for HCDs in general enterprise environments. It is currently being validated for certification by BSI11 and is expected to be approved by the IEEE
and certified by BSI in 2010. At that time, it will be published
by the IEEE and made available free of charge from the IEEE,
BSI, or the Common Criteria Portal.12
IEEE 2600.3 and IEEE 2600.4
IEEE 2600.3 is the protection profile for HCDs in publicfacing environments, and IEEE 2600.4 is for HCDs in small
office/home office environments. Due to economic conditions, the P2600 working group has been unable to fund the
certification and free publication of these profiles. They are
expected to be approved as IEEE standards in 2010, but cannot be used as the basis for Common Criteria product evaluation unless they are certified sometime in the future. In the
meantime, they can be used as references for assessing the
security of HCD products for their respective environments.
How to use the IEEE 2600 series standards
Interpreting manufacturers’ claims
HCD manufacturers can claim product compliance to IEEE
2600-2008 for one or more of the defined operational environments. Such claims do not require independent testing
and confirmation.
Manufacturers’ primary use of the IEEE 2600 series will be
to submit products for Common Criteria certification which
claim conformance to IEEE 2600.1-2009. At this writing, several manufacturers have already begun the evaluation process for such certification.
Product procurement
HCD customers can use the IEEE 2600 series to help specify,
identify, and select products that meet their security needs.
The first step is to identify the IEEE 2600 operational environment that most closely applies to your intended environment. Once identified, you have several choices:
• Require Common Criteria certification conforming to the
protection profile for your environment. At this writing,
7 NIAP CCEVS is the National Information Assurance Partnership, Common Criteria
Evaluation and Validation Service. It is the U.S. national Common Criteria scheme.
For more information, visit niap-ccevs.org.
8 IEEE – standards.ieee.org/getieee/2600.
9 NIAP – niap-ccevs.org/cc-scheme/pp.
10Common Criteria Portal – commoncriteriaportal.org/pp_OD.html#OD.
11BSI is the Bundesamt für Sicherheit in der Informationstechnik. It is the German
national Common Criteria scheme. For more information, visit bsi.de.
12Ibid.
32
©2009 Information Systems Security Association • www.issa.org • [email protected] • Permission for author use only.
The IEEE 2600 Series of Security Standards | By Brian Smithson
only IEEE 2600.1-2009 is available. IEEE 2600.2 is expected to be certified in 2010, but certification is not planned
for 2600.3 and 2600.4.
• If no certified products are available for your environment, then require compliance to IEEE 2600-2008 for
your environment.
• If no products claim compliance to IEEE 2600-2008 for
your environment, then the security objectives and other
guidance in IEEE 2600-2008 can be used to help identify
and select products. The security objectives and requirements of the protection profile for your environment can
be used in a similar way, even if the protection profile has
not been certified.
Product configuration and use
HCD administrators and other security professionals can
use the IEEE 2600 series to help securely configure and use
HCDs:
• Follow the guidance in IEEE 2600-2008, clauses 7 and 8
and Annex A.
• Uphold the assumptions and fulfill the IT and non-IT environmental security objectives that are defined in the applicable IEEE 2600.n protection profile.
Conclusion
Hardcopy devices have become sophisticated networked information processing, communication, and storage devices
that deserve security consideration similar to workstations,
ISSA Journal | November 2009
servers, and other endpoint devices. IEEE 2600-2008 is a
baseline standard for hardcopy device security applied to
four typical operational environments and provides relevant
guidance to manufacturers, purchasers, administrators, and
users to ensure the effectiveness of the standard. The IEEE
2600.n series of protection profiles are related standards that
can be used for independently testing and certifying product
conformance.
For more information
The IEEE P2600 Working Group maintains a website13 and
plans to publish a Guide for the Development of Security Targets Conforming to the IEEE Std. 2600 Series of Protection Profiles in 2009-2010. It will be available free of charge from that
website.
About the Author
Brian Smithson, CISSP, CISA, PMP, CSM,
is a project manager for security research
in the Advanced Imaging and Networking
Technologies group of Ricoh Americas Corporation in Cupertino, California. He has
been an officer of the IEEE P2600 working
group since 2004, an editor for IEEE 2600,
and the lead editor for IEEE 2600.1, 2600.2, 2600.3, and 2600.4.
Brian can be contacted at [email protected] or
[email protected].
13IEEE P2600 Working Group – grouper.ieee.org/groups/2600.
©2009 Information Systems Security Association • www.issa.org • [email protected] • Permission for author use only.
33