Linux: /dev/random study published

Hi folks,

The updated study for the Linux /dev/random and /dev/urandom has now been 
published at BSI. Please see [1] for the general web site and [2] for the 
study.

Please note that at [1], there are additional documents for reusing the NTG.1 
conclusion of the study for Linux-based evaluations.

For the FIPS 140-2 folks: [2] should now be our entropy assessment report. In 
particular, chapter 6 provides the assessment according to SP800-90B we need. 
This study also contains in section 6.3 measurements of entropy during early 
boot time that will be necessary in the proposed update to SP800-90B.

This study will be continued for each new kernel version that comes out. The 
first kernel the study applies to is v4.9.

[1] https://www.bsi.bund.de/DE/Publikationen/Studien/LinuxRNG/index_htm.html

[2] https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile&v=4

~ Stephan Mueller

As You Like It!

Over the last few years we have seen some maturation in the processes of providing information security assurance. This is good.

First let’s roll back into history, to the days in the ‘70’s and ‘80’s, when it could not be safely assumed that the operating systems in use implemented access control correctly. “The Birth and Death of the Orange Book” by Steve Lipner, provides a wealth of detail on the situation in the U.S., in those pre-Common Criteria days. The Orange Book described several assurance cases, with C1 and C2 being deemed appropriate for commercial products. The rallying call back then was “C2 by 92!”

Realizing that a bunch of different national criteria was not a good way forward in the battle for cyber-security, and that reliance on commercially available products was increasingly important, the Common Criteria (CC) were developed and implemented, governed by an international Arrangement known as the Common Criteria Recognition Arrangement (CCRA).

By my reckoning, the CCRA has been amended at least four times since it was established in 1998, with revisions in 2000, 2006, and 2014. Amendments were made that describe the agreed upon policies for use of the CC standards in the current situation.

At first, the infant,
Mewling and puking in the nurse's arms.
Then the whining schoolboy, with his satchel
And shining morning face, creeping like snail
Unwillingly to school. And then the lover,
Sighing like furnace, with a woeful ballad
Made to his mistress' eyebrow. Then a soldier,
Full of strange oaths and bearded like the pard,
Jealous in honor, sudden and quick in quarrel,
Seeking the bubble reputation
Even in the cannon's mouth. And then the justice,
In fair round belly with good capon lined,
With eyes severe and beard of formal cut,
Full of wise saws and modern instances;
And so he plays his part. The sixth age shifts
Into the lean and slippered pantaloon,
With spectacles on nose and pouch on side;
His youthful hose, well saved, a world too wide
For his shrunk shank, and his big manly voice,
Turning again toward childish treble, pipes
And whistles in his sound. Last scene of all,
That ends this strange eventful history,
Is second childishness and mere oblivion,
Sans teeth, sans eyes, sans taste, sans everything.

This first chart shows the number of evaluations completed in each year of the CCRA.

For the first version of CC, published in 1998, and in version 2, there was no concept of strict or demonstrable conformance.

This situation remained until CC version 3 was published in 2005. At that time three types of conformance were allowed: Exact, strict and demonstrable. As in earlier versions of the CC, partial conformance to a Protection Profile (PP) was not allowed.

Exact conformance is expected to be used by those PP authors with the most stringent requirements that are to be expressed in a single manner. This approach to PP specification will limit the ST able to claim conformance to the PP purely on the basis of the wording used in the PP, rather than a technical ability to meet the security requirements. This may be used in a Request For Quotation in a product acquisition process.

Strict conformance is expected to be used by those PP authors with vast experience of developing PPs, who again have requirements that must be adhered to in the manner specified. However, this completion permits the ST author claiming compliance to the PP to add to those requirements, provided it is in a restrictive manner. i.e. the additional requirements cannot weaken the existing requirements.

Demonstrable conformance allows a PP author to describe a common security problem to be solved and generic guidelines to the requirements necessary for its resolution, in the knowledge that there is likely to be more than some way of specifying a resolution.

By the time that CC version 3.1 was published in 2006, the notion of exact conformance had disappeared from the standard. So, this initial appearance of “Exact conformance” was with us for less than a year.

In 2012, a vision statement was published by the CC management committee. This introduced the idea of promoting the use of PPs, and evolved the PP development notion to include all stakeholders. (Previously most PPs were written by groups dominated by developers.)

