Wednesday, May 27, 2015

An Article on Random Numbers from CPU Execution Time Jitter

Here is a link to an interesting thread on Random numbers from CPU execution
time jitter.

Random numbers from CPU execution time jitter

Wednesday, May 20, 2015

The 27K Summit: The First U.S. Conference Focusing on the ISO/IEC 27001 Family of Standards

Ron Ross, NIST Fellow, delivers his keynote presentation
Last week, May 12th through 14th, 2015, through the efforts of atsec information security corporation, the very first "27K: The Security Summit for the Americas" was held in Austin, Texas. In fact, this was the first conference focused on the ISO/IEC 27001 standard for Information Security Management Systems (ISMS) ever organized in the U.S.

The ISO/IEC 27001 standard is a globally accepted standard for ISMS. It is widely used in Europe and Asia, but to date it has not been as widely adopted in the United States, this first conference of its kind in the U.S. was held last week in Austin, Texas.

atsec initiated the organization of the conference due to the history of atsec and the ISO/IEC 27001 standard. Sal La Pietra, atsec CEO, in his closing remarks at the conference said, "We organized this conference because we believe in the 27K standard and atsec owes the foundation and growth of the company to the standard." Much of atsec's early business in Europe was related to the ISO 27001 standard. atsec was assisted in the development of the conference by Cyberdefenses and BSI.

A day of pre-conference workshops was followed by the conference opening with keynote presentations by
  • David Cannon, President & CEO, CertTest Training Center,
  • Ron Ross, Fellow, National Institute of Standards and Technology (NIST),
  • Scott Bullock CCSK, CISSP, CISM, Information Security Manager, Websense Cloud Services,

The conference was capped with a summary panel discussion on the subject of Integrating ISO/IEC 27001 with Existing Management Systems. The panel was moderated by Vern Williams, Chief Security Officer of CyberDefenses, and consisted of Fiona Pattinson, VP of atsec information security, John DiMaria ISO Product Manager of BSI Group America, Timothy Woodcome, Director of NQA USA, and David Ochel, Senior Information Security Manager of Rêv Worldwide. It was clear from the enthusiastic participation and discussion of the attendees that a conference on the subject of ISO/IEC 27001 has been needed and was valued highly by the community.

Vern Williams moderates the summary panel
In his closing remarks, Sal La Pietra, atsec CEO, stated that just as with the International Cryptographic Module Conference (ICMC), also initially organized by atsec, "We are not interested in owning the conference. We are giving it back to the community we managed to bring together for these two days. Of course we will continue to support future efforts, but we will discuss in what way after we see the results of this conference."

Thank you to everyone for attending! We are truly sorry that the typically beautiful Austin Spring weather chose not to cooperate on the week of the conference.

The conference organizers would like to thank Vern Williams and Willibert Fabritius for their invaluable contribution to the organization of the conference. We would also like to thank all of the conference sponsors: BSI, CyberDefenses, Inc., SGS, UL DQS Inc., DEKRA Certification, Inc., National Quality Assurance, The Open Group, SecuraStar, and Developing Telecoms. We are also grateful for the able assistance of Bill Rutledge of Cnxtd (“Connected”) Event Media Services.

Wednesday, May 13, 2015

27K: Security Summit for the Americas has started


The 27K: Security Summit for the Americas started off with keynote speeches from David Cannon, Ron Ross and Scott Bullock. The next two days will see presentations from thirty speakers on a wide variety of topics concerning ISO/IEC 27001. atsec information security is represented by Fiona Pattinson, Yi Mao and Helmut Kurth. For more information on the conference, please visit http://iso27001.com.

Thursday, May 7, 2015

Newly Approved NIAP "collaborative Protection Profile for Network Devices"

NIAP recently approved a new protection profile for network devices called the "collaborative Protection Profile for Network Devices"(NDcpp) version 1.0. This protection profile supersedes the older NDPP v1.1 protection profile. NIAP plans to sunset NDPP v1.1 on August 27, 2015.


The NDcpp contains most of the same requirements as NDPP plus several new requirements, several enhanced requirements, and a few optional requirements. The linked PDF presentation contains a comparison of the new NDcpp v1.0 to NDPP v1.1 Errata #3. It also contains a slide of a few SFR inconsistencies found in the new NDcpp.


cPP for Network Devices v1.0

Monday, December 8, 2014

PCI in Practice: Payment Security in China

During the PCI Community meeting in Sydney, Australia on the 18th and 19th of November 2014, atsec (Beijing) Information Technology Co.,Ltd (hereafter “atsec China”)* invited payment security experts from China to give a presentation on the topic of “payment security in China.”

The study focused on policies, regulations and standards related to payment security and risks in China. The presentation also included the experience and methodology for how atsec China performs PCI assessment in China, and a case study regarding Air China’s experience with PCI compliance.

This document includes an abstract of the study paper to share with the industry.

