What causes the majority of firewall breaches? It’s tempting to assume that hacking techniques have become so sophisticated that they’re pushing IT security to its limits, or that vulnerabilities are endemic. However, the real reason is usually far simpler: research from Gartner suggests that, through 2020, 99% of firewall breaches will be caused by simple firewall misconfigurations, not flaws.
What’s more, IBM Security Services’ 2014 Cyber Security Intelligence Index reported that misconfigurations are most commonly due to human error. It’s easy to see how this could happen: consider the difference between ‘neq’ and ‘eq’ – a single letter dictates opposite meanings. When configuring network devices, ‘eq’ (‘equal to’) will allow access to a single, specified port – whereas ‘neq’ (‘not equal to’) will allow access to any other service. So a traffic path intended to be highly specific and restrictive becomes widely permissive – all thanks to a single misplaced letter ‘n’.
It’s no surprise, then, that the latest AlgoSec State of Automation survey found that 20% of organizations had a security breach, 48% had an application outage and 42% a network outage resulting from errors during a manual security-related process.
Misconfigurations can cause serious business problems even if they are never exploited by a hacker. In July 2015, a router misconfiguration at United Airlines grounded more than 90 aircraft at US airports for over two hours – causing widespread disruption to flights and negative publicity. So given the impact that a simple, unintentional misconfiguration could have on an organization’s network and business, how can companies ensure they avoid these errors?
Minimizing Misconfigurations
Misconfigurations are most likely to occur during security change processes – that is, when new rules are added, or existing ones changed or removed on a firewall. There are six stages to consider in a change process, and at each stage, visibility, testing and verification must be balanced against speed to mitigate the risk of errors and misconfigurations. Here are the six stages, and the key safety-first elements for each stage:
- A request for a change is made - A common complaint from businesses is that it takes too long to process a change request. Before making any changes you need to fully understand your network infrastructure, ideally with a dynamic, up-to-date infrastructure map.
- Planning for the change - This is where full network visibility is critical. The topology of the network and the security policies associated with each network device must be understood.
- Understand the risk - It is essential that you properly understand the risk involved. If a change will cause undue security, compliance or business risk to the network environment and/or application, the change should be re-planned or even denied.
- Making the change - Here, you must consider how best to insert the new security rule into the device’s current policy. Should a new rule be added to the device’s current policy, or an existing one modified? Any changes should be automatically documented.
- The change is validated. - It is wise to check that the request is implemented correctly before notifying stakeholders. To verify this, important questions to ask are ‘Was the change implemented exactly as requested?’ ‘Does the change include an overly permissive, risky rule?’ (One example here is using ‘any’ rather an https service).
- Closing the request - 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.
The crucial principle that should underline each of these stages is automation, to eliminate guesswork and error-prone manual input. Security policy management solutions deliver this automation, and document the entire change process to provide accountability, tracking and ensure compliance. Implementing each stage of a change control process as part of a unified, automated workflow goes a long way to eradicating the risk of accidental manual device misconfigurations, and the business disruptions and security holes they can cause.
In fact the process should be similar to ordering a burger in McDonald’s: you decide what you want to order, make a selection from the pre-arranged menu, are given a price, swipe your credit card, your card is approved and your food gets delivered. The process is the same every time, in every branch.
The same automation principles can be applied to network security. The application development team decides what connectivity they want to ‘order’. The Security Operations team processes this order via predefined change request form. As part of this process risk automatically assessed, and at the end of the process, the change is implemented and validated, and everyone involved gets confirmation. Ordering in McDonald’s, as we know, takes a couple of minutes – security changes can be just as fast.
Aligning Business and Security
To effectively mitigate against the risk of device misconfiguration – and all of the business disruption and vulnerability to attacks this can cause – your organization needs to work on better aligning business needs with IT security necessities.
In a typical company, the connectivity requirements for business applications change all the time. Even when using automation solutions, actually making these changes can take longer than non-IT staff think. This is because the people requesting a change may not understand the underlying complexities of reconfiguring all the necessary devices and ports that the change demands. IT and security teams work in a different language from application owners and developers, and sometimes things can get lost in translation.
Everyone needs to get on the same page before any changes can be done. This starts with visualizing application connectivity. Security policy management solutions do this automatically, to illustrate how application connectivity needs map onto the underlying IT infrastructure. This enables all stakeholders to clearly visualize current – and future – connectivity, and the impact of any changes.
The advantages of this approach are:
- IT security clearly understands why particular change requests are made, and gets a view of what connectivity is required by those changes
- Business owners can see how their applications are impacted by IT security, and vice versa, giving a deeper understanding of the risks linked to particular applications
- Problems are quickly identified and the necessary changes made to policies affecting an individual application
With everyone on the same page, change control processes can be done faster, more efficiently and accurately, with the policy management solution automating the translation of change requests into the right network and connectivity terms, making the change easy to do. This combination of automated change control processes, and clearer communication between the business and its IT and security teams, will help any organization minimise their inadvertent, manual misconfigurations, and improve their overall security and agility.