Common Criteria Certification (ISO15408) Update

Transcription

1 Common Criteria Certification (ISO15408) Update November 2012 Eecutive Summary This document is intended to eplain the purpose and goals of Common Criteria certification. It will cover the overall direction of the certification process, as well as specifics related to certifying multifunction devices in a certification environment that is moving away from Evaluation Assurance Levels. Table of Contents Eecutive Summary Table of Contents List of Abbreviations Common Criteria History About Common Criteria Recognition Agreement Common Criteria Certification Methods Hardcopy Device Protection Profile (IEEE2600) NIAP CCEVS Policy Letter #20 NIAP CCEVS Policy Letter #9 FIPS Crypto Validation Requirements Changes Coming to Common Criteria New CCMC Mission Statement Finally, a Clear Vision of the Future Development of cpps with Technical Communities Conclusion

2 List of Abbreviations CCDB Common Criteria Development Board CCMC Common Criteria Management Committee CCRA Common Criteria Recognition Agreement CCUF Common Criteria Users Forum cpp Collaborative Protection Profile EAL Evaluation Assurance Level FIPS Federal Information Processing Standard ICCC International Common Criteria Conference IPA Information-technology Promotion Agency MFD-PP Multifunction Device Protection Profile NIAP National Information Assurance Partnership PP Protection Profile PWG Printer Working Group SFR Security Functional Requirement SOHO Small Office/Home Office ST Security Target TC Technical Community USB Universal Serial Bus Common Criteria History About Common Criteria Recognition Agreement Common Criteria represents a framework to provide a validation of the security functionality of a computer system. By performing a set of rigorous and repeatable tests, the framework provides participating countries assurance that the product meets the internationally agreed upon security functional criteria. By meeting the requirements defined in the Common Criteria framework, a product evaluated by one nation is considered to have a valid evaluation by all other nations who have signed the Common Criteria Recognition Agreement (CCRA). This, in practice, can result in common procurement requirements for the governments that are part of the CCRA. The CCRA defines two oversight groups: the Common Criteria Management Committee (CCMC) and the Common Criteria Development Board (CCDB). The CCMC is made up of representatives of all 26 nations who have signed the CCRA. The CCDB is made up of all nations who are authorized to issue validation certificates. Common Criteria Recognition Agreement (CCRA) Common Criteria Management Committee (CCMC) All 26 Nations Recognizing ISO15408 Common Criteria Development Board (CCDB) 16 Certificate-Issuing Nations

3 Common Criteria Certification Methods CCRA originally defined two methods to validate security features on a device: Security features could be validated against a security target (ST) or a protection profile (PP). A security target defines a set of security capabilities a device will be evaluated against. The device will only be evaluated against the security capabilities defined in the security target, nothing more or less. A protection profile defines the security threats, security functionality to combat those threats and the assurance testing for a class of security devices. When a device is certified against a protection profile, a corresponding security target will be developed with specific details of the security functionality in the device per the protection profile along with any augmentations of the protection profile s defined functionality; this means that a vendor can choose to validate additional security functionality other than that defined in a protection profile. The CCRA originally defined four mutually recognized Evaluation Assurance Levels (EALs) for both a security target and protection profile validation to be certified against for commercial products. The EALs define the rigorousness of the testing that must be performed on the security functionality defined in the security target. It is important to note that an EAL does not define the tested security functions in an evaluation. For eample, it is possible to certify a product at an EAL4 level that has no security functionality defined in its security target. This is why validations against a protection profile are considered to be more beneficial, since the security threats, functions and assurance requirements are defined for a specific technology. Hardcopy Device Protection Profile (IEEE2600) Beginning in 2003, the hardcopy industry realized that there was inequality in the validations being performed by various printer manufacturers. Some hardcopy device validations would validate a single security feature on the device and others would validate significantly more functionality in the device. This resulted in certificates being issued that really didn t validate the full security of a device. To provide clarity for customers, Lemark, working with other leaders in the hardcopy industry, initiated a project in the IEEE Standards Association to define a set of standards for hardcopy devices which would define the threats and security features necessary to protect a user s job data, access to user/administration functions on the device, and provide audit records of all access to the device. The IEEE Standards Association was chosen as the forum for this effort to ensure that the work would become a recognized industry standard. The IEEE effort resulted in five IEEE standards: a base IEEE 2600 standard that can be used by vendors who don t choose to use the Common Criteria evaluation process, and four Common Criteria protection profiles addressing four independent operational environments as listed below: A = Highly restrictive security environment B = General enterprise environment C = Public environment (kiosk, library, etc.) D = Small office/home office (SOHO) environment

