Monday, November 5, 2012

A Dragon or a Worm?




According to the Chinese Zodiac calendar, 2012 is the Year of the Dragon. It has been long believed in Chinese culture that some “special” things of immense importance are assumed to happen in a dragon year. After attending the ICCC 2012 in Paris, I immediately realized that one such “special” thing that had happened was the announcement of the CCRA vision statement. The Chinese prophecy about a dragon year was manifested even from the commencement of CCRA - itself a seminal document that was published in 2000, which was another Year of the Dragon.

Article 2 of the CCRA states that the scope of the arrangement covers claims of compliance against any of the Common Criteria assurance components required for Evaluation Assurance Levels 1 through 4. This scope of arrangement has remained unchanged in twelve years until the recent announcement of CCRA vision statement. Although a full consensus on the entire statement has not yet been reached as noted in Double Vision by Sal la Pietra, it undoubtedly points to the future direction of CCRA.

The proposed fundamental changes are expressed most noticeably in item 5 of the vision statement: “Whenever applicable, cPPs should be applied instead of individual STs. The application of STs should be reserved for cases where cPPs do not exist or are not applicable and CCRA mutual recognition should be limited to EAL 2.” The changes are twofold with the dividing line being “To PP or not to PP," as the title of Ken Hake’s blog article indicates:

  1. If a product is compliant to some applicable cPP, then it can be evaluated at the assurance level defined in the compliant cPP.
  2. If a product is not compliant to any cPP, then the mutual recognized assurance level is limited to EAL2.

I welcome #1 above, but have difficulty understanding the intent of #2. Moreover, it’s a puzzling thing why #1 has to be accompanied by #2, since #1 does not logically imply #2.

The reason I welcome #1 is that the PP approach can provide the much needed assurance for those STs that are compliant to some PP. In the presentation titled “Introducing Assurance Measures for the Security Target” at the 9th ICCC, I discussed the weakness of CC where a flexible framework allows ST authors to freely define security problems for their products and sets very few restrictions on the acceptance criteria.

The enforcement of requiring an ST to be compliant to some PP tightens that loose end. PPs being developed by a Technical Community (TC) formed by the technology experts from vendors, labs, schemes, and end users is a promising solution to address the issue. TCs know best what threats the technology in question is facing, how to define the security problems that challenge this technology, and what vulnerabilities a product built upon this technology may have.

With the recently added “c” (where "c" stands for “collaborative”), cPPs are expected to be developed from the global expertise and to be mutually recognized among CCRA member nations. In theory, this is the most promising road to keep CC evolving with rapidly emerging technologies. In reality, how well this plan is going to play out depends on a number of assumptions, such as:

  • A TC shall have well balanced knowledge in CC and a specific technology area for which a cPP is targeted.
  • Stakeholders of the TC shall overcome their own diverse interests and be agreeable to reach consensus on a common set of security requirements for a certain technology area.
  • cPPs shall be developed in a timely manner.
  • cPPs shall be available to cover most of the technology spectrum.
  • CCMC and CCDB will provide more concrete guidelines on cPP development.

Considering the challenges of upholding these assumptions, the future looks a bit more blurry than the bright theoretical picture that has been painted. Nevertheless, with everyone from the CC community providing constructive inputs to this joint adventure based on experience  accumulated in the past (e.g. Deep Thought on PPs by Fiona Pattinson and "How to Write a (good) Protection Profile" by Helmut Kurth), we can still keep a hope high and wish for the best: that one day plenty of high quality cPPs will be out there to support the vision statement in moving to the cPP-centric approach.

PPs in the past and cPPs in the future can definitely align the Security Functional Requirements (SFRs) for products in the same category, which are derived from well-understood security threats and better-tailored security problem definitions that are particularly fit for the technology in question. However, Security Functional Requirements and Security Assurance Requirements (SARs) are orthogonal in CC. A product with one single SFR may be evaluated at EAL4 while another product with a set of ten SFRs may be evaluated at EAL1. The SFRs do not correlate to SARs.

Without compliance to a commonly shared set of SFRs, products of the same category but from different vendors could hardly be compared to each other. The crucial role that a PP played (and that cPPs will continue to play in the future) is to provide the much-needed common set of SFRs for each technology area. The new trend for the highly expected cPPs is that they will go beyond SFRs and also provide well-tailored packages of SARs in place of the traditional EALs. That is also fine. After all, EALs 1-7 are just special kinds of pre-defined packages of SARs. The notion of assurance package is present in the current CC, and it’s not surprising to advocate the use of different packages of SARs to meet the various needs raised from different scenarios.

However, what puzzles me is the #2 (listed above). I have failed to find any logical implication that could possibly lead #1) to reach #2. I truly cannot understand the intent of #2. All I can see is that it will downgrade the importance of the CC and eventually backfire to hurt #1, which I have agreed upon with my whole heart -- despite the skepticism about its depending assumptions. Following are the reasons why.

Until there are a large number of cPPs publicly available that cover every corner of modern IT technology, there will be plenty of cases where a product is not compliant to any cPP -- not because the vendor deliberately does not want to be cPP-compliant, but because there simply is no existing cPP with which they can be compliant. There are always new emerging technologies, and innovative vendors come up with new products well before corresponding cPPs can be created. So, being non cPP-compliant would not be a vendor’s fault, but rather a consequence of their own innovation. Yet, their products would have to be limited by CCRA mutual recognition up to EAL2 if the vision statement were to become effective.

