We have a new look and feel at ApexAssurance.com. It’s much cleaner, which was our main goal. I like the result.

The blog will have a similar design because I’m a stickler for consistency. Apparently custom-developing WordPress themes is no easy task, and hopefully the new theme will be ready soon. You’ll know when I know.

If you like, send an email to webteam [at] apexassurance [dot] com and let us know what you think of the new design.

I heard about this through other channels, but this article gets me fired up.

In summary, here’s what happened. The DoE made a relatively small purchase for vulnerability management/compliance software, and the decision was between three vendors. Part of the RFP required a statement of status for Common Criteria compliance, and one vendor was fully evaluated while the other two were in process. DoE chose the product that was evaluated, and issues arose because, while evaluated, this solution was more expensive and rated lower on technical specifications.

My complaint with the article is this: why does it take such a stab at Common Criteria? Consider these examples:

Deal raises questions about evalution process, Common Criteria’s value

First of all- say it with me: “E-val-u-a-tion” … let’s spell it correctly before we criticize it.

Second, I think the subtitle should be “Deal raises questions about procurement requirements” … what does it have to do with the value of the Common Criteria? Sure, maybe the evaluated product wasn’t running the latest version of code, but that’s part of the evaluation cycle. The real issue is how the selection process was conducted.

The Government Accountability Office recently issued a report critical of the certification process, because—among other problems—it takes so long for companies to obtain, and it does not necessarily guarantee an improvement in security for government agencies.

Where is it written that Common Criteria improves product security? Who says this? I’ve got a blog post queued up and another magazine article that address benefits of Common Criteria and what it does actually provide. Increased security is not in that list.

And again, the real issue here is that two vendors felt slighted by a poorly executed RFP evaluation process, which likely should have been a sole source contract. The issue isn’t Common Criteria in and of itself.

Other experts also question its usefulness. Alan Paller, a leading security expert with the SANS Institute in Bethesda, Md., called the certification process a paper-pushing exercise that has a lot of support in the international community, because labs in other countries can bring in hard currency from U.S. firms trying to get certified.

Pardon me? Look at the in-evaluation list for the US, and then look at in-evaluation lists in other schemes. The international community doesn’t support Common Criteria because of the huge influx of dollars from US companies going abroad to conduct evaluations. The international community supports Common Criteria because they don’t have to maintain a separate program for product evaluations - it’s called Mutual Recognition. I’d prefer to call it “documentation intensive” … “paper-pushing” belittles the efforts of product vendors who commit considerable time and senior resources to pursuing evaluations.

Q. Why did DOE acquire Hercules Version 3.5 instead of 4.1 (the most current version on the market)?

A. A DOE official close to the deal said it was because the new version does not have Common Criteria certification and the older one does; the department will upgrade when the certification is obtained, he said.

Absolutely. Why would they require Common Criteria compliance and then run any (non-evaluated) version? The article then goes on to mention the concept of deferred compliance. Do folks realize how difficult it is to actually qualify for deferred compliance? At Cisco I pushed for this no less than a dozen times with different procurements officials, and it just doesn’t happen.

Why would DoE allow deferred compliance for products in the process when one has completed the process? Just imagine the fallout in that situation.

Here’s my advice to the other two vendors: keep pushing forward. Don’t worry about this small deal, because when you finish your evaluations, your evaluated versions of code will be much newer, and you’ll have the upper-hand. It’s all cyclical. It takes time and strategy.

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.)

Here is (yet another) article on the OpenSSL FIPS 140-2 validation. I like the business-perspective discussion of the validation effort’s background and positioning. One thing that particularly stuck me was that the article disclosed the cost of the effort: “about $85,000″ … Well worth it considering the plans for implementation and estimated cost savings realized by the DoD Defense Medical Logistics Standard Support program.

FYI: here are our archived posts on OpenSSL and FIPS 140-2.

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?

Yesterday I presented at (ISC)²’s Security Leadership series. My talk was “Security Testing for the Risk Management Process” … The objective was to discuss an overview of the Risk Management process and the benefits of a risk management program. Then we discussed where/how/if security testing fits into the model.

The talk was similar to the one summarized in this post. I took a forum style approach to the discussion, and the reviews were quite good. Here’s a big thank you to all who attended and participated. It was flattering for me- there was standing room only, and the event director was bringing in chairs by the handful! I’m glad to see such interest in these topics, and thank you again to all the folks who attended the talk.

-Later that day-

Audrey Dale of NIAP gave an excellent presentation on the state of Common Criteria / NIAP / CCEVS and touched upon some potential future directions for the program. Some highlights from her presentation:

• CC v3.1 could be published as early as July of this year
• South Korea is joining the CCRA as a certificate producing nation
• The IDA Report on NIAP could be released any day now

