How businesses are building firewalls is changing. We’re seeing a continued trend toward smaller firewall boundaries and micro-segmentation to support zero-trust strategies, although it can be very piecemeal.
As businesses think less about centralized firewalls, and more about cloud, they are “dipping their toes” into cloudy waters that can easily cause configuration problems.
The State of the Firewall Report 2018 from FireMon uncovered very mixed results when it came to managing firewalls in the cloud, especially in EMEA, where respondents said they were less likely to know who is responsible for cloud operations, and 33% of respondents saying they weren’t sure who was responsible all.
Some of the most high-profile data breaches this century were triggered by misconfiguration in the cloud. High profile breaches, such as the Time Warner Cable breach, the FedEx breach, and the Target breach all amount to this growing problem.
Firewall fallout: what are the issues?
When we have public and hybrid clouds, the principles of managing a firewall don’t change, but the scale changes the way we approach management. Cloud implementations don’t always give you as much control over the security architecture – the cloud providers define what’s available, and you inherit what they provide.
You can say it is a collaborative relationship. For example, Amazon Web Services (AWS) allows you to deploy a firewall, but they’ll give you access to secure it yourself. So, options can be both limited and varied at the same time. This means a company’s network operations personnel need to be well-versed in all of this - and when picking a cloud provider, they need to advise the business on the implications of certain choices.
There are many other factors that need to be considered when moving into the cloud. For example, if you’re moving an existing on-premise system into the cloud, and if the security controls in your new cloud implementation do not mimic those of the on-premise implementation, you’re taking a step backwards when it comes to security.
This inconsistency in security implementation is often an operational issue, not a technical one: someone takes control of the cloud migration who does not have knowledge of the pre-existing security controls, and as a result deploys a system in the cloud with configuration problems that can lead to unintended data exposure. This is why it is important to have full collaboration between all stakeholders.
This same level of collaboration should be in place for new cloud deployments (those for which there is not a pre-existing on-premise system). Creating security controls for the system should involve business stakeholders, developers and security personnel. This ensures the proper balance of business and security in cloud controls.
Unfortunately, the person taking responsibility for security in these situations is, as we’ve observed, may not be someone who is part of the traditional security team, which can lead to unintentional configuration errors that allow inappropriate access to the system.
Cloud and Proud
Traditional security models implement and enforce controls for the current state of affairs. In our fast-paced, technology-driven world, nothing stays current for long.
To stop misconfiguration errors, especially those in cloud environments, companies need to shift their mindset to managing security intent (or intent-based network security) as a way to manage cloud scale and the corporate firewall. It won’t be possible, with cloud’s dynamic and scaled nature, to manage the point-to-point address implementation manually (which is what has happened historically) as these networks grow.
So what is security intent? Well, it departs from the old way of manually writing rules to enforce security policy on individual assets. Instead, we create an abstracted layer of security intent that defines our desired state of security affairs, and then builds and automatically implements security controls to fit the intention.
You can then adapt to anything that comes, such as a new cloud proof of concept. Whatever the enforcement points (firewalls, routers, cloud, containers, VMs), all the correct rules are put in place by converting your desired state of affairs into your network.
The key to security intent is that it separates intent from implementation. In this model, intent becomes the backbone of all policies and firewall controls, and implementation serves as the device-specific enforcement of the declared security goal. In other words, we want our security implementation to be an accurate reflection of our security intent.
To achieve security intent anywhere, you need four things:
- Translation: Taking the overall security goal and mapping it to specific rules, irrespective of enforcement point (e.g. firewall, router, switch, VM, cloud, etc.).
- Automation: Checking the design against all possible contingencies, scoring the risk and, if all cleared, pushing rules to the enforcement point.
- Network Awareness: Real-time monitoring that pulls data from across the network and gives instant detail about how intentions are playing out.
- Network adaptation: A change to the network becomes a new input, is tested against the desired state and, if new rules are required, they are deployed instantly…no human required
Companies are working in a very piecemeal way when it comes to cloud right now. There are a variety of approaches people are implementing; even within the same organization, some groups or applications may use traditional firewall infrastructure, and others may use purely cloud/host-based security, and others a combination.
While this piecemeal transition is going on, moving towards a security intent model becomes even more important.