* atsec China is a Joint Venture between Mr. Yan Liu, Managing Director of atsec China and atsec information security GmbH, the atsec holding in Munich Germany. atsec GmbH is the majority shareholder of atsec China.

Disclaimer

atsec China is an independent lab specializing in IT security evaluations.

The presentation was given by Yan Liu, Managing Director of atsec China Operations and Senior Consultant (atsec China), Gary Gu, Vice President (99Bill), and Tao Chen, PCI Project Manager (Air China).

The authors do not represent any Chinese government agency or Chinese government-controlled lab. All information used for this presentation is publicly available on the Internet, though most of the material is in Chinese.

The presentation consists of background, challenges, approach and summary.

Background

China’s electronic payment space is currently growing rapidly. According to recent investigation, there are about 270 non-financial payment organizations in China, and this number continues to grow. The e-payment penetration rate keeps rising, Internet retail volume is growing rapidly, and the e-payment sector remains highly concentrated. There are different payment innovation patterns with underlying risk factors (e.g. Mobile POS, Biometric technology, etc.) The payment risk profile trends include, but are not limited to: security risk around mobile payment becoming increasingly critical, surge of CNP risk hitting domestic and cross-border e-commerce, data leakage protection continuing as a challenge to the industry, and cybercrime becoming more organized and sophisticated. The security risk management focus areas include product security, data security, transaction security, and fund security.

Starting in 2008, some of the payment service providers in China considered becoming PCI compliant because of the requirements of global payment business and branding. Currently about 80% of service providers in China who are supporting payment from global card brands are already PCI compliant. In 2012, the first bank’s credit card center passed PCI compliance for their acquiring business. ICBC (Industrial and Commercial Bank of China Limited) attained PCI compliance in 2013. ICBC has one of the largest and most complex cardholder data environments (CDE).

99Bill is one of the service providers that attained PCI compliance early, in 2009. The assessment was performed by atsec China QSA lab, and PCI DSS is the first data security standard 99Bill followed. In addition, 99Bill is currently compliant with some of other national and global programs including ISO/IEC 27001, classified security protection level-3 certification issued by the Ministry of Public Security, ADSS (Account Date Security Standard) issued by China UnionPay, and the license of a non-financial organization’s payment system issued by the People’s Bank of China.

The key national security standards in China include GB 17859-1999, “Classified Criteria for Security Protection of Computer Information System” and GB/T 20271-2006, “Information Security Technology - Common Security Technology Requirements for Information Systems”. Both standards are used for classified security protection certification. The standards classify the security protection capability of Computer Information Systems into five levels: Level 1 - Discretionary Protection, Level 2 - System Audit Protection, Level 3 - Security Flag Protection, Level 4 - Structure Protection, and Level 5 - Access Verification Protection. They outline the incremental requirements for each security protection level from security functions in ten aspects including Discretionary Access Control, Mandatory Access Control, Labels, Identification, Object Reuse, Audit, Data Integrity, Covert Channel, Trusted Path, and Trusted Recovery. In addition, GB/T 18336.1-2008, GB/T 18336.2-2008, and GB/T18336.3-2008 are the Chinese translations of Common Criteria Part 1, 2 and 3.

There are quite a few surveillance and authority organizations in China, and some of them are briefly introduced in this paper. First, the People‘s Bank of China (PBC) was established on December 1, 1948. In September 1983, the State Council decided to have the PBC function as a central bank. Starting from September 2010, the PBC issued licenses for payment organizations in China after an assessment (including requirements regarding information security, but also business, performance, etc.) according to the “non-financial institutions payment service management measures” (the Chinese name is 非金融机构支付服务管理办法). The list of licensed organizations can be found at: http://www.pbc.gov.cn/publish/zhengwugongkai/3580/index.html. Under the schemas, there are a few laboratories performing the testing and two major certification bodies for certification. Payment & Clearing Association of China (PCAC) was founded on May 23, 2011, upon the approval of the State Council and the Ministry of Civil Affairs of China. Registered at the Ministry of Civil Affairs as a national non-profit organization, PCAC serves as a self-regulatory body of the payment and clearing service industry of China, and operates under the business guidance and oversight from the People’s Bank of China. On February 28, 2014, PCAC, VISA China and atsec China held a payment security conference in Beijing. The conference materials can be found at (some of the information is in Chinese): http://www.atsec.cn/cn/news--361.html

The global card brands in China facilitate collaboration with industry and build a more secure and trusted payment network in China. For example, Visa’s qualified service provider (QSP) program was started on April 1, 2013. A list of who has passed the QSP certification by VISA can be found at: http://www.visa.com.cn/merchants/riskmanagement/accountsecurity.shtml. PCI QSA validation is one of the requirements for QSP. In addition to that, VISA will perform audits with respect to the requirements related to business operation, risk management and GBPP, etc. VISA acts as an additional oversight layer to acquirer due diligence. China UnionPay issued the Account Date Security Standard (full Chinese name of the standard: 银联卡收单机构账户信息安全管理标准) initially in 2008.

