NetFlow is a network monitoring protocol that:

• allows routers and switches to aggregate traffic passing through them into flows,

• enables the export of flow data to a flow collector for storage, and

• supports offline querying and analysis.

To set up NetFlow, follow these steps:

1. Enable the NetFlow feature on your network devices. Then, configure the flow templates for export.

2. Configure the NetFlow Collector Endpoint information on the remote network devices. The NetFlow collector listens to the configured endpoint to receive and process NetFlow flow records.

NetFlow is supported by Cisco routers and switches, providing a method to extensively understand traffic patterns.

A NetFlow connector is a network component that

• acts as a NetFlow collector,

• registers as a NetFlow agent, and

• supports NetFlow v9 and IPFIX protocols.

The NetFlow connector is configured to receive flow records from network devices and forward them to Secure Workload for analysis. You can enable them on a Secure Workload Ingest appliance and run it as a Docker container.

The NetFlow connector registers with Secure Workload as a Secure Workload NetFlow agent. It decapsulates NetFlow protocol packets (that is, flow records); processes flows, and reports them like a standard Secure Workload agent. They focus on reporting flow records without process or interface information, unlike a Deep Visibility Agent.

Note	NetFlow connector supports NetFlow v9 and IPFIX protocols.

Note

Each NetFlow connector should report flows for a single VRF. The flows are exported and placed in the VRF based on the Agent VRF configuration in the Secure Workload cluster. To configure the VRF for the connector, choose Manage > Agents and click the Configuration tab. Under the Agent Remote VRF Configurations section, click Create Config . Provide the VRF name, the IP subnet of the connector, and the range of port numbers to send flow records to the cluster.

A rate limit is a threshold that

• allows the NetFlow connector to accept up to 15,000 flows per second.

• ensures that if the limit is exceeded, additional flow records are dropped.

• mandates a correct flow rate for customer support eligibility.

The NetFlow connector can parse packets with multiple flow and template records. It maintain efficiency within specified limits and identifies the flows.

The NetFlow connector accepts up to 15000 flows per second. If the connector parses more than 15000 flows per second, it drops the additional flow records.

The Secure Workload customer supports the NetFlow connector only if the flow rate is within this acceptable limit.

If the flow rate exceeds 15000 flows per second, it is important to adjust the flow rate to within limits and maintain it for at least three days. This helps rule out issues related to a higher incoming flow rate.

If the original issue persists, customer support becomes involved to investigate the problem and develop effective solutions.

The NetFlow connector supports these information elements in NetFlow v9 and IPFIX protocols. For more information, refer to IP Flow Information Export (IPFIX) Entities.

NetFlow Connector enables Secure Workload to ingest NetFlow v9 or IPFIX from Nexus routers or switches. No agents needed on hosts—connector on Ingest appliance processes flows up to 15K per second per conenctor with VRF support.

• Flow analytics dashboard: View ingested flows in real-time Flow Rate Gauge (green <5K pps, yellow 5-10K, red >10K approaching limit).

• Color coding:

  Status	Color	Meaning
  Healthy	Green	Flows <10K pps, 0 drops
  Warning	Yellow	10-14K pps, minor drops
  Critical	Red	>15K pps, rate limiting active

• Highlights client-server flow pairs using blue lines for bidirectional flows and orange lines for unidirectional flows.

For information about required virtual appliances, refer to Virtual Appliances for Connectors. For NetFlow connectors, IPv4 and IPv6 (dual stack mode) addresses are supported. However, note that dual stack support is currently a beta feature.

You can configure the connector with the following options:

• Log: For more information, refer to Log Configuration .

In addition, you can update the listening ports of IPFIX protocol on the connector through the Docker container in Secure Workload Ingest appliance using an allowed command. You can issue this command on the appliance by providing the connector ID of the connector, the type of the port to be update, and the new port information. You can find the connector ID on the connector page in Secure Workload user interface. For more information, see update-listening-ports.

BIG-IP IPFIX logging is a feature on F5 appliances that:

• collects flow data detailing traffic navigating the F5 BIG-IP infrastructure,

• exports IPFIX records to designated flow collectors, and

• operates with F5 BIG-IP software version 12.1.2 and later.

For more information, refer to F5 BIG-IP IPFIX logging.

The setup involves these steps:

1. Create the IPFIX Log-Publisher on the F5 BIG-IP appliance.

2. Configure the IPFIX Log-Destination on the F5 BIG-IP appliance, which listens on the configured endpoint to receive and process flow records.

3. Create an F5 iRule that publishes IPFIX flow records to the log-publisher.

4. Add the F5 iRule to the virtual server of interest.

   Note	F5 connector supports F5 BIG-IP software version 12.1.2 and above.

An F5 BIG-IP connector is a component that

• acts as an IPFIX collector,

• stitches NATed flows for forwarding to Secure Workload, and

• configures LDAP attributes for transactions if authentication is managed by F5.

