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 • editor@issa.org • 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 • editor@issa.org • 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 • editor@issa.org • 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 • editor@issa.org • 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 • editor@issa.org • 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 brian.smithson@ricoh-usa.com or brian.smithson@ieee.org. 13IEEE P2600 Working Group – grouper.ieee.org/groups/2600. ©2009 Information Systems Security Association • www.issa.org • editor@issa.org • Permission for author use only. 33