Following the FIPS 140-2 validation of OpenSSL, some comments posted on Slashdot were incorrect. Most were corrected in replies, but this one was untouched:

Another poster mentioned that this restricted the choice of encryption algorithms to 3DES. That is incorrect. FIPS 140-2 is an AES implementation, specifically because of concerns over 3DES’ long-term viability. There are no approved 3DES implementations under FIPS 140-2.

FIPS 140-2 is a specification for cryptographic modules. In addition to specifying requirements for cryptographic algorithms, FIPS 140 specifies requirements other categories including key management, self tests, interfaces, design assurance, and others. A module must implement at least one approved security function (here is the approved list). A module *may* implement AES as an approved cryptographic function. Incidentally, AES is specified in FIPS 197.

There are many 3DES implementations in cryptographic modules validated under FIPS 140-2. The 3DES validations are listed here. Note that just because a module has its algorithms validated, it does not necessarily have a full FIPS 140 validation unless it’s listed here. DES is withdrawn as an approved security function (see NIST’s DES Transition Plan).

A new presentation is uploaded to the Presentations & Whitepapers section of the site. The presentation was originally prepared for our BoF at ShmooCon, and actually, the presentation wasn’t used at all … we just dove right in and starting talking about the issues!

This entry summarizes part of the con discussion, as does this one.

Also our method for requesting presentations & whitepapers was revamped and is now more user friendly.

We saw this posting yesterday on OSSI’s site. And here is one other article on the subject.

Customers of Apex Assurance Group have waiting for this day for many months (hence the reason we also filed this in “Common Questions”), and this is terrific news for them and for the open source movement as well. As the OSSI site says:

… the validation does not immediately solve all FIPS 140-2 compliance issues

This is a true statement. While it certainly will help facilitate the process, product vendors pursuing validation won’t be able to claim that their product is validated only because it uses the validated version (v0.9.7j) of OpenSSL. For more information, end users and vendors will want to refer to section G.5 Maintaining validation compliance of software or firmware cryptographic modules of Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program. Going forward, we’ll provide guidance on this blog as well.

Congrats to the team for making this happen.

We found another summary of our Security Product Testing and Certification BoF at ShmooCon 2006. Here is an extract of the major discussion points around Common Criteria:

* what is the practical usefulness of Common Criteria or any other certification other than its mandated use in government installations?
*a reminder that crypto is not part of the Common Criteria, nor is Common Criteria certification meant to be an assurance of security
*vendor writes a target (e.g. ST security target) which asserts claims of product’s features and certification verifies that the vendor complies with its stated target
*probably the biggest drawback is that certification can’t address the end-user; meaning the product may provide secure features but be misconfigured
*however, separate tools exist to address end-user configurations; an example is FISMA
*certification is often an afterthought instead of a part of the design process
*the real value is often going through the process and the lessons learned in order to get the product certified
*there are no studies showing that certified products are safer than non-certified products
*certification is often mandated by people who don’t understand technology and its limitations
*there is a need for dynamic time-sensitive certifications: by the time a product is certified it is obsolete and the code has exploits

Obviously there is ample material from the Shmoo discussion to provide the basis for future posts on this blog. Stay tuned for our thoughts and insights on these issues!

We found this article at Network World online. For the most part, the content is accurate. We do have the following comments:

1. The title “Status of federal encryption standard gains increasing acceptance”

This point was never really justified. FIPS 140-2 is gaining increasing acceptance where? In non-Federal verticals? There was a mention that FIPS 140-2 is the basis of a draft standard for the financial community… but this has been talk for the last 5 years. Some financial institutions do require FIPS 140-2 for cryptographic products, but this isn’t a standard policy across the industry. It’s possible that FIPS 140-2 may become table stakes to enter the financial market, but you better believe those entities will not maintain FIPS compliance on deployed products. That’s a subject for another post though.

2. Regarding the “How It Works” process flow on Page 2

On Step 3, the vendor doesn’t write the test report- the testing laboratory writes the test report with input from other documentation that the vendor produces (including the Security Policy, Vendor Evidence, and Finite State Machine). The Vendor Evidence document provides the bulk of information to be included in the lab’s test report, and the testing lab also draws on functional tests and code reviews to deliver the test report.

Otherwise, the article was concise, clear, and accurate.

If you found this article interesting, check out our Product Manager’s Guide to FIPS 140. Here is the abstract:

This paper provides an overview of FIPS 140 validation and highlights salient points from a product manager’s point of view. While specific requirements are not covered, this paper addresses the validation process, the reasons to pursue validation, typical timeframes, categories of requirements, and documentation requirements. This paper concludes with a list of recommendations and best practices for pursuing FIPS 140 as well as information on services from Apex Assurance Group.

Updated January 18, 2006: Interesting comment posted

Apex Assurance Group was at ShmooCon to talk about Security Testing and Certification. The panelists were as follows:

• Al Potter - ICSA Labs
• Bruce Potter - Booz Allen Hamilton (and Shmoo Organizer)
• Ray Potter - Apex Assurance Group

Note: there is no relation between the panelists. And why get that many Potters in one room? Because we could.

The discussion was in BoF format, and it was certainly one of the more useful, enlightening, and entertaining discussions around security testing we’ve seen recently. First of all, *everyone* in the room was familiar with the FIPS 140, Common Criteria, and ICSA programs. And judging by the insightful comments, it was clear that the audience read the standards, understood their purpose, and implemented/configured certified products.

Must of the discussion centered around Common Criteria, where the group discussed the following:

• Certified products are not necessarily secure

  There is no conclusive research that certified products are more/less vulnerable than uncertified products. FIPS 140 and Common Criteria are about assurance, not about security. One BoF participant made the comment that the programs are for point products, and hooking certified products together will not make the system secure. This is a very true and valid point; Apex Assurance Group would like to remind readers that FIPS and Common Criteria are only a part of systems security design and engineering.

  One suggested resolution was to have a group of independent, certified, firewalled (”ed” - not “firewall”) experts to conduct a series of vulnerability assessments and penetration testing on the product under test in paralle to the work done by the Common Criteria evaluation and testing team. This could provide a more “security” meat behind the assurance certification. Not a bad thought, actually. The devil is in the details and the execution, of course. But it’s a valid concept.

• The value of certification is over-substantiated (or just not understood)

  Surprisingly, FIPS 140 and Common Criteria weren’t faulted in their delivery of security assurance. The audience widely agreed that FIPS 140 and Common Criteria do not meet the security needs of end users. The perception and marketing of these programs took the most criticism.

From our point of view, the main take-away from the discussion is that security assurance and security testing are complex topics. There are misperceptions about the purpose and value of FIPS 140 and Common Criteria, and while they are valuable, there is vast potential for improvement in how these programs can meet the security needs of end users.

Finally, hats off to Bruce Potter and the Shmoo Group for putting this conference together. The con was well organized, well attended, and very well managed.

Our recent post about Apex Assurance Group’s plan to become a FIPS 140 test lab (we’re not becoming one, by the way) sparked an interesting question:

If we use [a consultant] to help us with certification, will we complete testing without any issues?

A product vendor should always expect a testing laboratory to return questions/issues after submitting a product/documentation for either Common Criteria or FIPS 140-2 testing/evaluation. It’s the testing lab’s job to be thorough; if they aren’t, their hands are slapped by the government oversight and validating bodies. And if they aren’t thorough, then the value of the assurance process suffers.

Also, remember that these validation processes are not simply black-box testing.* The lab isn’t only testing expected outputs for a given set of inputs; they also test and evaluate the inputs. As such, there is room for interpretation and different ways to meet some of the more subjective areas of either standard.

The role of the consultant is to provide experienced technical guidance and facilitation of the product assurance process, and consulting services can help reduce the time and can help minimize the number of issues uncovered during the testing process. When deciding whether to use a consultant, a vendor should conduct a cost-benefit analysis and decide whether they want to support the short-term fixed costs of consulting versus the long-term variable costs of not using a consultant. Either way, the product vendor should not expect their submission documentation and product to be “rubber stamped” through the process.

Please contact us with other questions.

* If you’re reading this blog, then chances are you understand the difference between these testing methodologies. But just in case, here is an article that discusses white-box and black-box testing. Certainly other (and likely better) resources exist on the Internet, but time prohibits us from doing an exhaustive search for the most comprehensive resource to explain the concept. Google’s top result was enough.

In an earlier post, we addressed a potential catch-22 with risk assessments:

The organization’s stakeholders (e.g., business process owners and systems owners) must recognize, adopt, and address the threats and mitigation plans detailed in the risk assessment. If they don’t, then what was the point of the risk assessment?

Before conducting a risk assessment, an organization (usually) has a sense that they need a risk assessment. And that’s a very important part of the problem- realizing that a problem may exist. Whether trying to hide insufficiencies from management or not accepting the fact that something actually could be wrong, people tend to be bashful and even threatened to identify, recognize, and (of course) take responsibility for areas of risk within the organization.

So what’s the message? Check the ego at the door. The information and benefits gleaned from a thorough risk assessment outweigh any short-term gains from covering up the problem. Be proactive. Be concerned. Hopefully your systems will be more secure, your processes more streamlined, and who knows… maybe you’ll get a raise or promotion. When that happens, contact us - drinks are on you.

The short answer here is “no.” There is no policy mandating revalidations. In our experience, the decision to revalidate is governed by these parameters:

1. Customer demand.

Demand varies by department/agency. It depends on whether they run the product(s) in the evaluated configuration (more on this in a future post).

2. An aggressive certification strategy

A validation certificate for either FIPS 140 or Common Criteria applies to a single version of operating system on a specific version of hardware (e.g., a snapshot in time of the product). Some product vendors revalidate often to generate more certificates to prove their commitment to certifications. Vendors also pursue revalidations frequently to help save in long-term cost and effort. Generally (but not always, of course) the deltas between candidate versions diminish as a product pursues validation more frequently, and fewer changes can mean lower costs.

Apex Assurance Group specializes not only in helping vendors through FIPS 140 or Common Criteria but also in developing a strategy to reduce long-term costs and expedite time-to-market. We are the only consulting firm with proven experience from the vendor perspective in achieving that kind of horizontal success.

At the present time, Apex Assurance Group has no plans to become a FIPS 140-2 test laboratory. For one reason, there are currently plenty of laboratories. But primarily (and more importantly to our customers), becoming a testing laboratory would conflict with Apex Assurance Group’s core mission and services. Here’s why (from the CMVP implementation guidance):

A CMT Laboratory may not perform validation testing on a module for which the laboratory has:

1. designed any part of the module,
2. developed original documentation for any part of the module,
3. built, coded or implemented any part of the module, or
4. any ownership or vested interest in the module.

Apex provides consulting services to support the first three points listed above. Our Security Certification Consulting services include education, design assistance, development of FIPS 140-specific and other supporting documentation. We can also provide software engineering resources to help build products for FIPS 140-2 compliance.

Our Security Certification Consulting services augment our Security Assurance Strategy services to help companies build a security assurance program to address communications/sales strategy, education and training, and process improvement across the organization- with the end goal to reduce time-to-market and long term costs.

While theoretically we could offer both consulting and testing services, we feel this does not support our core mission, and it potentially obfuscates the understanding of our value proposition.