How a Little ‘n’ can Threaten Your Entire Business

According Gartner, through 2020, 99% of firewall breaches will be caused by firewall misconfigurations, not firewall flaws. And IBM Security Services’ 2014 Cyber Security Intelligence Index, reported that misconfigurations are the most commonly recorded form of human error.

A misconfiguration can be as simple as typing ‘neq’ instead of ‘eq’ – or vice versa.  The difference is tiny, but the two terms have opposite meanings – ‘not equal to’ and ‘equal to’.  So, in the context of network configuration, ‘eq’ will allow access to a single, specified port, whereas ‘neq’ will allow access to any other service.  Such services could include FTP, Active Directory, SSH and so on.

Other types of typos can include incorrect subnet masks, which may prevent access to particular devices on the network, or direct information to an incorrect destination.  These are particularly difficult to single out and identify.

So while a misplaced ‘n’ might not sound like the most serious information security threat facing your organization, in the context of configuring devices on your network, it can actually be a serious problem.

Bad news travels fast

Misconfigurations may also be a significant business issue even if it is never taken advantage of by criminals. In July, a router misconfiguration at United Airlines grounded more than 90 aircraft for over two hours. And of course, in our highly dynamic and connected world, news of the outage rapidly spread across social media and international news outlets.  United’s outage wasn’t just a problem on the day, but had repercussions in terms of revenue and reputation.

Avoiding the errors

So if it’s this easy to accidentally misconfigure a device, which cause huge network – and business – disruption, what can you do about it?  To answer the question, we need to examine the process by which a device change takes place within your organization’s network.

There are six stages to consider in a change control process, and at each stage, principles of visibility, testing and verification must be balanced with speed and agility. But by designing and implementing an intelligent – and automated – process, you can mitigate the risk of misconfigurations, and make it easier to spot mistakes when they occur.

The crucial principle that should underline every stage in your change control process is automation. Every step in the workflow from change request, through design and implementation to close, should be automated as much as possible to eliminate guesswork and human error.  As part of the process, security policy management solutions also self-document the entire change process to provide accountability, tracking and ensure compliance.

Here is what the individual stages in that change control process should look like:

1. A request for a change is made. A common complaint from businesses is that it takes too long to process a change request. To accelerate this process, you need to thoroughly understand your network infrastructure before beginning – in other words, you need a dynamic, up-to-date network infrastructure map.
2. Planning for the change takes place. This is where full network visibility is absolutely critical. The topology of the network must be fully understood, as well as the security policies associated with each device within the network.
3. Understand the risk. Before making any changes, it is important that you properly understand the risk involved. If a change will cause undue risk to the network environment and/or application, the change should be re-planned or even denied.
4. The change is implemented. Here, you must consider how best to insert the new security rule into the device’s current policy. Should you add a new rule or modify an existing one? The rule change and the process for deciding what to do should be automatically documented.
5. The change is validated. It is wise to check that the request is implemented correctly before notifying stakeholders. Important questions to ask are ’Was the change implemented exactly as requested?’ ‘Does the change incorporate an overly permissive and therefore risky rule?’ (One example here is using ‘any’ rather an https service).
6. Close. Here, you should check that the work done matches the original ticket, and ensure there is no mismatch between the change request and the ticket.

By committing to implementing each stage of this change control process as part of a unified automated workflow, you will have begun to mitigate your device misconfiguration risk. But there is more to be done. In next week’s blog, we’ll be examining how you can better align your business and IT security functions.