A summary of the first ICMC:

The first ICMC is over.

It was a wonderful event and thanks are due to all of the 171 participants for making it so.

Participant Quote: "This conference is Win Win Win!"

These attendees represented developers, governments, laboratories, consultants,  and academics from the cryptographic module community.

ICMC 2013 sponsors

It turned out to be a truly international affair with people from organizations based in eighteen countries: Australia, Belgium, Brazil, Canada, China, Finland, France, Germany, Japan, Netherlands, Singapore, South Korea, Spain, Sweden, Switzerland, Taiwan, the U.K., and the United States of America.

Thanks are also due to the sponsors. A first conference is always a risk, and it would have been hard to make the conference a success without them.  

Thanks to Bill and Nikki from CNXTD who planned and supported us; arranging the hotel, providing registrations, communications, last minute schedule patches and the management of all those things that security experts are often bad at. CNXTD focus on planning conferences in the security field and have immense experience that showed!

About the conference

We already posted short summaries of each of the days including some of the photographs that we took.

Monday was the CMVP and accredited laboratories meeting. Many of us heard how much hard work that was, especially since they usually take at least three days to cover all of their business. This is a private meeting and as you might expect there are no public slides or links.

Tuesday was for workshops: These were very well attended, and my big surprise was how popular Steve Weingart's, "An introduction to FIPS 140-2" was. I had my doubts since almost everyone who signed up for the conference was an expert in the field. Silly me! Almost everyone I spoke to that had attended said they still learned something new! The quality of the other workshops on more specialised areas (physical security, side channel analysis and testing, and mobile security) were of a very high standard and provided excellent opportunities to learn more on these topics.

Wednesday and Thursday included the keynotes, policy/program related and technical  presentations and plenty of coffee breaks.

As the conference progressed we began to see some themes and memes emerge:

Credibility and Trust

Charles H. Romine

Although cryptographic modules are very important to security in government, critical infrastructure and commercial sectors, it is rare that anything to do with cryptographic modules and the validations of their conformance to standards become the subject of public and political attention. Usually this topic is reserved for the "boffins" i.e., it is a very technical topic only well understood and discussed by the policy and technical experts. For many end users the assurance they rely upon is based on the trust and credibility they hold in those specifying the assurance case on their behalf. In the U.S. that is NIST and the CMVP. For many years this has not been doubted in the slightest.

Surprise!!! 

In the weeks leading up to the conference this topic was headline news, not just within our small community, but it was discussed in the popular media around the world. Not just fame, but infamy. Oh my....

This truly vital topic was addressed by Charles H. Romine, Director of the Information Technology Laboratory at NIST who was a keynote speaker for ICMC. It is clear that NIST take this subject very seriously indeed and are taking appropriate action. Dr. Bertand du Castel also talked about trust from a non-governmental perspective.

The delays to the update of FIPS 140-2, and the length of time that developers must wait to be listed as conformant with the standard ("The Queue" is currently measured at several months) are also affecting the credibility of NIST. The conference participants asked that NIST listen to the community and take appropriate action on these topics too.  

The future of the FIPS specifications, ISO

FIPS 140-3 was bound to be a discussion topic. We heard, as we expected, that FIPS 140-3 is moribund. This has brought problems which are getting worse with time, not better. As technology moves on, and the pace of change increases, with no real update to the specification for a decade, FIPS 140-2 is creaking badly. To deal with this, the CMVP must issue Implementation Guidance (I.G.), which is now so complex that it is virtually impossible to understand all the nuances. We saw several presentations on the topic of several notorious implementation guidances, and even some more formal logical analysis of the I.G. themselves. My goodness, what have we created?...

We heard a lot of discussion and grievances in relation to this topic and we realised that at least part of the reason for the length of the queue is related to the I.G.:  Its (sometimes) retroactive applicability; its complexity; incomplete understanding and inconsistent application of the policies by validators, testers and developers.

There is some light at the end of the tunnel. We heard a lot about the ISO standards and supporting documents for cryptographic modules. How they have been developed by experts, and are now publishing the second revision, representing more recent technical improvements that have "leap-frogged" the FIPS specifications. We heard from several programs that are already using the standards in formal programs. including Japan, South Korea, Spain and Turkey. We heard of the iCMVP that is a memorandum of understanding between Japan and NIST in regard to the framework for accepting work done under each program. This may be a simplistic start when we look at the CC Recognition Arrangement, but it could, in time, grow to include other nations...