4 Of the most interest are Operational Environment A (IEEE2600.1) and Operational Environment B (IEEE2600.2). The latter IEEE is an EAL2 validated protection profile that includes protection of user document data at rest, administrative functions and audit of configuration changes on the device. IEEE is an EAL3 validated protection profile that includes protection of user document data in transit and at rest, in addition to user functional data, administrative functions, and audit of user jobs and configuration changes on the device. The most significant assurance testing difference between EAL3 and EAL2 is that EAL3 requires every user-facing security feature to be fully tested, including every error condition. EAL2 requires every user-facing security feature to be tested but not all possible error conditions, only randomly selected conditions. Lemark completed an IEEE validation on February 3, 2011, for Lemark X463, X464, X466, X651, X652, X654, X656, X658, X734, X736, X738, X860, X862 and X864 Multifunction Printers. NIAP CCEVS Policy Letter #20 In 2009, the National Information Assurance Partnership issued a broad policy stating that it would no longer certify any commercial equipment beyond EAL2. NIAP s belief is that protection profiles should be developed for any technology that is to be certified and that a protection profile should be technology-specific to target the security threats that are applicable for that technology. Along with this new policy, NIAP also issued Policy Letter #20, which states that NIAP no longer allows validations of hardcopy devices at EAL3 using IEEE Instead, all validations must be done using IEEE but with augmenting requirements (as defined in Policy Letter #20) which relate to protecting user document data at rest and in transit. The table below illustrates the security functional requirement focus of IEEE2600 and NIAP Policy Letter #20. Security Functional Requirement All users are authenticated and authorized Administrators authorize users to use device Document data at rest is protected Document data in transit is protected Function data at rest is protected Function data in transit is protected Configuration data is protected Security relevant events are logged* IEEE IEEE PolicyLetter #20 * Even though NIAP Policy Letter #20 does not require event logging, Lemark products continue to support event logging with functionality that eceeds the requirements of the IEEE Protection Profile. Lemark completed an IEEE validation per Policy Letter #20 on May 29, 2012, for Lemark X548, XS548, X792, XS796, X925, XS925, X950, X952, X954, XS955 Multifunction Printers and the Lemark 6500e Scanner configured with a T650, T652, T654, or T656 Printer.

5 NIAP CCEVS Policy Letter #9 FIPS Crypto Validation Requirements Around the same time that NIAP issued Policy Letter #20, it also issued Policy Letter #9 requiring any cryptography used for security features claimed in the security target either be FIPS validated, or a nearly equivalent crypto evaluation process must be performed by the certification lab on the device. FIPS is a United States Government assurance program that accredits the proper use of cryptography in a device. FIPS crypto validation has very specific requirements for the cryptographic algorithms which may be used on a device, how those algorithms must be configured, and supporting self-test infrastructure in the device to ensure that the algorithms continue to work properly. NIAP has since cancelled Policy Letter #9, but it continues to be informally enforced for all NIAP scheme validations. To support this requirement, Lemark has also completed a FIPS algorithm validations on the Lemark products which were validated on May 29, 2012 (see previous section), to provide further assurance of the security of user data while in transit and at rest on these devices. Changes Coming to Common Criteria New CCMC Mission Statement On September 18, 2012 at ICCC2012, the Common Criteria Management Committee (CCMC) released a new mission statement for the Common Criteria Recognition Agreement (CCRA). In that statement, CCMC stated that mutual recognition of certificates would only be available through validations against collaborative Protection Profiles (cpps) and Security Targets (ST) evaluated at EAL2, when a cpp is not applicable. These profiles will be developed through joint efforts of national schemes, certification labs, technical communities, and end users who are knowledgeable eperts on the technology; such profiles will be developed with procurement requirements in mind and address current security threats. The collaborative protection profiles will define security functional and assurance requirements that lead to reasonable, comparable, reproducible and cost-effective evaluation results. These new collaborative protection profiles will not be associated with an Evaluation Assurance Level (EAL), instead they will consist of the necessary security requirements and assurance testing which the eperts within the technical community have deemed appropriate. Additionally, the collaborative protection profiles will be developed under international guidance by the Common Criteria Development Board (CCDB) and will be mutually recognized by all CCRA countries. Common Criteria Recognition Agreement (CCRA) Common Criteria Management Committee (CCMC) All 26 Nations Recognizing ISO15408 Common Criteria Development Board (CCDB) 16 Certificate-Issuing Nations Common Criteria Users Forum (CCUF) As of 2012, the CCUF is the officially recognized technical community to the CCDB. Lemark is a member of the CCUF and is participating in the development of a new multifunction collaborative Protection Profile (cpp).

6 Finally, a Clear Vision of the Future The development of mutually recognized collaborative Protection Profiles (cpps) is good news given that recent events within various national certification schemes have started to fragment the recognition of validation certificates. In particular, the U.S. scheme, which is run by the National Information Assurance Partnership (NIAP), has been arguing that the government should no longer be in the business of defining protection profiles, due to its lack of deep technology epertise. Additionally, it believes EAL assurance testing varies too much between schemes and assurance level testing is not tailored enough for the specific threats for a given technology. Therefore, NIAP believes industry eperts should define security requirements and additionally believes they should not be augmented, as the technical community does not currently recognize the added functionality as an active threat against the technology. Additionally, new functionality would be difficult to test in a way that provides repeatable assurance of a given device s security. Until recently, NIAP s view had not been recognized by those countries that continue to support traditional evaluation assurance level testing of protection profiles. Development of cpps with Technical Communities The Common Criteria Development Board (CCDB) is working with the USB certification community to create the first collaborative protection profile (cpp): a USB thumb drive protection profile. The USB Certification community is serving as the pilot technical community for this effort. The CCDB has stated it will not recognize any other technical community until it has defined the process, created technical community mission/ guidelines, and successfully developed this first collaborative protection profile. In the meantime, NIAP has already started creating protection profiles with the help of various technical communities. The first protection profile developed without Evaluation Assurance Level requirements was the Network Device Protection Profile. In addition, NIAP has kicked off a technical community with Japan s Information-technology Promotion Agency (IPA-Japan Scheme) to jointly develop a Multifunction Device Protection Profile (MFD-PP). The new MFD-PP will replace the eisting IEEE2600 MFD-PP. Lemark is a member of this technical community and is participating in the development of a MFD-PP. Once the USB thumb drive collaborative protection profile is completed, other technical communities, such as the MFD technical community, will be able to apply for technical community status with the CCDB. Once the MFD technical community is recognized as a Common Criteria Technical Community, the MFD-PP will be modified to comply with the process, guidelines and mission set forth by the CCDB, thereby creating a collaborative protection profile for multifunction devices, which would be recognized by all CCRA countries.

7 Conclusion At first glance, the direction set forth by the new Common Criteria Recognition Agreement (CCRA) mission statement appears to be beneficial to both customers and vendors like Lemark. As soon as NIAP, the IPA, and industry eperts establish a new multifunction device protection profile (MFD-PP), the changes to the Common Criteria process should provide unified assurance to customers that a certified device provides the essential security functionality to protect their information, whether stored on the device or in transit. Lemark is optimistic that moving toward a collaborative protection profile will speed up the time to certification, as well as lower the cost of evaluations, while providing mutual recognition of certification certificates across all schemes. Once the MFD-PP has been completed and recognized by the CCRA, Lemark will pursue the certification of its devices using this protection profile. Copyright 2012 Lemark International, Inc. All rights reserved. Lemark reserves the right to change specifications or other product information without notice. References in this publication to Lemark products or services do not imply that Lemark intends to make them available in all countries in which Lemark operates. LEXMARK PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. This publication may contain third party information or links to third party sites that are not under the control of or maintained by Lemark. Access to any such third party information or site is at the user s own risk and Lemark is not responsible for the accuracy or reliability of any information, data, opinions, advice or statements made by these third parties. Lemark provides this information and links merely as a convenience and the inclusion of such information and/or links does not imply an endorsement. All performance information was determined in a controlled environment. Actual results may vary. Performance information is provided AS IS and no warranties or guarantees are epressed or implied by Lemark. Buyers should consult other sources of information, including benchmark data, to evaluate the performance of a solution they are considering buying.