Welcome to the Acumen Security Blog

Archives for April 2014

Getting ready for an ISO 19790 based FIPS 140-Next

Recently, there has been a lot of talk about the next version of FIPS 140 being based on ISO 19790:2012.  The CMVP has even added a section to its website to address its consideration. At first glance, the differences between FIPS 140-2 and ISO 19790:2012 may not seem too bad. However, in doing a deep dive into the requirements, one finds that there are numerous changes that will directly affect every cryptographic module that has ever been validated. If vendors are caught off guard, it will be very painful to complete their next FIPS 140 validation after the transition.

For many vendors, it makes sense to consider getting a head start into integrating the new functionality required by ISP 19790:2012. However, the transition plan is not finalized (the CMVP could potentially even go a completely different direction) and it would not be prudent to completely overhaul code and design to meet the ISO requirements. There are, however, several requirements that could be considered not only because they will be required, but, they are also just good security practices. Here are a few suggestions a product vendor may wish to consider to get a head start on an ISO 19790:2012 based FIPS 140-Next.

  • Password Complexity Requirements: FIPS 140-2 allows any password complexity requirement to be enforced procedurally. This will NOT be the case moving forward. Now is the time to add minimum complexity rules to your software. At minimum, even if it does not become part of FIPS 140-Next, you will prevent the dreaded one-character password. As an added bonus, this may also help with other certifications you are interested in, such as, NIAP NDPP Common Criteria evaluation.
  • Default Authentication Data: If you provide default authentication data to initially access your product, ISO 19790:2012 requires that these credentials be changed after first usage. Default credentials are one of the more common ways a system in operation is compromised. Requiring the user to change these credentials will not only be necessary to validate against FIPS 140-Next but is a good security practice.
  • Automated Security Diagnostic Testing: ISO 19790:2012 requires that any software/firmware in a product be run through automated testing (such as, static analysis).  If you are not already performing that type of testing, now is a good time to start. Not only will you be meeting the new validation requirements, but, you may just identify and prevent a vulnerability from getting out into the field.

The list above only touches on a couple of the differences between FIPS 140-2 and ISO 19790:2012. There are a number of other differences that will directly affect product vendors’ development plans. Acumen Security has performed a detailed analysis between the two standard and put together an easily consumable white paper providing a high-level description of the differences between FIPS 140-2 and ISO 19790:2012 and some recommendations to help make the transition easier. Check out “FIPS 140-Next is coming: What does it mean and what are you going to do?,” give us a call, or drop us a note. We’d love to help you understand what this transition would mean to you and how you can minimize its impact.

Also, follow us on Twitter and like us on Facebook, we’ll keep you up-to-date on the ever changing world of government certifications.

Heartbleed and certifications

heartbleed

Before we go any further let me clarify that this is not just another heartbleed post. If you are interested in details there is plenty of information available here, here, and here.

More importantly if you want to know whether your webserver/website is vulnerable you can test it here or on your webserver you can do the following:

echo B | openssl s_client –connect $HOST:$PORT

If you see “heartbeating” at the end, then $HOST is vulnerable.

With that out of the way, let me get to the point of this post. This morning as I was reading up on the coverage this vulnerability has gotten (which is a good thing) it struck me how this situation reaffirms the case that standards based certifications are useful and some of the bad rap it gets is misplaced. I know, you are wondering what I had to drink this morning (and whatever it was, you want some), but hear me out.

The heartbleed vulnerability was introduced in openSSL v1.0.1 which introduced the heartbeat functionality for TLS connections. This version was released on March 14, 2012. So, for a little over two years this code was out there being looked at by many smart security researchers and being used in hundreds of thousands of products. It took two years for this bug to be found even with so many eyes looking at the code, tests being run, and sanity checks being performed.

Critics of standards based certifications complain that the certifications are useless because they do not catch real world vulnerabilities. To them, I point to above. If it takes two years and thousands of man hours before such a bug is caught, is it realistic to expect that certifications that operate on limited budgets and constrained timelines catch bugs such as these? It is just not practical.

Standards based certifications are meant to be validation of the use of best practices that must be followed by all developers and product vendors. It is meant to ensure that you, the developer, is doing the right thing and not something stupid. It is meant to raise the bar of the security posture of a product while balancing real world priorities such as costs, time, and effort. So while certifications will not catch bugs such as hearbleed, they will ensure that you do not leave plaintext keys unprotected, you will employ good password hygiene, and your crypto algorithms are working correctly.

That said, not for a minute am I saying certifications is perfect. Gosh, having been in the certifications world for over a decade there are so many things that can be improved upon (saved for a later post!) but I am saying that it is better to have certifications and ensure base requirements are being met by all products than not to have anything and be the wild wild west!
So, what do you think? Does the Heartbleed bug provide an opportunity to examine and accentuate the value that certifications bring? Or does this and other similar vulnerabilities highlight the weaknesses of product certification? Or maybe something in between? Let us know what you think!