For those of us in technical or security roles, today has been quite eventful.

I won’t join the hundreds of other security bloggers writing about the details of the Shellshock vulnerability. There are many awesome information sources out there that will explain it in great detail.  Here are some particularly handy ones:

• New Zealand Internet Task Force
• The Register
• NIST
• Troy Hunt

I even spoke to ITnews for business Australia about it. You can read the article here.

For me, today was interesting as it reinforced how the vulnerability disclosure world had changed in the last 12 months.

When Heartbleed emerged in April 2014, complete with logo and human readable website – suddenly the world was able to understand and talk about a security vulnerability. For the first time, non-security people were aware that there was a problem, that problem was serious and they knew it’s name.

Today, when the vulnerability now known as Shellshock came into the public consciousness there were expectations. Clients and contacts wanted to know what it was called and where to find a simple understandable set of remediation options. The example set by Heartbleed had set the bar high and the security community scrambled to keep up.

As security professionals we talk about the value of patching and monitoring for security vulnerabilities a lot. Our clients know that part of growing a resilient and secure organisation is accepting that your technical stack is a complex entity that contains issues, not all of which have yet been found. We teach the importance of knowing what libraries, applications and components are in use, what versions are present and where to find new updates….

We teach this regularly but we do a really poor job of it.

You see there is a practical issue here. Knowing that you should do these things is not the same as being equipped with the skills, tools and support to do so.  Security vulnerability becomes something you know about but feel ill equipped to fix. Not ideal for anyone involved.

So what can we do to improve this?

Within the security community we have to watch the way we communicate when security vulnerabilities are disclosed. In addition to the technical information sources, we need to prioritize plain English trustworthy and accessible disclosures for non-security people. This information needs to link to trusted technical sources, contain information on what is known/assumed and provide guidance on remediation. If remediation or patches aren’t yet available we have to help suggest interim solutions.

Most importantly however these disclosures need to be regularly updated and free from advertising and product placement. This is not the place to sell border devices or audit tools.

Within the greater technical community, I encourage you to come find a friendly security person (we exist, I promise) and explain your needs, your concerns and your situation. Help us to understand what you need to get you patching regularly and monitoring security information sources.

Show us how to help you.