We spend a lot of time working with end-users in the public and private sectors, and I am often asked about “compliance” programs such as SOX, HIPAA, GLBA, and others. I’m also asked about their relationship with government assurance/compliance programs such as FIPS 140, Common Criteria, DITSCAP, etc.

Here is a brief intro to the main compliance programs in the private sector and some quick thoughts about the applicability of FIPS 140/CC:

Sarbanes-Oxley (SOX aka SarBox) - Company CEOs and CFOs attest to their having proper controls for accounting and security. SOX brings accountability to company executives. As painful as it is for companies to comply, the consumer in me really likes this idea.

Gramm-Leach-Bliley (GLBA) - Aims to protect consumers’ personal financial information held by financial institutions. GLBA includes an obligation to keep non-public personal information secure and to respect customers’ privacy. This is a good thing. Seems like common sense, but remember, security/encryption/etc. at the policy level is an expense weighed against risk and cost of breach. It all comes back to economics and finance.

Health Insurance Portability and Accountability Act (HIPAA) - Includes provisions for securing health records and personal information and provides standards for exchanging medical information. Probably one of the most commonly misspelled acronyms (it’s not “HIPPA”).

I’ll admit that I’m not an expert with these programs, but I’ll offer the following based upon experience from my relationships with folks in the finance, healthcare, telecom, and manufacturing markets. Basically, there is no magic pill for complying to these programs. Buying a FIPS 140-2 validated product doesn’t alone provide organizational compliance. Can it help? Well, maybe. My experience has been that the overlap is minimal. While there are requirements for data encryption, there is no blanket mandate for purchasing FIPS 140 or CC-validated products. The same applies to DITSCAP, DCID 6/3 and other government C&A programs. They don’t necessarily or specifically call out requirements for validated products.

Using a validated product may provide risk reduction or may facilitate meeting other requirements such auditing, key management, I&A, etc…. but as I said earlier, there isn’t a magic pill.

Stay tuned… you’ll see a lot more from us on these types of discussions. Maybe even a whitepaper or two.

The saga continues. For a while now, the Security Policy for OpenSSL has been marked as “Not Available.” I have been asked literally four times today by different people about the situation and several other times during the past two weeks. It’s worth a blog post, though this post won’t directly answer all the questions.

A colleague sent me this news article, which actually provides little insight.

Here’s my favorite quote:

NIST is not saying why the certificate was removed.

“The CMVP does not provide information regarding the status or reason as in many cases it may be proprietary,” Easter said in his statement.

What about this case? I can go download the entire source code, so what is proprietary? Why isn’t NIST talking about this?

I have heard a lot of different things about the OpenSSL validation from various entities, and I have made a few of my own estimates. I believe there are other factors at play, but I don’t want those rumors to propagate here.

Last week an email thread with one of our customers contained the following question:

How should [we] measure the return on investment for our certifications?

Well, there is a difference between measuring effectiveness/success and measuring ROI. Measuring effectiveness/success falls into two categories:

1. Measuring success at the project level
2. Measuring success at the program level

At the project level, success can be measured by additional revenue realized and time to market. Success at a program level can be measured by softer areas such as aggregate time to market, effectiveness of outside consultants (if used), impact to other programs, level of communication/understanding in the organization, etc. Success/effectiveness at the project and program levels is one piece of the ROI puzzle.

At Cisco I grew the certifications program from a handful of certifications to one of the most prolific entities in the certifications/assurance space. How did I measure ROI at Cisco? To be honest, I had help from a gentleman who at one point ran Strategic Alliances and Channels for Cisco to map a plan for calculating ROI of the certifications program. Over the course of many months, we worked an initial model and revised it as the program grew. Things really started clicking when we used that model to communicate with product managers and executives from sales, marketing, and development. Having that clear vision was certainly a contributing factor to the growth and success of the program.

Side note: this individual left Cisco, went to another networking company as SVP of Sales, Alliances, and Channels and since left to start his own practice. And today he still is one of my most trusted, respected, and leveraged business resources.

There are many folks who talk about measuring ROI but have no experience doing so from a vendor’s perspective. It’s more than “educate your sales teams” or “how many sales did I make” or “how much money/time I saved by outsourcing.” Building an ROI model for certifications (especially one that will stand up to executive scrutiny) involves many more concrete parameters and formulas - and one size does not fit all.

Unfortunately I’m not going into detail on the blog because, well, building a successful ROI model is one of the services we offer. But perhaps we will write a whitepaper that sheds a bit more light on this topic. There is just too much detail and too many formulas (i.e., too much intellectual property!) for a blog entry.

Let us know what you think of the whitepaper idea at info [at] apexassurance [dot] com.

One of my colleagues called me with the following question:

If version 6.1.2 of software is certified under FIPS 140-2, can [a vendor] claim that v6.1.4 is certified as well?

Note: I randomized the version numbers to keep the situation out of context

This colleague was in a competitive situation where another vendor was claiming that scenario. They had patched their validated version of software, but they were claiming conformance to FIPS 140-2 for the newer version because “no FIPS-relevant changes were made.”

