When it Comes to Compliance Requirements – Topology Matters!

When I look at the evolution of network security and how IT and security practitioners have protected the network for the last 30 years, I can’t help but notice how traditional network security enforcement points (insert your favorite firewall here) are still used to secure networks and workloads. They have evolved to offer a diverse set of features (i.e., IPS, decryption, application detection) to deeply analyze traffic coming in and out of the network to protect workloads. However, while firewalls are very capable appliances, it has been proven that they are not enough to keep malicious actors at bay, especially if those actors manage to breach the firewall defenses and move laterally in the network. But why is this?

We are in the digital era, where the concept of the perimeter is no longer contained to a location or a network segment. To offset this new reality and provide a more tailored-based policy control for protecting workloads, vendors have moved security closer to the workload.

There are two approaches to do this -, using agent or agentless techniques to build a micro-perimeter around the workloads.

Which approach is the correct one to take? Well, this depends on multiple factors, including organizations, type of application, or team structure. So, let’s start untangling this.

The challenge(s)

The most direct approach to protect applications is to install software agents on every workload and call it a day. Why? Because then every workload has its own micro-perimeter, allowing access to only what is necessary.

However, it is not always possible to install a software agent. Perhaps it is a mainframe application or a legacy operating system that requires fine-grained policies due to a compliance mandate. Or application workloads that are in the cloud and the agent installation is simply not possible due to organizational constraints.

And this is not the only challenge or consideration for choosing your approach. The teams or groups that comprise any company often have different security requirements from each other, leading to the triad challenge: people, processes, and technology.

Let’s start with people (policy owner) and process (policy execution). Usually, each organization has its own set of unique requirements to protect its application workloads, and a defined process to implement those requirements in the policy. To support this, a tool (technology) is required, which must adapt to each organization’s needs and should be capable of defining a common policy across agent and agentless workloads.

To start unwrapping this, you need to ask yourself:

• What are we protecting?
• Who is the owner of the policies?
• How is policy execution done?

As an example:

Say you want to protect a finance application (what) using an agent-based approach (how), and the owner of the policies is the App Team/Workload Team (who). In this scenario, as long as the application doesn’t break and the team can continue to focus on coding, this is generally an acceptable approach. However, when implementing the common policy, the translation from human language to machine language tends to generate extra rules that are not necessarily required. This is a common byproduct of the translation process.

Now, let’s assume that in your organization the protection of a legacy application (what) is tasked to the Network/NetSec team (who) using an agentless enforcement approach with network firewalls (how) because in this case, it is not possible to install software agents due to the unsupported legacy operating system. As in the first example, extra rules are generated. However, in this case, these unnecessary extra rules create negative consequences because of firewall rules auditing requirements for compliance mandates, even though they are part of the common policy.

Topology as the source of truth – pushing only what is required

Cisco Secure Workload has been addressing the people, process, and technology challenges since its inception. The solution embraces both approaches – installing software agents on workloads regardless of form factor (bare-metal, VM, or container) or by using agentless enforcement points such as firewalls. Secure Workload adapts to each organization’s needs by defining the policy, such a zero trust microsegmentation policy, to effectively apply micro-perimeters to application workloads in support of the zero trust approach. All within a single pane of glass.

However, as explained in the example above, we still needed to align our policy to the compliance needs of the Network/NetSec team, only using the policy rules that are required.

To tackle the additional rules challenge, we asked ourselves, “What is the most efficient way to push policies into a network firewall using Secure Workload?”

The answer boiled down to a common concept for Network/NetSec teams – the network topology.

So how does it work?

With Secure Workload, the term topology is intrinsic to the solution. It leverages the topology concept using a construct named “Scopes”, which are totally infrastructure agnostic, as shown in Figure 1.

It allows you to create a topology tree in Secure Workload based on context, where you can group your applications and define your policy by using human intent. For example, “Production cannot talk to Non-Production” and apply the policy following the topology hierarchy.

The Scope Tree is the topology of your application workloads within the organization, but the key is that it can be shaped for different departments or organizational needs and adapted to each team’s security requirements.

The concept of mapping a workload Scope to a network firewall is called “Topology Awareness.”

Topology Awareness enables the Network/NetSec teams to map a particular Scope to a specific firewall in the network topology, so only the relevant set of policies for a given application is pushed to the firewall.

So, what does this execution look like? With the Scope mapping achieved, Secure Workload pushes the relevant policy to the Cisco Secure Firewall by way of its management platform, Secure Firewall Management Center (FMC). To maintain compliance, only the required policy rules are sent to FMC, avoiding the extra unnecessary rules because of Topology Awareness. An example of this is shown in Figure 2:

Key takeaways

Operationalizing a zero trust microsegmentation strategy is not trivial, but Secure Workload has a proven track record of making this a practical reality by adapting to the needs of each persona such as Network/NetSec admins, Workload/Apps owners, Cloud Architects, and Cloud-Native engineers – all from one solution.

With topology awareness, you can:

• Meet compliance and audit requirements for firewall rules
• Protect and leverage your current investment in network firewalls
• Operationalize your zero trust microsegmentation strategy using both agent and agentless approaches

For more information on agentless enforcement please read: Secure Workload and Secure Firewall Unified Segmentation Blog

Want to learn more?  Find out more at by checking out our Secure Workload resources.

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Share: