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.

Safeguard processes protect the Factory Process to ensure it is not being abused.  These activities ensure that you are doing the “right” things right. The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems. This can lead to all manner of problems. Let’s use the following example to illustrate various safeguards to a factory process.

This is tax season in the United States. Taxpayers are voluntarily computing their final tax bulls for the preceding year and are squaring their accounts with the IRS. Some people owe a little more and some people paid too much during the year and are due a refund. The IRS has implemented an electronic filing system that relies on independent software developers and web hosters to help taxpayers through the process.  This results in a system (the Factory Process) that allows the IRS to process a very large number of tax returns very quickly with little human intervention.

The IRS spot checks taxpayer accounts using the dreaded tax audit.  The IRS will select a taxpayer and ask him to visit them and bring his tax returns and records for for a designated number of past filings.  The IRS will comb through those records and determine whether the taxpayer’s filing present an honest account of reality.  This is a Safeguard process for the IRS.  The threat and execution of these audits protect the Factory Process by encouraging the taxpayers to provide honest accounting of their tax years.

Unfortunately, tax audits only protect the system from real, honest taxpayers who can be located once the IRS decides to audit them.  There is an increasing business of defrauding the IRS by filing returns for non-existent taxpayers or for taxpayers whose identities have been stolen and having the IRS deposit a refund amount in a bank account from which the money can be immediately swept beyond their reach.  This scheme depends on forged documentation that is processed before its veracity is checked.  The IRS is now using more prospective methods of identity verification and cross checking employer records against employee claims.  These too are Safeguard processes because they help prevent the processing of fraudulent transactions.

So you see, Safeguard processes can be placed anywhere within the Factory Process.  Edits and cross checks are prospective or in-line Safeguards.  Audits are retrospective Safeguards.  Both types help the IRS collect and retain the maximum amount of revenue owed by taxpayers.  It is very important to find and utilize every means to protect the Factory Process from abuse.

Once the enterprise has identified a risk that can be mitigated, it becomes time to fix the problem. This should be a very disciplined activity because it was a lack of discipline the got you where you are in the first place.

I think mitigation must be approached on three fronts.

• You must know exactly what you’re doing now
• You must know exactly what you should be doing
• You must utilize “gap analysis” to get from what you’re doing now to what you should be doing

I have posted essays previously that describe all three of these activities. I won’t restate those thoughts here other than to reiterate my belief that the “gap analysis” approach offers the lowest risk strategy for attaining a successful remediation. Gap analysis keeps the remediation team focused on the essential repair and keeps them from wandering off to “fix” other things that may or may not be wrong.

Remember, there are two aspects of “gap analysis”. The aspect that is easy to grasp is that the gap should be filled by creating something new to satisfy a deficiency. The more subtle aspect is that something should be removed. For example, the work-around for a process requires that workers be given access to data for which they would otherwise have no need. The access is restricted because regulators require special handling of that data. The gap analysis should be focused on two ideas: redesigning the process to eliminate the need to grant access to the data or reinforcing the data security measures governing the process. The resulting candidate solutions would need to be subjected to a cost-benefit analysis to determine the correct course of action.