Currently more and more merchants are pursuing PCI compliance, including airlines, e-commerce companies, etc. Let’s take a look at Air China’s PCI compliance as a case study. Air China is the only airline with the National Flag marking on her planes. The business handles not only the transport of international and domestic passengers and goods, but also the task of state leaders’ official visits. As of October 2014, Air China has 512 aircraft, 323 air routes, and is open to 32 countries and regions in the world. In 2014, passenger volume is up to 77.974 million. The amount of e-ticket transactions was 874 billion Chinese Yuan last year.

There are six factors driving the need to achieve PCI DSS compliance.
  1. The transformation of commercialized e-business. With the development of e-business in China, Air China completed the quick transformation in ticket booking from agent selling to e-tickets.
  2. The sensitive payment data or information that needs to be collected during payment.
  3. The importance of reliability and data. With the ongoing growth of e-tickets, management began paying more attention to payment reliability and data security.
  4. Air China conducts e-business through multiple channels.
  5. With the high level of attention to information security, government regulations and industrial requirements are becoming increasingly strict.
  6. Our business partners, who have already achieved PCI compliance, are requesting it. Meanwhile, Air China is required to ensure the security of payment information during transmission.
Due to the business and compliance requirements mentioned above, Air China began to cooperate with atsec China on PCI compliance officially in November 2013.

Challenges

Looking forward, there are different challenges faced by the China payment sector: new rivals (domestic and abroad), product innovation, talent, compliance, the legal system, risk management, technology, and operational efficiency.

The PCI standards family was developed globally and smoothly. Nevertheless, due to quite a few differences between regions, it would not be easy and convenient for some Chinese organizations to understand and learn the standards requirements efficiently. On the other hand, it would also be a challenge for the world outside of China to understand the payment industry, and its surveillance requirements, regulations, etc. in China. As the global brand focusing on independent security assessment and evaluation, atsec China aims to be the bridge between China and the rest of the world for the information security industry. atsec China helps Chinese organizations to understand, apply and promote international standards (such as PCI, Common Criteria, CC, and FIPS 140) while assisting experts across the world to understand China. In addition to PCI QSA, ASV, PFI and PA QSA of atsec China, globally atsec offers evaluation and testing services leading to formal certification of information security technology, including evaluations under Common Criteria schemes in the U.S., Germany, and Sweden. The atsec U.S. organization also operates a Cryptographic and Security Testing Laboratory accredited under the Cryptographic Module Validation and the Cryptographic Algorithm Validation Programs of the National Institute of Standards and Technology (NIST) in the U.S. and Communications Security Establishment Canada (CSEC) in Canada for validating cryptographic modules under the FIPS 140-2 standard. atsec China achieved the China National Accreditation Service for Conformity Assessment (CNAS) and the China Metrology Accreditation (CMA) laboratory accreditations in order to ensure that the laboratory is competent to perform testing and produce reliable data.

Let’s zoom in on Air China’s challenges encountered during the beginning of PCI compliance. There are several payment channels and these businesses are run in different systems according to the initial analysis. In addition, the cardholder data is also located in different systems, which made it necessary to segment the network. All of these factors made PCI compliance rather complicated. Therefore, the first principle is simplicity.

We noted that the key payment process is the integrated e-payment platform. It is the core of all the payment information transmission and storage. After consideration, discussion and decision, a project implementation plan was created.

Initial compliance will focus on the core platform, and then extend to other payment channels. The goal of Air China is to achieve PCI compliance on all the payment systems, and enhance overall security. Last August, Air China completed initial compliance for the core platform, and will continue the work with atsec China to complete PCI compliance for the e-business website and call center system soon.

Approach

An initial readiness assessment is always important for any security assessment or evaluation project. The scope definition and detailed gap analysis for the cardholder data environment were completed during the beginning of the project. The general project process is diagrammed in the following image.


It is also very important for the assessed entity to assign a Project Manager who understands the standard itself, and who will also push forward the implementation within the organization. Especially within large-scale organizations, communication and coordination between different internal departments (e.g. security team, system administrators, developers, and operators) are always key for success of the compliance implementation.

The PCI implementation of Air China started with data optimization. The business departments were led to recognize the confidential payment data, meanwhile helping them review business procedures regarding when sensitive data should be deleted. Practical solutions were provided, so as to achieve business sustainability and reduce conflict from the business departments to the greatest extent.

During the establishment of new technical measures and business, Air China combined the existing ISO/IEC 27001, the information security protection procedure and the technical requirements, and took advantage of current regulation and technical measures to integrate the multi-security system. PCI requirements are the foundation for improving secure data protection in Air China as a whole. In this way, an established and stable payment environment is available for compliance with various standards.

That is also atsec China’s methodology on establishing an integrated and unified management system. Payment organizations could consider using PCI standards as the baseline for data protection. In addition, national or local standards and regulations should be met. ISO/IEC 27001 could be established for high-level information security management systems, Common Criteria could be used for secure development and risk management, FIPS 140-2 could be referenced as a best practice on cryptography, and O-TTPS could be considered as the supply chain security practice to mitigate maliciously tainted and counterfeit products, and so on. Overall, the management system serves the organization’s own operation, business and culture; different standards and regulations could be compliant respectively.

