Sorry to inundate you with posts today. I have been using the WordPress app on my iPad to write these posts and apparently it can’t update the blog on the website. I had to copy and paste the content so I could post it.
I’ll be more timely in the future.
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.
I was flipping through my social media accounts this morning and the theme of the day appears to be “innovation” and “transformation”. They were used in articles in contrast like maybe they were similar but different. I looked up the definitions of both terms in the dictionary.
Innovation (noun) – something newly introduced; such as a method or device.
Transformation (noun) – a marked change, as in appearance or character, usually for the better:
Granted, I picked the definitions but I used those that didn’t describe either term recursively. Here’s what I get: an Innovation is a new thing and a Transformation is a changed thing. So I guess they’re not really similar but they certainly are different. But they still might be related.
So what’s this got to do with Enterprise Architecture? I think it’s this…
Your future state is your innovation. You aim to create something new. Most enterprise architects are satisfied with this and set out to build this new thing.
Unfortunately, if you have an existing business, your starting point is not your blank canvass or empty project file. You need to start with where you are now. That’s your current state. The plan that gets you from your starting point to your end point or from the current state to the future state is that which generates that marked change. It’s a transformation.
You must completely understand your current state in order to build that transformational plan. That’s business-driven enterprise architecture. That’s complete understanding.
Back in December 2013, I started a series of posts that describe processes and how to manage them. You can read them here, here, here, here, and here. Go ahead, we’ll wait.
OK, you’re back!
I have had some time to ruminate and use this processing model. It seems to breed some confusion in my business partners when I discuss it with them. The problem is my use of “Factory” to describe a core process. It is so much simpler to just call it a “Core” process. The definition, the right thing to be doing, still holds but the association is much easier to grasp.
However, we still need the Factory. The new definition of the Factory is the process flow that emerges as a transaction moves through the core processes. This is what we in systems analysis call “the happy path”. Transactions that stay in the Factory make us happy because they process in an efficient and effective manner where variability and risk are controlled.
Experience is a great teacher. I hope I never grow too old or set in my ways to change.