Saving Money with IT Security Processes. Example 11/26: Avoid a Technology SPOF with License Management

Article number 11 in a series dedicated to giving examples of the way IT security processes can help your company save money.

What's License Management got to do with SPOFs?

It's got to do with the Technology SPOF.  "Technology SPOF" is the name I gave to all incidents that trigger a failure on all systems of a similar technology. For instance, if two redundant servers share a single storage bay that's full, both servers will suffer the same disk full failure.

Licences are a major source of technology SPOFs. Many products, once their paying period is expired, just stop functioning at all. For instance, antivirus software suites. Many products, once reached their usage limit, also just stop functioning at all. For instance, a dedicated appliance that can host 100 concurrent users.
That's the time when you'd wish you had a sound License Management process.

The License Management process does the following:

• It inventories all current licenses and their limitations.
• It monitors their use so that they don't reach limitations.
• It purchases new licenses in time and quantity.
• It installs new licenses and updates the inventory.

The Licence Management could be seen as a part of a larger Procurement process, however I see fit to put it in Security and not Procurement, because it requires active monitoring, capacity planning and some administation, which are more IT related.

Saving Money with IT Security Processes. Example 4/26: Identifying SPOFs with Network Architecture

Article number 4 in a series dedicated to giving examples of the way IT security processes can help your company save money.

SPOF is a very hackneyed expression, nowadays. However, a certainty remains: SPOFs must be addressed, or your company will loose a lot of money in downtimes. To address them, you must first identify them. One of the objectives of the Network Architecture process is to prevent SPOFed architectures to go into production and to identify SPOFs in the existing production architectures.

This, contrary to the opinion of many, is not a lost race. There is a finite number of 4 kinds of SPOFs, that you must all look for:

1. The hardware SPOF: your hardware (whether servers, network equipments, etc.) is not redundant.
2. The network SPOF: your hardware is redundant, but the network links that connect equipments are not crossed. They should normally deserve all redundant hardware just as well.
3. The configuration SPOF: your hardware is redundant, the network deserves it well but the clients are not aware that they should be connecting to the failsafe servers if the main ones are not available. In my experience, this one type of SPOF accounts for a huge part of forgotten SPOFs and related losses in unplanned downtimes.
4. The technology SPOF: one of your technologies fails (whether hardware, software or network). As it is the same in the main architecture and in the redundant architecture, both suffer from the same downtime.

Please read my previous article for sample network diagrams of these types of SPOFs. With a sound Network Architecture process, you can reduce downtimes by identifying SPOFs before crashes occur.

Back on the technology SPOF: practical case

A reader commented in private that the article about the technology SPOF was too abstract and lacked a few simple illustrations. The opposite would have been surprising ^^ The subject seems universal, which is no reason not to give a good example.

So, there I have it, example with an "all-in-one" security appliance, as is too often so often used in SMBs. It's mainly sold as a corporate firewall and serves many other uses.

The first SPOF is the hardware one. When the hardware fails, you've got a problem:

You can resolve that SPOF by adding another piece of hardware:



The second kind of SPOF is the network one. You have the backup hardware, but it's not available:

In this case, it's completely useless... You can solve this problem by making sure that the access to the redundant appliance is also redundant:


The third kind is the configuration SPOF. The backup is ready, working and available, but it's not used because clients are not configured to use it. For instance:

For this, you just have to configure the backup to be used in case of problem on the master or, if it's not possible, to setup an emergency procedure that switches from a configuration with the master to a configuration with the backup. That should look like:


Finally, and that the point in my previous post, you've got the technology SPOF, which means that both the master and the backup suffer from the same problem. This could be anything from "disk full" to "corrupted configuration file" ranging through "expired license". In this case, it's no help that you have a backup:

You just have to be sure about the list of the services you provide with that specific technology, and which of those are critical enough to require a reduced/degraded mode:

The technology SPOF

When I'm thinking availability, a lot my time and thoughts go to the careful search for SPOFs.

1. I do look for hardware SPOFs, like a unique machine doing an important job and requiring a backup in case of breakdown. [first step of a BCP]
   
2. I also do look for network SPOFs, like making sure the backup has the same network accesses as the master machine, so that it doesn't remain alone, useless. The same is true for firewall accesses and all kinds of filtering that network flows do undergo. [careful execution of the BCP]
3. I furthermore do look for configuration SPOFs. These consist of the rather funny case when the backup machine is up, reachable on the network, but the clients are not aware it's there and so don't undertake anything with it. This is usually the case when IP addresses are not switched automatically between the master and the backup or when a configuration screen allows only to type in one server, not two or many. Hopefully, this should not happen with MS Domain Controllers, the way they work (or we would hear this kind of SPOF more often). Anyway, it's still recurrent in many "small vendor" appliances and in the application world. [very careful execution of the BCP]
4. Nonetheless, a terrific SPOF remains: the technology SPOF. You have the backup machine, it's reachable, and others are aware that they should communicate with it. But the backup suffers from the same technological incident as the master machine did.
   Say, for example, that the master breaks down because it fails to handle a large quantity of "client data" (or anything) that has to be treated. The backup will also break down under the same charge.
   Let's take another example, the server is an application connecting to a database. The database received a minor software update that changes something that makes the master server go crazy. The backup takes the job and goes crazy too.
   Third and last example, you have a nice application server with scheduled tasks that make needed job. One fails and the server goes down, unable to continue its work. At that moment, the backup goes up and launches the same scheduled task, failing also... [and that's outside the perimeter of most BCPs]

That's the time when you'd want to have another way to provide your service. That's the moment when you are forced to remember that the machine is not here just to be here and working, it's here to help provide a service. And that service may be provided otherwise. That's the time when you enjoy having a well-prepared DR plan, with forethought reduced/degraded modes...