All we have to do is convince NIST and CSEC to adopt the ISO standards as national standards, and manage the transition.

The Queue

The length of "The Queue" was discussed during several sessions. This subject was at the front of everyone's minds as the CMVP, with limited resource, struggle to keep up with the number of validations, laboratory assessments, policy writing, as well as other assigned duties.

The current length of The Queue means that it can take developers many months to get their modules validated and hence available for procurement from federal agencies. In an increasing number of cases, products are obsolete or un-supported by the time the validation is finally documented. We heard how  the unpredictability of The Queue is a problem too, since it greatly affects  how developers can perform their marketing, sales and project planning.

We heard a lot more detail about the resource constraints under which the CMVP must operate, and by the end of the conference I believe everyone had a better understanding of why, and we even had some ideas on how to address this problem. These ranged from increased fees for service which would allow NIST to have more resources, sub-contracting validators to the NIST team, allowing labs and developers to work on appropriate topics that would make validation of the test reports easier  and more efficient, and discussion of the internal CMVP review process.

Entropy 

Captain Entropy:
conceived at the first ICMC

Another "hot" topic was entropy. We heard several papers related to entropy, including the philosophical,the mathematical and the practical. Earnest discussion of the subject  was continued throughout the evening by representatives of several of the accredited laboratories, which finally resulted in the conception of "Captain Entropy." We share the vision with you and hope that you can forgive both poor artistic skills and our making light of what really is a serious subject.

What's next?

During the final wrap up session we had a clear mandate from the participants to continue the ICMC conference next year, and also to champion the establishment of a "user group." The user group will seek active participation from all the stakeholders for the development, testing and validation of cryptographic modules. 

So please do not think it is all over for a year. This was the beginning and we have work to do together during the remainder of this year and in 2014.

atsec will continue to facilitate this, but we will be seeking active participation from all the stakeholder groups. We envisage something similar to the CC User's Forum and will initially use both the mailing list for ICMC 2013, the ICMC 2013 and FIPS 140-2 related LinkedIn groups to communicate how this will happen. Please help us spread the word.

Fiona Pattinson

The Third Day of the International Cryptographic Module Conference

The third and final day of the conference again saw a number of excellent talks both on the certification and policy track as well as in the technical track.

We were very pleased with the wide range of topics and the quality of the presentations and the expertise that the presenters showed.

Long breaks between the talks gave the attendees an opportunity to mingle and to continue discussing the presented topics in a more casual manner.

One of the highlights of the day was the "Everything you always wanted to ask a laboratory... but were afraid to ask" panel with representatives from several of the accredited FIPS 140-2 laboratories who fielded varied questions from the audience.

The day ended with a summary session and with unanimous support, a the clear commitment to continue the International Cryptographic Module Conference in 2014 was made.

The Second Day of the International Cryptographic Module Conference

The second day of the conference started with the keynotes and a buzzing auditorium.
Charles H. Romine, Director of NIST's Information Technology Laboratory was the first to speak and gave an overview of the work that NIST is doing in regards to cryptographic modules. He addressed some of the challenges that the FIPS 140-2 program faces and called on the technical community to develop a mechanism for structured input of ideas and improvements.

Bertrand Du Castel, Schlumberger Fellow and Java Card Pioneer, offered a very entertaining look into the history of smart cards and the differences between Europe and the U.S.

His speech was followed by the presentation "CAVP/CMVP Status - what's next". Sharon Keller (NIST), Carolyn French (CSEC) and Randall Easter (NIST) gave short introductions of their respective organizations and programs and an outlook on the coming developments.

A similar presentation followed later in the day when Junichi Kondo (Director of the JCMVP), Yongdae Kim (Researcher with ETRI) and Helmut Kurth (atsec Chief Scientist) brought the audience up to speed on the current state of validation programs in Japan, Korea and Germany.