Recently, in May 2017, proposed addenda to CC 3.1 R5 for exact conformance were published. This reflects the de-facto situation that exact conformance is specified in several PPs and in the cPPs defined in accordance with the CCRA of 2014.

This next chart shows the percentage of CC evaluations claiming conformance to a PP.

So, over the years the following types of PP conformance claims have existed.

1. OPEN: An assurance claim (usually) on the Evaluation Assurance Level (EAL) scale is made, but the security functionality claimed by the TOE is open, no PP claims are made. Assurance consumers must be CC experts to navigate the claims. The specification of the ST is typically performed directly by the developer.
2. NO CONF CLAIM: A PP is claimed but no statement in regard to the type of conformance to the PP is made. This is typically applicable to evaluations before CC version 3 was applicable.
3. DEMONSTRABLE: A PP is claimed, as well as an assurance claim, but the security functionality claimed is variable. Assurance consumers must be expert to navigate any additional augmentation claims, understanding boundary restrictions, and also in understanding the rationale in regard to why something is equivalent to what was specified. The specification of the PP is typically developer led.
4. STRICT: A PP is claimed; the security functionality includes a minimum set defined in the PP. Assurance consumers must be expert to navigate any additional augmentation claims, understanding boundary restrictions. The specification of the PP is typically developer led.
5. EXACT: A PP is claimed that specifies the security functionality, as well as an appropriate assurance claim. The boundary of the evaluation is set. Assurance consumers can rely on a certification without much CC Expertise. The specification of the PP is typically led by the assurance consumer.

The following chart shows the percentage of each of these types of evaluation.

The chart shows that the evaluations performed in conformance with a PP have grown from less than 5% to over 70% over the last ten years. In 2012 when the vision statement was published the number of evaluations with a PP claim was around 50%, today we are approaching 75%.

Even though the notion of exact conformance has only just been formally published, some schemes have been promulgating exact conformance since 2011, and supported the development of PPs that specified this adaptation of strict conformance. These exact conformance evaluations now represent around 30% of the total evaluations performed.

The next life-stage for security criteria

There is much evidence that the CCRA has been a success, and continues to evolve to meet the needs of its stakeholders. Since the CCRA and the Common Criteria were established by nations who had already evolved security criteria (ITSEC, CTCPEC and TCSEC, aka the Orange Book), there has been a lot of change. With post cold war co-operation in the ‘90s, and greater reliance on commercial off the shelf products, the establishment of a device such as the CCRA was a great step forward. We should note that since then the reliance on COTS technology has increased and that the development of information technology has occurred over the last twenty years with exponential growth. This has brought new and more sophisticated threats to the table. The response to this proliferation of threats at national and regional levels is not completely uniform and is at varying levels of maturity.

For example, most nations have traditionally focused on the threats to government systems, with the original criteria and the Common Criteria standards developed by government agencies. Most nations now agree that the threats presented to their national infrastructures are critical in nature and must also be addressed, while the number of participants who have cybersecurity responsibilities are vast. A huge amount of effort has been focused on that in the last decade. Of course, this must go far beyond product evaluations, but these product evaluations are still a piece of the puzzle.

These “differences” have so far been accommodated using the deliberately flexible Common Criteria standards. A prime example being the emergence of the Senior Official Group-Information Security (SOG-IS) agreement, which addresses the European region’s directives and common goals.

The signatories to the CCRA have grown over the years, and today some twenty-eight nations subscribe to the Arrangement, with the latest participant being added in June (welcome to Ethiopia!) Truly, a recognition of the success of the Common Criteria in providing assurance in the security functionality of many ubiquitous IT products, is that it can be recognized by nations that do not have the resources of some others. However, the CCRA and its signatories are only part of the story. As nations develop cybersecurity strategies appropriate to their needs we observe some divergence in the application of the Common Criteria. To date, this divergence is reflected in the specification of the conformance-type to a PP, and the development of PPs applicable not just to technology type, but also addressing the needs of the various cybersecurity strategies.

The need for public-private collaboration has come to the fore, and the Common Criteria standards must develop appropriately. With this in minds, ISO will take a much greater role in the future development of the standards. The close liaison with the Common Criteria Development Board (CCDB) will continue, but ISO affords much greater opportunity for non CCRA nations and sectors outside the government-sector to be involved. The standards should allow all stakeholders, including those with differing use-cases for Common Criteria, to take an active role in their development.