As I’ve said before, 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). The only way this competing vendor can back up that claim is to show the updated certificate/Security Policy which will indicate the validated version - which, of course, won’t matter if the procurement officials buy the argument.

You’re probably thinking, “Your colleague should just raise that issue with the procurement folks and the case will be closed.” Well, not exactly. In these situations, you have to pick your battles wisely. You have to be careful because the pitch could backfire. I’m speaking from experience here; I’ve been on the winning side and the losing side of this scenario. You have to know the people, know the histories, and know the game. In my previous position, I sat across the table from many procurement folks in Intel, Defense, and Civilian operations countering these arguments (and launching offensives!).

Having a process and a methodology will facilitate choosing the correct path. And that’s what we’re all about here (shameless plug for our Assurance Strategy services, but, hey, it is our blog.)

Before a Common Criteria Testing Laboratory becomes officially accredited, it must successfully perform a trial evaluation. During this trial period, the contact information is posted on the CCEVS list for Candidate Common Criteria Testing Laboratories (CCTL), which can be found here. CCEVS Policy Letter #11 specifies requirements for success of Candidate CCTLs. In my opinion, this policy letter (dated September 28, 2005) makes a great deal of sense and was long overdue.

I know of at least two labs that are no longer on the candidate CCTL list. My hunch is that the list has been pared because of the following rule:

After 18 months, if an initial evaluation has not been successfully completed, the Candidate CCTL will be removed from the website, and CCEVS resources will be removed from all ongoing evaluations within the Candidate CCTL.

Perhaps too many people were jumping on the bandwagon thinking that becoming a CCTL is a great business idea, only to find they didn’t know what they were getting into. Or perhaps it was something worse:

CCEVS may also remove resources and/or remove the Candidate CCTL from the website at any time. Reasons for removal include, but are not limited to, technical incompetence, unethical practices, inadequate staffing levels, and notification by NVLAP that the candidate lab has failed to meet NVLAP requirements.

So where did all the candidate labs go? Did they not finish their evaluations in time? Did they not have any vendors willing to take the chance on a candidate lab? Did they not have the steady resources, positive reputation, and blend of business/technical acumen to properly run a CCTL?

We’ve been asked about this several times, and I figured I’d update the blog … OpenSSL has finally achieved FIPS 140-2 validation! See certificate 642.

I know many folks (including a few of our customers) greatly appreciate all the time and energy that went into this. And this finally puts to rest the blog posts we’ve had on the subject. Expect more though, as I’m sure more questions will be raised.

In case you missed it, I posted some comments on questions compiled by D-kripik regarding FIPS 186-3.

We received the following question regarding OpenSSL and FIPS 140:

How can [the validation] go from Finalization back to Coordination?

There are a number of reasons why this can happen, such as the last-minute emergence of a critical issue. As far as why it did happen, that will be up to OSSI to disclose.

The stages of Pre-validation are not always entirely serial. For example a module can return to the Implementation Under Test phase from the Coordination (or even Finalization phase) if a critical issue occurs that requires a significant source code change which impacts the overall version of the module.

What’s the moral of the story? The validation is not complete until the certificate appears on the Cryptographic Module Validation List.

In this post, we forwarded some links from the Internet community regarding the FIPS 140 validation of OpenSSL. Well, it looks as if the news was premature, as we noticed that the validation recently regressed to the “Coordination” phase on the Pre-validation list. OSSI’s site has the following commentary:

The FIPS module has been downgraded temporarily (few days) to cover a couple of very specific details. We will provide an update on the “reasons” for this shortly.

Best of luck to all stakeholders involved. Let us know if we can help.

We received this question yesterday:

To sell to the US government, do vendors have to use a US-based Common Criteria lab?

The answer here is: No, but they should.

Common Criteria is an evaluation methodology that is recognized globally. The full list of schemes can be found here. A product vendor may use a laboratory in any of the “certificate authorizing” schemes. If the main goal of pursuing Common Criteria is to sell to the US Federal Government, then vendors should absolutely consider using a US-based lab. Here’s why:

1. This stuff is complex, and it’s not the responsibility of the end-user or procurement official to know everything about the CC. These folks may not know that products can be certified in other countries, and they may not even think to look at foreign validated products lists.

2. Various entities do not have access to the Internet because of multi-level security concerns, and they may not be able to check validated products lists or in-evaluation lists. What happens in this case is that these lists are ported from the NIAP site as static pages into these classified/sensitive environments. These organizations will not even have an opportunity to review the websites from schemes outside the US.

3. As a product vendor, educating your sales staff to effectively sell certifications such as CC is not easy. In the US, Common Criteria is synonymous with NIAP. We’ve been in many meetings with procurement officials looking for “NIAP certification” (see point #1). Changing your sales strategy is not a trivial task.

What qualifies us to make these points?

Our experience from the vendor’s perspective is what uniquely positions us in the marketplace. We built and owned the certifications program for one of the most prolific vendors involved with security certifications. We have personally met procurement officials at the Intelligence, DoD, and Civilian operations. We have seen and commented on several public and draft procurement policies, and we have developed and tailored vendor sales and marketing strategies.

The US isn’t the only option for pursuing Common Criteria. But if your main goal is to secure business from the US government, using a US lab is your best option.