The panel discussion on how to improve the validation queue for the CMVP saw a packed room and a lively discussion. Nithya Rachamadugu (Cygnacom), Steve Weymann (Infogard), James McLaughlin (Gemalto) and Michael Cooper (NIST) talked about the challenges for all parties involved - from federal hiring practices to the delays in bringing a product to the market - and possible ways to fix it.

The day ended with a well-deserved wine-and-cheese social and will continue with a packed agenda on Thursday.

The First Day of the International Cryptographic Module Conference

The first day of the ICMC was dedicated to workshops and catching up with friends, colleagues and peers from around the world. We are excited to see such an impressive roster of attendees, including government, commercial, and research entities.

The day started with two well-attended workshops: Steve Weingart's "Introduction to FIPS 140-2," that had a lively question and answer session...

...and the highly technical "Introduction to Side-Channel Analysis and Testing", presented by Gary Kenworthy and Gilbert Goodwill.

The second round of workshops featured "Physical Security for FIPS 140-2," also presented by Steve Weingart. He explained how anything from common household chemicals to laboratory-grade lasers can be used to compromise cryptographic modules, and how to protect against these attacks.

The second track, "The Cryptographic Module and Beyond for Data Protection in a Mobile World," was presented by Eugene Liderman and Sriram Krishnan and included many practical examples.

We look forward to the second day of the conference, which starts with a keynote speech by Charles H. Romine and continues with two parallel tracks of presentations.

A Youthful Idiot's Take on the Common Criteria

I am only twenty-seven years old with a little more than five years of experience in Information Assurance. The collective wisdom, experiences, and vantage points of the giants of our field make what I have learned and done insignificant in comparison. Nevertheless, my passion for the art of computer security may likely be greater. With my inexperience comes youthful naivety and a drive to want to see the ideal be realized. I am regularly living the excitement of discovery that my seniors have come to know well beyond familiarity. I am the youthful idiot who wants to do what most others believe is impossible. It's this reckless optimism, the innocent taboo questions, the willingness to violate prior assumptions that makes me and those from my generation valuable to you as a community. What is the community doing to keep my generation interested and engaged? I fear the answer is quite disappointing.

The Common Criteria community at large is removing the notion of architectural assurance from security, and NIAP and its close partners particularly. They have reached the conclusion that their stakeholders benefit more from focused conformance testing than they do from an architectural review. In a practical sense, this amounts to asking evaluators to set firewall rules and check that packets are indeed blocked, rather than asking them to study and understand the internal data flow of the firewall to determine that the claimed functionality is actually sufficient to meet its objectives. While I cannot fault anyone for making their own value judgments, I cannot help but wonder if the Common Criteria community wouldn't be upset to see passionate young professionals take their enthusiasm elsewhere.

Very personally speaking, what inspires me to work for atsec is the shared belief in the importance of careful, deliberate, and holistic information assurance. When I first joined the company, I found that the Common Criteria echoed these values, and I grew to appreciate what it was and what it had set out to achieve. Of course, just like anyone involved in the certification process, I ran afoul of the deficiencies in the standard that the community hadn't ironed out yet, but I had believed that would all come in time. Wielded expertly, I saw that the Criteria could be used as a robust methodology for tracking down serious design flaws and for assuring and reassuring end users of the claims made by developers.

Over the last several years, I've seen the Common Criteria community diverge from the original goals I thought it strove for. First, I witnessed the destruction of its flexibility in meeting the varied assurance demands of the industry. The community rightfully recognized that consumers of certified products were not being served effectively by a coarse and vaguely specified leveled assurance methodology. However, with its enthusiasm to eradicate what didn't work, it failed to replace it with something that did, leaving the community in chaos. Without a path forward, government agencies, critical infrastructure, finance, and other industries with highly valued assets had no way of answering the questions posed by their stakeholders: Why should I trust these systems with our lives and livelihoods?

