Abstract

In a world of application workloads deployed anywhere, at any time, with hybrid multi-cloud solutions, applying network security controls is no longer a trivial task. The policy control toolset just keeps growing, with multiple enforcement points in the network to protect our application workloads using different approaches such as host firewalls, network firewalls, SDN controllers, or cloud-based in the form of security groups. Adding to the equation different teams managing each policy control and usually working in organizational siloes, there is no wonder why it often leads to inconsistent islands of policy controls across the environment. With Cisco ® Secure Workload, organizations can embrace the zero trust microsegmentation journey to harmonize different network security policy controls into a consistent, unified policy across hybrid multi-cloud environments to ultimately reduce the attack surface and contain lateral movement.

Target Audience

This document provides a technical overview of the design principles, architecture, and use-cases for Cisco secure Workload and Secure Firewall integration. The target audience for this document is Network Engineers, Network Security Engineers, System Engineers, Security Architects, and Cloud Architects.

Scope

This document covers multiple Cisco Secure Firewall architecture insertion options with their capabilities and related use-cases.

Cisco Secure Workload – Solution Overview
Cisco Secure Workload is a holistic security platform built to deliver in-depth application workload visibility and protection across hybrid multi-cloud environments. Secure Workload focuses on 3 main use cases:

• Zero Trust Microsegmentation: Using agent and agentless approaches, Secure Workload can discover workloads based on labels, automatically discover, and suggest segmentation policies based on traffic flows, validate and test the policy without any operational impact and enforce the dynamic distributed policy in multiple enforcement points such as host-based firewalls, DPUs, network firewalls, Load-Balancers and cloud built-in firewall security controls.
• Vulnerability Detection and Protection: Utilizing the agent, Secure Workload can provide visibility of the application runtime such as the detection of vulnerable packages and containers images, and leverage this information for reporting and protection using vulnerability (CVE) attributed-based policies to quarantine workloads or perform virtual patch via Secure Firewall.
• Behavioral Detection and Protection: Monitor running process for change in behavior and a detailed process tree and process snapshot. Detect anomalous behavior using MITRE ATTC&CK TTPs (Tactics, Techniques, and Procedures) or with custom forensic rules. By leveraging Secure Firewall, protection of both agent and agentless workloads can be achieved using Rapid Threat Containment.

Cisco Secure Workload and Secure Firewall – Microsegmentation Use-Case

Cisco Secure Workload and Secure Firewall provide a way to implement microsegmentation for east-west traffic flows to application workloads where agent installation is not feasible. There are 3 main capabilities to achieve this:

Visibility of Agentless Workloads

Ingest telemetry from Secure Firewall via NSEL (NetFlow Secure Event Logging) and automatic discover workloads by leveraging manual labels or external systems labels such as CMDBs, IPAMs. NSEL provides stateful IP flow tracking, considering the bi-directionality of flows.

• Ingest Connector: NSEL events are streamed to Secure Workload Ingest Connector for processing and the flow data is then exported to Secure Workload from the Ingest Connector. Ingest Connector can scale up to 45k fps per individual Secure Firewall connector and a total up to 135k fps for the entire appliance (for on-prem).

• End-To-End Visibility: Secure Workload is also capable stitching related flows (flow-stitching) to get end-to-end visibility even when NAT (Network Address Translation) is performed.

Secure Workload Dynamic Policy Engine

On Secure Workload, the user can define policy manually or perform automatic policy discovery with ADM (Application Dependency Mapping). Once the policies are validated and enforced, they are pushed to Firewall Management Center (FMC). If Secure Workload is the SaaS offering or is behind a proxy, the Secure Connector to connect to FMC is required.

• Policy Discovery and Analysis: By leveraging Machine Learning and Behavioral algorithms on the flow data ingested, Secure Workload automatically discovers policies. Once policies are discovered, they can be tested and validated is ready for enforcement.

• FMC (Firewall Management Center) Onboarding and Enforcement: Before enforcing the policies, east-west firewalls are onboarding through the FMC Connector. The FMC Connector supports single domain and multi-domain deployments of secure firewalls. The REST API use configured for Secure Workload must have administrative privileges.

• FMC Connector leverages the concept Topology Awareness to only push the necessary rules to a specific Secure Firewall. Firewall onboarding happens on a Access Control Policy (ACP) basis by mapping an ACP to a Scope. Each ACP-To-Scope mapping capabilities can be modified depending on the application or segmentation requirements:
  • Enforcement Mode: With “Merge Mode”, Secure Workload honors existing rules on FMC, allowing for policy dual-management. With “Override Mode”, Secure Workload removes any existing rule on FMC, only allowing Secure Workload pushed rules.
  • Rule Ordering: Secure Workload policies can be pushed either on top or bottom of existing FMC rules. “Default Policies” from Secure Workload will be pushed to the “Default Category” on FMC whereas “Absolute Policies” will be pushed to the “Mandatory Category” on FMC.
  • Optional Catch-All: You can select whether to use Secure Workload Catch-All policies or leverage the existing Default action from FMC.

