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?

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.

Some of our customers have asked us to provide an analysis on the new testing of the RSA algorithm for FIPS 140-2 validations. Without going to too much depth (to respect their contracts and interests), I thought I would summarize that analysis here.

Basically, NIST CMVP requires testing against a vulnerability discovered in RSA a few months ago that allows attackers to forge a PKCS-1 signature. Vendors face the following implementation policies (from the NIST CMVP website):

1. For any algorithm validation request where a lab has used a previous version of CAVS to create files and has already sent the sample and request files to the vendor, NIST will accept validations using this tool up through December 31, 2006.
2. If there are any validation requests where a lab has used a previous version of CAVS to create files and has not yet sent the appropriate files to the vendor, please regenerate everything using CAVS5.2.
3. It is strongly advised that any CMVP cryptographic module in the pre-validation phase re-test the RSA implementations with the new version of CAVS.
4. After December 31, 2006, all new received test reports to the CMVP pre-validation queue must use the CAVS5.2 to validate RSA.

A colleague sent me a note inquiring about the applicability regarding OpenSSL. If you’re running OpenSSL, you can

1. download versions version 0.9.7k or later or version 0.9.8c or later
2. apply this patch

We recently ran algorithm testing for a customer running OpenSSL and passed with no issues. Then again, since they meet the criteria above, we expected them to.

The best bet here is to have your implementation validated with CAVS5.2 to be sure this vulnerability is addressed. It may not be easy, but it beats having your customer fault you if this vulnerability is exploited in their environment. Here is a rare example of being able to use assurance as intended!

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.

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.

I ran across this post on Microsoft Technet’s Regulatory Compliance blog. The conceptual, high level thoughts don’t detail a “how-to” guide for compliance, but they do get the brain cells moving somewhat.

Update: new comment posted

The GAO recently released a report on the current state of NIAP. As I mentioned to a few customers, I don’t think there are any new or revolutionary ideas here. Most of it seems to parallel the concepts poised to be (or not to be) released in the IDA NIAP Report. Regardless, it’s a very interesting read.

Stay tuned for a flurry of blog posts on this GAO report. I have a slew of thoughts and comments on this… I just don’t have the time to write them up right now.

The House Government Reform Committee released its latest FISMA grades, for Federal agencies, and the results were not good. Here is a link to the report.

After reading my previous post, IT Security Improving in Government, you might be thinking that this seems contradictory. Remember that FISMA looks at more than just C&A, including developing/maintaining inventories of systems and configuration management plans, training employees, and other areas of security.

Ironically this article was released while the DHS Software Assurance Forum was taking place. I was at that forum, and while this didn’t come up, rest assured that many folks are tasked with improving the situation. The forum itself was interesting, though some of the talks seemed to be blatant advertisements for LSIs and what not. There are many efforts taking place (some of which are coordinated) to improve software quality and testing. Hopefully next year those grades will improve.

Update: New comment posted

OMB reports that security assessments under FISMA are on the rise:

The amount of certified and accredited systems has increased from 77 percent to 85 percent. In fiscal 2005, for the first time, agencies assigned a risk impact level to their systems. Agencies reported 88 percent of their high-risk systems had been certified and accredited.

Personally, I’d like to see the stats for C&A of high-risk systems at > 90% … but we’re getting there.

This article (courtesy of D-kriptik) gives some specific C&A details for various Departments:

The Defense Department, which houses 3,583 IT systems, went from 58 percent of systems certified and accredited to 82 percent, though the Pentagon inspector general gave the department a “poor” certification and accreditation rating in the OMB report.

I’m not sure of why the rating was poor because I haven’t read the OMB report yet. Nevertheless, I do know that DoD is doing a great job regarding C&A, and these stats support that.

The Veterans Affairs Department, which reported 14 percent of its systems as certified and accredited in fiscal 2004, reported that all 585 of its systems were certified and accredited the next year.

This is a huge improvement. The VA has been serious about C&A for years, and the sheer growth and “absoluteness” of the stats show their commitment to C&A.

On another note, here is an article positioning a case on the usefulness and value of FISMA.

High grades could mean a lot of compliance but not necessarily a lot of security

Compliance is not necessarily security. That was essentially the core point in my article in Information Security Magazine (see previous post).

There are some interesting sessions on security certifications and assurance at this year’s RSA Conference. First, there is a tutorial on Monday titled Implementation and Selection of FIPS 140-2 Modules: … and Benefits gained! This talk is at 9am on Monday the 13th and is led by Allen Roginsky, Jean Campbell, and Randy Easter.

Steve Lipner from Microsoft is on a panel on the 14th to talk about Government Information Security and the Need for Software Assurance … this should be quite interesting.

The 16th has some interesting sessions, including “Security vs. C&A” Celebrity Death Match 2006 and Federal Information Processing Standard 140-3 - A Standard for the Future … unfortunately both of these talks are at the same time! Two other potentially interesting talks are Managing Business Risk via Information Classification and How I Learned to Stop Worrying and Love ISO17799.

Also consider these talks on Friday: A Primer to Global Compliance Landscape should provide a nice introduction to non-government compliance regulations. Information Access Implementation Strategies for FIPS 201 looks like an interesting talk.

We have been asked about IPv6 transition/implementation (especially in the US Federal government). Friday’s Federal Agency IPv6 Transition Challenges and Potential Solutions talk should hopefully provide a nice overview of the issues.