As I watched and participated in our progress—albeit distantly as an evaluator behind the scenes—the community began figuring out that tailoring assurance for specific technical classes of products was the most sensible solution, and though the birth of the protection profile was many years ago, it was reborn when we rediscovered its value as a community. However, the execution of these protection profiles has obliterated the Criteria's original goal of curating a comprehensive catalog of security mechanism descriptions that are comparable and compatible internationally. A vast majority of the profiles created since the CCRA shifted its weight make only superficial reference to the Criteria, and I am uncomfortable using them. If I were asked to evaluate them, I would be forced to fail them, because they are clearly not conformant to the Common Criteria. Authors have all but re-written Part 2 of the Common Criteria without providing any more of a rationale than the formalism is irritating. However irritating it is, formalism is a way of communicating effectively through time and across national borders. When authors capriciously change the formal language, evaluators are forced to ask, “What was the purpose of that change?” As Miguel Banon very wisely pointed out at the 14^th ICCC in Orlando, despite our efforts to provide the world with achievable, repeatable, and testable criteria, we have accomplished precisely the opposite.

In my five years, I have witnessed the destruction of a great portion of what makes the Common Criteria extraordinary. From within atsec, I see the desperation that Sal, Helmut, Fiona, Staffan, and Gerald have to hold this community together. Their sharp criticism stems from the stewing frustration that bubbles up from our evaluators, our customers, and our fellow labs who I'm very certain are just as dedicated to information assurance as we are.

What I—and all the rest of your colleagues from my generation—cannot provide you with, is the capability, wisdom or knowledge from decades of experience. We cannot offer sage advice on entropy testing methodologies. We cannot provide guidance on how to set up a technical community with international members. We cannot connect the dots between old Orange Book certifications and new operating system evaluations. There are giants still among us willing to share that. What we do represent is the potential future of your community. We are sponges for knowledge eager to engage in the problems you have tackled before us. If you take information assurance out of the Common Criteria—the same source of passion that enthralled you when in our shoes—we will innovate elsewhere.

To drive home the point, the University of Texas, my alma mater, was recognized by the NSA/CSS as a “National Center of Academic Excellence in IA Eduction” a year or so after I graduated. The goal of the program, as stated on the NSA website, is “to reduce vulnerability in our national information infrastructure by promoting higher education and research in IA and producing a growing number of professionals with IA expertise in various disciplines.” Yet, how are these goals at all consistent with the dilution of information assurance in the industry that we have all witnessed? When held in stark comparison to these goals, I find it quite astonishing that NVLAP, the accreditation body for laboratories in the U.S., has removed its requirement for CC Part 3 assurance proficiency. While I'm just a guy who likes to fix broken things (and break fixed things), I'm afraid you might have to deal with the very real situation that maybe the next information security savant is somewhere out there feeling just as disenchanted and disappointed in the state of information assurance as I am.

From my humble office chair, I struggle to see how I can make a discernible difference. Traveling to the ICCC this year, I found myself out of place. There's so much reminiscing about the Orange Book, the Federal Criteria, ITSEC, and reports by some dude named Anderson. And yet, where are the Andersons of my generation? Where are the Schells? Where are the Kurths? What is our community doing to embrace my generation to foster new security geniuses other than scorching the Earth and leaving us the pleasure of reinventing from scratch?

By Jeremy Powell

Riding the tiger

The 14th ICCC is now over. 

As you know, we were hoping to see a new CCRA announced but it seems that was an over-optimistic expectation. There has been no new version of the CCRA signed, and it seems that there are still open issues, matters of interpretations which need to be resolved and of course the long and winding road of ratification by each of the nations.

The good news is that there is an agreement in principle that a new CCRA is needed.

In fact during the conference we heard several estimates of tasks and milestones from the CCDB and CCMC chairs on this topic. Since in a previous blog we suggested that a simple Gantt chart might be useful in visualizing this we present a simple chart here, both the optimistic and the pessimistic scenarios. Probably the new CCRA will be with us somewhere between the best and worst case; i.e., sometime between the beginning of 2016 and mid-2018.

 
We have previously raised some of our concerns relating to the CCRA vision in our blog. 
But, and this is important, the impressions we gained from this conference is that some of these issues are at long last being discussed much more actively and openly than ever before with the CCUF. Both in the formal presentations to the conference attendees and also on a one-to-one basis with the participants at the conference. We can hope that with this openness also comes a little more understanding for the concerns in respect of the position from all CCRA nations, both new and old as well as from other stakeholders represented through the CCUF. The opening and closing presentation of the CCMC and CCDB chairs surprised us. 

This time we were positively surprised. Thank you for listening.

