• See Supported Platforms and Requirements.

• Root privileges to install and execute the services.

• 1-GB storage space for agent and log file.

• Security exclusions are configured on the security applications that are monitoring the host to prevent these applications from blocking agent installation or agent activity. For more information, see Security Exclusions.

• A special user, tet-sensor, is created in the host where the agent is installed. If PAM or SELinux is configured on the host, tet-sensor user must be granted appropriate privileges for executing the tet-sensor process and making connections to collectors. If an alternative install directory is provided and SELinux is configured, ensure that execution is allowed for that location.

• You must be able to use the unzip command, if the agent is installed using the AutoInstall (installer script) method.

Methods to install a Linux agent for deep visibility and enforcement:

• Install Linux Agent Using the Agent Script Installer Method

• Install Linux Agent using the Agent Image Installer Method

• For more information, see the Supported Platforms and Requirements.

• Administrator privileges are required for install and service execution.

• Npcap must be installed on workloads running Windows 2008 R2 or when the installed agent version is prior to version 3.8. If the Npcap driver is not already installed, the recommended Npcap version will be installed silently by the agent after the service starts.

  For more information, see the Npcap version information.

• Storage requirement for agent and log files: 1 GB.

• Required Windows services: If your Windows hosts have been security that is hardened or have deviated from the default configuration as shipped from Microsoft, you may have some Windows services disabled that are required for successful agent installation.

  For more information, see the Required Windows Services section.

• Prevent other security applications from blocking agent installation or agent activity by configuring security exclusions on the security applications that are monitoring the host. See

  For more information, see the Security Exclusions section.

There are two methods to install an agent on Windows platforms for deep visibility or enforcement:

• Install Windows Agent using the Agent Script Installer Method

• Install Windows Agent using the Agent Image Installer Method

You can also install using a golden image. See Deploying Agents on a VDI Instance or VM Template (Windows).

1. Verify that the service TetSensor (for deep visibility) and TetEnforcer (for enforcement) running in the config- ured service user context. TetSensor and TetEnforcer run in the same service user context.

   Run command cmd.exe with Admin privileges

   Run command sc qc tetsensor

   Check SERVICE_START_NAME <configured service user>

   Run command sc qc tetenforcer

   Check SERVICE_START_NAME <configured service user>

   OR

   Run command services.msc

   Find name Cisco Secure Workload Deep Visibility

   Check Log On As for the <configured service user>

   Find name Cisco Secure Workload Enforcement

   Check Log On As for the <configured service user>

   OR

   Run command tasklist /v | find /i “tet”

   Check the user context for the running processes (5th column)

To modify the service account after installing Windows Agents, use one of the following methods to modify the existing Deep Visibility and Enforcement services.

• Use services.msc.

  

• Use any third party application to configure the services.

• Use the following commands:

  1. Run cmd as an administrator.

  2. Modify the services using service account name by running the following commands:

     1. sc config tetsensor obj= <service user name> password= <password>

     2. sc config tetenforcer obj= <service user name> password= <password>

  3. Verify service configurations by running the following commands:

     1. sc qc tetsensor

     2. sc qc tetenforcer

  4. Restart the tetsensor and tetenforcer services by running the following commands:

     1. sc stop tetsensor / tetenforcer

     2. sc start tetsensor / tetenforcer

By default, agent services start automatically after agents are installed. When installing on a golden image, you must use installer flags to prevent these services from starting. When instances are cloned from the golden image, agent services will start automatically as expected.

Similarly, NPCAP is normally installed automatically after agent installation if it is not already present. NPCAP is not automatically installed on golden images, but will be automatically installed if needed on VM instances cloned from a golden image. For more information, see Windows Agent Installer and Npcap.

1. For supported Npcap versions, see the Support Matrix at https://www.cisco.com/go/secure-workload/requirements/agents.

