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.

Some Efficiencies in the O-TTPS Accreditation Program

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

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

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

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

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

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

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

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

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

We have:

• ISO/IEC 17025: 2 for NVLAP (don't ask!), BSI, FMV, and by ISCCC;
• Technical competence audits: CMVP, NIAP, GSA, BSI, CSEC, O-TTPS;
• PCI SSC: (not based on international standard);
• ISO 9001 (Customer demand);
• ISO/IEC 27001  (Customer demand);
• and soon to ISO/IEC 17020.

None of the our auditors are allowed to accept the results from the others. Granted, each scheme requires a different technical competence, but our document and record control, HR, training, resource management, corrective and preventive actions, internal audit, calibration, etc. are the same for all of the programs to which we belong.

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

.. back to the O-TTPS Accreditation Program: 

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

Here are some of the efficiencies that we identified and that the Accreditation Program has implemented:

• The ability for O-TTPS assessors to reuse existing audit reports presented by the developer. These might include, where relevant, ISO 9001, security audits, Common Criteria site visits, etc.
  Note that there are some careful provisions, which are detailed in the Assessment Procedures.
• Currently under development: The provision of mappings, allowing the work done for existing product certifications, such as Common Criteria, to be more easily mapped to the O-TTPS requirements.
• For prospective Recognized Assessor companies and assessors, the ability to accept a variety of existing certifications of management systems and assessor qualifications that address the core skills needed as information assurance (IA) professionals. This allows The Open Group to concentrate only on the additional specialised skills needed for the O-TTPS accreditation program.

Although simple policies, they allow the program to be more efficient, reducing the overhead of unnecessary duplication, meaning that the costs of accreditation are not overburdened. These reduce the costs of assessment, to all parties involved: The Accreditation Authority, the Recognized Assessors and to the Organizations undergoing accreditation.

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

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

~ Fiona Pattinson

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

A doodle

Vendor Viewpoints (from a Lab)

What might we hear if we sat at a round table with software vendors currently pursuing Common Criteria evaluations? Would we hear the same thoughts that currently drive the CC community at large?

The following discussion is based on comments from vendors in response to the questions posed below regarding their selection of a CC scheme:

1. Were the entrance requirements for CC evaluation clear? Is the fee structure clear? Did you have to collect a group of documents to get a complete understanding of the differences from one scheme to the next?
2. Does your government sales team have a clear view of what is required to enter into CC evaluation? Did you receive guidance regarding the approach to take for CC evaluations?
3. What change or improvement would you like to see in the certification process overall?

General Response 

One vendor replied that they have a collection of scheme policies, statements, and guidance. Obtaining guidance from the schemes was not an issue, the problem was in getting a definitive picture of the life cycle of an evaluation project.

Another vendor responded that PPs highlight their product’s features, which they found very beneficial. They noted that internally, their development organization needs to remember that, for the company, the end goal is sales and it is the product management and marketing teams who provide input to the company’s CC requirements. The sales team is generally unaware of the effort an evaluation will take.

Time and Cost

High on the list of issues is the amount of time an evaluation will take to complete. Some vendors may have experience with multiple schemes and so have rationale for making a choice between schemes.  And, remember that time is a factor that is equally important as choosing the right PP – it affects sales.

Several vendors commented that the overall change or improvement they would like to see is a reduction in time or cost of performing evaluations.

Need for unified requirements

Another consideration for the choice of where to go is the assurance level that can be used in evaluation. One vendor responded that since many its customers are asking for a specific assurance level, the vendor has had to choose a certain route for an evaluation, even though it was a more difficult path to take, because the vendor needed to satisfy their customers. The vendors are trying to balance the requirements of both US and non-US customers. The schemes are not helping solve this business problem since the Common Recognition arrangement is not so much an arrangement any longer.

Another vendor responded that they look forward to stability and cooperation. Problems have included not being able to predict requirements and the resulting difficulty in being able to tailor their development plans. Elements in the CC world are changing but importantly, the vendor notes, no one is agreeing on these changes.

Duplication

Another respondent commented that there must be a way found to avoid their running evaluations in more than one place. This will raise the price, not lower it.

Another vendor responded with a somewhat different approach in that they are evaluating their product in one place but getting two certificates. The reason for this was that one scheme demands exact PP compliance while another allows us to exceed that. So with some extra work that vendor can get what both international markets want.

Confusion factors

One point of confusion (and thus, delay) is the current misunderstanding for some new protection profiles. There is a learning curve for the creation of specific profiles. But there is also a learning curve for customers who even have yet to understand what the current US plan is. At atsec, we work to educate them, but more information and a clearer understanding provided by the schemes themselves is in order.

One vendor’s sales team does not fully understand just what it takes to fulfill security requirements, and so it is unlikely that this vendor sales team can explain to their prospective DoD customers the correct path to take. Again, this information needs to be clearly outlined by the scheme.

And the same observation was made about another vendor’s sales team that didn't understand what the CC evaluation process takes, and so aren’t able to offer guidance to their own development team. The sales team needs to understand the requirements of the ultimate customer – the user.

Another respondent indicated that they have to look at each product over again regarding the entrance requirements. Getting into evaluation is no longer a consistent process because some products, for example, need to have crypto validated by a FIPS validation while others are subject to entropy scrutiny. It differs by product and by which policy is in place at a particular time, and it varies by scheme.

Conclusion

What do our vendor customers want? The same thing that we want: they want faster evaluations. Who doesn’t want this? And this is in line with what the US scheme has also heard and is working toward.

They want “a stable, common worldwide evaluation standard” as one of them succinctly put it.

Does this mean the same level of security assurance or more? Less cost is derived from less work, which is derived from less scrutiny and less assurance.

Vendors want things to be equal among the international schemes – as they were told they were supposed to be. But there is a decided expectation that only the US rules are acceptable, and so that colors their decisions regarding not only whether to undergo a CC evaluation, but also where and when.

One respondent suggested a novel idea.  They suggested having some sort of SLA (service level agreements) from the schemes, much as atsec provides for our internal / external customers. The SLA could outline what the vendor (and labs) can expect from the scheme given a specific input. This would make the evaluation process more of a business-focused proposition.

Note: atsec would like to point out that one scheme has instituted a plan to address this last point. CSEC, the national scheme in Sweden, sets its feedback to the lab based on each report or set of reports sent to the certifier for the entire length of the project. Once the lab delivers a given report to the scheme, there is an established date for certifier feedback to the lab’s evaluation team. This enables the customer to plan for any needed responses in a more predicable manner. This also makes for a more transparent practice that the lab can share with the sponsor. This is not the total solution, but it may make for faster turnaround and thus faster evaluation.

-- Ken Hake

Lab manager (US)

Dual_EC_DRBG Usage in Evaluations

This information is intended to be of use to those working under all the CCRA national evaluation schemes. Some of whom are updating policies relevant to this topic. This blog is not intended as an atsec opinion about the underlying issues.

On September 9th this year, NIST posted the following announcement:

In light of recent reports, NIST is reopening the public comment period for Special Publication 800-90A and draft Special Publications 800-90B and 800-90C.

NIST is interested in public review and comment to ensure that the recommendations are accurate and provide the strongest cryptographic recommendations possible. The public comments will close on November 6, 2013. Comments should be sent to RBG_Comments@nist.gov.

In addition, the Computer Security Division has released a supplemental ITL Security Bulletin titled "NIST Opens Draft Special Publication 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, For Review and Comment (Supplemental ITL Bulletin for September 2013)" to support the draft revision effort.

The above-mentioned ITL Security Bulletin makes the following recommendation:

NIST strongly recommends that, pending the resolution of the security concerns and the re-issuance of SP 800-90A, the Dual_EC_DRBG, as specified in the January 2012 version of SP 800-90A, no longer be used.

We have found that the following Protection Profiles allow for the optional claims of the Dual_EC_DRBG random number generator in FCS_RBG_EXT.1:

• Protection Profile for Software Full Disk Encryption
• Protection Profile for USB Flash Drives
• Security Requirements for Mobile Operating Systems
• Security Requirements for Voice Over IP Application
• Network Device Protection Profile (NDPP) Extended Package VPN Gateway
• Protection Profile for Network Devices
• Standard Protection Profile for Enterprise Security Management Policy Management
• Standard Protection Profile for Enterprise Security Management Identity and Credential Management
• Standard Protection Profile for Enterprise Security Management Access Control
• Protection Profile for IPsec Virtual Private Network (VPN) Clients
• Protection Profile for Wireless Local Area Network (WLAN) Access Systems
• Protection Profile for Wireless Local Area Network (WLAN) Clients

Since some schemes have different policies in regard to this topic, we recommend that vendors and labs check with their scheme before including this algorithm in their security claims.

~the atsec team

How long is a piece of string?

"How long is a piece of string?" is an English idiom; it is something that you say when someone asks you a question that you cannot answer about how big something is or how much time something will take.

This was the phrase that came to mind when we saw the old, 2005,  NSTISSP#11 guidance from the CCEVS: "The goal established for low assurance products (i.e., EAL 1) is 30-90 days of evaluation time and will cost less than higher assurance (e.g., EAL4) evaluations."

First, an important caveat: It seems that since 2005 at least, the NIAP have been leaders in the field to try and address the topic of providing timely information assurance, which is a problem that has also been expressed more widely within the CC community. So please do not see this blog as being focused particularly at NIAP. It is relevant to any scheme aiming to bound the length of an "evaluation." In fact, the very first key point in the CCMC's Vision Statement is: "The general security level of general ICT COTS certified products needs to be raised without severely impacting price and timely availability of these products."

The issue of evaluations taking too long is a perennial problem that the CC community hopes to address together. Of course, the U.S. scheme is amongst the schemes represented in the community, and the NIAP are lucky enough to have their own national feedback in the form of reviews and studies that are part of the checks and balances in place in the U.S. For example, in 2006 the IDA published, "Review of the National Information Assurance Partnership (NIAP)."

This report gave attention to efficiency and effectiveness of the U.S. scheme and includes the statement: "Evaluation costs are too high and they take too long. These are common complaints, particularly from small businesses." The topic of appropriate metrics is pervasive throughout the report. In fact, just after that report was published, U.S. labs saw a flurry of activity from NIAP hoping to identify and establish appropriate measures, amongst them was the elapsed time for an evaluation project.

This is an important metric, BUT it needs to be defined correctly and appropriately if it is to be useful.

I contend that what NIAP really meant to say in their old NSTISSP#11 guidance was:

"The goal established for low assurance products (i.e., EAL 1) is 30-90 days of validation time and will cost less than higher assurance (e.g., EAL4) evaluations."

Consider that the evaluation portion of a project is the work undertaken by the lab in close cooperation with the vendor.  How long this takes depends on how you define "evaluation project."

• For developers, it starts the moment they decide that they may need to perform a CC project.
• For labs and consultants, it starts the moment a developer hires them.
• For schemes, it starts when a project is formally "entering evaluation."

Let's consider a typical project, identifying the following key "phases" of an evaluation project from the point of view of the sponsor of a project.

1. Decision: The decision process when a vendor identifies the requirements for the "project:" factors include their target market and the associated requirements for CC compliance, which scheme to use, which national policies apply, identifying a laboratory and any needed consultancy, defining the TOE, and selecting appropriate PPs. Depending on prevalent policy, this phase may include the need to develop a suitable PP before a product can be evaluated.

2. Review: A review of the product against the identified requirements, which is often made with a consultant. This may mean that organizational processes or product changes need to be made. The axiom, "the earlier in the cycle, the cheaper it is to fix" may well apply.

3. Evaluation: The laboratory performs the evaluation. Currently some schemes are closely involved with this task. Oversight of the laboratory by the scheme is close. Other schemes identify particular checkpoints. (For example, NIAP's Validation Oversight Reviews (VOR), which is a type of formal technical review.)

4. Validation: The scheme performs the validation of the lab's work. Historically this was performed hand-in-hand with the evaluation work performed by the lab. This phase usually includes discussion and negotiation of the technical and policy details and interpretations are issued and managed. Once the validator is satisfied, the process culminates with the issuance of a certificate.
Here is a typical waterfall view. I don't for a moment think that any of the community runs projects like this! Notice that the timeline is in quarters of a year (i.e., 3 months). The durations given are typical, but in real life are dependent on many factors and can be much shorter or longer.

So how are projects currently organized?

Assuming that an appropriate PP exists,or is not specified, in atsec's experience we are used to seeing a model like this:

For developers with complex international markets, the decision phase can be quite lengthy. Once the basic parameters are set, getting the consultants in early can help shorten the project and reduce some of the project risks. Some technologies or products are naturally more complex and take longer (the shaded areas in Evaluation and Validation). The "Review" phase can be significantly lengthened if this is the first time a developer's project team has performed a CC project, or if significant process or product changes are needed.

One important point to remember is that one of the project dependencies is the availability of scheme (validator) resource. In the past, we have seen projects delayed in more than one scheme because of availability of scheme resources.

What about schemes that require a PP that doesn't yet exist?

NIAP have been demanding that the community write a PP first (and cPPs for the wider CC community are part of the Vision). As we know, developing a PP is a lengthy process. At the moment, it typically takes close to two years. Of course, as more and more PPs and cPPs become available, then this issue will reduce. The quality of the PP, and how much interpretation or guidance in its application is needed will affect all the subsequent projects.

This scenario is adding huge costs to the developers, immensely extending the timeline for projects, and given the typical product life-cycle, means that for many newly issued certificates the related products are no longer current (a problem that already existed, but that this scenario exacerbates).

Consider also that the real world is not so simple. For developers with a defined certification strategy, several projects may need to be coordinated and budgeted, and not just CC projects. When timescales can be variable, it can make program management very difficult indeed. 

What will a defined validation period mean?

Granted, at lower assurance and with improved processes, the time for evaluation will reduce. Of course we need to consider that for many of the developers that address international markets and must or want-to demonstrate higher assurance in the same project or run a NIAP project concurrently with other projects than the natural approach is to have the lab perform the evaluation ahead of the formal "entry" into the NIAP program. In effect, the NIAP's 90 days becomes an additional overhead as the participants strive to reduce the risk of last-minute surprises.

So making such a mandate may do little more than add an extra 90 days to the schedule, reduce the involvement of the validator in the evaluation work, and increase project associated costs to the developer.

An additional item for the efficiency of this model is the documentation, consistency and dissemination of any interpretations and policy changes. Without the developers and labs having access to a formal set of precedent rulings, prior adjudications and  interpretations, the validation phase will inevitably extend as a result and may result in confusion, inconsistent application of precedents and perhaps worse, inconsistent and even unfair evaluations. As new PPs are applied, then we find the need for interpretations, new policy and for potentially inconsistent applications inevitably increasing. Of course this may result in new versions of PPs, and the need to consider transition plans throughout the review and decision phases. For the "old" CC model of course we had the "interpretations" mechanism at both local and international levels, but for the new NIAP paradigm, many policies are not public, are disseminated to labs directly and may not even be formally and reliably fed back into the initiating technical community.

Without existing PPs, as is currently the case for many developers,the project will take at least 3 years!

What about the scheme metrics for the length of an evaluation?

Well, it depends how the scheme defines what an "evaluation project" is.

NIAP, like many schemes, define the start point as when an evaluation project is formally registered with the scheme.

So, for the scheme, the measurement is often made from the time an application to the scheme occurs until the certificate is issued. The time is variable, but over the years many schemes have found the need to set limits. These limits have been imposed to address abuse. (For example, by using the official: "In evaluation" status as a substitute for the certificate when dealing with procurement requirements, or because a ridiculously long project consumes valuable scheme resources.) NIAP's new policy is to reduce the length of this phase of the project to 90 days.

In order to meet such a timescale for the validation phase, the bulk of the evaluation work must be completed first. (It is the process of evaluation, or pre-evaluation that identifies all the inconsistencies that need to be cleared up in order to keep the "validation phase" to minimum length.)

How smoothly a validation goes (and hence how fast it can be done) depends on the ability to engage with the scheme to allow project members to ask for interpretations, the fine details of policy, and so on, means that "surprises" at the end of the process can be forestalled. This is especially important when a model is used where the validation runs very quickly as a "check" at the end of the project. With the validator assigned at the beginning of the lab engagement, many questions and issues can easily be ironed out.

Examples of this kind  of project model are adopted by many conformance testing programs. Let's use the CMVP (NIST's crypto module program) as an example.

Look what happened! Here the final "validation" phase became the main variable in project length which, due to resource variability in the program, fluctuates; in recent years, between three and ten months. Could this be a lesson learned that CC schemes should pay attention to?

 

Summary: Just how long is a piece of string?

The answer is:

• For the scheme, NIAP: 90 days. 
• For the rest of the community it is the same length it was before, plus 90 days. 

Thoughts, comments and feedback are welcome from the CC community.

P.S. If you are interested in this topic, then I will highlight the accepted paper at ICCC this year by Courtney Cavness entitled: "Faster Evaluations: A Matter of Timing." Check the ICCC program for the abstract and timing.

By Fiona Pattinson