For example, it may be appropriate that some sectors develop protection profiles that meet their own needs, perhaps set up their own “private” validation schemes, and even negotiate recognition arrangements appropriate to their sector.

In conclusion, the evaluation and testing of IT security products has evolved within the government sector over the last two decades, from the days of the Orange book, the number of evaluations performed each year has grown from a handful to over four hundred. We see differing use-cases for the standards, developing, not just within the government sector, but by other sectors, and we see different assurance needs for differing technologies. The next few years should be very interesting in terms of the development and use of the standards for product security evaluations and testing especially in keeping the standards flexible, finding the common denominators, enabling the needed use-cases and allowing for the development of meaningful mutual recognition.

Yi Mao's Opening Speech at the Fifth ICMC

Dear Community,

It is the second time that I have had the honor and pleasure to open the International Cryptographic Module Conference. This year is very special since it is the fifth anniversary of the conference. 

I’d like to welcome you all with an image from the end of the 1^st ICMC. Many of you may still remember that we used the flamingos to say “Thank you,” in many different languages, for your participation.

Now, the flamingos are saying “Welcome,” in even more languages, to all of our old and new friends coming to this conference. 

As we move forward I’d like to share some crucial dates, thoughts and pictures on how the current form of ICMC came into existence.

The idea for the conference first circulated in the ISO meetings in early 2010. However, atsec started to consider it at the end of 2012, specifically on November the 2^nd, when we first established a repository for the conference with the current name: ICMC.

The name had to address two key aspects: International and Crypto Module, since the focus would be on crypto modules and attract an international audience.

During the first months of 2013 we contacted Bill Rutledge, the current organizer, and started the process. First we had to set a budget and make the funds available.

In April 2013 we set up the Web site, the logo, and started the process of finding the date and venue to host the event. We had to be careful to avoid clashing with the International Common Criteria Conference as the CC and the FIPS communities share the same set of users, vendors and labs.

The venue we picked for the 1^st ICMC was a Holiday Inn. 

It was very frugal, nothing fancy and no entertainment organized after hours. We picked Gaithersburg, to maximize our chances of having as many people from NIST as possible. Google map shows that it’s 1.4 miles away from the NIST campus and it takes 5 minutes to get there. 

The 1st ICMC ran from the 24^th to the 26^th of September, 2013, to avoid collision with the ICCC, which was held on the 10^th to the 12^th of September.  

Once everything was settled for the conference we started to receive reservations. By mid-July, two months before the conference started, we had only four paying applicants registered for the conference! They were a representative of Finnish Communications, two from Coact, Inc, and one from Sicore Technologies. I would like to thank you as early believers in the conference.

The main goal of the conference was to bring the crypto module community together. We knew the risks involved, such as losing money or damaging our company’s reputation if the conference did not go well. We put in a seed, the result of failure or success could be random.

However, shortly after those first 4 reservations, the community came together strongly, and none of the risks we were afraid of materialized. On the contrary, the first ICMC was a success and made a profit. We had a total of 163 participants and 13 sponsors. One Participant Quote was: "This conference is Win Win Win!". 

You can see this quote in our post-conference blog post at:

http://atsec-information-security.blogspot.de/2013/09/a-summary-of-first-icmc-win-win-win.html

A survey after the first ICMC encouraged everybody to continue with the conference:

http://survey.constantcontact.com/survey/a07e896rooghm2en1zl/results

Sixty-four percent of the people surveyed answered that they would definitively plan to attend the next conference and thirty-six said they would maybe attend again, but nobody said that they would not attend again.

After the first ICMC, atsec decided to leave the funds and the profit made with the organizer and the community to continue to prosper the conference.

We consider it one of the best investments our company has ever made, because today after 5 years this conference has more than 20 sponsors and close to 400 participants. 

I want to thank all of our sponsors and exhibitors for supporting the conference. I’d also like to thank the Program Committee for their hard work from planning the conference to putting together the agenda. This year we have some student volunteers. Thank you for your help! My special thanks go to Bill Rutledge and Nikki Principe for making the conference possible.

We have left the infant and toddler phase. Now the ICMC is growing healthier and stronger every year with more sponsors, users, labs and vendors from all market segments and all over the world. The spirit of the conference hasn’t changed: it is a platform where we improve the communication among all parties involved in designing, implementing, using, testing and validating crypto modules while the load of organizing the conference is shared.

