Archive for August, 2006
My Dilemma
Wednesday, August 30th, 2006
There are some very interesting things going on within NIST regarding FIPS 140 and within NSA regarding Common Criteria. There are some new areas of potential FIPS 140 implementation guidance from NIST, and CCEVS is redefining a couple of policies. We have been working with our customers to address these situations, and a few customers have asked why I haven’t updated the blog with more details.
So here’s my dilemma- I don’t think I should blog about them because they’re not public and/or official yet. This blog isn’t meant to be a rumor mill. I’m not the press, and I don’t care to publicly speculate on unsettled, unofficial information.
As new CCEVS policies are released or FIPS 140 Implementation Guidance is issued, we will issue announcements and comments accordingly.
The Great Debate (well, sort of)
Tuesday, August 22nd, 2006
End users are under pressure to secure their systems and their infrastructure. And by “secure” I mean reduce risk. Or at least cover their own ass. For obvious reasons, end users cannot exclusively hold product/solution vendors to this task. So they rely on process, and specifically mapping best practices in processes to their environments.
Enter Common Criteria. If you’re not familiar with the term, it is a methodology for evaluating security functionality of IT products. As one of my colleagues said:
[Common Criteria] provides a methodology for finding and testing vulnerabilities related to the design, development and operation of the claimed security features.
Security products conform to this evaluation process to qualify for procurement in global public sector markets (mainly the US Federal market because it has the most stringent requirements for procuring evaluated products). Product vendors could potentially see benefits to pursuing CC evaluation past the revenue opportunities, but these benefits are often hidden by 1) the considerable costs of dollars and constraint of resources and by 2) the perception that Common Criteria does not improve product security.
The purpose of the ensuing posts is to discuss a few things about Common Criteria:
- its value and relevance in risk reduction
- its ability to improve security products
- its value and relevance to security product vendors
Many of the readers of this blog know that I’ve worn two hats in the Common Criteria community: that of a product vendor and that of a consultant. I have solid working relationships with the current director and former director of the National Information Assurance Partnership’s Common Criteria Evaluation and Validation Scheme. While that certainly strengthens my business as a consultant, it can potentially lead to conflict of thoughts and statements during this debate. So I will be forthcoming in my approach: I will draw from I have seen from the product vendor and the consulting perspectives, and I will communicate the unbiased intentions and purpose of the CC itself. As with everything else that I post on this blog or publicly talk about, I will not disclose customer names, customer situations/issues, or anything else that is confidential (either by formal NDA or by implicit trust to do the right thing) between other stakeholders and me.
Many of my opinions of the CC were captured in this post. More to come…
FYI: this was originally prepared as my opening statement for the debate referenced here at Apex Assurance and here at Matasano Security. It doesn’t look as if the debate will happen, but I’d still like to use this as a vehicle for future posts.
SOX, GLBA, HIPAA, and FIPS/CC
Thursday, August 10th, 2006
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.
New Features at CCEVS Site
Tuesday, August 8th, 2006
The NIAP CCEVS In-evaluation list has a new look and feel. I like it… very easy sorting of information. Well done.
For the record, this was released a while ago, and my post was stuck in the “draft” state for over two weeks. Sorry about that!
FIPS 140 and Product Vulnerabilities
Wednesday, August 2nd, 2006
I am frequently asked about the FIPS 140-2 validation program’s impact on product security. Of course, it depends on how “security” is defined, but most folks asking the question are asking about its effectiveness in finding and reducing vulnerabilities. There are cases were certain types of vulnerabilities may be minimized because of FIPS 140-2 validation, but it’s not a panacea product security.
Here is an example: Cisco Systems recently announced a vulnerability in their IKE implementation, affecting ASA/PIX appliances, IOS software, and the VPN 3K Concentrators.
The attack against the Internet Key Exchange (IKE) protocol described in the NTA Monitor advisory exploits the stateless nature of the IKE version 1 protocol. The goal of such an attack is to deplete the resources available on a device to negotiate IKE security associations, and block legitimate users from establishing a new security association.
Now, I’m not picking on my former employer here; it’s just an example. This is a serious vulnerability that affects FIPS-validated products… including products from other vendors. So why didn’t FIPS 140-2 catch this? Well, because that level of protocol scrutiny doesn’t fall within the scope of FIPS 140-2 validation. It’s as simple as that.
It’s also important/interesting to note that the products will maintain their FIPS 140-2 validation certificates.
For more details on this vulnerability, read this document from Cisco.
Travel woes and customer successes
Tuesday, August 1st, 2006
I really need my own jet. I’m enjoying another overpriced airport lounge beer, stuck again because of another delayed flight. In the past month alone I’ve been to Europe, New York, Washington DC area, California, and now New York area again. Next I’m off to Minnesota, the SouthWest, Las Vegas, back to DC, and probably Boston and New York again. And this is all (except my previous trip to NYC) related to client work, not my busy round of talks and presentations.
Now, I have no problem hopping on a plane to meet with clients and with potential clients. And being stuck in an airport gives me a chance to update the blog and to catch up on some work. Guess which one has priority? Hopefully now you’re getting a sense of why I’m not able to update the blog as much as I would like. Maybe I should just open up the blog to others…
Business has really been booming, and we sincerely appreciate the energy and commitment our customers and partners have shown us.