• There are 2 ways to perform the ACP-to-Scope mapping, depending on how many applications are being protected by the firewalls:
  • Child Scope / Single Application: Mapping a child/leaf scope is done when only one application is being protected by Secure Firewall. In this case, Secure Workload only pushes policies that belong to the child scope and any other parent policy guardrail.
  • Parent Scope / Multiple Applications: Mapping a parent scope is done when multiple applications are being protected by Secure Firewall. In this case, Secure Workload pushes rules that belong to the mapped scoped but can also push policies from child/leaf scopes that are below the mapped scoped. This is done by virtue of the hierarchical policy. Parent policy guardrails will also be pushed.

• Enforcement on FMC and Monitoring
  Policies orchestrated from Secure Workload leverage FMC Dynamic Objects, so the policy is dynamic and doesn’t require policy deployments if an object changes.
  • Dynamic Objects: FMC will push the orchestrated dynamic policies from Secure Workload to the relevant Secure Firewalls in the environment.

• Policy Compliance: The policy is constantly monitored to verify compliance, and alerts and reports can be generated for deviation conditions to rapidly investigate and mitigate anomalies.

Workload Protection Level Definition

Before selecting the firewall insertion mode, defining the workload protection level based on the department or persona security/trust boundary is advisable. Below are some of the reasons for to do it:

• Simplicity and Abstraction: Defining the persona security/trust Boundary creates the bridge that connects the business requirements with the technical requirements. It helps to abstract the intrinsic complexities of heterogenous environments, so the business outcome is easily trackable.
• Common Language for Different Personas: Microsegmentation can have multiple definitions based on the persona or department task with it. The definition must consider each department/persona security/trusted boundary, so it is understood by the whole organization.
• Creates Consistency: By defining a persona-based security/trust boundary, the resulting segmentation controls on the network are consistent, allowing each persona or department a deep understanding of the segmentation controls and their limitations, if any.
• Prepares Path for Approach Selection: Depending on the persona security/trust boundary, agent-based or agentless might be used. Agent-based shine when the constructs defined by the persona are not network-based, whereas agentless-based is typically a good fit for personas using network constructs as security/trust boundaries.

The image below shows an example of how a Workload Protection Level Definition looks like depending on the personas security/trust boundary.

For this document, the personas assumed to manage and operate the Secure Firewall network security controls are the Network/Firewall engineers and/or Cloud Engineers, and the workload protection level security boundary in use is the subnet level.

Cisco Secure Workload and Secure Firewall Insertion Options - On-Premises

Layer 2 Firewall (Transparent Mode) Insertion

• Best fit for localized workloads
• Acceptable for fine-grained segmentation
  • FW as bump-in-Wire on the datapath
  • Workloads that require fine-grained segmentation but an agent cannot be install, such as legacy OS workloads
• Protection at the network level
• Full flow visibility with NSEL
  • Intra and Inter-subnet flows
• Protection at the network level
  • Intra-subnet (App-App)
  • Inter-subnet (App-App and External-App)
• Allows policy dual-management
  • CSW owned-policies
  • FMC owned-policies
• Convenient for network and firewall engineers

Layer 3 Firewall (Routed Mode) Insertion

• Excellent fit for distributed workloads
• Reasonable segmentation for workloads
  • Firewall as GW
  • Quick time-to-segment. Good for segments that do not require fine-grained segmentation (such as non-production/development).
• Protection at the network level
  • Inter-subnet only (App-App and External-App)
• Partial flow visibility with NSEL
  • Inter-subnet flows only
• Allows policy dual-management
  • CSW owned-policies
  • FMC owned-policies
• Convenient for network and firewall engineers

Application Centric Infrastructure (ACI) Insertion

Service Graph With Policy Based Redirect

• No re-architecture
  • Flexible and easy to configure
  • FW is selectively inserted in the path
• Supports both L3 and L2 FW modes
  • Intra and inter-subnet flow visibility (both)
  • Intra and Inter-subnet protection (both)
  • Preferred L3 mode
• Can do intra-ESG redirection

Service Graph Go-To/Go-Through Mode

• FW is in-path (Security over Connectivity)
  • Not very flexible and more complex
  • Typically used for North-South traffic
• Go-To
  • Inter-subnet visibility and protection
• Go-Through
  • Intra and Inter-subnet visibility protection