Vendors and labs are all competing, but during the ICMC everybody comes together as during the Olympic Games to share with each other the fruit of a hard year of work. However, unlike the Olympics, at ICMC everybody is a winner!

What a great story of community. Thank you very much for believing in it.

Mea Culpa.

Unfortunately, atsec has been accused of distributing fake news.

Here at atsec we take such an accusation seriously. We have performed a thorough internal investigation and have determined that the accusation is true. atsec has been guilty of disseminating fake news on an annual basis for the last fifteen years.

We have followed our internal ISO 9001 and ISO/IEC 27001 conformant procedures, and determined a root cause of the issue.

•  This issue is traditional and widespread. The production of fake news on an annual basis can be traced back as far as 1392, when the first identified written documentation of an annual fake news article was recorded by a Mr. Geoffrey Chaucer.
•  Further research has shown that the practice can be traced back to the Roman and Ancient Greek eras. These civilizations celebrated The Hilaria around the time of the March equinox and this included abstinence form eating pomegranates during this time.
•  Considering atsec’s diversity we identified that the Italians, Germans, Swedes, French, Latvians, Indians, Chinese, Polish, Vietnamese, British, Mexicans, and Argentinians are all taught at an early age the art of providing fake news on an annual basis. 

As additional input, we note that:

•  atsec China since last year is subject to local restrictions on this matter, however this practice has been widespread in China in the past.
•  Germany is considering legislating on this practice .

In consideration of this the following improvements and additional controls are being implemented within atsec and will be strictly enforced.

1. atsec management team will assess the merits of introducing a policy in regard to the production of fake news during the Spring equinox period. Possibly implementing a “no fake-news” policy, enhancing our current internal policies for fake news review. 
2. atsec staff will develop a system to be named the Public Kidding Infrastructure (PKI), which will be based upon defining the roles, policies and procedures needed to help recipients of news determine the integrity index of the news that they are subject to. Information sources will be identified and authorized as part of a trust relationship. In particular, atsec staff will consider the use of blockchain based kidding.
3. atsec proposes and requests support from all atsec associates in defining an internationally agreed fake-news emoji that can be implemented on a wide variety of platforms. As an interim measure, atsec propose the use of Emoji U+1F925 be reserved for this context: 

----------------------------------------------------------------------------------------------------------------------------------------------------

Breaking News: April 1st, 2017......

🤥 **** With immediate effect, any national scheme reports for Common Criteria evaluations above EAL2 will be distributed via WikiLeaks no later than two years after their submission for validation. ****

🤥 **** The successor to FIPS 140-2 will be published in 2017. To avoid conflict with previous drafts, this version will be known as FIPS 140-jalapeño ****

🤥 **** A new Global Protection Profile is being written. This PP will aim to satisfy the needs of security assurance consumers all around the world, and will address all information technologies. Volunteers from the CC community are solicited to serve on the associated technical community are invited to contribute their knowledge and skills in this endeavor ****

🤥 **** A new cPP will be published soon ****

IT Security Issues of Autonomous Cars

Introduction

Over the past decades’ cars have become one of the most complex IT systems. Today each new car has a large number of computer systems interconnected within the car over different bus systems. With the integration of additional assistance systems as required by semi-autonomous or fully autonomous (self driving) cars, the overall complexity of IT systems in the car will increase further as will the requirements for the ability of the car to communicate with cloud services, road-side infrastructure, and other cars.

Communication and its Security Problems

So far the computer systems within the car had only limited connection to the outside world except for their diagnosis interfaces and the interfaces they expose to user devices mainly using Bluetooth -based near field communication technology or direct connection of devices via USB. Some cars also use the cellular network for communication with the workshop or with other centralized systems used for monitoring or for emergency responses. So far cars did not provide the capability to communicate with other cars within their proximity or with the road-side infrastructure (which today usually does not have communication capabilities itself).

With the development of semi autonomous and (later) self-driving cars this will change dramatically. Today the prototypes of those cars rely mainly on the data they receive from the sensors installed within the car. While those sensor systems and the algorithms to derive a view of the car's nearby surrounding get more and more elaborate, there are still significant limitations on what the sensors can 'see' and how fast they can correlate the data to get a complete picture of the situation. What is missing today is a concept for re-using the information gathered and processed by other cars or by the road side infrastructure. Since only a few cars today are equipped with elaborated sensor systems for collecting information from the car's environment, this is not surprising.

