I have been asked twice in the past week if we are planning to become a FIPS 140 testing lab. The answer is still no. Here is a post for reference.

In case anyone missed it, SAIC is now an accredited Cryptographic Module Testing Laboratory. They’ll be one to watch. Given their success in the Common Criteria space (one look at the In-evaluation list gives you some indication), they should be poised to do quite well.

When it rains, it pours. We’ve been busier than ever lately, and there has been a flurry of Common Criteria activity recently in the blogosphere. I’m trying to address everything as quickly and as thoroughly as possible, but our customers come first. So please understand if our post/response time lags.

First, check some of the comments on our previous post. All things considered, we get a lot of hits but don’t get many comments like Schneier or some of the other security blogs. But the comments we do get are of decent quality. Actually, I prefer that; a blog with too many comments is a forum.

There’s a new post at Matasano that issues a call to action: a scholarly debate on the value and merits of the Common Criteria. I like this idea because I want to share more about my thoughts and ideas around security certifications, which is the main reason I started this blog. I want to hear more about what others have to say. And I want to take all those good ideas and actually do something with them!

Over the years, I have said a lot of things about Common Criteria in news articles, presentations, this blog, private discussions with process owners and other stakeholders, etc. Here’s a quick overview of my opinions:

• I think the intent and value of Common Criteria is misunderstood. I think this is the root of most of the issues, diatribes, and general bitching about the CC.
• I don’t believe Common Criteria is the end-all and be-all of security testing. I don’t think it was intended to be, but it has somehow developed that reputation. See previous bullet.
• I do think Common Criteria is (in many cases) a checkbox during procurement. It’s a checkbox because many folks in the end-user community don’t use Common Criteria as it was intended. See first bullet.
• I do think that the evaluation process as a whole can help weed out some of the dreck vendors/products/solutions that would be deployed into our Federal infrastructure.
• I do think requiring Common Criteria objectively and effectively can be a valuable component of an agency’s risk management plan. It shouldn’t replace systems-level certification and accreditation activities.
• 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 think Common Criteria should focus more on testing and less on documentation at the lower levels of assurance. If not Common Criteria specifically, then something Common Criteria-like. Some structured methodology for testing.

Stay tuned. Things could get interesting.

Thomas Ptacek at Matasano Security wrote an interesting post titled “What Common Criteria Certification Means” … I read the Matasano blog regularly because they seem like a bright bunch of folks, and I was surprised to see a post about Common Criteria. Ptacek points out a few misconceptions of the CC and offers an analysis of its value. I agree with portions of the post, and I disagree with others (mainly the semantics). Check out my comments on the blog itself.

As I mentioned in this post, people love to flame Common Criteria and NIAP. And believe it or not, I have sharply criticized the CC both publicly and privately. But it’s a pet peeve of mine when people bitch about issues and offer no resolution or when they bitch about things that they don’t necessarily understand.

Sure, I have my opinions on what’s wrong with NIAP, Common Criteria, FIPS 140, etc. “So where is your list of recommendations for process improvement?” you ask. Fair question. I am working with key stakeholders through various channels to drive action and offer insights/recommendations for resolution of several issues. Hopefully you’ll see more details made public as allowed by agreements, ethical choices, circumstances, etc.

For now, I aim to keep this blog relatively objective, hopefully informative, and somewhat free from bitching. Unless, of course, the mood strikes…

It’s amazing what people talk about in airports. I’m on my way to Toronto for a talk, and I’m sitting across from a guy who works for a large and well-recognized organization (I won’t mention the name). He is apparently involved in a post-merger integration, and he is rather loose with the details. After talking about various (what I would consider sensitive) business-related topics, he starts talking about technology and security. Then he lets out this little nugget of hacker-bait:

Our [sanitized systems] will be taken down this weekend to perform [sanitized operations]. Then we’re going to deploy [sanitized edge solution] sometime between 6 and 8 pm on Saturday … We’ve got a new security guy, and everyone is confused about what’s going on and who’s who. It’s chaos.

I don’t have the first clue how to technically exploit this (I wouldn’t anyway, but that’s beside the point). But I know enough to know that this guy should not be discussing this information in a crowded public area, especially considering the fact I just saw a guy a few gates down pounding on a PowerBook with a bumpersticker on the bezel that said, “I read your email.” I love that sticker.

Anyway, to make things worse, Ole Loudmouth starts name-dropping what sounds like owners of the systems or sys admins. What a recipe for social engineering!

