According to NIAP CCEVS:

Beginning 1 October 2007, for FY08, the NIAP CCEVS office will begin accepting US Government PP compliant (basic, medium or high) and EAL 4 or above products in support of National Security customers. Product submissions meeting the above criteria will be queued and validation resources allocated as they become available. Detailed letters of intent identifying DoD or IC customers will continue to be required.

There is still a bit of discussion and concern around the Fee for Service validation plan, so things will certainly be interesting.

September is a busy month (even by our standards!).

In case you missed it, there is a draft policy for the fee-for-service validation model from NIAP CCEVS. Details can be found at the NIAP CCEVS website.

Things have been so hectic lately. It’s been almost a month since my last post (thank you for your patience, by the way), so this better be good.

It is, and it isn’t.

Has anyone seen the newest Medium Robustness Firewall PPs? Here and here.

Here are the requirements for alarm notification upon identifying the potential security violation:

• local console,

Fine.

• remote administrator sessions that exist, and;

Okay.

• remote administrator sessions that are initiated before the alarm has been acknowledged, and;

Fine.

• at the option of the Security Administrator, generate an audible alarm, and;

Uhhh . . . pardon me?

An audible alarm? Remember, the devices pursuing these Protection Profiles don’t sit on “Joe Administrator’s” desk. They sit in physically secure data centers, and there isn’t someone standing by the appliance at all times. So, honestly, what is the point?

Remember my rant on FIPS 140 Opacity requirements? Well, we’ve got a similar issue here. Assurance goes beyond point products.

A co-worker of mine coined the phrase “COTS-but” … meaning these PPs are written for products that are COTS- but we’ve added all sorts of custom, localized, illogical requirements that systems level assurance should address.

Does someone really need this?

Before I embark on a whirlwind itinerary next week (five days of customer meetings in four cities), I wanted to put up a brief post about some changes in the Canadian Common Criteria Evaluation and Certification Scheme (CCS).

In case you aren’t aware, the CCS has instituted a policy for the acceptance of new evaluations. You can read the policy here.

Remember the fallout from the NIAP announcement? There hasn’t been similar punditry for this situation. Why is that?

The NIAP CCEVS website has a new address:

http://www.niap-ccevs.org/cc-scheme/index.cfm

Update your bookmarks accordingly!

One of our customers recently asked the following question:

I have a potential government customer asking me for a copy of our ST. Is this something that I should distribute?

There is nothing wrong with this. I sent draft STs to potential customers quite frequently at Cisco.

Certain departments/agencies are more prolific in their requests of draft documents than others. I actually had a system coordinated with folks at State, NSA, the Army, and several other accounts for releasing draft documents, and it certainly helped in the sales process.

When delivering a draft ST to a customer or potential customer, be sure to state that it’s a draft and may change during the course of the evaluation. I placed huge “DRAFT” watermarks on it just to make it clear. The ST will be publicly available when the evaluation effort is complete.

In this post, I said the following:

I think the Common Criteria evaluation process can be of value to many product vendors. Note the way I said that: can be of value to many product vendors. Is always of value? No. For all vendors? No.

I wanted to share with you an example of a realized benefit: documented configuration management processes.

Every software development team has established processes for version control and development processes. They exist whether or not they’re documented or follow best practices. These tools and processes are rarely succinctly documented. Why? Well, several reasons:

1. It’s relatively elementary. Any developer worth their salt knows the value and concepts of version control. And if they aren’t following a specific process document, they are made aware of the CM process in a relatively short conversation with someone who does know the details before they begin developing.
2. It’s a small team. Maybe it’s only one developer, or a few developers working side by side. Maybe they communicate very well and implicitly follow a set of processes.
3. It’s low priority for developers. See the first two points.

It makes good sense to capture these details whether you’re trying to justify sound processes for increased funding/acquisition or whether you’re trying to manage your growth.

And that’s exactly what one of our customers communicated to us recently: they are happy to go through this development process with us for a couple of reasons. First, they’d like to have these procedures documented to ease growing pains. And second, they’re looking to improve their processes against best practices.

And that’s exactly what we’re going to do.

Check out this blog post at Tenable Security. Marcus always has interesting things to say. There’s some talk about assurance, where Marcus essentially says that assurance shouldn’t be an afterthought.

I agree. True assurance should be baked in to the design of a product or system. Unfortunately that rarely happens with some of the government assurance programs such as FIPS 140 or Common Criteria. I’ve leveraged the requirements and processes of these programs during product design (both during my tenure at Cisco and at Apex). From my experience, considering these requirements at product design provides a much more positive impact on design / development and smoother execution of documentation evaluation / product testing when conforming to FIPS 140 or CC. It’s ideal, but obviously not necessary.

The Canadian Common Criteria Scheme is preparing a policy for review/acceptance of evaluations as a proactive attempt to manage a potentially large number of evaluations resulting from the recent NIAP policy. I certainly respect their foresight to prevent long queues, but they’re going about it incorrectly, and it’s potentially going to piss off a lot of folks.

But they have to do something. Their labs can’t handle the volume of work traditionally supported by US labs, and the certifiers will almost certainly have difficulty managing their workloads.

I think it will be a rough year for the Common Criteria. But if NIAP’s plans for FY08 are successful, then everyone (non-US schemes included) will breathe a bit easier.

I can’t believe some of the garbage I’ve read and heard about this latest CCEVS policy. Here are a few summaries:

• One individual claims to have known about this “months ago”
  
  The real story: Talk is cheap. I doubt even NIAP CCEVS knew about this months ago. What’s this person trying to prove? That’s not the way to build credibility. Offer some solutions! If you’ve known about it that long, then the community expects to see some detailed and thoughtful solutions.
• One company claims to have already shifted their consulting efforts to support evaluation with non-US labs because they anticipated a scenario such as this one.
  
  The real story: no US lab will work with this company, and they were essentially forced to work with non-US labs. But I guess marketing and truth rarely collide.
• One individual claims that NIAP CCEVS implemented this policy to “stick it to the labs”
  
  Puh-lllleeeeeeeaaaaasssssseeeeee.

I am preparing a formal statement on the subject. But in the meantime I’m working with several customers to submit evaluations to NIAP CCEVS ahead of the deadline. Obviously that has priority.

And I’m not worried about NIAP’s increased scrutiny over schedules and evaluation progress for one simple reason:

We don’t miss deadlines.

More to come after we get through the short-term urgency.