Now let us look at a scenario in the (near) future where many (but still not all) cars are equipped with such elaborated sensor systems as well as the capability to communicate with their local environment as well as with centralized systems that can provide the car with useful information. Current developments in the mobile communication world will allow cars to download large amounts of data from cloud services and centralized systems very fast. Cloud services can provide up-to-date map information including information about the traffic situation, street conditions, free parking spots, etc. This information can be gathered from road-side units as well as other cars reporting specific conditions to the cloud services.

The communication link between the car and the centralized systems can be protected using standard protection features offered by the cellular network protocols combined with application-layer security protocols like TLS.

While the general communication security issues for this type of communication can be solved using existing protocols and technology, the situation with car-to-car communication is very different.

Car-to-car communication links are more of an adhoc type where communication partner change rapidly. With some cars, the communication links will be lasting longer (e. g. with cars driving on the same road and in the same direction) while it will be lasting only for a very short time for others (e. g. cars passing by). Especially the cars in front of you may provide very useful information about traffic situations, aspects to watch (like children playing near the road, people that want to cross, other cars trying to enter), their intention (e. g. will brake soon, will turn soon), or about road conditions (e. g. water, ice, or debris on the road) that your sensors can not (yet) 'see' and that the cloud services cannot provide. This information can supplement the data collected by the sensors and thereby enhance the picture of the local situation significantly.

Technically such an adhoc communication network can be established using upcoming technologies like IEEE 802.11p (with IEEE 1609) or LTE ProSe.  In addition, the merging 5G standards will also provide a basis for adhoc networks. Those protocols also provide general security functionality for entity authentication, encryption, and integrity protection. But this is not sufficient for car-to-car communication! You also need to know the exact location of the sender and you need to know that the data is 'fresh'. Even a delay of one or two second in receiving the data may be unacceptable since the data may not only be useless but also dangerous! Those are security issues not addressed by current protocols.

The freshness issue may be easily resolved by a time stamp, but this requires highly synchronized clocks between the sender and the receiver - not a real issue today. The exact location is slightly more complicated but using GPS in correlation with data obtained by the sensors of the car, the location can be determined very precisely and transmitted as part of the data.

While there are emerging standards for the lower protocol levels of car-to-car communication, work needs to be done on the establishment of standards at the higher protocol levels. Interoperability at all protocol levels is key for car-to-car communication at all protocol levels. This is more important than for the communication of cars to cloud services where vendor or vendor group specific solutions may be acceptable.

Security (and Safety) Aspects of IT Systems in the Car

As stated in the introduction, the IT systems in the car have been developed for a closed operational environment. Security was therefore often not a top priority. Those systems also have been quite static with software updates being performed in the workshop only. Adding new applications like it is common in mobile devices was not foreseen and not necessary.

The isolation of the IT systems in the car was broken up with the ability to connect smart phones to the car. Seeing the possibilities Apple (with Apple CarPlay) and Google (with Android Auto) then developed integrated solutions that allow to use the smart phone as an intelligent bridge into the car's navigation and entertainment systems. It is just a matter of time until they also serve as bridges into the more critical IT systems of the car, especially those that collect and correlate the data required for semi-autonomous or autonomous driving.

With the smart phone technology comes greater flexibility, including the ability to install new applications or to update the software over the air.  

Supporting this type of flexibility while also satisfying the strict safety requirements will be the main challenge for the future. The smart phones export quite a number of communication interfaces and their operating systems have reached a level of complexity that allow for the same type of attacks we have seen in standard client and server operating systems over a long period of time. Although iOS and Android allow only for the download of applications that have been signed by Apple or Google, both companies are not able to verify that applications they have signed are free of (intentional or unintentional) security critical flaws. What needs to be prohibited is that those applications can be used as a trojan horse to attack the more critical systems of the car.

To do this the IT systems within the car need to be structured into several criticality levels where levels of higher criticality are separated from the next lower criticality level by some kind of guard system that controls the data transferred between the levels. For example, a guard system protecting a critical system could pass data from the 'low assurance' Android or iOS system to the critical system only if the data as a whole is digitally signed by an entity allowed to communicate with the critical system. The guard system would only verify that the data has a well defined format and is digitally signed. If confidentiality is required the guard system could also be used to decrypt the data. The correctness of such a system can be verified at a high level of assurance and with such a technique the 'low assurance' system can be used just as a 'pass through' system to allow for controlled communication between the critical system and well-defined entities. This is a way that can be used to transport software updates, specific data, and even new applications to the critical system without the ability of other entities within the communication path to interfere with the integrity and - if required - the confidentiality of the data transmitted.

