The FBI issued a bulletin on February 18, 2016 warning government entities of a ransom ware threat exploiting a security weakness in the JBOSS application server.  It appears that versions of JBOSS prior to version 7.0 are affected.  Red Hat,  the primary support company for JBOSS,  verified the fix for the weakness on February 15.

This post is not about bashing the open source movement or Red Hat.  This is about understanding the software you are running in your environment.

I work at a government agency that received the notice from the FBI.  It caused me to consider the following:

Do we have this vulnerable software running on our network now?

Is it exposed to the outside world?

How did it get there?

How do we remediate if the answer to the first question was yes?

What’s the next potential threat?

The best situation is that you control your technology stack to the point that you already know what is running in your systems environment.  If not, it’s pretty easy to find any software package, especially if it’s a Java .jar file as open source software is predominantly.  But this does take time.  You just set the network scanners to look for it and then read the report.  If it shows up on the report, you have a problem. How big a problem?

If it’s used in a system that is exposed to the Internet, you have a big problem because the exploit door is wide open.  If the system is buried inside your network and only used by internal users, you are much better off, if you can trust your users to adhere to your organization’s security standards and protocols.  You have those in place.  Right?

How did it get there?  There are two ways: First, your own developers could have introduced it in a software system they wrote.  Open source software is great because there is no acquisition (i.e. Licensing) costs and you can find documentation with the package, on the Web, or in a book.  It’s also a great way to jump start a project because a big bunch of code is already developed and stable(?). Many developers like to use open source for these reasons.  You just need to make sure that they are paying attention to maintenance changes required by their choices and that you provide time to let them make those changes when required. Like now.  Or better yet, before now.

The second way to obtain this software is from a vendor.  Vendors providing turnkey solutions really fall under the scenario of your internal developers unless you have retained them to maintain your software.  The other way is that it was introduced by a vendor with a COTS system.  This is a different situation, especially if you are paying for maintenance.  You expect that your maintenance contract will provide coverage for problems like this.  But here are the issues you could encounter…

First, there must be a remedy available.  This is either an executable or .jar (i.e. A patch) or it’s an entirely new version to which you can upgrade.  If a remedy is available you have the basis for a plan.  If not, you have to deal with the murky world of open source software.  I’ll discuss this below.  If a remedy is available, your COTS vendor must have the resources to upgrade his code to use the upgraded component and then he must be able to deploy it to you and all of his other customers who are in the same predicament.  This takes time and people.  Time you may not have.   People he might not have.  And people you might not have to do the regression testing this change might require.

In the case referenced at the beginning, Red Hat has the resources to provide a remedy and it is available.  But what if the package that is vulnerable is not managed by a deep-pocketed open source supporter like Red Hat?  What if it’s like the OpenSSL project that’s basically four guys in a garage?  OpenSSL is one of the most important technologies on the Web, providing encryption services for over half of all websites.  Well, you might have to wait a little longer for that remedy and meanwhile you’re the one sweating it out.  What if it’s an abandoned project?  You are now on your own.  That is the darkest side of open source.

Finally, the question is whether your vendor (or your developers if this is a home-grown system) have the capacity to get your system upgraded before you fall prey to the ransom demand.  We talked about the vendor and his challenges already.  If you have your own developers supporting this system, it’s probable they’re not just sitting around waiting for things like this to happen.  This means they need to disengage from whatever it is that they’re doing now and concentrate onfixing this  problem.  And timelines slip.  Just another day at the office.

What’s the next potential threat?  Who knows?  There are security firms all over the world who make their livings testing software and working with development teams and organizations to fix security problems.  There are also hackers doing the same testing and working with other like-minded people to exploit those vulnerabilities before they are found by the good guys and fixed.  The critical period of disintermediation is not between these two events but from the time a vulnerability is found until you have the security fix in place in your systems.

So is this to say that open source software is bad?  Not at all.  Its usage just requires that the enterprise architect and the systems manager understand the risks, the resources, and the timelines required to fix security problems before they result in a breach.  It requires steadfast management of your technology stack.   It really requires complete understanding of the software comprising the systems you run.

Leave a reply