Note	F5 connector supports only the IPFIX protocol.

Note

Each F5 connector reports only flows for a single VRF. Based on the Agent VRF configuration in the Cisco Secure Workload cluster, the connector assigns the flows to the VRF . To configure the VRF for the connector, choose Manage > Agents. Click the Configuration tab. Under the Agent Remote VRF Configurations section, click Create Config. Provide details such as the VRF name, IP subnet of the connector, and the range of port numbers that can send flow records to the cluster.

The following steps are for F5 BIG-IP load balancer. For more information, refer to Configuring F5 BIG-IP for IPFIX.

These steps configures IPFIX on the F5 BIG-IP load balancer to export IPFIX protocol packets for traffic traveling through the appliance. Here is a sample config of F5.

In this example, flow records will be published to ipfix-pub-1. ipfix-pub-1 is configured with log-destination ipfix-collector-1 which sends the IPFIX messages to IPFIX pool ipfix-pool-1. ipfix-pool-1 has 10.28.118.6 as one of the IPFIX collectors. The virtual server vip-1 is configured with IPFIX iRule ipfix-rule-1 which specifies the IPFIX template and how the template gets filled and sent.

• F5 and Secure Workload approved iRule for TCP virtual server. For more information, refer to L4 iRule for TCP virtual server.

• F5 and Secure Workload approved iRule for UDP virtual server. For more information, refer to L4 iRule for UDP virtual server.

• F5 and Secure Workload approved iRule for HTTPS virtual server. For more information, refer to iRule for HTTPS virtual server.

Note	Before using the iRule downloaded from this guide, update the log-publisher to point to the log-publisher configured in the F5 connector where you add the iRule.

Note

F5 has published a GitHub repository, f5-tetration, to help you to start with flow-stitching. The iRules for publishing IPFIX records to the F5 connector for various protocol types are available at: f5-tetration/irules. Visit the site for the latest iRule definitions. In addition, F5 also develops a script to: Install the correct iRule for the virtual servers. Add a pool of IPFIX collector endpoints (where F5 connectors listen for IPFIX records). Configure the log-collector and log-publisher. Bind the correct iRule to the virtual servers. This tool enables flow-stitching use-case, minimizing manual configuration and reducing user error. The script is available at f5-tetration/scripts.

A configuration connector is a component that

• facilitates LDAP and log configuration,

• enables updating IPFIX listening ports, and

• supports a range of virtual appliances for connectivity.

For information about required virtual appliances, refer to Virtual Appliances for Connectors.

LDAP Configuration

The LDAP configuration supports discovery of LDAP attributes, provides a workflow to pick the relevant attribute for username identification and allows the fetching of up to six attributes per user for integration.

Log Configuration

For more information on log-related settings and to ensure correct integration with your system, refer to Log Configuration .

IPFIX Protocol Updates

You can update the IPFIX protocol listening ports on a Docker container through the Secure Workload Ingest appliance using a command that is allowed to be run on the container. You need the connector ID and new port data, which can be easily found on the connector page in Secure Workload user interface. For more information, refer to update-listening-ports.

The Citrix NetScaler AppFlow is a traffic management feature that:

• collects flow data for traffic moving through the NetScaler,

• exports IPFIX records to flow collectors, and

• operates using the IPFIX protocol supported in Citrix NetScaler load balancers.

Citrix AppFlow is supported in Citrix NetScaler load balancers.

For more information about Citrix NetScaler AppFlow, refer to Citrix NetScaler AppFlow.

The setup for Citrix NetScaler AppFlow involves these steps:

1. Enable the AppFlow feature on one or more Citrix NetScaler instances.

2. Configure the AppFlow collector endpoint information on remote network devices. This AppFlow collector listens on the configured endpoint to receive and process flow records.

3. Configure AppFlow actions and policies to export flow records to AppFlow collectors.

Note	The NetScaler connector supports Citrix ADC software version 11.1.51.26 and higher.

Flow ingestion is a network process that

• gathers data from Citrix ADC devices,

• utilizes Docker containers on Cisco Ingest appliances, and

• registers as a NetScaler agent with the secure workload platform for analysis.

NetScaler connector is essentially a Citrix AppFlow (IPFIX) collector receiving flow records, stitching NATed flows, and forwarding them to Secure Workload for flow analysis. A NetScaler connector can be enabled on a Cisco Secure Workload Ingest appliance and runs as a Docker container. The NetScaler connector registers with Secure Workload as a Secure Workload NetScaler agent.

Note	NetScaler connector supports only IPFIX protocol.

Note

Each NetScaler connector should report flows only for one VRF. The flows exported by the connector are placed in the VRF based on the Agent VRF configuration in the Secure Workload cluster. To configure the VRF for the connector, perform these steps: Choose Manage > Agents. Click the Configuration tab. Under Agent Remote VRF Configurations section, click Create Config. Provide the details such as the name of the VRF, IP subnet of the connector, and range of port numbers to send flow records to the cluster.