Remarks and Summary

In addition to the protection of the cardholder data environment, Air China plans to use the standard requirements as a best practice to all data control and management within Air China’s IT system, not just for a certificate. According to the three-year plan for data security construction made by Air China, it will continue and extend PCI compliance, and apply the experience to wider data security construction in Air China. Combined with the PCI standard, Air China will take two steps and carry it out in five phases in order to achieve the whole data lifecycle management. As a result its business can benefit from reliable data security. A diagram explaining the plan for after Air China’s initial compliance is shown below.


In general, the values of security compliance are summarized below.
  1. Meet the mandatory requirements defined by external cooperating organizations like card brands and related customers.
  2. Increase confidence during business cooperation with:
    1. Surveillance organizations or authority organizations;
    2. Customers, partners, suppliers; and
    3. Internal organizations or departments.
  3. Further improve internal management and control by:
    1. Improving security management, and integrating high level policy into the business process efficiently;
    2. Establishing measurable methods for management and technology;
    3. Enhancing the assurance of security control within the organization;
    4. Enhancing the security awareness, and benefit for corporate culture; and
    5. Enhancing the investment confidence.
  4. Reduce costs by:
    1. Reducing the cost and investment for security incidents and risks; improving processes on risk management, business continuity, and incident response;
    2. Reducing the cost on the audit or assessment in other areas, like due diligence;
    3. Reducing the insurance cost;
    4. Clarifying the security roles and responsibility;
    5. Improving competitiveness; and
    6. Establishing trust and recognition globally.
Finally, the recommendations are emphasized as follows:
  1. Harmonization with national standards and global standards;
  2. Further industry collaboration including governments, authority agencies, standards organizations, certification bodies, and especially the card brands, banks, service providers, and merchants in the payment industry.
  3. CDE Scope and implementation plans are important for the initial implementation of PCI DSS compliance.
  4. A risk-based approach is suggested for security technology implementation and management.
The presentation slides “Payment security in China” during PCI SSC 2014 AP community meeting can be downloaded at:
http://www.atsec.cn/downloads/pdf/PCISSC_2014CM_PaymentSecurityInChina_20141109_v7Sub_YanLiu_atsec_Final_released.pdf

References

  1. PCI SSC: https://www.pcisecuritystandards.org/
  2. atsec: www.atsec.cn
  3. VISA: http://www.visa.com.cn/index.shtml
  4. The People’s bank of China: http://www.pbc.gov.cn/
  5. MPS information classified security protection: http://www.cspec.gov.cn/web/
  6. UnionPay: http://cn.unionpay.com/


Thursday, November 20, 2014

The Second International Cryptographic Module Conference

The Second International Cryptographic Module Conference (ICMC)
The 2014 ICMC started with a day of workshops on FIPS 140-2 and ISO/IEC 19790, followed today by keynote speakers Helmut Kurth (atsec information security) and Mary Ann Davidson (Oracle).

Helmut Kurth
Mary Ann Davidson
Almost 200 attendees from around the world came to this year's conference to discuss topics ranging from high-level policy to advanced technical subjects.

Yi Mao presenting "Making Diamonds Out of Coal: CST Labs Are Under Pressure"
One of the highlights of today's presentations was Yi Mao (atsec information security) entertaining the audience with a humorous look into the daily routine of a CST lab. Her talk, entitled "Making Diamonds Out of Coal: CST Labs Are Under Pressure" included the animation shown below.

Monday, June 2, 2014

The Spirit of the CCRA has not changed. Neither have the Disagreements

The proposed new CCRA (draft version 16.5.1)  was recently published on the Common Criteria Portal along with a covering message from the chair of the CCRA Management Committee.
This blog describes the major changes that we have identified.
The draft CCRA document builds upon the current CCRA, first published in 2000, which is supplemented by four procedures listed on the CC portal.

General

There are many instances of grammar corrections throughout the new Agreement. These are not reported here unless we believed that it changes, or may change the meaning of the Agreement.
  • The title has no changes.
  • 26 Participants are listed, although Hungary is listed as "to be completed".
  • In Annex "L", The list of  Compliant CBs, two are missing from the current list of "Authorizing Participants currently published on the portal: New Zealand and India.
  • Throughout the Arrangement the formalization of the status of "Supporting Documents" has been added.
  • Throughout the Arrangement the standards to which CBs and ITSEF must comply have been updated. Now ISO/IEC 17065 and ISO/IEC 17025 are the norm.

Purpose

1.    The paragraph:
"The purpose of this Arrangement is to advance those objectives by bringing about a situation in which IT Products and Protection Profiles which earn a Common Criteria Certificate, as per the requirements of the CC standard, can be procured or used without the need for further Evaluation. It seeks to provide grounds for confidence in the reliability of the judgements on which the original certificate was based by requiring that a Certification/Validation Body (CB) issuing Common Criteria Certificates should meet high and consistent standards."
Was changed to add the text " as per the requirements of the CC standard."

