Welcome to the Acumen Security Blog

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!

Hello World!

Hello World working copy

Hello world!  Here at Acumen Security we are excited to begin our journey in the world of certification testing as an independent lab.  We truly believe in the value that certifications can bring to a product developer. This value is not only derived by the very real product improvements that are realized by certifying a product but also the procurement enablement and competitive advantages that product certifications can bring. Over the following months (and years), we’ll use this blog to talk about our certification philosophy and to bring you information and news that you’ll find useful as you progress through your certification journey. But before we do that, let us take a moment to introduce ourselves.
Acumen Security started as an off the cuff conversation between two seasoned certification engineers. Ashit Vora and I were chatting about various topics when it was noted that there weren’t manypeople in certification labs that truly understood what certifications mean for a product developers. Since we both had managed a certification lab and been employed by a vendor who played big in certification, we had a perspective that was uncommon in the industry.  That initial conversation did not immediately lead to the formation of Acumen, however, it did sow the seeds of thought.  We both knew that if they took the lessons learned from our experiences at a product vendor and applied them to a certification lab, we could change the way certifications were done.
Finally, we took the dive and decided that it was time to make our ideas come to life and start a lab. The lab would be built on the principle that vendors were busy making and selling world class products for their customers and certifications should not get in the way of that. And so Acumen Security was started.  Thank you for taking the time to read our blog. We have some really big things in store for you and the entire industry.  If you should have any questions or comments, please reach out to us. We’d love to help you achieve your goals!