A connector is a network device that

• allows specific log configurations,

• update listening ports on the IPFIX protocol,

• has identifiable connector IDs

For information about required virtual appliances, refer to Virtual Appliances for Connectors. The following configurations are allowed on the connector.

For more information, refer to Log Configuration .

To update the listening ports of IPFIX protocol on the connector, use the allowed command on the Docker container in Secure Workload Ingest appliance. This command is issued on the appliance by providing the connector ID, the type of port to be updated, and the new port information. The connector ID is available on the connector page in the Secure Workload user interface. For more information, see update-listening-ports.

A NetFlow protocol is a network monitoring standard that:

• allows aggregation of traffic data by network devices,

• enables export of flow data to collectors for storage, and

• assists in offline querying and analysis of network traffic.

For more information, refer to Meraki Firewall.

Set up the system by completing these steps:

1. Enable NetFlow statistics reporting on Meraki Firewall.

2. Configure the Meraki Firewall with the endpoint information for NetFlow collectors.

A Meraki connector is a NetFlow collector that:

• Receives flow records from the configured Meraki firewalls to export NetFlow traffic statistics.

• Processes the NetFlow records.

• Sends the flow observations reported by Meraki firewalls to Secure Workload for flow analysis.

You can enable a Meraki connector on a Secure Workload Ingest appliance and run it as a Docker container.

The Meraki connector registers with Secure Workload as a Secure Workload Meraki agent. It decapsulates the NetFlow protocol packets, processes and reports flows as a regular Secure Workload agent. Unlike a Deep Visibility Agent, it does not report any process or interface information.

Note	The Meraki connector supports the NetFlow v9 protocol.

Note

Each Meraki connector should report flows for a single VRF. The flows exported by the connector are placed in the VRF based on the Agent VRF configuration in Secure Workload cluster. To configure the VRF for the connector, complete these steps: Choose Manage > Agents. Click the Configuration tab. Under the Agent Remote VRF Configurations section, click Create Config. Provide the VRF name, IP subnet of the connector, and a range of port numbers that can send flow records to the cluster.

Based on the NetFlow record, Meraki connector sends flow observation to Secure Workload. Meraki NetFlow flow records are bidirectional. So, Meraki connector sends 2 flows: forward flow and reverse flow to Secure Workload.

Here are the details about flow observation sent by Meraki connector to Secure Workload.

A connector is a configuration tool that

• allows specific authorized configurations,

• enables updates to listening ports, and

• provides necessary integration with virtual appliances.

For information about required virtual appliances, refer to Virtual Appliances for Connectors.

For more information, refer to Log Configuration .

Listening ports of NetFlow v9 protocol on the connector can be updated on the Docker container in Secure Workload Ingest appliance using authorized command. This involves providing the connector ID, type of the port to be update, and the new port information. You can find the connector ID on the connector page in the Secure Workload user interface. For more information, see update-listening-ports.

A ERSPAN is a network feature that

• mirrors frames observed by network devices,

• encapsulates them into IP packets, and

• sends the packets to a remote traffic analyzer.

Encapsulated Remote Switch Port Analyzers typically involve these steps:

• Configure monitoring sessions for source ERSPAN on network devices.

• Use a remote network device that is directly connected to a traffic analyzer for destination monitoring.

The Secure Workload ERSPAN connector provides destination ERSPAN session and traffic analyzer functionalities, negating the need to configure destination sessions on the switches with the Secure Workload solution.

A SPAN agent is a network monitoring component that

• registers with each ERSPAN connector within a cluster,

• processes only ERSPAN packets, and

• performs traffic analysis without interface or process reporting like regular agents do.

Like Cisco destination ERSPAN sessions, SPAN agents decapsulate the mirrored frames. Then, they process and report the flows like a regular Secure Workload agent. SPAN agents differ from Deep Visibility Agents by not reporting process or interface information.

An ingest appliance for ERSPAN is a virtual machine (VM) that

• internally runs three ERSPAN Secure Workload connectors

• uses the same OVA or QCOW2 as a standard Ingest appliance

• assigns one vNIC and two vCPU cores to each connector without a limiting quota.

Each connector operates inside a dedicated Docker container to register a SPAN agent with the cluster. The container hostname is formatted as <VM hostname>-<interface IP address>. Connectors and agents are maintained upon VM, Docker daemon, or Docker container crashes/reboots.

Note	The ERSPAN connector’s status is reported on the Connector page. Check to the Agent List page and review the corresponding SPAN agent's state.

For more information on the required virtual appliances, refer to Virtual Appliances for Connectors. ERSPAN connectors support IPv4 and IPv6 addresses in dual stack mode, though dual stack support is currently a beta feature.

A source ERSPAN session is a network feature that

• allows the mirroring of ingress and egress frames on an interface,

• uses GRE packets to transport mirrored frames,

• and requires a source and destination IP address.

