easy-accordion-free domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114zoho-flow domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/mother99/jacksonholdingcompany.com/wp-includes/functions.php on line 6114When 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\u2019t help but notice how traditional network security e\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n 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\u2019t 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?<\/p>\n 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.<\/p>\n There are two approaches to do this -, using agent or agentless techniques to build a micro-perimeter around the workloads.<\/p>\n Which approach is the correct one to take? Well, this depends on multiple factors, including organizations, type of application, or team structure. So, let\u2019s start untangling this.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/strong>, processes<\/strong>, and technology<\/strong>.<\/p>\n Let\u2019s 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\u2019s needs and should be capable of defining a common policy across agent and agentless workloads.<\/p>\n To start unwrapping this, you need to ask yourself:<\/p>\n What are we protecting? As an example:<\/p>\n Say you want to protect a finance application (what)<\/strong> using an agent-based approach (how)<\/strong>, and the owner of the policies is the App Team\/Workload Team (who)<\/strong>. In this scenario, as long as the application doesn\u2019t 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.<\/p>\n Now, let\u2019s assume that in your organization the protection of a legacy application (what)<\/strong> is tasked to the Network\/NetSec team (who)<\/strong> using an agentless enforcement approach with network firewalls (how)<\/strong> 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.<\/p>\n Cisco Secure Workload has been addressing the people, process, and technology challenges since its inception. The solution embraces both approaches \u2013 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\u2019s 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.<\/p>\n 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.<\/p>\n To tackle the additional rules challenge, we asked ourselves, \u201cWhat is the most efficient way to push policies into a network firewall using Secure Workload?\u201d<\/p>\n The answer boiled down to a common concept for Network\/NetSec teams \u2013 the network topology.<\/p>\n So how does it work?<\/p>\n With Secure Workload, the term topology is intrinsic to the solution. It leverages the topology concept using a construct named \u201cScopes\u201d, which are totally infrastructure agnostic, as shown in Figure 1.<\/p>\n 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, \u201cProduction cannot talk to Non-Production\u201d and apply the policy following the topology hierarchy.<\/p>\n\n 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\u2019s security requirements.<\/p>\n The concept of mapping a workload Scope to a network firewall is called \u201cTopology Awareness.\u201d<\/p>\n 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.<\/p>\n 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:<\/p>\n\n 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 \u2013 all from one solution.<\/p>\n With topology awareness, you can:<\/p>\n Meet compliance and audit requirements for firewall rules For more information on agentless enforcement please read: Secure Workload and Secure Firewall Unified Segmentation Blog<\/a><\/p>\n Want to learn more?\u00a0 Find out more at by checking out our Secure Workload resources<\/a>.<\/p>\n We\u2019d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!<\/em><\/p>\n Cisco Secure Social Channels<\/strong><\/p>\n Instagram<\/a><\/strong>Facebook<\/a><\/strong>Twitter<\/a><\/strong>LinkedIn<\/a><\/strong><\/p>\n \u00a0\u00a0Provide zero trust segmentation with fine-grain rules to application workloads where an agent cannot be installed using existing network firewalls.\u00a0\u00a0Read More<\/a>\u00a0Cisco Blogs\u00a0<\/p>","protected":false},"excerpt":{"rendered":" <\/p>\n 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\u2019t help but notice how traditional network security e\u2026 Read more on Cisco Blogs<\/a><\/p>\n \u200b<\/p>\n 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\u2019t 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?<\/p>\n 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.<\/p>\n There are two approaches to do this -, using agent or agentless techniques to build a micro-perimeter around the workloads.<\/p>\n Which approach is the correct one to take? Well, this depends on multiple factors, including organizations, type of application, or team structure. So, let\u2019s start untangling this.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/strong>, processes<\/strong>, and technology<\/strong>.<\/p>\n Let\u2019s 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\u2019s needs and should be capable of defining a common policy across agent and agentless workloads.<\/p>\n To start unwrapping this, you need to ask yourself:<\/p>\n What are we protecting? As an example:<\/p>\n Say you want to protect a finance application (what)<\/strong> using an agent-based approach (how)<\/strong>, and the owner of the policies is the App Team\/Workload Team (who)<\/strong>. In this scenario, as long as the application doesn\u2019t 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.<\/p>\n Now, let\u2019s assume that in your organization the protection of a legacy application (what)<\/strong> is tasked to the Network\/NetSec team (who)<\/strong> using an agentless enforcement approach with network firewalls (how)<\/strong> 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.<\/p>\n Cisco Secure Workload has been addressing the people, process, and technology challenges since its inception. The solution embraces both approaches \u2013 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\u2019s 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.<\/p>\n 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.<\/p>\n To tackle the additional rules challenge, we asked ourselves, \u201cWhat is the most efficient way to push policies into a network firewall using Secure Workload?\u201d<\/p>\n The answer boiled down to a common concept for Network\/NetSec teams \u2013 the network topology.<\/p>\n So how does it work?<\/p>\n With Secure Workload, the term topology is intrinsic to the solution. It leverages the topology concept using a construct named \u201cScopes\u201d, which are totally infrastructure agnostic, as shown in Figure 1.<\/p>\n 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, \u201cProduction cannot talk to Non-Production\u201d and apply the policy following the topology hierarchy.<\/p>\n 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\u2019s security requirements.<\/p>\n The concept of mapping a workload Scope to a network firewall is called \u201cTopology Awareness.\u201d<\/p>\n 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.<\/p>\n 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:<\/p>\n 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 \u2013 all from one solution.<\/p>\n With topology awareness, you can:<\/p>\n Meet compliance and audit requirements for firewall rules For more information on agentless enforcement please read: Secure Workload and Secure Firewall Unified Segmentation Blog<\/a><\/p>\n Want to learn more?\u00a0 Find out more at by checking out our Secure Workload resources<\/a>.<\/p>\n We\u2019d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!<\/em><\/p>\n Cisco Secure Social Channels<\/strong><\/p>\n Instagram<\/a><\/strong>Facebook<\/a><\/strong>Twitter<\/a><\/strong>LinkedIn<\/a><\/strong><\/p>\nThe challenge(s)<\/strong><\/h2>\n
\nWho is the owner of the policies?
\nHow is policy execution done?<\/p>\nTopology as the source of truth \u2013 pushing only what is required<\/strong><\/h2>\n
Key takeaways<\/h2>\n
\nProtect and leverage your current investment in network firewalls
\nOperationalize your zero trust microsegmentation strategy using both agent and agentless approaches<\/p>\nThe challenge(s)<\/strong><\/h2>\n
\nWho is the owner of the policies?
\nHow is policy execution done?<\/p>\nTopology as the source of truth \u2013 pushing only what is required<\/strong><\/h2>\n
Key takeaways<\/h2>\n
\nProtect and leverage your current investment in network firewalls
\nOperationalize your zero trust microsegmentation strategy using both agent and agentless approaches<\/p>\n