This opens up the possibility to use the smart phones and their technology as a gateway that can easily adapt to new communication protocols e. g. when 5G becomes mainstream. With this concept, the gap between the (relatively short) life time of communication protocols in the mobile world and the (compared to this: relatively long) life time of a car can be bridged.

We have talked about different levels of criticality before. In our model, we see at least three of those levels:

• low criticality: infotainment, navigation data (for use by human drivers) etc.
• medium criticality: connection to roadside assistance services, monitoring performance of car systems and communication with vendor/workshop
• high criticality: sensor systems and the data they collect, navigation data (when used automated navigation in semi-autonomous or fully autonomous cars), critical information received from other cars, any data received from other systems used for automated driving.

As stated before each level should be separated from the others by using a gateway but also by cryptographic means. Cryptography will play an important role for secure car systems. There should be a separate 'master key' for each level (usually the private key of a private/public key pair) as the top of a key hierarchy used for the different application areas within each level. Software updates as well as the installation of new applications would require a digital signature as is already the case in the mobile systems we use. But unlike those systems within the car updates or new applications for the medium and high criticality levels within the car will need a significantly more careful analysis - preferable by an independent third party - to ensure that the software update or the new application adhere to well defined safety and security standards, work as specified and do not misuse the privileges assigned to them. This could be achieved by multiple signatures applied to a software update or a new application where each independent third party applies a signature with the specification of what it has analyzed e. g. the standard used within the analysis, the level of scrutiny (if the standard defines such levels), specific properties looked at during the analysis. Based on those signatures and its attributes the software management within each criticality level can then decide if the update or new application is accepted and what privileges or access to critical functions is allowed.

This could be the basis for a secure IT architecture within a car. To get there, it requires a lot of work to develop the standards not only for communication but also for data structures at the application level and for the general policies of software management within the car. 

By Helmut Kurth

atsec's International Women - Congratulations

The 8th of March is International Women's Day.

Traditionally, women offer flowers to other women on this day. 

The traditional flower is called a Mimosa, a simple spring-time yellow flower.

Well, it may not be possible to find Mimosa in every country, but we take what is common and yellow and...

Celebrate!!!

ISO/IEC JTC1/SC 27/WG 3 meeting in Abu Dhabi

At the end of October I was once again privileged to be able to  join ISO/IEC JTC 1/SC 27/WG 3 during the latest of their bi-annual working sessions held in April and October.

Convened by Miguel Bañón, this working group is of particular interest to atsec since it includes work on the international standards and guidance documents relating to ISO/IEC 15408, ISO/IEC 19790 and other documents closely related to evaluation and testing and the provision of security assurance.

I have written in more detail on these standards in:

ISO's work related to the Common Criteria
ISO's cryptographic module work.




A little history on the relationship between ISO/IEC 15408 and the Common Criteria reveals that in the early 1990's, as the various national criteria, including Europe's ITSEC, The Canadian Criteria (CTCPEC) and the US Federal criteria, were brought together in order to create a single set of harmonized criteria, the intention was to publish the new set of "Common Criteria" as an ISO standard. A decision was made to create a more agile  technical community, the Common Criteria Development Board (CCDB), that could produce the work and present it to ISO. This was not done using the ISO "PAS" process, but aimed to produce and submit  a substantially complete work that would allow expeditious instantiation of the work with the full involvement of the ISO community, which could then support the standard's future maintenance within ISO.

Hence, the CCDB and ISO established a close liaison relationship, the Common Criteria were submitted to ISO by the CCDB and the first edition of  ISO/IEC 15408 was published in December of 1999.  Since then the CCDB have continued to liaise with ISO enabling the content  of ISO/IEC 15408 and the "Common Criteria" to remain synchronized. It's a two way relationship allowing for changes and innovations from WG 3 to be brought into the CCDB standards development.

The CCDB was initially comprised of representatives from those  countries contributing their own national criteria, today the CCDB is still a subset of  the  17 members of the CCRA certificate issuing signatory nations and the CCDB standards development efforts reflect the needs of the government agencies which they represent.

From the perspective of commercial industry it is a closed group, a little disconcerting when you realize that at least in the U.S., the stated policy is to adopt COTS products as a means of making government systems, more timely and cost-effective  and the US government emphasizes the benefits of public-private partnership.