When configuring a source ERSPAN session on a Cisco Nexus 9000 switch, follow platform-specific configurations which you can find in the Cisco Secure Workload User Guide. Ensure that the L3 interface on the switch is the source and matches the IP address on the ERSPAN VM.

You create a source ERSPAN session with ID 10. The switch mirrors the frames ingressing and egressing (both) the interface eth1/23 and those on VLANs 315 and 512. The outer GRE packet carrying the mirrored frame will have source IP 172.28.126.1 (must be the address of a L3 interface on this switch) and destination IP 172.28.126.194. This is one of the IP addresses configured on the ERSPAN VM.

The Secure Workload SPAN Agents can process ERSPAN type I, II, and III packets as described in the proposed ERSPAN RFC. SPAN agents process ERSPAN packets generated by Cisco devices and, among non-RFC compliant formats, those generated by VMware vSphere Distributed Switch (VDS).

An ERSPAN source is a configuration aspect of ERSPAN that:

• Selects port/VLAN lists carefully to avoid overwhelming the SPAN agent.

• Utilizes Access Control List (ACL) policies for fine-grained frame selection.

• Allows for MTU modifications to manage bandwidth without affecting SPAN agent processing load.

The ERSPAN source session can modify the Maximum Transport Unit (MTU) of the ERSPAN packet, which commonly defaults to 1500 bytes. Decreasing the MTU will limit ERSPAN bandwidth usage without affecting the SPAN Agent load, as the agent’s workload is on a per-packet basis. Reduce the MTU to make a 160-byte allowance for the mirrored frame. For more information on ERSPAN header overhead, review the proposed ERSPAN RFC.

Three versions of ERSPAN exist, each providing varying overhead and functionalities such as QOS policies on versions II and III. The smaller the version, the lower the ERSPAN header overhead. Version II and III allow for applying QOS policies to the ERSPAN packets, and provide some VLAN info. Version III carries even more settings. Cisco switches default to Version II, while Secure Workload SPAN Agents support all versions, although they do not utilize extra information from ERSPAN versions II and III packets.

The Ingest Virtual Machine for ERSPAN uses CentOS 7.9, from which OpenSSL server/clients packages were removed.

Note	CentOS 7.9 is the guest operating system for Ingest and Edge virtual appliances in Secure Workload 3.8.1.19 and earlier releases. For releases starting from 3.8.1.36, it transitions to AlmaLinux 9.2.

After booting the VM and deploying the SPAN agent containers, all network interfaces except the loopback are unavailable, so the console remains the only access method.

Agent and Container Configuration

The VM network interfaces are encapsulated within Docker containers that use a centos:7.9.2009 based Docker image with no open TCP/UDP ports.

Containers run with base privileges, have added NET_ADMIN capabilities, and do not use the --privileged option.

Security Implications

In a container is compromised, guest OS security remains intact.

The same security measures applicable to other Agents in Secure Workload apply to the Secure Workload SPAN Agents within Docker containers.

When SPAN Agents show as active in the cluster Monitoring/Agent Overview page, no action is needed on the ERSPAN Virtual Machine. Users do not need to log in to it. If the SPAN Agents do not show as active or the flows are not reported to the cluster, this information will help pinpoint deployment problems.

Under normal conditions on the VM, these conditions should be verified:

• systemctl status tet_vm_setup reports an inactive service with SUCCESS exit status;

• systemctl status tet-nic-driver reports an active service;

• docker network ls reports five networks including host, none and three erspan-<iface name>;

• ip link only reports the loopback interface;

• docker ps reports three running containers;

• docker logs <cid> for each container contains the message:INFO success: tet-sensor entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

• docker exec <cid> ifconfig reports only one interface, besides the loopback;

• docker exec <cid> route -n reports the default gateway;

• docker exec <cid> iptables -t raw -S PREROUTING reports the rule: -A PREROUTING -p gre -j DROP;

In the case of discrepancies, check the deployment script logs in /local/tetration/logs/ tet_vm_setup.log.

For further agent troubleshooting:

• Use docker exec <cid> ps -ef, which reports two instances of tet-engine, tet-engine check_conf and two /usr/local/tet/tet-sensor -f /usr/local/tet/conf/.sensor_config instances, one with root user and other with tet-sensor user, along with the process manager /usr/bin/ python /usr/bin/supervisord -c /etc/supervisord.conf -n instance.

• Use docker exec <cid> cat /usr/local/tet/log/tet-sensor.log to view the agent’s logs;

• Use docker exec <cid> cat /usr/local/tet/log/fetch_sensor_id.log to view the agent’s registration logs;

• Use docker exec <cid> cat /usr/local/tet/log/check_conf_update.log to view the configuration update polling logs;

  Use tcpdump in the container’s network namespace to monitor traffic.

  To monitor specific container traffic:

  1. Retrieve the container’s network namespace (SandboxKey) using docker inspect <cid> | grep SandboxKey;

  2. Enter the container’s network namespace with nsenter --net=/var/run/docker/netns/...;

  3. Use tcpdump -i eth0 -n to monitor eth0 traffic.