We also heard, at last, the confusion caused by mixing up the CCMC vision and national policies being addressed through clearer communication about what is the purview of the CCMC and which is a national approach. One contribution to this clarity is that the CCDB and national schemes are using recently coined terminology more precisely and not re-using terminology for similar, but nevertheless different concepts. It is vital that similar yet different terms are clearly distinguished if we are to avoid wasting time due to issues of fear, uncertainty and doubt.

Some high-lights of the conference:

•    The collaboration between the CCRA community and the CCUF was very evident. We also heard from both the CCMC and the CCUF a clearly stated intent to involve the end-user community in the future. (The assurance consumers.)

•    The CCUF are growing, leading the community, becoming a force for change, can move relatively quickly, are gaining momentum and is proving to be a much respected organization.

•    Although we are not allowed to see any of the 17 drafts of the proposed CCRA agreement, we are made aware that, with so many revisions, the discussions have involved a lot of hard work...

•    The transition period for the new CCRA is 36 months once it is fully signed. Alas it is estimated that it will take at least a year and maybe two before all the nations complete their bureaucratic dance.

•    As of this moment we have no available cPPs. 

We believe that it is necessary for the key cPPs to be in place as soon as the CCRA is signed and a great many more of them must be in place before the 36 month transition period ends.

The CCDB chair estimated that 10, 20, or more cPPs might be possible by next year. Let's see if that is possible. 


•    Several schemes have expressed that they will continue to do medium and high assurance certification, while at the same time participate in the cPP development. This means that there will not be high or low assurance schemes, but schemes that are committed to both and will allow end users to select the assurance they need.

•    India is a new CCRA certificate authorizing member. This is important, not only because India is a large nation, but because they have been the only nation so far to ask for certification of telecom products.

...and some low-lights:

•    The CCRA has 26 nations all over the world. So how is it that we have a marketing panel of U.S. vendors only discussing primarily how to market the CC to the U.S. DoD? The CCUF, although dominated by the U.S., must take great care to make sure that all the CCRA nations are properly represented. An important working group like this, composed of members from only one nation is not credible.

•   One thing to note is that the CCUF has no way to move things forward without the CCDB authorizing that. The CCUF can suggest a cPP but only the CCDB will say "yes" or "no." 

Summary

Not only did we receive positive comments on our “activism” but interestingly references to the atsec blog were made in plenary, formal presentations, and by many individuals at least once a day during the conference. We heard little dissent about our blog, although we recognize that an approach relying on informal public discussion  is a difficult one for government folks to be able to contribute.

There will be a long ride with the tiger. The discussions, development and implementation of the new CCRA framework will not be over soon. During this process it is important not only to understand the technical underpinning of the Common Criteria, but also the technical and political issues involved with the standardization processes.

Finally, it would be appreciated if the CCDB could agree on the location of the next ICCC, at least “in principle."

By Staffan Persson

P.S. If anyone is interested to receive the atsec material we showed at our conference booth (pictures and clips) as well our presentations and other material please send us an email request to  info@atsec.com

The first week in Orlando

Last week we attended the CCUF meeting in Orlando. 

This meeting is co-located with the bi-annual CCDB meeting and co-locating them allows the two organizations the opportunity for cooperation. Both groups operate in closed session but for the CCMC the members are the CCRA nation representatives while the CCUF membership includes representatives from the whole community, including the national schemes. The two organizations also arranged for some joint “de-briefing” meetings.
 
In addition to the formal sessions, of course a lot of discussion also happens during the breaks, and for quite a few of us at the joint “(Un) Happy” hour.

Gossip, rumors, and innuendo are always prevalent when two groups with different objectives are juxtaposed. Here are a few from the week:

If only… “The atsec blog would go away”…  and … “Yay! for the atsec blog”  ;)

If only… We could solve the CCUF tea problem! 

Trivial? Perhaps this is a symptom; but how can the CCUF be a powerful organization if we don’t have a nice hot cup of tea? 

It's an important part of the process, accepted and enjoyed by the diverse peoples of many nations. Tea can be used to predict the future and, especially useful when discussing crypto topics, can also be used for  generating small amounts of finite improbability.

(I don’t know, perhaps the CCUF needs to be a legal entity before we can sponsor tea for ourselves?)