Service Graph PBR and Firewall Insertion Protection

• Flexible segmentation for workloads
  • Acceptable fine-grained
  • Reasonable
• Full visibility of flows with NSEL
  • FW inserted in datapath with service graph
  • Intra and inter EPG/ESG
• Protection at network level
  • Intra EPG/ESG (intra-app)
  • Inter EPG/ESG (inter-app)
• Allows policy multi-management
  • CSW owned-policies
  • FMC owned-policies
  • ACI owned-policies
• Convenient for network (ACI) and firewall engineers

Cisco Secure Workload and Secure Firewall Insertion Options - Cloud

AWS Centralized East-West Insertion

• Reasonable segmentation
  • Full flow visibility with VPC flow logs and NSEL
  • Intra and Inter-subnet flows
• Protection at the network level
  • Inter-VPC / Inter-subnet
    • App-App and External-App
• FMC policy dual management
  • East-West (CSW+FMC)
  • North-South – Ingress/Egress (FMC)
• Suitable for network/firewall engineers

AWS Distributed East-West Insertion

• Reasonable segmentation
• Full flow visibility with VPC flow logs and NSEL
  • Intra and Inter-subnet flows
• Protection at the network level
  • Intra-VPC / Inter-subnet
    • App-App and External-App
• FMC policy dual management
  • East-West (CSW+FMC)
  • North-South – Ingress/Egress (FMC)
• Suitable for network/firewall engineers

Azure Hub VNet East-West Insertion

• Acceptable for fine-grained segmentation
  • Azure UDR
• Full flow visibility with NSG flow logs and NSEL
  • Intra and Inter-subnet flows
• Protection at the network level
  • Intra-VNet
    • Intra-Subnet (App-App)
    • Inter-subnet (App-App)
  • Inter-VNet
    • Inter-subnet (App-App and External-App)
• FMC policy dual management
  • East-West (CSW+FMC)
  • North-South – Ingress/Egress (FMC)
• Suitable for network/firewall engineers

GCP Hub VPC East-West Insertion

• Reasonable segmentation
• Full flow visibility with VPC flow logs and NSEL
  • Intra and Inter-subnet flows
• Protection at the network level
  • Inter-VPC
    • Inter-subnet (App-App and External-App)
• FMC policy dual management
  • East-West (CSW+FMC)
  • North-South – Ingress/Egress (FMC)
• Suitable for network/firewall engineers

Cisco Secure Workload and Secure Firewall – Virtual Patch Use-Case

Cisco Secure Workload delivers in-depth visibility of agent-based workloads runtime. Runtime information retrieve by the agent:

• Running processes, process snapshots, process tree and process hash
• Software packages
• Software and kernel packages vulnerabilities

Secure Workload can export the vulnerability information from workloads to FMC via the FMC connector. FMC administrator can then run firepower recommendations to have fine-tune IPS policies to apply virtual patch in case there are important vulnerabilities in the environment and cannot be patched right away.

Vulnerabilities Export

FMC connector manages both use-cases (microsegmentation and virtual patch). The virtual patch use-case has its own tab, where all relevant virtual patch rules are created.

To export vulnerability information from agent-based workloads, the Virtual Patching a virtual patch rule creation is required. The virtual patch rule consists of 2 elements:

• Host Query: The host selector component to specify which workloads to export vulnerabilities from.
• CVE Query: Query to specify the CVE selector for the workloads.

FMC Vulnerability Import/Visibility

Secure Workload will export vulnerability information to the Third-Party Vulnerabilities on FMC. This information is useful for FMC admins and SecOps operators to have visibility on the current hygiene of workloads.
For CVEs which have a snort signature or signatures (SnortID) available, the cve-to-snortid mapping will be shown

Cisco Recommendations for Fine-Tuned IPS Policies

With the CVE intelligence exported from Secure Workload to FMC, automatic discovery of snort signatures that mitigates applicable CVEs on the workloads can be applied.

Cisco Recommended Rules must be run (previously known as Firepower Recommendations).

There are 2 main approaches to discovering snort signatures that are applicable to CVEs on the workload:

• No Rules Active: By selecting no rules active, no preconfigured snort signatures will be enabled on the IPS policy. Use this option is fine-tune IPS policy is required and only the snort signatures which have a CVE mapped to them are required.
• Selected Base Policy: By selecting this option, a preconfigured base policy such as Cisco default ones (e.g. Connectivity Over Security, Balanced Security and Connectivity, Maximum Detection) or a custom defined one. This option is useful when fine-tune snort signatures are not required, but is preferable to have coverage from a base policy snort rules as well as the identified from the Cisco Recommended Rules.