The Network Visibility Module (NVM) is a software component that

• provides visibility and monitoring of endpoint and user behavior,

• collects context information from endpoints, and

• supports multiple contexts such as device, user, application, location, and destination.

AnyConnect NVM collects various contexts:

1. Device/Endpoint Context: Device/endpoint specific information.

2. User Context: Users associated with data flows.

3. Application Context: Processes associated with data flows.

4. Location Context: Available location specific attributes.

5. Destination Context: FQDN of the destination.

   AnyConnect NVM generates three types of records.

   NVM Record	Description
   Endpoint Record	Device/endpoint information including unique device identifier (UDID), hostname, OS name, OS version and manufacturer.
   Interface Record	Information about each interface in the endpoint including the endpoint UDID, interface unique identifier (UID), interface index, interface type, interface name, and MAC address.
   Flow Record	Information about flows seen on the endpoint including endpoint UDID, interface UID, 5-tuple (source/destination IP/port and protocol), in/out byte counts, process information, user information, and FQDN of the destination.

Each record is generated and exported in IPFIX protocol format. When the device is in a trusted network (on- premise/VPN), AnyConnect NVM exports records to a configured collector. The AnyConnect connector is an example of an IPFIX collector that can receive and process IPFIX stream from AnyConnect NVM.

Note	AnyConnect connector supports AnyConnect NVM from version 4.2 and later of the Cisco AnyConnect Secure Mobility Client.

For step-by-step instructions on how to implement AnyConnect NVM using either Cisco Secure Firewall ASA or Cisco Identity Services engine (ISE), refer to How to Implement AnyConnect NVM. Once the NVM module is deployed, the NVM profile should be specified, pushed to, and installed on endpoints running Cisco AnyConnect Secure Mobility Client. When specifying NVM profile, the IPFIX collector should be configured to point to the AnyConnect connector on port 4739.

AnyConnect connector registers with Secure Workload as a Secure Workload AnyConnect Proxy agent.

The AnyConnect connector processes AnyConnect NVM records by registering endpoints, determining interface IP addresses, and translating flow records to ensure effective network operations in Secure Workload.

The key components involved in the process are:

• AnyConnect connector: Registers endpoints and processes records for Secure Workload.

• NVM record: Contains endpoint-specific information used to enable communication.

• Secure Workload: The platform where all interactions from AnyConnect inputs are integrated and monitored.

The process involves these stages:

• Endpoint Record Processing:

  • Upon receiving an endpoint record, it registers the endpoint on Secure Workload using specific information and certificate.

  • It enables data-plane by connecting to a Secure Workload collector and periodically checks the endpoint status.

• Interface Record Processing:

  • IP address for an interface is recognized when flow records arrive.

  • Sends a snapshot of interfaces once the IP is defined, integrating VRF with incoming interface data.

• Flow Record Processing:

  • Translates and transmits flow records in a compatible format to Secure Workload.

  • Associates LDAP attributes to endpoint IP if configured, ensuring all data is correlated for network monitoring.

Endpoint Record

Starting with version 4.9, AnyConnect NVM begins to send the agent version. By default, Secure Workload registers the AnyConnect endpoint as version 4.2.x. This version indicates the minimum supported AnyConnect NVM version. For the AnyConnect endpoints with version 4.9 or newer, the corresponding AnyConnect agent on Secure Workload would show the actual version installed.

Note	Secure Workload does not control the installed version of the AnyConnect agent. Upgrading the AnyConnect endpoint agent via Secure Workload user interface has no effect.

Flow Record

Note

Each AnyConnect connector will report only endpoints/interfaces/ flows for one VRF. The endpoints and interfaces reported by AnyConnect connector are associated with the VRF based on the Agent VRF configuration in Secure Workload. The flows exported by the AnyConnect connector agent on behalf of the AnyConnect endpoint belong to the same VRF. To configure the VRF for the agent, go to: Manage > Agents and click the Configuration tab. In this page, under “Agent Remote VRF Configurations” section, click “Create Config” and provide the details about the AnyConnect connector. The form requests the user to provide: the name of the VRF, IP subnet of the host on which the agent is installed, and range of port numbers that can potentially send flow records to the cluster.

A duplicate UDID in Windows endpoints is a cloning issue where:

• All cloned endpoints from the same golden image have identical UDIDs.

• This identical UDID limits the AnyConnect connectors' ability to differentiate records.

• Makes data association to the correct AnyConnect agent indeterministic.

To solve this, AnyConnect NVM 4.8 provides a tool named dartcli.exe to find and regenerate UDID on the endpoint.

• dartcli.exe -u retrieves the UDID of the endpoint.