2.    The paragraph:
"It is likely that some sensitive government IT Systems will be procured, certified and Recognised according to specific user’s requirements for their strategic need or separate bilateral or multilateral agreements. This Arrangement does not constrain such agreements. In particular, the exceptions described in Article 3 do not apply to any such separately negotiated agreements."
Was changed to add the text "specific user’s requirements for their strategic need "

3.    Text was added that basically incorporates the 2006 supplement to the CCRA. "Multiple or commercial CBs MC policy procedure 2006-09-001 v 1.0"

Spirit

The spirit of the Agreement has not changed.

Article 1: Membership

No changes.

Article 2: Scope

The scope has, of course, changed. With the removal of mutual recognition up to EAL 4 and the addition of the new text:
"This Arrangement covers certificates with claims of compliance against Common Criteria assurance components of either:
1) a collaborative Protection Profile (cPP), developed and maintained in accordance with Annex K, with assurance activities selected from Evaluation Assurance Levels up to and including level 4 and ALC_FLR, developed through an International Technical Community endorsed by the Management Committee; or
2) Evaluation Assurance Levels 1 through 2 and ALC_FLR2.
The scope may be modified with the consent of the Participants in this Arrangement at any time, in accordance with the provisions of Article 14, by addition or removal of assurance levels or components."

Discussion

In the past, the CCRA did not set any de-jure requirements for PPs specified by evaluations that were formally recognized under the Agreement beyond that they be validated in accordance with the CC standards. Of course, this meant that the Arrangement did not formally specify an organization for the development of PPs and for many years, such an organization was not in place.
In both the 1998 and 2000 versions of the CCRA there was an implicit acceptance that a validated PP approved by any one CCRA Participant should be recognized by all.
Hence, the Common Criteria Management Board (CCMB) did not sponsor development of PPs. (Another reason has been cited by them is that they had no resource to do so.)
However, a list of de-facto CC validated PPs was and is still maintained on the CC portal . It was left to the various national schemes to make de-jure policy about which PPs could be specified in an evaluation performed within their scheme. The original 1998 CCRA included the concept of national PPs but this was removed in the 2000 version.

The 2014 draft CCRA changes this allowing for mutual recognition of evaluations specifying an agreed collaborative PP (cPP) and sets the rules for their development such that to be a cPP it must have been developed under the auspices of an International Technical Community (iTC). The new CCRA defines an iTC as:
"A group of technical experts including Participants, Certification/Validation Bodies, ITSEFs, developers and users which are:
 a) working in manners that promote fair competition;
 b) working in some specific technical area in order to define cPPs;
 c) endorsed for this purpose by the Management Committee; and
 d) establishing Interpretations of the application of the CC and CEM necessary for cPPs through Supporting Documents which are subject to the CCRA approval process"

Article 3: Exceptions

The following text was added:
"Annexes F.3 and G.2 of this Arrangement should be followed by Participants who call for exceptions in accordance with this article."

Annex F.3 is "General Information Affecting the Terms of this Arrangement" which requires Participants to inform the the CCMC about changes in national laws, regulations etc. and about any changes in the operation or procedures of its national scheme if they affect the ability of that Participant to comply with the Arrangement.
Annex G.2 "Documentation to be Provided" is the list of items such as the point of contact, quality manual, procedures, etc.

Article 4: Definitions

No substantive changes here, but there were plenty in the Glossary (see the changes in the Annex "A" section below).

Article 5: Conditions for Recognition

No substantive changes.

Article 6: Voluntary Periodic Assessments

No substantive changes.
See also Annex "D."

Article 7: Publications and the Use of the Service and Certification Mark

Certificates that in the previous version of the CCRA "should" have displayed the mark of the Recognition Arrangement, now "shall " bear the device.
Note that Annex "E" has been extensively changed. The two logos look the same, but they are much more extensively defined in terms of color, spacing, etc. There is a much updated policy about their usage.

1. The added text in E.1:
"The Certificate Authorising Participants shall make necessary legal arrangements with their ITSEFs and their Client vendors, to the effect that the vendors are also required to:"…
may be problematic, since the Particpant does not have a relationship with the ITSEF. According to the Arrangement it is the CB that has the relationship with the ITSEF. I guess it's just through the chain...

2. The added text in E.2 (in green) makes a sentence that cannot be easily understood.
"After termination of participation in this Arrangement, the terminating Participant shall immediately cease to use the Service Mark and distribute any certificates bearing the Certification Mark of making reference to this Arrangement."
This text needs some clarification.

Article 8: Sharing of Information

No substantive changes.

Article 9: New Participants

No substantive changes.
See also Annex "G."

Article 10: Administration of this Arrangement

The text "All Participants should be represented on the Management Committee" was changed to:
"All Participants are represented on the Management Committee"

Article 11: Disagreements

The disagreements have not changed.

Article 12: Use of Contractors

No substantive changes.

Article 13: Costs of this Arrangement

No substantive changes.

Article 14: Revision

No substantive changes.

Article 15: Duration

No substantive changes.

Article 16: Voluntary Termination of Participation

No substantive changes.

Article 17: Commencement

The following text was added:
"In terms of continuation, the qualifying status of all members remains valid for a period of five years from the date of the latest Voluntary Periodic Assessment / Shadow Certification/Validation under the previous version of the Arrangement, unless otherwise approved by the Management Committee.
Certificate Consuming Participants, which have applied to become a Certificate Authorising Participant under the previous version of this Arrangement, and for which the Shadow Certification/Validation has not yet been completed, may choose to complete the Shadow Certification/Validation under the conditions of the previous version of this Arrangement.
Furthermore, all Participants agree:
a) to Recognise conformant certificates issued under the previous version of this Arrangement;
b) to Recognise certificates resulting from products accepted into the certification process prior to approval of this Arrangement according to the previous version of the Arrangement; and
c) for a period of 36 months from the date on which this Arrangement has been signed by all its Participants, to Recognise re-certifications and maintenance addenda issued according to the previous version of this Arrangement. Thereafter, within the scope of this arrangement all Participants shall limit recognition of certifications issued in accordance with Article 2."
The 2006 supplement to the Arrangement on "time criteria required to transfer from a Certificate Consuming Participant to a Certificate Authorising Participant"  does not seem to have been incorporated into this draft of the CCRA.

Article 18: Effect of this Arrangement

No substantive changes.

Annex "A" the Glossary

  • Added "Achievable Common Level of Security Assurance"
  • Changed "Approval/Licensing Policy"  was "Licensing policy" but the text changed too
  • Changed "CC" removed the reference of equivalence to ISO/IEC 15408
  • Added "Certification/Validation Body (CB)"
  • Added "International Technical Community (iTC)"
  • Changed "IT Security Evaluation Criteria"
  • Changed "System" which became an "IT System"
  • Changed: "Originator" which was "Originating Party"
  • Not changed: "Certificate Authorising participant: A Participant representing one or more Compliant CBs", this is pointed out because the definition in the "draft CCRA is inconsistent with text in the "Purpose" section of the Arrangement, which precludes having more than one Compliant CB
  • Added " Collaborative Protection Profile (cPP)"
  • Changed "Protective Marking"
  • Added "RA in Confidence"
  • Added "Security Target (ST)" The definition is consistent with that in CC part 1.
  • Added "Supporting Document"

Annex "B" Evaluation and Certification/Validation Scheme

In B.2, The Role and Principal Characteristics of the CB, the following text was added:
"An Evaluation Facility which has been Licensed or Approved to carry out Evaluations within a particular Scheme is known as an IT Security Evaluation Facility"
It is not obvious why that text was added into B.2 and removed from B.3, Accreditation and Licensing of Evaluation Facilities, especially since the term "ITSEF" is already defined differently in the glossary thus:
"ITSEF:
IT Security Evaluation Facility, an Accredited Evaluation Facility, Licensed or Approved to perform Evaluations within the context of a particular IT Security Evaluation and Certification/Validation Scheme."

Annex "C" Requirements for Certification/Validation Body

No substantive changes other than C.7 which now requires validations of IT products and Protection profiles to be correctly carried out.
"The CB is to have the required facilities and documented procedures to enable the IT Product or Protection Profile Certification/Validation to be correctly carried out in accordance with the Common Criteria and related Evaluation Methods"

Annex "D" Voluntary Periodic Assessments

In the existing CCRA a shadow certification/validation was performed on a "suitable IT product at Common Criteria Evaluation Assurance Level 3 or 4 as agreed upon by the Participants directly involved." This has now been changed to:
"A Voluntary Periodic Assessment should be performed on at least two IT Products that are within the scope of this Arrangement as decided by the Participants directly involved."
Additionally the documentation needing to be provided to the assessment team in support of the Voluntary Periodic Assessment was added to with the addition of:
"Other Evaluation reports should be provided on request in accordance with guidance issued by the Management Committee."
Note that currently the supplemental procedure, Voluntary Periodic Assessment 2005-06, currently applies and gives much detail on the conduct of a voluntary periodic assessment.
It is not clear from the published documents if this detailed procedure will remain in effect or withdrawn.

Annex "E" Certificate and Service Marks

Please see the discussion above under Article 7.
Additionally, it is not clear if an ITSEF may be allowed to use the mark to promote related ITSEF services. I guess that may be up to the relevant CB?

Annex "F" Information to be Provided to Participants

Many changes have been made, but they can be characterised in terms of modernization on the topic of information security. It seems that the topic of information security has moved forward over the last 15 years ;)

Annex "G" New Compliant Certification/Validation Bodies