I wrote an entry about the IDA Report in this post. Audrey mentioned that there are various levels of recommendations, ranging from “abolish the program” to “give it unlimited funding at let it solve all the world’s problems.” It’ll be interesting to see where that leads.

The audience at the event consisted mainly of end users, ISOs, and even a few CISOs. Hats off to Audrey and the NIAP team for being a part of this event. These types of engagements are certainly an ingredient for educating end users, providing status, and being involved with the community. And those are three crucial activities that NIAP CCEVS should continue to proliferate. Nicely done.

The objective: Drive to Washington DC from Research Triangle Park, NC

The asset: Dinner with a customer

The risk: Being late

The countermeasure: Drive faster than the posted speed limit

The vulnerability: Temporary lack of good judgment on my part

The threat: Getting a speeding ticket

The threat agent: Highway patrol

The threat probability: Low (based on personal experience)

——————-

The result: Low probability doesn’t mean no probability. The threat agent exploited the vulnerability.

The good news is that I was still on time for the dinner meeting. And hopefully the money will go towards a good cause (education, perhaps?). Or it may help sponsor an increase in threat agents, which will increase the threat probability. Which means I need to reassess my vulnerabilities and my countermeasures.

[You know you’ve reached a new level of geekdom when 15 minutes after getting a ticket you’re thinking, “How can I blog this?”]

In this previous post I mentioned that NIST is officially turning over the NIAP reigns to NSA. They’re moving full steam ahead, as indicated by the message on http://niap.nist.gov:

ATTENTION!
The NIAP website is moving.
The NIAP website is moving to a new address: http://www.niap.gov
However, during the transition, it will be hosted temporarily at http://niap.bahialab.com
Click the link above, or wait and you will be redirected there in 10 seconds.

So update your bookmarks and let your customers know where they can find everything.

As an aside, one of our customers sent me an email after reading the aforementioned “Changing the P in NIAP” post. I said, “Perhaps the P should stand for Program. Or Productvalidationprocess.”

This person suggested “How about National Information Assurance Painintheass.”

Sometimes it’s hard to find humor in this business, and this still makes me chuckle.

This FCW article was fraught with such juicy information… I have to write just one more post.

The article has a few quotes from Dan Kent, who is the Federal Systems Engineering Director at Cisco. I know Dan well, and we had a fantastic working relationship. I’m bringing this up because I’m very proud of my former employer. Getting executive recognition (other than approving my purchase reqs) and public involvement was a rare occurrence, with the exception of a couple of business units (you know who you are).

Salvatore La Pietra of atsec made the following comment:

“It’s easy for agencies to criticize NIAP, but they probably don’t use the processes correctly in the first place” because they’re not educated about them, he said. “They have to do their homework.”

I absolutely agree with this statement. I think a lot of folks are very quick to criticize NIAP because:

1. There are problems, which makes NIAP an easy scapegoat for any problem
2. They don’t truly understand the roots of the problem or the tangential ramifications
3. They somehow think that it will make them look better or mask their own faults

These points are self-evident, but I’ll expand on them in a future post.

In retrospect, I should have used a different title for the previous post. I thought there were more references to the FCW article out there. That’s what I get for expecting too much.

One facet of the article that struck me has to do with understanding not only what the Common Criteria is, but the language surrounding it. I touched upon this in a previous post. The FCW article has the following quote from John Pescatore:

Only government labs can test at Common Criteria Evaluation Assurance Levels 5 through 7 — the highest levels of scrutiny. NIAP now has fewer experienced testing employees and is not replacing them, which will further lengthen the process, he added.

This is somewhat misleading information. First of all, there isn’t really a “government lab” who conducts EAL5-7 evaluations. All CCEVS Common Criteria Test Labs are accredited to perform evaluations. There is an evaluation group in NSA that performs testing (e.g., AVA_VLA.3, etc.) at these higher assurance levels, but I wouldn’t consider this a government lab.

Does NIAP have testing employees? Not really. They have validators, who summarize “the results of an evaluation and confirm the overall results, (i.e., that the evaluation has been properly carried out, that the CC, the Common Evaluation Methodology, and scheme-specific procedures have been correctly applied; and that the conclusions of the Evaluation Technical Report are consistent with the evidence adduced).” (from NIAP CCEVS Acronyms and Terms)

I think that what Mr. Pescatore was trying to say was that there has been some attrition in the validation community, and NIAP is having trouble replacing the resources because of funding and lack of, well, talent - the pool of validators is small, and the pool of senior validators is even smaller. This has nothing to do with EAL5-7 testing. That level of evaluation will always take a long time because of the rigor involved. Plus, look at the In-evaluation list and the Validated Products List: there aren’t many EAL5-7 evaluations. That’s not what’s slowing the process.

I’m really not trying to rip into Mr. Pescatore’s comments. Doing what he does, he’s obviously a bright individual. I’m just trying to enlighten folks who may be misled or confused by his language and statements.