The goal of reaching “reasonable, comparable, reproducible and cost-effective evaluation results,” as stated in the section of Key points for future CCRA use, may explain the addition of a cPP-based approach, but it cannot be served as rationale to justify the downgrade of the current maximum, mutually recognized assurance level from EAL4 down to EAL2. Otherwise, one will get an undesirable implication: SARs that are not subordinate to EAL2 cause evaluation results which are not reasonable, not comparable, not reproducible, and not cost-effective.

If the SARs defined in CC part 3 can only be preserved up to EAL2, rendering the rest of the SARs as “trouble makers,” then CC would look really bad and its value becomes doubtful. Luckily, SARs are actually innocent. Blaming SARs above EAL2 as being responsible for irreproducible evaluation results is like blaming a French cuisine recipe simply because a novice Chinese cook was unable to reproduce the same dish made by an experienced French chef. As obvious as it is, the solution here is to adequately train the Chinese cook instead of banning the recipe! For the same reason, if the worry is that schemes from different nations tend to produce different results on some medium and high level SARs, then the CCMC should provide shadowing evaluation, supervision, or some other means to let newly joined schemes learn from an experienced scheme so that the desired reproducibility can be achieved.

I believe that holding the standard high and continually carrying the CC expertise forward
is the right way to build up the CC's reputation. The attempt to lower the standard in order to accommodate novice schemes or to attract new nations to join CCRA is no different from demanding all restaurants only serve fast food in order to accommodate some restaurants that are unable to provide fine dining.

Regardless of undesirable implications, the CCRA vision statement seems to be pushing CC into its lower corner -- even for the cPP development. It’s really worrisome to read the statements in the Baseline requirement section, such as the following: "All cPPs shall include assurance components derived from the CC part 3 to a maximum of EAL2, or higher (up to EAL4) if the TC can demonstrate a rationale that shows the activities can be repeated between schemes."

If CC is envisioned as a passive tool box (as stated in item 6 of the CCRA vision statement) where most of the “advanced” tools will not be used and get rusty, and new tools will no longer be added, I cannot help asking how long this toolbox will remain useful.

While my colleagues seek to have their questions answered by the Oracle of Delphi and Deep Thought, I turned to my oriental ancestor Dragon. As a “Descendant of the Dragon," I have a spiritual pathway via meditation to feel the great existence of the Dragon. Gradually, little by little, his image appears – he has horns of a giant stag, head of a horse, eyes of a demon, neck of a snake, abdomen of a tortoise, scales of a carp, claws of an eagle, paws of a tiger and ears of an ox! Those are the nine resemblances to various animals described in the legend.


As powerful as he is, he can surely read my mind. Before I could murmur a word, he began talking to me in a calm and steady voice, saying, “You see, I am the highly respected extraordinary Dragon because I have the best features from various creatures. If these features are taken away from me, then I will become an ordinary worm.” He disappeared before the sound of his voice faded away.


Becoming a dragon or a worm is the choice to be made. I wish the CC community
good luck, strength, and power to turn CC into a dragon!

by Dr. Yi Mao


Editors Note: If you would like to see why Dr. Mao is qualified for such an analysis, please check out her academic paper entitled "Generics and Metaphors Unified under a Four-Layer Semantic Theory of Concepts," which was co-authored by Dr. Mao and Dr. Bertand du Castel.


1 comment:

  1. Since my blog article was posted, I received some helpful and valuable comments from the Common Criteria Professionals Group on LinkedIn and CC Users Forum (CCUF). I’d like to add a short summary here for those who do not have membership of these groups to view and participant in the discussions there.

    John Ata has helped me to realize through his comments that there could be a connection between #1 and #2 under one condition: there will never be cPPs with assurance levels above EAL2. If this condition is intended to be true, then #2 makes sense for ensuring the consistency across all evaluations. Nevertheless, if EAL2 would also be the de facto assurance ceiling for cPPs, then it would be a different issue that needs a justification. That is, why would one limit the assurance ceiling to EAL2 regardless of being cPP compliant or not?

    David Chizmadia has explained that the EAL2 assurance ceiling is a consequence of the failure of the CC community to develop precise standard specifications of development evidence and evaluation analysis. In the absence of these preconditions, the policy level people running the CCRA have concluded that the only assurance activity that can be shown to be repeatable (same CCTL in the same scheme can derive the same result) and reproducible (different CCTL, possibly in a different scheme, can derive the same result) is SFR testing.

    Bhavin Desai has confirmed that #1 and #2 are logically independent. #2 is a decision of the CCRA Management Committee, whereas #1 is a technical point. They just happen to be stated together with no logical connection. Nevertheless, he thinks that policy items may be mutually and logically independent, subject to the intentions that are being expressed. He has observed that many decisions, policies, approaches and methods are not logical, and hence it is not necessary to discover some underlying logic.

    My response to Bhavin’s comments is that statements in a document can be independent to each other. However, together they are expected to reach the common goal expressed in a well-written coherent document. The bottom line is that they do not contradict each other, but I am concerned that #2 will downgrade the importance of the CC and eventually back fire to hurt #1. cPPs should be built upon a healthy, well-alive and high quality CC, but the EAL2 limitation in my humble opinion will make CC diminish. Whether the EAL2 assurance ceiling is going to damage CC or benefit CC in a long run is another topic to discuss. Constructive discussions make us think clearly and act responsibly. Hope all will turn out to be well.

    For the detailed discussions, please take a look at http://www.linkedin.com/groupItem?view=&gid=121693&type=member&item=182478379&qid=0d435532-11b3-4314-a34d-38a0ea46ed5e&trk=group_most_popular-0-b-cmr&goback=.gmp_121693 and https://ccusersforum.teamlab.com/products/community/modules/forum/posts.aspx?t=51550&p=1#215250

    ReplyDelete

Comments are moderated with the goal of reducing spam. This means that there may be a delay before your comment shows up.