The text requiring that the initial shadow certification/validation be for two products at EAL3 or EAL4 was changed to:
".. the applicant will be asked to nominate as candidates for Shadow Certification/Validation at least two products evaluated against a collaborative Protection Profile, or a Security Target claiming at least Evaluation Assurance Level 2 and, if appropriate, ALC_FLR where no cPP is used."
Personal comment: Two EAL 2 validations seems like a very low barrier for a potential CB to demonstrate confidence that a more complex cPP could be competently performed. Given the changes to the scope of the agreement, (EAL 2 plus cPPs) I see that this is a little moot given the number of cPPs currently available, but worry a little bit about the future cPPs, with as yet undefined functional and assurance requirements that may require mutual confidence in a deeper competence by CBs.

Note that the supplemental procedure, Conducting Shadow Certification 2004-07, currently applies and gives much detail on the conduct of a voluntary periodic assessment.
It is not clear from the published documents if this detailed procedure will remain in effect or be withdrawn.

Annex H: Administration of the Arrangement

In H.3 Decisions: There has been an addition that:
"The Management Committee should always attempt to achieve a unanimous vote," 
.. but the decisions are still, as before, to be reached by simple majority in most cases.

In H.7 Executive Subcommittee: Representation in the Executive Subcommittee  has been simplified, from the old:
"The Executive Subcommittee should consist of Qualified Participants and additional discretionary Participants up to a numerical limit determined by the Management Committee"
to a rather simpler :
"All Participants may be represented on the Executive Subcommittee."
Three responsibilities were removed from the EC:
"e) resolving technical disagreements about the terms and application of this Arrangement;
f) managing the development of IT security evaluation criteria and IT security evaluation methods;
g) managing the maintenance of historical databases as to the background to interpretations and any resultant decisions that could affect future versions of either the criteria or methodology."
(NB, These functions have not gone. They were added into the responsibilities of the CCDB. See H.8, below.)

And one was added:
"e) managing the promotion of the Common Criteria."

H.8 Development Board

This whole section was added. It seems that until this version of the CCRA is ratified there is no formal CCDB. I wonder who will chair it? Anyway, here is what the "new" CCDB will do:
H.8 Development Board
The Management Committee should establish a Development Board to manage the technical aspects of the Arrangement, foster and oversee the development and maintenance of the criteria, associated methodology and the development of collaborative Protection Profiles by suitable International Technical Communities, and to provide technical advice and recommendations to the Management Committee.
All Participants may be represented on the Development Board.

The business of the Development Board includes:
a) resolving technical disagreements about the terms and application of this Arrangement;
b) managing the development of IT Security Evaluation Criteria and IT Security Evaluation Methods;
c) managing the maintenance of historical databases as to the background to Interpretations and any resultant decisions that could affect future versions of either the criteria or methodology;
d) technical approval of updated criteria, methodology and CC Supporting Documents, to ensure technical consistency;
e) ensuring the effective development of collaborative Protection Profiles by means of suitable technical communities.
Perhaps this last one should really say "suitable iTCs"?

Annex I: Contents of Certification/Validation Reports

There are some additions and changes in regard to cPPs and a few changes that might have relevance to the contents of the reports.

Annex J: Common Criteria Certificates

The old section "Common Criteria Certificates Associated with IT Product Evaluations"  was replaced with two:
"Common Criteria Certificates Associated with IT Product Evaluations with a cPP claimed."
and
"Common Criteria Certificates Associated with IT Product Evaluations without a cPP claimed"
The section:
"Common Criteria Certificates Associated with Protection Profile Evaluations"
remains.
Some new text about supporting documents and use of the logo/mark that has been discussed elsewhere is included.

Annex K: Collaborative Protection Profiles

This is a whole new Annex.
The introductory paragraph seems to suggest that security can be analyzed into an IT product. I wish it were true.
"A collaborative Protection Profile (cPP) and related Supporting Documents define the minimum set of common security functional requirements and the Achievable Common Level of Security Assurance. It includes vulnerability analysis requirements to ensure certified products achieve an expected level of security."
In several places a reference to a "CCRA approval process" is made. For example in K.1 which says:
"The use of extended assurance components should be avoided unless such a rationale can be provided and is subject to the CCRA approval process."
This CCRA approval process is not defined or explained. Could it mean the long process used to approve the CCRA itself? Surely not!

Friday, February 28, 2014

Call for Papers for the Second International Cryptographic Module Conference

Mark Your Calendar: ICMC 2014, November 19-21, Hilton Washington D.C., Rockville, MD

ICMC brings together experts from around the world to confer on the topic of cryptographic modules, with emphasis on their secure design, implementation, assurance, and use, referencing both new and established standards such as FIPS 140-2 and ISO/IEC 19790.
We are focused on attracting participants from the engineering and research community, test laboratories, government organizations, the procurers, deployers and administrators of cryptographic modules and academia. Our program consists of one day of workshops and tutorials, followed by two days of 30 minute presentations (plus 15 minute for questions). We solicit proposals for high quality papers and relevant workshops that will be of interest to the community involved with cryptographic modules on topics below. Visit www.ICMConference.org for complete information.