• I’ve got the guy’s name off his luggage tag.
• I know where he works and can take a decent stab at what his role is.
• He’s disclosed names of internal personnel (both management and a technical roles)
• He’s admitted that the situation is “chaotic” and no one knows what’s going on.
• He’s identified sensitive internal systems, work/upgrades that will be performed, downtimes, projected uptimes, and design solutions.
• Etc., etc., etc.

Ira Winkler would have a field day with this!

I am thinking about leaning over to say something, but before I can figure out just how to approach this, his counterpart changes the subject to the World Cup as they head over to stand in the cattle line to board the plane. Damn. So much for the fat contract for internal training or process improvement. And so much for the opportunity to verbally slap someone back to reality.

This is a very difficult security problem to solve (and I’m not talking about the World Cup). These types of situations support my belief that security is less of a technical issue and more of a business issue.

This particular battle will have to be fought some other day and by someone else.

More FIPS and Common Criteria fun later in the week…

A colleague sent me this news article which parallels the discussions in my earlier post about 802.11i, FIPS 140, Common Criteria, and JITC requirements for wireless products deployed in DOD. It’s worth a look.

This will be a busy week, but I’ll try to post when I can.

We’ve been asked about this several times for nearly a week, so I figure it’s worth a blog post. Earlier this month the DoD issued a memorandum for the “use of commercial wireless Local-Area Network (WLAN) Devices, Systems, and Technologies in the Department [of] Defense Global Information Grid.” The new policy supplements DoD 8100.2 and is effective June 2, 2006.

Essentially, the new policy specifies the use of standards-based technology (such as the 802.11 suite). In addition to FIPS 140 and Common Criteria, the policy also requires Wi-Fi Alliance and WPA2 certifications. The policy does discuss Common Criteria requirements for WLAN components that weren’t covered in 8100.2, but this isn’t necessarily new or revolutionary as they have required Common Criteria on those components for quite some time.

The memo also defines additional policies for JITC testing. I haven’t posted much on the blog about JITC testing since it’s a relatively narrow focus for specific environments. I had exposure to JITC testing at Cisco, and it makes FIPS 140 and Common Criteria look like a walk in the park!

Note: Please email us at info [at] apexassurance [dot] com if you’re unclear about anything that is mentioned here or its significance.

Wow, things have been busy lately! This is the longest drought for a post in this blog’s six month history. Sorry about that.

After reading Robert Scoble’s post about leaving Microsoft and responding to some of the rumors out there, I thought I’d offer a similar post on my reasons for leaving Cisco to address many questions and quell several rumors.

Leaving Cisco was one of the most difficult decisions I have ever made. My management team gave me carte blanche to run my program to my discretion. I never had to justify expenses for travel, conferences, training, or marketing because they supported the mission of the program (and trusted my judgment not to abuse my privileges because well, I didn’t abuse them). I was never micro-managed, nor was I held to unrealistic expectations. I was encouraged to explore areas of business and technology that went outside my core job description, and I had exposure to senior level executives, including Cisco’s Chief Technology Officer and the now-retired Chief Development Officer (more to follow on this). I left on the best of terms, and lord knows they did everything they could to keep me… which I respect and appreciate because I know they don’t do that for everyone.

As many opportunities and successes as I had, I wanted to build my own company. I knew I had a comfortable, stable position, so why trade that for the risk of entrepreneurship? Those of you who know me know that I’m not always the most risk-tolerant person, but I saw both short-term and long-term opportunity. It was calculated risk.

It’s been well over a year now, and business is going well. As far as FIPS 140 or CC validation support goes, well, we’re changing the way you think about certifications consulting. We have solid relationships with several US Common Criteria labs, and we have an excellent working relationship with the Scheme. We are also working on exciting projects outside of FIPS 140 or CC validation support engagements. Expect to see more on this in the future.

Finding success at Cisco spawned and validated my beliefs that I could be successful at starting this firm. I sincerely thank the company, my management team, and my counterparts for all the opportunities, experience, and knowledge I gained and strengthened. There days when I do miss wearing a Cisco shirt, and I still keep in regular contact with a good number of folks there, all of whom continue to respect and support my decision.

So congrats, Robert, for making the difficult move to another venture. I know it’s not easy, but it can be both personally and professionally rewarding.

I’ve been asked quite frequently lately if I will attend this year’s ICCC. In short, we shall see. I have another speaking engagement that week, and I’m trying to work out a suitable itinerary.

Things here have been busier than ever, and it looks as if this trend will continue. Of course, this is a great position but also prevents me from updating the blog as often as I would like. We’re also working on some interesting ideas for expansion to new markets and services. As these plans are solidified, you’ll undoubtedly see more information on our website as well as updates on the blog.

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.