So, this has been the status quo for several years: The CCDB updates the Common Criteria and the CEM standards using input from the CCDB members and from the WG 3 experts.  ISO publishes the aligned CC/CEM content as the ISO/IEC 15408 and ISO/IEC 18045 standards.

ISO brings to the table a breadth and depth of constituents far beyond that of the CCDB. SC 27 (IT Security Techniques) currently brings together 53 participating nations, a further 20 observing nation and is in liaison with many industry groups and standards organizations such as:
(ISC)2, CCETT, Cloud security alliance, ECBS, ENISA, EPC, ETSI, Ecma International, IEEE, ISACA, ISSEA, ITU, MasterCard, MasterCard
CCDB, TCG, Opengroup, United Kingdom, TMForum, ISA, ABC4Trust, CSCC, INLAC, Cyber Security, TAS3, (ISC)2, PRACTICE, ISF, OECD, FIRST, OIDF, PQCRYPTO, WITDOM, Kantara Initiative, ISCI, PRIPARE, EuroCloud, PICOS, Article 29 Data Protection Working Party, Interpol, ETSI, TREsPASS, EUDCA

The various national bodies and liaison organizations represented in WG 3 work closely within their home fields to garner the participation of, and to  represent the interests of their own constituents.

Over time, the success of the Common Criteria has resulted in interest and use of the CC standards far beyond the national Agencies that are the the constituents of the CCDB. The diagram below attempts to illustrate this:

After a year long joint study period, WG3 and the CCDB recognized this evolution, and noting that ISO has more resources, and more widely represents the diverse stakeholders of the Common Criteria standards,  decided that ISO will take the lead in developing the next revision of the standards.

If you are interested in contributing to the development of ISO/IEC 15408 (The "CC"), ISO/IEC 18045 ("The CEM") or other projects within SC 27 then you can do so either through your national body, or through one of the liaison organizations to SC 27.

By Fiona Pattinson

P.S. in the U.S. the national body is ANSI who are are represented in SC 27 by INCITS.

Second Annual 27K: Security Summit for the Americas meets in San Francisco

From Monday, September 26^th to Thursday, September 29^th, 2016, the second annual 27K: The Security Summit for the Americas took place at the South San Francisco Conference Center in South San Francisco, California. The conference brought together experts in the ISO/IEC 27001 Information Security Management System (ISMS) standard along with people on the front lines of international IT security to promote the standard in the Western Hemisphere. See the 27K Summit website for full details on the conference.

Ryan Hill, Community Engagement Manager for
atsec information security manning their booth

The summit was attended by more than 120 individuals and was sponsored by more than 20 IT security companies, including atsec information security. This year’s conference was focused on the challenges of security in the area of Cloud Computing.

The 27K Summit started with a day of workshops on Monday that covered topics from introductions to the standard to harmonizing ISO/IEC 27001 with other standards. Day two, Tuesday, began with opening remarks from Ryan Hill, atsec’s Community Engagement Manager, followed by keynote presentations from Jim Reavis, Co-Founder and CEO of the Cloud Security Alliance, and Crispen Maung, Vice President of Compliance at Box.

Jim Reavis, CEO of Cloud Security Alliance,
speaking on "Security Assurance at the Speed of Cloud"

The conference continued with presentations on two tracks, Getting Started and Implementation, for the remainder of the day. The Implementation track continued into Wednesday and a new track, Enterprise Issues, was also introduced. In all there were over thirty speakers who presented.

atsec adds Italian Common Criteria Scheme accreditation

atsec is pleased to announce that it has recently been accredited to work as a Common Criteria evaluation laboratory (LVS - Laboratori per la Valutazione della Sicurezza) under the Italian Common Criteria scheme.

OCSI - Organismo di Certificazione della Sicurezza Informatica, founded in 2004, is the Italian scheme which is a signatory to both the CCRA - Common Criteria Recognition Arrangement as well as SOGIS – the Senior Officials Group Information Systems Security.

This means that atsec’s Common Criteria customers have the opportunity to select from the US, Sweden, Italian and German Schemes for their Common Criteria certification.

Helmut Kurth, atsec Chief Scientist stated that the addition of an LVS accreditation by the Italian national scheme to astec’s portfolio allows atsec to support customers in selecting the certification scheme that best fits their commercial needs with respect to certification timeline, cost, and knowledge in specific technical domains.