One of the biggest internal threats to an organization’s IT infrastructure is the presence of any Single Points of Failure (SPOF). An SPOF is any design, implementation, or configuration flaw in an information system where the malfunction or loss of a single component can propagate a cascading failure, ultimately causing the loss of a critical mission or business capability. Even the smallest organizations have single points of failure somewhere in their infrastructure. Many SPOF do not become completely visible to the organization until they fail, at which point the organization notices pretty quick. SPOF exist at many different points in a network environment, they are not confined to just system hardware. SPOF can be broken down into:

  • Physical SPOF: systems and hardware components whose failure cascades to other parts of the organization and hampers workflows and output.
  • Software SPOF: applications and databases whose failure halts operations on any data they host. Worst case scenarios involve complete data loss due to software failure.
  • Network SPOF: network devices whose failure halts any communication with the rest of the local network, the Internet, or both.
  • Human SPOF: often overlooked, these appear when a single individual is tasked with a critical operation or decision. Their absence brings a workflow to a complete halt.

Modern IT environments should place a large focus on eliminating SPOF by implementing redundancy and failover mechanisms to protect the availability of the network. This can be a challenging process, as it involves acquiring additional technology to provide redundancy, which can be tough to initially justify to senior management. This is why it is essential in this stage to clearly identify SPOF and demonstrate/document the consequences to the organization if failure occurs.

At this point in the framework, organizations should already have a useful collection of documentation outlining the state of their network. These include hardware/software asset inventories, data flow diagrams, network maps, and dependency maps. In tandem, all these documents will help weed out SPOF. To identify them, it is best to start small by starting at the gateway point of the network, tracing down the topology to the smallest asset participating in the network. If you encounter a component whose removal will prevent normal operations for a group of assets beneath it, you have found an SPOF. It is best to drill even further and identify SPOF in the individual systems themselves. Every system is comprised of various components; storage, RAM, power supplies, CPUs, etc. All of these components can fail at any given time, so organizations should try to identify the most critical components and look into ways to increase redundancy for them.

While performing this process, detailed documentation must be kept for producing a detailed report on the SPOF. A copy of the network map and data flow diagram could be made and marked up to clearly identify the SPOF. This should be accompanied by a report explaining each SPOF in detail. This report will help with identifying threat scenarios and performing risk assessments, as well as making a business case for procuring redundancy technologies.  

Some common SPOF in enterprise environments include:

  • A single server hosting a critical web app or service. Availability of the resource depends on the availability of the one server. This can be rectified by installing more servers in a server cluster and then installing a load balancer to evenly distribute traffic between the different servers as to not overload any of them.
  • A single border router providing downstream connection from the Internet to all devices beneath it. If the router goes down, all network activity ceases. This is rectified by using a Virtual Routing Redundancy Protocol (VRRP) such as Cisco’s HSRP. This way, there are two border routers running that provide a virtual IP address to the rest of the network. When one router goes down, the other takes over and provides connectivity while the original is fixed.
  • Switches and other backbone network devices may only have a single cable connecting them to the systems they depend on. A cable break will take the device out of commission and hamper connectivity for the nodes beneath it. This can be rectified by installing multiple cables in an EtherChannel.
  • Servers might only have a single storage drive installed, with all application and user data depending on its availability. This can be rectified by installing multiple hard drives and creating a RAID array, with options for parity, mirroring, or both.