[ad_1]
When I look at the evolution of network security and how IT and security professionals have protected the network over the last 30 years, what strikes me is that traditional network security enforcement points (insert your favorite firewall here) are still used to secure networks and workloads. They have evolved to provide a variety of capabilities (e.g. IPS, decryption, application discovery) to thoroughly analyze incoming and outgoing network traffic to protect workloads. Although firewalls are very powerful devices, they have been shown to be insufficient to keep malicious actors at bay, especially when these actors manage to breach firewall defenses and move laterally within the network. But why is it like that?
We are in the digital age where the concept of the perimeter is no longer limited to one location or network segment. To address this new reality and provide tailored policy control to protect workloads, vendors have moved security closer to the workload.
There are two approaches to this: using agent-based or agentless techniques to build a microperimeter around workloads.
Which approach is the right one? Well, that depends on several factors including organizations, type of application, or team structure. So let’s start untangling this.
The challenges)
The most direct approach to protecting applications is to install software agents on each workload and call it a day. Why? Because then each workload has its own microperimeter that only allows access to what is necessary.
However, it is not always possible to install a software agent. Maybe it’s a mainframe application or an older operating system that requires fine-tuned policies due to a compliance requirement. Or application workloads that are in the cloud and whose installation is simply not possible for organizational reasons.
And that’s not the only challenge or consideration when choosing your approach. The teams or groups that make up a company often have different security needs, leading to the triad challenge: People, ProcessesAnd technology.
Let’s start with the people (policy owners) and the process (policy execution). Typically, each organization has its own unique requirements for protecting its application workloads and a defined process for implementing those requirements into policy. To support this, a tool (technology) is required that must adapt to the needs of each organization and should be able to define a common policy for agentless and agentless workloads.
To clear this up, you need to ask yourself:
- What are we protecting?
- Who owns the policies?
- How are the guidelines implemented?
As an example:
Let’s say you want to protect a financial application (What) using an agent-based approach (How)and the policy owner is the app team/workload team (WHO). In this scenario, this is generally an acceptable approach as long as the application does not crash and the team can continue to focus on coding. However, when implementing the common directive, the translation from human language to machine language tends to generate additional rules that are not strictly necessary. This is a common byproduct of the translation process.
Now let’s assume that your company is concerned with protecting a legacy application (What) is assigned 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, additional rules are generated. However, in this case, these unnecessary additional rules have negative consequences because the firewall rules meet audit requirements for compliance requirements even though they are part of the common policy.
Topology as a source of truth – advance only what is needed
Cisco Secure Workload has addressed people, process and technology challenges since its inception. The solution includes both approaches – installing software agents on workloads regardless of form factor (bare metal, VM or container) or using agentless enforcement points such as firewalls. Secure Workload adapts to the needs of each organization by defining the policy, such as a zero trust micro-segmentation policy, to effectively apply micro-perimeters to application workloads, supporting the zero trust approach. All in a single pane of glass.
However, as explained in the example above, we still needed to adapt our policy to the compliance needs of the Network/NetSec team and only use the necessary policy rules.
To address the challenge of additional rules, 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 – network topology.
So how does it work?
At Secure Workload, the term topology is an essential part of the solution. It leverages the topology concept using a construct called scopes, which is completely independent of the infrastructure, as shown in Figure 1.
It allows you to create a context-based topology tree in Secure Workload where you can group your applications and define your policies using human intent. Example: “Production cannot communicate with non-production” and apply the policy according to the topology hierarchy.
The Scope Tree is the topology of your application workloads within the organization. The key, however, is that it can be designed for different departments or organizational needs and customized to suit each team’s security needs.
The concept of mapping a workload range to a network firewall is called topology awareness.
Topology Awareness allows network/NetSec teams to map a specific area to a specific firewall in the network topology so that only the relevant policies for a specific application are pushed to the firewall.
So what does this execution look like? Once scope mapping is achieved, Secure Workload pushes the relevant policy to the Cisco Secure Firewall through its management platform, the Secure Firewall Management Center (FMC). To maintain compliance, only the necessary policy rules are sent to FMC, avoiding additional unnecessary rules due to topology discovery. An example of this is shown in Figure 2:
The central theses
Operationalizing a Zero Trust micro-segmentation strategy is not trivial, but Secure Workload has a proven track record of putting this into practice by adapting to the needs of each individual, such as: B. Network/NetSec administrators, workload/app owners, cloud architects and cloud architects. Native engineers – everything from one solution.
With topology awareness you can:
- Meet firewall rule compliance and audit requirements
- Protect and leverage your current investment in network firewalls
- Operationalize your zero trust micro-segmentation strategy with agent and agentless approaches
For more information about agentless enforcement, see: Blog on unified segmentation of Secure Workload and Secure Firewall
Would you like to find out more? Find out more by checking out our Secure workload resources.
We’d love to hear what you think. Ask a question below, comment, and stay connected to Cisco Secure on social media!
Cisco Secure Social Channels
Instagram
Facebook
Twitter
LinkedIn
Share:
[ad_2]