If only… The CCUF would represent the whole of the criteria-using community. Not just those working under one MRA (i.e., the CCRA) but also supporting those working under other mechanisms for applying the criteria such as SOGIS, commercial schemes, and even national applications – regardless of whether they use the CCDB’s CC or ISO/IEC 15408.

An observation from the Mobility Device working group: "The CCUF has just about zero direct representation from end users. This is fine (in theory) because the schemes may play the role of advocating for their end users. They don't here. At least, NIAP doesn't, who was clearly running this TC."

If only… “We’d started developing cPPs ten years ago. Using this process we would have an agreed PP for secure floppy disks ready for use very soon now.”

Does the CCMC realize that it takes at least 2-3 years for international organizations to achieve international consensus? While some TC's are being led to believe that once completed a PP can be approved in a few months (NIAP quoted 3-4 months from completion in the TC to publication during the MFP workshop today) the CCMC process can be expected to take much longer, with the complex national approvals and endorsements required by the formal process being developed as part of the USB TC. 

We must set expectations properly and communicate that in reality, following a formal process, it will take at least 5 years to produce a cPP.

In fact ISO’s JTC 1/SC 27 and the CCDB have an established special relationship, are we clever enough to leverage that relationship intelligently? Can we save some time?  

If only… Key CCDB documents, such as the proposed new CCRA, could be open for CCUF members to review too. 
The CCUF has many very experienced members and offer potentially valuable contributions. Even though the CCUF will not be a signatory to the CCRA, the CCUF members are key stakeholders. 
Last week I heard from the MC chair that the new CCRA will be published without any review from the CCUF constituents. If these stakeholders have any issues, the CCMC may consider these for the next CCRA. – Wow!

If only… The good intentions, willingness to contribute and produce something good, enthusiasm and expertise that we find in the CCUF was not being eroded by confusing, changing, inconsistent policies, and delaying tactics from the CCMC.   

Here is one expression of opinion I heard: "There is not clear direction, everyone is concerned they will do work that won't be approved, and they constantly look around to see what others are doing to see if they comply with that, since there seems no clear directive on a way forward."

(See Edward Gibbons "The History of the Decline and Fall of the Roman Empire")

 
If only…  We understood the parameters and goals of the proposed iTC for “Apps on an OS.” That is obviously going to be one very busy iTC and will need some special management techniques.

By the way, is a virtualized OS also an “App on an OS” and will there be another sister iTC for “Apps not on an OS?”

Again, information on this proposal seems scanty, and I, for one, look forward to much more clarity from the CCMC on the scope of this item.


If only… The CCMC would adopt another message for the week other than “It is hard to co-ordinate 26 nations.” Yes, we got that. All the CCUF members I spoke with during the week agreed that it is hard to coordinate 26 nations.
Two points on this:

1. I would suggest that every time we hear this message next week we recall that some organizations have already worked this out, and have policies and procedures to deal with this problem in “reasonable” time-frames: Two examples: ISO (SC27 currently coordinates 68 nations) and ICAO (currently coordinates 191 nations). These organizations publish their procedures and it’s not easy for them either.

At least ISO’s JTC 1 process includes co-ordination with each national standards body. In turn many of these JTC 1 members include representatives from the vendor/developer community, whose expert contributions are solicited and respected.

Does the CCMC not try to learn from these mature organizations?

2. Developers working internationally also have to deal with this problem. They are selling products to a variety of national governments and have the unenviable task to understand the various regulations and policies of nations in order to develop and sell their products. That is not easy either.

If only… The CCMC paid attention to some of the project dependencies and communicated (estimated) time frames. Perhaps a simple Gantt chart might help the CCUF in their planning and coordination?
Example: New iTC’s cannot be formed until the iTC procedures and policies are complete, yet we seem to have already formed several TCs that may be put back at beginning once we know where the beginning is.

If only… The schemes paid proper attention to current weaknesses and threats.
Example: The Mobile PP requiring just TLS 1.0 rather than more recent versions that have been updated to address more recently identified weaknesses and threats.
(On this topic an interesting speculative blog article by Matthew Green, is here.) 

If only… The  national schemes would communicate between themselves more effectively.
Example: last week we heard from two major vendors in the OSPP workshops claim that a document containing "General-Purpose OS Cryptographic Requirements" had been provided to U.S. and Canadian evaluations back in April, but the OSPP pilot evaluation run by BSI has never been made aware of their existence, which shows some weird understanding of the cooperation in such pilot projects.

If only… There were no rumors…:
Next week we may find out if some are true…

• A new certificate producing nation will be announced. (It is already announced on the CC Portal)
• A new CCRA , as promised by the CCMC chair (this was announced at least a year ago in Paris) and the promise has been re-iterated this week.
• Where will the conference be held next year?
• Who is the missing Mickey?  

By Fiona Pattinson

Marketing the CC: It's all about Trust

Shall we call our new product "honey" or "bee vomit"?

When it comes to selling products, you need to choose your words wisely, or you might offend your customers and not sell anything at all. Still, just using some wording to hide your intentions most often only buys you some time until your customers realize that your 97% fat-free yoghurt was not so fat-free after all. (I'd rather go for a 100% fat free beer, just to be safe :-).

While starting to pack my stuff to leave for Orlando, I am wondering about some of the wordings we have been accustomed to, and I also wonder how much of a marketing event the upcoming ICCC is going to be, and for whom.

 

One of the key aspects of marketing the CC is that it is a brand. It’s not a product brand (such as those marketing their products use.) Instead it is a brand associated with the trust that others may place in the products sporting the logo. The Common Criteria logo is a registered trademark*, and its use is regulated, because it has value. The CC brand is all about trust.
 

But what is the value of the brand? A brand conveying trust must be recognised for trust: Criteria including credibility, who is supplying the trust, core values of the CCMC, the goals of the CCRA, openness and transparency, etc.

Even the name itself is a key part of the brand: "Common Criteria."* To what does the "common“ refer: The standards containing the criteria, the framework in which they are applied, or both?

Perhaps the "Common Criteria"* brand, as we have previously established it, used it and relied upon, is eroding.

Do we still have a common understanding about what assurance the certificates provide? Are the customers really prepared to trust a certificate, no matter where it comes from? With every cPP defining its own evaluation methodology, disregarding the Part 3 of the CC as the common assurance framework, can we really claim these this to be  either "common“ or "criteria“ at all, and still respect the common framework that has been built over the years?

For the upcoming ICCC panel discussion on "Marketing the CC," I am curious what the topics will be. I have myself some ideas for promoting the acceptance of the "New CC" (did you notice that there are no "New CC" standards? That's probably just another marketing gag.):

1. What are the goals of the CCRA?

The CCRA is the basis for conveying trust. The CCRA has been used for establishing trust supporting commercial trade as well as for helping establish some of the security assurance for those involved with government systems, or even a simply subsection of government organizations.

One of the goals of the CCRA is to support international trade and to support national vendors and developers in their goal to be successful globally. To support this goal it is important that national certificates are accepted by other governments and companies globally. In that scenario it's not helpful if the organization that is your national scheme has core competences including clandestinely break into systems; eaves-dropping on communications and disseminating disinformation. It makes sense to entrust those agencies with your national computer security, but it works really poorly in the international arena. Others just have a hard time to figure out if the schemes are honest or fooling them again.

Signed by many of the worlds key national security agencies, some nations have forgotten or sidelined that commercial goal and as the world changed have not promulgated that CC may be used outside of systems needing higher assurance than national security systems.

At least some of the certificate-issuing nations have built their scheme outside their intelligence community; for example, Turkey has chosen the national standards body to host its scheme. Although such a change is probably very hard for most nations. The U.S. originally envisaged this by founding the National Information Assurance Partnership (NIAP) with both the NSA and the NIST as two signatories of the CCRA. (although of course the current situation is that NIST's currrent involvement is restricted to support of the NSA led scheme by accrediting labs to the US 17025 equivalent.) As a major certificate issuing nation the U.S. could show commitment and leadership by having NIST come back into its original issuing role for the commercial sector.

My hope here is that the CCUF will break up the navel-gazing of government agencies for their own procurement, supposing that „if it's good for us, it's good for everybody else“. The CCUF should open the view into other markets, acknowledging that different markets have different assurance requirements, even for the same product type. "A good marketing organization listens to its customers. We hear you!", if you get my drift :-)

At least if providing assurance to others outside national security systems is no longer a goal of the CCRA then that change should be clearly communicated.

2. In whom do we place our trust?

My understanding is that the CCMC is responsible for managing the international agreement that is the CCRA.

Today, center stage in the CCMC is provided to partners from the "five eyes" club, their contractors and collaborating companies.

When thinking about about marketing, it makes me wonder if this is such a good idea. Clearly, it is expected of the hosting country to provide some focus on how the CC are used locally, but given the current propaganda about the "five eyes“ club members being involved in massive spying on their and other nation's citizens, I'd rather suggest a more open debate on how, given the associations, that issue might affect the CC brand. What effect does this have on end-users and consumer nations perceptions and on trust in the certificates issued?

3. Credibility:

The CCRA is first and foremost about the trust that the signatory isssuing nations have vested in the awarded certificates.

The CC & CEM are standards intended to be used by many nations, and provide at least part of the basis of trust for the CCRA. They are internationally agreed standards. When the CCDB was first established it was intended that the standards become international standards, and indeed they were submitted to ISO and fast tracked as ISO/IEC 15408 and ISO/IEC 18045. The CCDB is a closed community whose task was to bring together the various national criteria from various national agencies, ISO’s role was to be to foster open development allowing input from the commercial community and from IA experts around the globe. This happened and for a while the two communities worked together to keep the two sets of standards in line as the CC and CEM evolved. Of course as we can observe, the CCDB did not "let go" of the standards development (as was intended) and the current CCRA specifies equivalency to a particular version of the IS standards, and so ISO is "stuck in the doldrums" by staying in synch with currently unmaintained standards, and allowing for loopholes that allow signatory nations to bypass the CCRA by specifying the current ISO standards as national standards hence allowing them to produce national policy which is outside of the intention of the CCRA.

Of course this may not be so simple when governments, in order to save money, are specifying that COTS products be used in national security systems wherever possible. While that is, of course, a matter of national perogative the credibility issue that ensues is when the morphing of the CC paradigm, and the policies surrounding cPPs are seen to be a thinly disguised method of converting COTS (that draw requirements from the larger global market) to GOTS (that draw requirements from the government specifications).

4. Transparency:

Another mistake being made is that the "5 eyes club" seem to be subverting the CC brand by morphing the whole CC paradigm into a low-assurance one. The flexibility of picking appropriate assurance, that is the corner-stone of the CC is being removed. Unspoken, but visible through observation, are the close similarities between the current US approach and the UK’s CPA scheme. While that is a perfectly valid approach to address national assurance requirements, it’s a huge marketing mistake that undermines the CC brand.

You see, it‘s not CC at all (it is one perfectly valid corner use-case for CC), but it is being being sold to consumers as the "new CC." That is a huge marketing mistake and leads to issues of reduced credibility and opaqueness! By some definitions the tactic could even be defined as fraud or counterfeiting.

The forthcoming ICCC panel discussion on "Marketing the CC" is scheduled with U.S. panelists only, and the panel discussion about "Widening the use of CC for End users Worldwide" originally had just one European telecom supplier as the only panelist not too deeply entangled with the "five eyes" intelligence community. This supplier does not even have any CC-certified products . Now let's see whether the panel will include another developer who do pursue CC certification on this basis. Perhaps the brand would be much enhanced if the program committee put national politics to one side and reflected the diversity that is CC? Allowing Europeans, and Asians, and perhaps even developers that use the CC that are headquartered outside a CC signatory nation.

5.Don't change everything at once:

The CC standards have been a success story in the past not because of new features added every month, but because it distilled decades of experience with security evaluations into a commonly accepted framework. Back then, the CC actually marketed themselves.

As in every aging house, renovations are due every now and then. If you don't like your house anymore, it's even o.k. to build a new one. However, it's quite silly to burn down the old house first and only then start to think about how to build the new, especially when other people still lived in it.

Gerald Krummeck

atsec GmbH Laboratory Manager 

* "Common Criteria" and the associated logo is a registered trademark by the National Security Agency FEDERAL AGENCY UNITED STATES ATTN: AGC (IP&T) 9800 Savage Road, Suite 6542 Fort Meade MARYLAND 207556542f