Topics

  • Management of Cryptographic Modules in the Field
  • Standards: Including FIPS 140-2, ISO/IEC 19790, FIPS 140-3
  • Physical Security and Hardware Design
  • Key Management
  • Random Number Generation
  • Side Channel Analysis, Non-invasive Attacks
  • Choice of and Implementing Cryptographic Algorithms
  • Cryptographic Modules Implemented in Open Source
  • Hybrid Systems, Embedded Systems
  • Tools and Methodologies
  • Other Cryptographic Standards
The committee favors vendor-neutral presentations that focus on the practical design, testing and use of cryptographic modules. Product vendors are encouraged to recruit clients and partners who are front-line implementers as presenters.

Dates
  • Abstracts: April 10, 2014
    All prospective authors must submit their abstracts and workshop proposals using this link: http://icmconference.org/?page_id=24
  • Review and comments: May 18, 2014
  • Acceptance notifications: July 17, 2014
  • Final versions due: October 23, 2014
Workshops/Tutorials: November 19, 2014
Presentation of papers: November 20-21, 2014

For any questions regarding submissions or the conference in general, please contact us at info@icmconference.org.

Presented with the cooperation of:
CMUF
Cryptographic Module User Forum

Friday, February 14, 2014

Some Efficiencies in the O-TTPS Accreditation Program


One of the nice things about working with the OTTF and The Open Group TM in developing their O-TTPS Accreditation Program has been the emphasis that the forum members placed on efficiency within the program.

One of the major gripes in the IT assurance community is that we seem to do the same things over and over again.

That costs us precious resources, people, money and time and was pointed out by many of the members of the OTTF.

Mary Ann Davidson of Oracle, as usual, expressed the problem very well: "Doing the same thing twice or more unintentionally usually ends up with worse security as we use scarce resources on duplicative measures."

For developers, how many times do they really have to get their processes checked to see if, for example, they use an automated configuration management system, and that they have implemented access control for it. Such checks are made over and over again if they need to certify products under a variety of assessment programs.

For some of our customers, we have checked this close to a hundred times over the last decade.

Using the above example, the checks are made if a product from the developer needs FIPS 140-2, Common Criteria, O-TTPS assessment, etc., etc. It's both inefficient and expensive for the developers.
These overlaps are prevalent and extend to many of the organizations' processes, not just to configuration management.

Similarly, for mature IA assessment companies like atsec, we find that all of the various programs that we are involved with demand that we have certified management systems. The problem is that there are a variety of standards and a variety of certification programs to choose from.

In atsec's case, this has meant that we have to, across our small company of less than 100 people, to manage, endure and pay for many management system audits; It is a cost of our doing business, but a real pain in the... .

We have:
  • ISO/IEC 17025: 2 for NVLAP (don't ask!), BSI, FMV, and by ISCCC;
  • Technical competence audits: CMVP, NIAP, GSA, BSI, CSEC, O-TTPS;
  • PCI SSC: (not based on international standard);
  • ISO 9001 (Customer demand);
  • ISO/IEC 27001  (Customer demand);
  • and soon to ISO/IEC 17020.
None of the our auditors are allowed to accept the results from the others. Granted, each scheme requires a different technical competence, but our document and record control, HR, training, resource management, corrective and preventive actions, internal audit, calibration, etc. are the same for all of the programs to which we belong.

atsec customers can be assured that our management system is well audited!


.. back to the O-TTPS Accreditation Program: 

The forum saw the chance to try and address this issue: The notion of carefully reusing existing assurance was one of the factors we considered during each stage of developing the new O-TTPS Accreditation Program.

Here are some of the efficiencies that we identified and that the Accreditation Program has implemented:
  • The ability for O-TTPS assessors to reuse existing audit reports presented by the developer. These might include, where relevant, ISO 9001, security audits, Common Criteria site visits, etc.
    Note that there are some careful provisions, which are detailed in the Assessment Procedures.
  • Currently under development: The provision of mappings, allowing the work done for existing product certifications, such as Common Criteria, to be more easily mapped to the O-TTPS requirements.
  • For prospective Recognized Assessor companies and assessors, the ability to accept a variety of existing certifications of management systems and assessor qualifications that address the core skills needed as information assurance (IA) professionals. This allows The Open Group to concentrate only on the additional specialised skills needed for the O-TTPS accreditation program.
Although simple policies, they allow the program to be more efficient, reducing the overhead of unnecessary duplication, meaning that the costs of accreditation are not overburdened. These reduce the costs of assessment, to all parties involved: The Accreditation Authority, the Recognized Assessors and to the Organizations undergoing accreditation.

Not only that, but we can concentrate more on the important issue of integrity in the COTS ICT Supply Chains.

Thank you to the OTTF for living in the real world! :)

~ Fiona Pattinson

- "The Open Group" is a trademark of The Open Group