Apply Virtual Patch

To apply the compensating control for vulnerable workloads traffic flows, it is required to modify or create an Access Control Rule in the Access Control Policies, and add the Intrusion Policy capability selecting the virtual patch IPS policy.

Cisco Secure Workload and Secure Firewall – Rapid Threat Containment Use-Case

The Rapid Threat Containment use-case between Secure Workload and Secure Firewall is to enable network security and network operators to quickly identify and quarantine compromised workloads due to an anomalous behavior detected such as malware event, intrusion event or a correlation event, just to name a few.

This process consists of 4 steps:

• Anomalous Workload Behavior: An agent or agentless workload changes its behavior and generates anomalous or malicious traffic.
• Secure Firewall Detection Secure Firewall will detect the change in behavior and block the traffic flow if configured. An event is sent to FMC with the workload details.
• FMC Orchestration: A preconfigured FMC correlation policy, tracking the change in behavior conditions, will orchestrate the response via API to Secure Workload.
• Secure Workload Policy: A predefined policy containing the quarantine attribute/label, which get updates automatically via FMC will propagate the policy through different enforcement points such as agent-based with host-based firewalls or agentless with Secure Firewall to contain lateral movement and any malicious activity propagation.

FMC Remediation Module for Secure Workload

FMC Remediation Module for Secure Workload automates responses based on anomalous or malicious behaviors observed in network traffic flows or endpoints.

The package needs to be downloaded and uploaded to FMC, and some minimal configuration is required such as the Secure Workload Cluster IP, Root Scope and the API Key for FMC. The only permission that is required is for “User Data Upload” in Secure Workload.

Correlation Rules Definition

Correlation Rules are a set of define events or signals that FMC must track in order to be triggered. Complex conditions can be build by leveraging the AND and OR operators for the rules.

Correlation Policy Rules and Response

After defining the correlation rules, these rules are grouped together into a Correlation Policy, where each rule gets assigned a priority and an assigned response.

Remediation Module and Correlation Policies Events Workflow

If a Correlation Rule condition is met, this will trigger the Correlation Policy

• Correlation Rule Condition: If a condition is met, this will trigger the Correlation Policy.
• Correlation Policy: The Correlation Policy gest will initiate the response.
• Remediation Module: The Remediation Module is the instrumental piece to orchestrate the response to external systems, in this case Secure Workload. It will automatically send the affected workload or endpoint IPs to Secure Workload via API for later consumption in the segmentation policies.

Secure Workload Guardrail Policy

With Secure Workload human intent-based policy, policy guardrails can easily be crafted with labels, which is used for context, to automatically discover workloads and reduce the attack surface.

This integration can be used for the following scenarios:

• Quarantine Workloads: Block access to agent-based or agentless workloads with anomalous/malicious behaviors.
• Deny Access to Compromised Users/Endpoints: Block access to compromised users or endpoints to applications on-premises or in multi-cloud (example shown below).

FAQs

• What happens if I have a mix of agent-based and agentless workloads behind the firewall mapped to FMC Connector?
  • The use-case of Secure Workload and Secure Firewall integration is to protect agentless workloads. However, in such scenario that there are a mix of agent-based workloads and agentless behind the firewall the solution will still work. The main difference is that rules from agent-based workloads (which are enforcing policies using the native host OS firewall) will be pushed to FMC Access Control Policy (ACP) as well. This is a byproduct of the hierarchical policy engine of Secure Workload.
• Can I map more than one Scope to an ACP?
  • No. Only one Scope can be mapped to one ACP
• I want to enable Layer 7 capabilities and other FMC functionalities to the Secure Workload controlled rules. Can I do that?
  • No. Secure Workload rules are orchestrated from Secure Workload and no modification should be done to them. While it is possible to add FMC functionalities, this is not advisable and not supported. At the time of this writing the use-case is to provide east-west microsegmentation with L3/L4 policies.
• How can I have dual-management of policies (Secure Workload owned and FMC owned)?
  • Secure Workload has the capability to honor existing rules (merge) on FMC. Dual management is achievement by selecting to place Secure Workload rules either on top or bottom of existing ones. After this is done, the rule ordering must be kept in order to preserve policy authoring from FMC and Secure Workload. If a rule that is controlled by Secure Workload (or misplaced), Secure Workload will override the change and return the policies to the original state.
• What happens if a rule owned by Secure Workload is modified?
  • Secure Workload will override the change and return it to the original state
• Which FMC versions are supported?
  • To leverage dynamic objects any version above 7.0.1 is supported.
  • To leverage Virtual Patch any version starting 7.2 is supported.
  • Current qualified releases by engineering includes 7.0.1 and 7.2.5