2. Installation:

   If Npcap is not installed, the agent will install the supported version ten seconds after the service starts. If User has Npcap installed but is older than supported version, Npcap will not be upgraded. Up- grade/uninstall Npcap yourself, run the agent installer with option overwritenpcap=yes, or run installer script with -npcap to get the supported Npcap version. If Npcap driver is in use by any application, the agent will try to upgrade Npcap at a later time.

3. Upgrade:

   If Npcap is installed by Windows Agent and the version is older than the supported version, Npcap will be upgraded to the supported version ten seconds after the service starts. If Npcap driver is in use by any application, the agent will try to upgrade Npcap at a later time. If Npcap is not installed by Windows Agent, Npcap will not be upgraded.

4. Uninstall:

   If Npcap is installed by Windows Agent, it will uninstall Npcap. If Npcap is installed by user, but upgraded by the agent installer with overwritenpcap=yes, it will not be uninstalled. If Npcap driver is in use by any application, the agent will not uninstall Npcap.

• See Supported Platforms and Requirements.

• Additional requirements for deep visibility:

  • Root privileges are required to install and execute the services.

  • Storage requirement for agent and log files: 500 MB.

  • Prevent other security applications from blocking agent installation or agent activity by configuring security exclusions on any security applications that are monitoring the host. See Security Exclusions.

  • AIX only supports flow capture of 20 net devices (6 net devices if version is AIX 7.1 TL3 SP4 or earlier). The deep visibility agent captures from a maximum of 16 network devices, leaving the other 4 capture sessions available for exclusive generic system usage (For example, tcpdump).

  • The deep visibilty agent does the following to ensure this behaviour:

    • The agent creates 16 bpf device nodes under the agents directory (/opt/cisco/tetration/chroot/dev/bpf0 - /opt/cisco/tetration/chroot/dev/bpf15)

    • tcpdump and other system tools using bpf will scan through the system device nodes (/dev/bpf0-/dev/bpf19) until they find an unused node (!EBUSY)

    • The agent created bpf nodes and system bpf nodes will share the same major/minor, with each major/minor only be opened by one instance (either tcpdump or agent)

    • The agent will not access the system device nodes, and not create them as tcpdump does (tcpdump-D will create /dev/bpf0. . . /dev/bpf19 if they do not exist).

  • Running iptrace on system will prevent in certain scenarios flow capture from tcpdump and deep visibilty agent. This is a known design issue and needs to be checked with IBM.

    • To check if this scenarios exists before installing the agent, run tcpdump. If error message is like tcpdump: BIOCSETIF: en0: File exists iptrace is blocking flow capture. Stopping iptrace will resolve the issue.

  • Not every deep visibility functionality is supported on AIX. Package and process accounting are among the ones not supported.

• Additional requirements for policy enforcement:

  • If IP Security Filter is enabled (i.e. smitty ipsec4), agent installation fails in pre-check. We recommend to disable IP Security Filter before installing agent.

  • When IP security is enabled, while Secure Workload enforcer agent is running, it will be reported as an error and enforcement agent will stop enforcing. To disable IP Security Filter when enforcement agent is active, contact a customer service representative.

• See Supported Platforms and Requirements.

• Root privileges are required to install and execute the services.

• Storage requirement for agent and log files: 1 GB.

• Prevent other security applications from blocking agent installation or agent activity by configuring security exclusions on the security applications that are monitoring the host. See Security Exclusions.

The Linux kernel has iptables and ip6tables that are used to set up, maintain, and inspect the tables of IPv4 and IPv6 packet filter rules. The iptables and ip6tables consist of many predefined tables. Each table contains predefined chains and can also contain user-defined chains. These chains contain sets of rules and each of these rules specifies the match criteria for a packet. Predefined tables include raw, mangle, filter, and NAT. Predefined chains include INPUT, OUTPUT, FORWARD, PREROUTING, and POSTROUTING.

The Secure Workload agent programs a filter table that contains rules to allow or drop packets. The filter table consists of the predefined chains INPUT, OUTPUT, and FORWARD. Along with these, the agent adds custom TA chains to categorize and manage the policies from the controller. These TA chains contain Secure Workload rules that are derived from the policies along with rules that are generated by the agent. When the agent receives platform-independent rules, it parses and converts them into iptable, ip6table, or ipset rules and inserts these rules into TA defined chains in the filter table. After programming the firewall, the agent monitors the firewall for any rule or policy deviation and if so, reprograms the firewall. It keeps track of the policies that are programmed in the firewall and reports their stats periodically to the controller.

Here is an example to depict this behavior:

A typical policy in a platform-independent network policy message consists of:

source set id: “test-set-1”
destination set id: “test-set-2”
source ports: 20-30
destination ports: 40-50
ip protocol: TCP
action: ALLOW
. . .
set_id: “test-set-1”
     ip_addr: 1.2.0.0
     prefix_length: 16
     address_family: IPv4
set_id: “test-set-2”
     ip_addr: 3.4.0.0
     prefix_length: 16
     address_family: IPv4

Along with other information, the agent processes this policy and converts it into platform-specific ipset and iptables rule:

ipset rule:
Name: ta_f7b05c30ffa338fc063081060bf3
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 1
Members:
1.2.0.0/16
Name: ta_1b97bc50b3374829e11a3e020859
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 16784
References: 1
Members:
3.4.0.0/16
iptables rule:
TA_INPUT -p tcp -m set --match-set ta_f7b05c30ffa338fc063081060bf3 src -m set --match-
˓→set ta_1b97bc50b3374829e11a3e020859 dst -m multiport --sports 20:30 -m multiport --
˓→dports 40:50 -j ACCEPT

A native component on Windows, the Windows Firewall with Advanced Security, regulates network traffic that is based on the following types of settings:

• Rules that regulate inbound network traffic.

• Rules that regulate outbound network traffic.

• Override rules that is based on the authentication status of the source and destination of the network traffic.

• Rules that apply to IPsec traffic and to Windows services.

The Secure Workload Network Policy is programmed using inbound and outbound firewall rules.

On the Windows platform, the Secure Workload Network Policy is enforced as follows:

1. The platform-independent firewall rules from the Secure Workload Network policy are translated into Windows Firewall rules.

2. The rules are programmed in Windows Firewall.

3. The Windows Firewall enforces the rules.

4. The Windows Firewall and its ruleset are monitored. If a change is detected, the deviation is reported and the Secure Workload Network policy is reset in the Windows Firewall.

Windows Firewall groups the rules based on the network that the host is connected to. These rule groups are called Profiles and there are three such profiles:

• Domain Profile

• Private Profile

• Public Profile

The Secure Workload rules are programmed into all the profiles, but only rules in active profiles are continuously monitored.

The set of rules in the Windows Firewall is not ordered based on the precedence. When multiple rules match a packet, the most restrictive of those rules take effect meaning that DENY rules take precedence over ALLOW rules. For more information, see the article on Microsoft TechNet.

1. ALLOW 1.2.3.30 tcp port 80
2. ALLOW 1.2.3.40 udp port 53
3. BLOCK 1.2.3.0/24 ip
4. ALLOW 1.2.0.0/16 ip
5. Catch-all: DROP ingress, ALLOW egress

When a packet headed for the host 1.2.3.30 TCP port 80 reaches the firewall, it matches all the rules above, but the most restrictive of them all, Rule number 3, is the one that will be enforced and the packet will be dropped. This behavior is contrary to the expectation that the rules will be evaluated in order, Rule 1 will be the rule that is enforced, and that the packet will be allowed.

This difference in behavior is expected in the Windows platform owing to the design of the Windows Firewall described above. This behavior can be observed in mixed-list policies with overlapping rules that have different rule actions.

For example,

1. ALLOW 1.2.3.30 tcp
2. BLOCK 1.2.3.0/24 tcp

Windows Advanced Firewall is considered as a stateful firewall, that is for certain protocols such as TCP, the firewall maintains internal state tracking to detect if a new packet hitting the firewall belongs to a known connection. Packets belonging to a known connection are allowed without the firewall rules having to be examined. A stateful firewall enables bidirectional communication without rules having to be established in the INBOUND and OUTBOUND tables.

For example, consider the following rule for a web server: Accept all TCP connections to port 443

The intention is to accept all TCP connections on port 443 to the server, and allow the server to communicate back to the clients. In this case, only one rule is inserted in the INBOUND table, allowing TCP connections on port 443. No rule is required to be inserted in the OUTBOUND table. Inserting a rule in the OUTBOUND table is implicitly done by the Windows Advanced Firewall.

Note	Stateful tracking applies only to protocols that establish and maintain explicit connections. For other protocols, both INBOUND and OUTBOUND rules must be programmed to enable bidirectional communication.

When enforcement is enabled, a given concrete rule is programmed as stateful when the protocol is TCP (the agent decides, based on the context, whether the rule is to be inserted in the INBOUND table or the OUTBOUND table). For other protocols (including ANY), both INBOUND and OUTBOUND rules are programmed.

Windows Filtering Platform (WFP) is a set of APIs provided by Microsoft to configure filters for processing network traffic. Network traffic processing filters are configured using kernel-level APIs and user level APIs. WFP filters can be configured at various layers, Network Layer, Transport Layer, Application Layer Enforcement (ALE). Secure Workload WFP filters are configured at the ALE layer, similar to Windows firewall rules. Each layer has several sublayers, ordered by weight, from highest to lowest. Within each sublayer, filters are ordered by weight, from highest to lowest. A network packet traverses through all the sublayers. At each sublayer, the network packet traverses through the matching filters that are based on weight, from highest to lowest and returns the action: Permit or Block. After passing through all the sublayers, the packet is processed based on the rule that Block action overrides Permit.

• Avoids Windows Firewall configuration dependencies.

• Overcomes GPO restrictions.

• Ensures ease of migration and policy reversion.

• Allows you to control policy ordering.

• Avoids strict block-first policy order of Windows Firewall.

• Reduces CPU overhead on policy update.

• Creates an efficient 1:1 policy rule filter.

• Ensures a faster single-step update.

When enforcement is configured to use WFP, Secure Workload filters override Windows Firewall rules.

In WFP mode, the agent configures the following WFP objects:

• Provider has a GUID and name, is used for filter management, and does not affect packet filtering

• Sublayer has a GUID, name, and weight. The Secure Workload sublayer is configured with higher weight than the Windows Advanced Firewall sublayer.

• Filter has name, GUID, ID, weight, layer ID, sublayer key, action (PERMIT/ BLOCK), and conditions. WFP filters are configured for Golder rules, Self Rules, and Policy Rules. The agent also configures the port scanning prevention filters. Secure Workload filters are configured with the FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT flag. This flag ensures that Secure Workload filters are not overridden by Microsoft Firewall rules. For each Secure Workload Network policy rule, one or more WFP filters are configured based on the direction (inbound or outbound) and protocol.

For TCP inbound policy,

id: 14 , TCP Allow 10.195.210.184 Dir=In localport=3389

The WFP filters configured are:

Filter Name:                  Secure Workload Rule 14
------------------------------------------------------
EffectiveWeight:                       18446744073709551589
LayerKey:                              FWPM_LAYER_ALE_AUTH_LISTEN_V4
Action:                                Permit
Local Port:                            3389
Filter Name:                           Secure Workload Rule 14
------------------------------------------------------
EffectiveWeight:                       18446744073709551589
LayerKey:                              FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4
Action:                                Permit
RemoteIP:                              10.195.210.184-10.195.210.184

Secure Workload agent configures Secure Workload Default Inbound and Secure Workload Default Outbound filters for inbound and outbound CATCH-ALL policy respectively.

• The agent does not monitor WAF rules or WAF profiles.

• The agent does not monitor firewall states.

• The agent does not require firewall state to be enabled.

• The agent does not conflict with GPO policies.

Agent enforcement in WFP mode supports mixed-list or grey list policies.

Consider the mixed-list (both allow and deny) policy example from the Enforcement Agent section:

1. ALLOW 1.2.3.30 tcp port 80-            wt1000
2. BLOCK 1.2.3.0/24 ip-                   wt998
3. ALLOW 1.2.0.0/16 ip-                   wt997
4. Catch-all: DROP ingress, ALLOWegress - wt996

When a packet headed for the host 1.2.3.30 tcp port 80 reaches the firewall, it matches filter 1 and is allowed. However, a packet that is headed for the host 1.2.3.10 is blocked because of filter 2. A packet that is headed for host 1.2.2.10 is allowed by filter 3.

Secure Workload WFP filters are configured at the ALE layer. Network traffic is filtered for socket connect(), listen(), and accept() operations. Network packets related to a L4 connection are not filtered after the connection is established.

You can view the configured Secure Workload WFP filters using c:\program files\tetration\tetenf.exe. Supported options:

• With administrative privileges, run cmd.exe.

• Run c:\program files\tetration\tetenf.exe -l -f <-verbose> <-output=outfile.txt>.

OR

• With administrative privileges, run cmd.exe.

• Run netsh wfp show filters.

• View the filters.xml file for configured Secure Workload filters.

You can delete the configured Secure Workload WFP filters using c:\program files\tetration\tetenf.exe. To avoid accidental deletions of filters, when you run the delete command, specify the token in <yyyymm> format, where yyyy is the current year and mm is the current month in the numerical form. For example, if today’s date is 01/21/2021, then the token is -token=202101

Supported options are:

• With administrative privileges, run cmd.exe.

• To delete all configured Secure Workload filters, run c:\program files\tetration\tetenf.exe -d -f -all - token=<yyyymm>

• To delete all configured Secure Workload WFP objects, run c:\program files\tetration\tetenf.exe -d -all -token=<yyyymm>

• To delete a Secure Workload WFP filter by name, run c:\program files\tetration\tetenf.exe -d -name=<WFP filter name> -token=<yyyymm>

• The Preserve Rules setting in Agent Config Profile has no effect when you set Enforcement Mode to WFP.

• Windows 2008 R2 does not support Windows OS based filtering policies.

• Network policy can be configured with a single user name whereas MS Firewall UI supports multiple users.

• While using the Windows OS-based policies, a consumer/ provider scope or filter should only contain Windows agents. Otherwise, non-Windows OSs (Linux, AIX) skip the policy and report a sync error in Enforcement Status.

• Avoid creating Windows OS filters with loose filtering criteria. Such criteria may open unwanted network ports.

• Due to limited or no knowledge of the process context, user context or service context of the network flows, there will be discrepancy in the policy analysis if the policies have Windows OS-based filters.

If you use Windows OS-based filtering attributes, the following topics provide you with verification and troubleshooting information.

Cisco TAC can use this information as needed to troubleshoot such policies.

The IPFilter package on AIX is used to provide firewall services and is available on AIX as a kernel expansion pack. It loads as a kernel extension module, /usr/lib/drivers/ipf. It includes ipf, ippool, ipfstat, ipmon, ipfs, and ipnat utilities that are used to program ipfilter rules and each of these rules specifies the match criteria for a packet. For more information, see the IPFilter pages in the AIX manual.

When enforcement is enabled, the agent uses IPFilter to program the IPv4 filter table that contains rules for allowing or dropping of IPv4 packets. The agent groups these rules to categorize and manage the policies using the controller. These rules include Secure Workload rules that are derived from the policies and rules that are generated by the agent.

When an agent receives platform-independent rules, it parses and converts them into ipfilter or ippool rules and inserts these rules into the filter table. After programming the firewall, the enforcement agent monitors the firewall for any rule or policy deviation and if so, reprograms the firewall. The agent keeps track of the policies that are programmed in the firewall and reports their status periodically to the controller.

A typical policy in a platform-independent network policy message consists of:

      source set id: "test-set-1"
      destination set id: "test-set-2"
      source ports: 20-30
      destination ports: 40-50
      ip protocol: TCP
      action: ALLOW
      ...
      set_id: "test-set-1"
         ip_addr: 1.2.0.0
         prefix_length: 16
         address_family: IPv4
      set_id: "test-set-2"
         ip_addr: 5.6.0.0
         prefix_length: 16
         address_family: IPv4

Along with other information, the agent processes the policy and converts it into platform-specific ippool and ipfilter rule:

    table role = ipf type = tree number = 51400
    { 1.2.0.0/16; };

    table role = ipf type = tree number = 75966
    { 5.6.0.0/16; };

pass in quick proto tcp from pool/51400 port 20:30 to pool/75966 port 40:50 flags S/SA group TA_INPUT
pass out quick proto tcp from pool/75966 port 40:50 to pool/51400 port 20:30 flags A/A group TA_OUTPUT

IPv6 enforcement is not supported.

1. Root scope owners have access only to create a Configuration Profile and Configuration Intent specification.

2. Root scope owners can create configuration profiles that are associated with only owned scopes and impose these configuration profiles on agents that are owned filters or scopes.

   Note	Under the Agent Configuration Profile, you can now see the number of intents using the configuration profile before you edit the profile.

   

3. Site administrators have access to all the components in the Agent Configuration page that include specifying interface configuration intents and remote virtual routing and forwarding configurations.

   

Network flow information is the summarization of all packets flowing through the system. There are two modes of capturing flow information: Detailed and Conversation. By default, the Detailed mode of capture is used. The captured flows are exported to a collector and the exported information includes:

• Flow identifier: Uniquely identify the network flow. It includes the general information such as: IP protocol, source and destination IP, and layer 4 ports.

• IP Information: Contains information that is seen in the IP header, such as: TTL, IP flags, Packet ID, IP options, and Fragmentation flags.

• TCP Information: Contains information that is seen in the TCP header, such as: sequence number, Ack number, TCP options, Rcvd windows size.

• Flow Information: Statistics of the flow (such as total packets, total bytes, TCP flags statistics, packet length statistics, and socket statistics), interface index from which the flow was observed, start time and end time of flow.

In Conversation mode, the agent exports only TCP flows that are bidirectional in nature along with other connectionless flows. Conversation mode is supported for Windows, AIX, and Linux platforms. For more information on Conversation mode, see Conversation Mode.

Note	In K8s environment, correlation of Pod or Host flows are not done in Conversation mode. In either of the modes, agents do not export the following flows: ARP/RARP conversations Agent’s flows to collectors

Machine info describes all the processes running on the host. In addition, it contains network information that is associated with the processes and the command used to launch the processes. Machine info is exported every minute and includes the following information:

• Process ID

• User ID: owner of the process

• Parent Process ID

• Command string used to launch the process

• Socket information: protocol (such as UDP or TCP), address type: IPv4 or IPv6, source and destination IP, source and destination port, TCP state, process’s start and end time, path to process binary

• Forensic information: for more information, see the section Compatibility.

Agent keeps track of various statistics, including system’s statistics and its own, such as:

• Agent’s start time and uptime

• Agent’s run time in user mode and kernel mode

• Number of packets received and dropped

• Number of successful and failed SSL connections

• Total flow packets and bytes

• Total exported flows and packets to collectors

• Agent’s memory and CPU usage

  {
    "AgentType":"ENFORCER",
    "Bios":"72EF1142-03A2-03BC-C2F8-F600567BA320",
    "CurrentVersion":"3.5.1.1.mrpm.build.win64-enforcer",
    "DesiredVersion":"",
    "HostName":"win2k12-production-db",
    "IP":"172.26.231.193",
    "Platform":"MSServer2012R2Standard"
  }

  {
    "AgentType":"SENSOR",
    "Bios":"72EF1142-03A2-03BC-C2F8-F600567BA320",
    "CurrentVersion":"3.5.1.1.mrpm.build.win64-sensor",
    "DesiredVersion":"",
    "HostName":"win2k12-production-db",
    "IP":"172.26.231.193",
    "Platform":"MSServer2012R2Standard"
  }