• dartcli.exe -nu regenerates the UDID of the endpoint. To run this tool, use these steps.

    C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -u
    UDID : 8D0D1E8FA0AB09BE82599F10068593E41EF1BFFF

    C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -nu
    Are you sure you want to re-generate UDID [y/n]: y
    Adding nonce success
    UDID : 29F596758941E606BD0AFF49049216ED5BB9F7A5

    C:\Program Files (x86)\Cisco\Cisco AnyConnect Secure Mobility Client\DART>dartcli.exe -u
    UDID : 29F596758941E606BD0AFF49049216ED5BB9F7A5

A periodic task is a scheduled activity that:

• runs at defined intervals,

• executes automatically without manual intervention, and

• involves processing to update various operational parameters.

Periodically, the AnyConnect connector sends process snapshots and user labels on AnyConnect endpoint inventories.

1. Process Snapshots: Every five minutes, the AnyConnect connector walks through the processes maintained locally, and sends a process snapshot for all endpoints with flows during that interval.

2. User Labels: Every two minutes, the AnyConnect connector walks through the LDAP user labels maintained locally and updates User Labels on those IP addresses.

For user labels, the AnyConnect connector creates a local snapshot of LDAP attributes of all users. With the AnyConnect connector enabled, provide LDAP configuration. This includes server/port information, required attributes, and the username attribute. In addition, the LDAP user credentials to access LDAP server may be provided. LDAP user credentials are encrypted and never revealed in the AnyConnect connector. Optionally, a certificate for the LDAP may be provided for secure access.

Note	AnyConnect connector creates a new local LDAP snapshot every 24 hours. This interval is configurable in LDAP configuration of the connector.

For information about required virtual appliances, refer to Virtual Appliances for Connectors. These configurations can be applied to the connector.

• LDAP: LDAP configuration supports discovery of LDAP attributes and provides a workflow to select the attribute that corresponds to the username and a list of up to six attributes to fetch for each user. For more information, refer to Discovery .

• Endpoint: For more information, refer to Endpoint Configuration.

• Log: For more information, refer to Log Configuration.

Additionally, the listening ports of IPFIX protocol on the connector can be updated on the Docker container in Secure Workload Ingest appliance using an allowed command. This command can be issued on the appliance by providing the connector ID of the connector, type of the port to be update, and the new port information. The connector ID can be found on the connector page in Secure Workload UI. For more information, see update-listening-ports.

Note	ISE version 2.4 or higher and ISE PIC version 3.1 or higher are required for this integration.

For information about required virtual appliances, refer to Virtual Appliances for Connectors. For ISE connectors, IPv4 and IPv6 dual-stack mode addresses are supported. Dual stack support is available as a beta feature.

You can configure the connector with these options:

• ISE Instance: The ISE connector connects to multiple instances of ISE using the provided configurations. Each instance requires ISE certificate credentials, a hostname, and a node name for connection. For more information, refer to ISE Instance Configuration.

• LDAP: LDAP configuration supports discovery of LDAP attributes, allows the selection of the username attribute, enables the fetching of up to six attributes for each user. For more information, refer to Discovery .

• Log: For more information, refer to Log Configuration.

  Note	ISE connector connects with the getSessions API call to fetch all active endpoints during the timeframe. The ISE connector also has a listener that subscribes to session topic in PxGrid that provides all the new endpoints updates.

Processing of ISE records involves integrating endpoint information and security group details into Secure Workload for timely updates and accurate content management.

The key components of the process are:

• ISE connector: Connects to the ISE instance to monitor updates and manage record registration.

• Secure Workload: Manages inventory enrichment using the registered endpoints.

• Local Database: Maintains mapping details for security groups.

The process involves the following stages:

• Connect and Subscribe: The ISE connector connects to the ISE instance and subscribes for updates on endpoints and security groups over pxGrid.

• Endpoint Record Handling: Upon receiving an endpoint record, the ISE connector registers the endpoint on Secure Workload using endpoint-specific information and its certificate, enriching the inventory.

• Security Group Management: ISE connector updates its local database with any Security Group Label changes and aligns these with endpoint records in Secure Workload.

ISE connector periodically updates user labels on ISE endpoint inventories.

1. Endpoint Snapshots: Every 20 hours, ISE connector fetches a snapshot of endpoints and security group labels from the ISE instance and updates the cluster if any change is detected. This call cannot handle disconnected endpoints if they are not visible in the ISE system.

2. User Labels: Every two minutes, ISE connector scans through the LDAP user and ISE endpoint labels maintained locally and updates user labels on those IP addresses.

For user labels, the ISE connector generates a local snapshot of LDAP attributes for all users. When ISE connector is enabled, configuration for LDAP may be provided, including server and port information, attributes to fetch for a user, and the attribute containing the username. Additionally, provide LDAP user credentials for LDAP server access. LDAP user credentials are encrypted and never revealed in the ISE connector. Optionally, provide an LDAP certificate for securely LDAP server access.

Note	ISE connector generates a new local LDAP snapshot every 24 hours. This interval is configurable in the LDAP configuration of the connector.

Note	After upgrading the Cisco ISE device, the ISE connector must be reconfigured with the new certificates generated by ISE.

An alert generates when an appliance (or a connector) is potentially down due to missing heartbeats from the appliance/connector.

Alert text: Missing <Appliance/Connector> heartbeats, it might be down.

Severity: High

Allowed Secure Workload virtual appliances: Secure Workload Ingest and Secure Workload Edge

Allowed connectors: All

When system usage (CPU, memory, and disk) is more than 90% on an appliance (and a connector). The appliance (and/or connector) generates an informational alert to indicate that it’s currently handling an increased system load.

It’s normal for appliances and connectors to consume more than 90% of system resources during heavy processing activity.

Alert text: <Number> of CPU/Memory/Disk usage on <Appliance/Connector> is too high.

Severity: High

Allowed Secure Workload virtual appliances: Secure Workload Ingest and Secure Workload Edge

Allowed connectors: All

When you try to connect a configured connector to a configured server and the configuration fails, the system generates an alert to indicate a potential issue with the configuration after accepting and deploying it.

For example, The AnyConnect connector can take an LDAP configuration, validate and accept the configuration. However, during the normal operation, it is possible that the configuration is no longer valid.

Alert captures the scenario and indicates that you have to take corrective action to update the configuration.

Alert text: Cannot connect to <Appliance/Connector> server, check <Appliance/Connector> config.

Severity: High, Low

Allowed Secure Workload virtual appliances: Secure Workload Ingest and Secure Workload Edge.

Allowed connectors: AnyConnect, F5, ISE, WDC, and ServiceNow.

Secure Workload Ingest appliance is a software appliance that can export flow observations to Secure Workload from various connectors.

Specification

• Number of CPU cores: 8

• Memory: 8 GB

• Storage: 250 GB

• Number of network interfaces: 3

• Number of connectors on one appliance: 3

• Operating System: CentOS 7.9 (Secure Workload 3.8.1.19 and earlier), AlmaLinux 9.2 (Secure Workload 3.8.1.36 and later)

See important limits at Secure Workload Virtual Appliances for Connectors.

Note	Each root scope on Secure Workload can have at most 100 Secure Workload Ingest appliances deployed.

Secure Workload Ingest appliance allows at most 3 connectors to be enabled on an appliance. There can be more than one instance of the same connector enabled on the same appliance. For the ERSPAN Ingest appliance three ERSPAN connectors are always automatically provisioned. Many of the connectors deployed on Ingest appliance collects telemetry from various points in the network, these connectors need to listen on specific ports on the appliance. Each connector is therefore bound to one of the IP address and the default ports on which the connector should be listening to collect telemetry data. As a result, each IP address is essentially a slot that a connector occupies on the appliance. When a connector is enabled, a slot is taken (thereby, the IP corresponding to the slot). And, when a connector is disabled, the slot occupied by the connector is released (thereby, the IP corresponding to the slot). See the Secure Workload Ingest appliance slots for how to ingest appliance maintains the state of the slots.

Allowed Configurations

• NTP: Configure NTP on the appliance. For more information, see NTP Configuration .

• Log: Configure Logging on the appliance. For more information, see Log Configuration .

Note	If there is a need to update the OS and packages to minimize vulnerabilities, redeploy both the Edge and Ingest appliances using the latest ingest OVA. For more information, see the Secure Workload Upgrade Guide.

Secure Workload Edge is a control appliance that streams alerts to various notifiers and collects inventory metadata from network access controllers such as Cisco ISE. In a Secure Workload Edge appliance, all alert notifier connectors (such as Syslog, Email, Slack, PagerDuty, and Kinesis), ServiceNow connector, Workload AD connector, and ISE connector can be deployed.

Specification

• Number of CPU cores: 8

• Memory: 8 GB

• Storage: 250 GB

• Number of network interfaces: 1

• Number of connectors on one appliance: 8

• Operating System: CentOS 7.9 (Secure Workload 3.8.1.19 and earlier), AlmaLinux 9.2 (Secure Workload 3.8.1.36 and later)

See important limits at Secure Workload Virtual Appliances for Connectors.

Note	Each root scope on Secure Workload can have at most one Secure Workload Edge appliance deployed.

The connectors deployed on Secure Workload Edge appliance do not listen on ports. Therefore, the Docker containers instantiated for the connectors on Secure Workload Edge appliance do not expose any ports to the host.

Allowed Configurations

• NTP: Configure NTP on the appliance. For more information, see NTP Configuration .

• Log: Configure Logging on the appliance. For more information, see Log Configuration .

Note	If there is a need to update the OS and packages to minimize vulnerabilities, redeploy both the Edge and Ingest appliances using the latest ingest OVA. For more information, see the Secure Workload Upgrade Guide.

NTP configuration allows the appliance to synchronize the clock with the specified NTP server(s).

Test: Test if a UDP connection can be made to the given NTP servers on port 123. If an error occurs for any of the NTP servers, do not accept the configuration.

# --- GENERAL CONFIGURATION ---
server <ntp-server>
...
server 127.127.1.0
fudge 127.127.1.0 stratum 10
# Drift file
driftfile /etc/ntp/drift

Note	Applicable to Secure Workload 3.8.1.19 and earlier.

# Secure Workload appliance chrony.conf.
server <ntp-server> iburst
...
driftfile /var/lin/chrony/drift
makestep 1.0 3
rtcsync

Allowed Cisco Secure Workload virtual appliances: All

Allowed connectors: None

Log configuration updates the log levels, maximum size of the log files, and log rotation parameters on the appliance and/or connector. If the configuration update is triggered on the appliance, appliance controller log settings are updated. On the other hand, if the configuration update is triggered on a connector, service controller and service log settings are updated.

Test: No op.

Apply: If the configuration is trigged on an appliance, update the configuration file of tet-controller on the appliance. If the configuration is triggered on a connector, update the configuration files of tet-controller and the service managed by the controller on the Docker container responsible for the connector.

Allowed Secure Workload virtual appliances: All

Allowed connectors: NetFlow, NetScaler, F5, AnyConnect, ISE, ASA, and Meraki.

Note

Since all alert notifier Connectors (Syslog, Email, Slack, PagerDuty, and Kinesis) run on a single Docker service (Secure Workload Alert Notifier) on Secure Workload Edge, it is not possible to update the log config of a connector without impacting the config of another alert notifier connector. The log configurations of Secure Workload Alert Notifier (TAN) Docker service on Secure Workload Edge appliance can be updated using an allowed command.

See Update Alert Notifier Connector Log Configuration for more details.

Endpoint configuration specifies the inactivity timeout for endpoints on AnyConnect and ISE connectors. When an endpoint times out, the connector stops checking in with Secure Workload and purges the local state for the endpoint on the connector.

Test : No op.

Apply : Update the configuration file of the connector with the new value

Allowed Secure Workload virtual appliances: None

Allowed connectors: AnyConnect and ISE

By default, the Secure Workload alerts are published to the Slack connector.

Test: To test the configuration, send a test alert to Slack using the webhook. If the alert is posted successfully, the test passes.

Apply: Update the configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: Slack

By default, the Secure Workload alerts are published to the PagerDuty connector.

Test: To test the configuration, send a test alert to PagerDuty using the service key. If the alert is published successfully, the test passes.

Apply: Update the configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: PagerDuty

By default, the Secure Workload alerts are published to the Amazon Kinesis connector.

Test: To test the configuration, send a test alert to the Kinesis stream. If the alert is published successfully, the test passes.

Apply: Update the configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: Kinesis

The process of alert email transmission using TAN service in Secure Workload Edge Appliance enables Secure Workload to integrate alerting seamlessly with email systems by notifying recipients directly through email:

• Email connector configuration–The Email Connector is set up with SMTP server details, including optional authentication mechanisms (basic SMTP authentication or modern Microsoft authentication). It also defines default recipient email addresses for alert delivery. This configuration can be customized for alerts, if needed.

• TAN service activation–When the Email connector is enabled on the Secure Workload Edge appliance, the TAN service is configured to handle alert notifications through email.

• Alert generation–The Secure Workload system continuously monitors workload security and generates alerts based on detected events or anomalies.

• Alert dispatch–After alert generation, the TAN service uses the Email connector configuration to format and send alert emails. The service acts as an alert publisher that pushes these notifications from the Edge appliance to the configured SMTP server.

Configure the SMTP Email connector using one of the authentication methods:

• Basic SMTP authentication

• Modern Microsoft authentication

Basic SMTP Authentication

The Basic SMTP authentication method uses SMTP username and password for authentication.

The following parameters are configured for Basic SMTP authentication:

Modern Microsoft Authentication

The modern Microsoft authentication (OAuth 2.0 authentication) method uses Microsoft client ID, Microsoft tenant ID, and client secret for authentication instead of username and password.

The following parameters are configured for modern Microsoft authentication:

By default, Secure Workload alerts are published to the Email connector.

Test: To test the configuration, send a test email.

Apply: Update the configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: Email

Default configuration for publishing Secure Workload alerts on Syslog.

Test: Send a test alert to Syslog server using the given configuration. If the alert is published successfully, the test passes.

Apply: Update configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: Syslog

The following table shows the default severity mapping for Secure Workload alerts on Syslog

You can modify this setting using this configuration.

Test: No op.

Apply: Update configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: Syslog

This configuration provides the parameters required to connect to the Cisco Identity Services Engine (ISE). By providing multiple instances of this configuration, the ISE connector can connect and pull metadata about endpoints from multiple ISE appliances. Up to 20 instances of ISE configuration may be provided.

Test: Connect to ISE using the given parameters. On successful connection, accept the configuration.

Apply: Update configuration file of the connector with the specified parameters.

Allowed Secure Workload virtual appliances: None

Allowed connectors: ISE