You can use Network Visibility Module for the following scenarios:

• To audit a user's network history for potential exfiltration after a security incident occurred.

• To see how system or adminstrative rights impact what network connected processes are running on a user's machine.

• To get a list of all devices running a legacy OS.

• To determine what application in your network is running the highest network bandwidth.

• To determine how many versions of Firefox are being used in your network.

• To determine what percentage of Chrome.exe connections are IPv6 in your network.

Of the five syslog data sources: per flow, endpoint identity, interface info, process info, and osquery data, the the Unique Identifier (UDID) field is used as a way to correlate records between these sources. You can use the InterfaceInfoUDID field to correlate a per flow record with an interface info record for collecting details on that specific interface. The following parameters are collected at the endpoint and exported to the collector:

The Network Visibility Module allows clients to identify themselves using DTLS or mDTLS. You configure Network Visibility Module to determine how to send data over plain UDP (IPFIX) or DTLS (IPFIX over DTLS). DTLS requires that Network Visibility Module clients verify the Collector's identity before sending data. With mDTLS, the Collector can also verify the Network Visibility Module Client's identity before the connection is established and data is received.

You enable the transport method in the Network Visibility Module Profile Editor.

In the profile editor, configure the IP address or FQDN of the collection server. You can also customize the data collection policy choosing what type of data to send, and whether data is anonymized or not.

Network Visibility Module can establish connection with a single stack IPv4 with an IPv4 address, a single stack IPv6 with an IPv6 address, or a dual stack IPv4/IPv6 to the IP address as preferred by the OS.

The mobile Network Visibility Module can establish a connection using IPv4 only. IPv6 connectivity is not supported.

Note

The Network Visibility Module sends flow information only when it is on the trusted network. By default, no data is collected. Data is collected only when configured as such in the profile, and the data continues to be collected when the endpoint is connected. If collection is done on an untrusted network, it is cached and sent when the endpoint is on a trusted network. If you are sending collection data to Cisco Secure Cloud Analytics 7.3.1 and prior releases (or something other than Splunk or similar SIEM tool), cache data is sent once on a trusted network but not processed. For Cisco Secure Cloud Analytics applications, refer to the Cisco Secure Cloud Analytics Enterprise Endpoint License and NVM Configuration Guide. If TND is configured in the Network Visibility Module profile, then the trusted network detection is done by Network Visibility Module and does not depend on VPN to determine if the endpoint is in a trusted network. Also, if VPN is in a connected state, then the endpoint is considered to be on the trusted network, and the flow information is sent. The NVM-specific system logs show Trusted Network Detection use. When configuring TND directly in the Network Visibility Module profile, an administrator-defined trusted server and certificate hash determine whether the user is on a trusted or untrusted network. Administrators configuring Trusted Network Detection for the core VPN profile would alternatively configure the Trusted DNS Domains and Trusted DNS Servers in the core VPN profile: Cisco Secure Client Profile Editor, Preferences (Part 2).

• Desktop or Mobile—Determines whether you are setting up Network Visibility Module on a desktop or mobile device. Desktop is the default.

• Collector Configuration

  • IP Address/FQDN—Specifies the IPv4 or IPv6 IP address/FQDN of the collector.

  • Port—Specifies at which port number the Collector is listening.

  • You cannot set DTLS and mDTLS to operate at the same time.

• Client Authentication—Determines if you want Network Visibility Module to securely send data to the collector over mDTLS. You can choose this checkbox only if the Secure checkbox in Collector Configuration is also selected. When enabled, Network Visibility Module uses mDTLS for transport. With mDTLS, the Collector (server) can also verify the Network Visibility Module Client's identity before the connection is established and data can be received.

  For mDTLS, you must install client certificates in the System certificate store, such as:

  • Windows—CERT_SYSTEM_STORE_LOCAL_MACHINE

  • macOS—System keychain

  • Ubuntu—"/etc/ssl/certs" or "/etc/ssl/private"

  • Red Hat—"etc/pki/tls/certs" or "/etc/pki/tls/private

  Only the client certificates with EKU ClientAuth and private keys (identity certificates) are used for client authentication. Root/Intermediate CA certificates of client certificates must also be present in the client Certstore. Currently Network Visibility Module supports RSA with PKCS1 and PSS padding as well as ECDSA keys and SHA hashing algorithms.

• Configure—Allows you to specify Client Match Criteria for Certificates used by client authentication (mDTLS). You can add up to four Distinguished Name Definitions as part of the Certificate Match Criteria. Network Visibility Module currently allows matching by subject name fields CN and OU, and Issuer subject name fields ISSUER-CN and ISSUER-OU.

• Cache Configuration

  • Max Size—Specify the maximum size the database can reach. The cache size previously had a pre-set limit, but you can now configure it within the profile. The data in the cache is stored in an encrypted format, and only processes with root privileges are able to decrypt the data.

    Once a size limit is reached, the oldest data is dropped from the space for the most recent data.

  • Max Duration—Specify how many days of data you want to store. If you also set a max size, the limit which reaches first takes precedence.

    Once the day limit is reached, the oldest day's data is dropped from the space for the most recent day. If only Max Duration is configured, there is no size cap; if both are disabled, the size is capped at 50MB.

• Periodic Template—Specify the period interval at which templates are sent out from the endpoint. The default value is 1440 minutes.

• Periodic Flow Reporting (Optional, applies to desktop only)—Click to enable periodic flow reporting. By default, Network Visibility Module sends information about the flow at the end of connection (when this option is disabled). If you need periodic information on the flows even before they are closed, set an interval in seconds here. The value of 0 means the flow information is sent at the beginning and at the end of each flow. If the value is n, the flow information will be sent at the beginning, every n seconds, and at the end of each flow. Use this setting for tracking long-running connections, even before they are closed.

• Aggregation Interval—Specify at which interval the data flows should be exported from the endpoint. When the default value of 5 seconds is used, more than one data flow is captured in a single packet. If the interval value is 0 seconds, each packet has a single data flow. The valid range is 0 to 600 seconds.

• Throttle Rate—Throttling controls at what rate to send data from the cache to the collector so that the end user is minimally impacted. You can apply throttling on both real time and cached data, as long as there is cached data. Enter the throttle rate in Kbps. The default is 500 Kbps.

  The cached data is exported after this fixed period of time. Enter 0 to disable this feature.

• Collection Mode—Specify when data from the endpoint should be collected by choosing: collection mode is off, trusted network only, untrusted network only, or all networks.

• Collection Criteria— You can reduce unnecessary broadcasts during data collection so that you have only relevant data to analyze. Control collection of data with the following options:

  • Broadcast packets and Multicast packets (Applies to desktop only)—By default, and for efficiency, broadcast and multicast packet collection are turned off so that less time is spent on backend resources. Click the checkbox to enable collection for broadcast and multicast packets and to filter the data.

  • KNOX only (Optional and mobile specific)—When checked, data is collected from the KNOX workspace only. By default, this field is not checked, and data from inside and outside the workspace is collected.

• Data Collection Policy—You can add data collection policies and associate them with a network type or connectivity scenario. You can apply one policy to VPN and another to non-VPN traffic since multiple interfaces can be active at the same time.

  When you click Add, the Data Collection Policy window appears. Keep these guidelines in mind when creating policies:

  • By default, all fields are reported and collected if no policy is created or associated with a network type.

  • Each data collection policy must be associated with at least one network type, but you cannot have two policies for the same network type.

  • The policy with the more specific network type takes precedence. For example, since VPN is part of the trusted network, a policy containing VPN as a network type takes precedence over a policy which has trusted as the network specified.

  • You can only create a data collection policy for the network that applies based on the collection mode chosen. For example, if the Collection Mode is set to Trusted Network Only, you cannot create a Data Collection Policy for an Untrusted Network Type.

  • If a profile from an earlier Cisco Secure Client release is opened in a later Cisco Secure Client release profile editor, it automatically converts the profile to the newer release. Conversion adds a data collection policy for all networks that exclude the same fields as were anonymized previously.

  • Name—Specify a name for the policy you are creating.

  • Network Type—Determine the collection mode, or the network to which a data collection policy applies, by choosing VPN, trusted, or untrusted. If you choose trusted, the policy applies to the VPN case as well.

  • Flow Filter Rule—Defines a set of conditions and an action that can be taken to either Collect or Ignore the flow when all conditions are satisfied. You can configure up to 25 rules, and each rule can define up to 25 conditions. Use the up and down buttons to the right of the Flow Filter Rules list to adjust the priority of rules and give them higher consideration over subsequent rules. Click Add to set up the component of a flow filter rule.

    • Name—The unique name of the flow filter rule.

    • Type—Each filter rule has a Collect or Ignore type. Determine the action (Collect or Ignore) to apply if the filter rule is satisfied. If collect, the flow is allowed when conditions are met. If ignore, the flow is dropped.

    • Conditions—Add an entry for each field that is to be matched and an operation to decide if the field value should be equal or unequal for a match. Each operation has a field identifier and a corresponding value for that field. The field matches are case sensitive unless you apply case-insensitive operations (EqualsIgnoreCase) to the rule set when you are setting up the filter engine rules. After it has been enabled, the input in the Value field set under the rule is case insensitive.

  • Include/Exclude

    • Type—Determine which fields you want to Include or Exclude in the data collection policy. The default is Exclude. All fields not checked are collected. When no fields are checked, all fields are collected.

    • Fields—Determine what information to receive from the endpoint and which fields will be part of your data collection to meet policy requirements. Based on the network type and what fields are included or excluded, Network Visibility Module collects the appropriate data on the endpoint.

      Note

      During an upgrade, the ProcessPath, ParentProcessPath, ProcessArgs, and ParentProcessArgs are excluded by default from being reported in the flow information, if one of these scenarios exist: If the profile in the older version of Network Visibility Module had no Data Collection Policy or had an include Data Collection Policy. If the profile in the older version of Network Visibility Module had an exclude Data Collection Policy, and the profile was opened and saved with a newer version profile editor. If the profile in the older version of Network Visibility Module had an exclude Data Collection Policy but the profile was not opened and saved with the newer 4.9 (or later) version profile editor, then these four fields are included. If Network Visibility Module is unable to compute the parent process id, the value defaults to 4294967295. FlowStartMsec and FlowStopMsec determine the Epoch timestamp of the flow in milliseconds.

      You can choose Interface State and SSID, which specifies whether the network state of the interface is trusted or untrusted.

    • Optional Anonymization Fields—If you want to correlate records from the same endpoint while still preserving privacy, choose the desired fields as anonymized. They are then sent as the hash of the value rather than actual values. A subset of the fields is available for anonymization.

      Fields marked for include or exclude are not available for anonymization; likewise, fields marked for anonymization are not available for include or exclude.

• Data Collection Policy for Knox (Mobile Specific)—Option to specify data collection policy when mobile profile is selected. To create Data Collection Policy for Knox Container, choose the Knox-Only checkbox under Scope. Data Collection policies applied under Device Scope apply for Knox Container traffic also, unless a separate Knox Container Data Collection policy is specified. To add or remove Data Collection Policies, see the Data Collection Policy description above. You can set a maximum of 6 different Data Collection Policies for mobile profile: 3 for Device, and 3 for Knox.

• Acceptable Use Policy (Optional and mobile specific)—Click Edit to define an Acceptable Use Policy for mobile devices in the dialog box. Once complete, click OK. A maximum of 4000 characters is allowed.

  This message is shown to the user once after Network Visibility Module is configured. The remote user does not have a choice to decline Network Visibility Module activities. The network administrator controls Network Visibility Module using MDM facilities.

• Export on Mobile Network (Optional and Mobile Specific)—Specifies whether the exporting of Network Visibility Module flows is allowed when a device is using a mobile network. If enabled (the default value), an end user can override an administrator when an Acceptable User Policy window is displayed or later by enabling the Settings > NVM-Settings > > Use mobile data for NVM checkbox in the Cisco Secure Client Android application. If you uncheck the Export on Mobile Network checkbox, Network Visibility Module flows are not exported when the device is using a mobile network, and an end user cannot change that.

• Process Tree Hierarchy—Until release 5.1.6, the flows reported by the Network Visibility Module only included information about the process and its parent process, and not information about the further process lineage. By clicking this checkbox, the Network Visibility Module will report the process lineage. Then a separate record (Process Record) is sent for each process in the process hierarchy. The process records will have a unique identifier (PUID) used to link between process records and flow records. You can receive a report of the process hierarchy for on-premises.

  Note	Currently, this feature is only supported in desktop platforms (Windows--only x86 and x64, macOS, and Linux), although macOS requires approval before an application can access parts of the file system. Refer to Provide Full Disk Access Manually for macOS.

• Trusted Network Detection—This feature detects if an endpoint is physically on the corporate network. The network state is used by the Network Visibility Module to determine when to export data and to apply the appropriate Data Collection Policy. Click Configure to set the configuration for Trusted Network Detection. An SSL probe is sent to the configured trusted headend, which responds with a certificate, if reachable. The thumbprint (SHA-256 hash) is then extracted and matched against the hash set in the profile editor. A successful match signifies that the endpoint is in a trusted network; however, if the headend is unreachable, or if the certificate hash does not match, then the endpoint is considered to be in an untrusted network.

  Note

  When operating from outside your internal network, Trusted Network Detection makes DNS requests and attempts to establish an SSL connection to the configured server. Cisco strongly recommends the use of an alias to ensure that the name and internal structure of your organization are not revealed through these requests by a machine being used outside your internal network.

  1. https://—Enter the URL (IP address, FQDN, or port address) of each trusted server and click Add.

     Note	Trusted servers behind proxies are not supported.

  2. Certificate Hash (SHA-256)—If the SSL connection to the trusted server is successful, this field is populated automatically. Otherwise, you can set it manually by entering the SHA-256 hash of the server certificate and clicking Set.

  3. List of Trusted Servers—You can define multiple trusted servers with this process. (The maximum is 10.) Because the servers are attempted for trusted network detection in the order in which they are configured, you can use the Move Up and Move |Down buttons to adjust the order. If the endpoint fails to connect to the first server, it tries the second server and so on. After trying all of the servers in the list, the endpoint waits for ten seconds before making another final attempt. When a server authenticates, the endpoint is considered within a trusted network.

• Osquery Data Configuration—Click Configure to allow endpoints to set options related to the Osquery Data Template. Network Visibility Module uses Osquery to run the queries and send output in JSON format with the Osquery Data Template.

  Currently, Network Visibility Module only allows the sending of Browser Plugins Data using Osquery.You can enable the reporting of browser plugins and also configure the browser plugin report intervals. The Browser Plugins Report Interval is from 1 to 720 hours and is 24 hours by default.

  Note	Currently Network Visibility Module is sending Chrome-Based Browsers' Browser Plugins and Firefox Browser Plugins.

Save the profile as NVM_ServiceProfile.xml. You must save the profile with this exact name or Network Visibility Module fails to collect and send data.

The addition of flow filters extends the current data collection policy from being just field centric, where the action is configured for a given field in each flow. With flow filter, you can create and apply rules to collect or ignore entire flows (as opposed to only particular fields), thus monitoring only the traffic of interest and potentially reducing storage requirements.

• A rule is a match only if all of the conditions specified in the rule are satisfied when matched against the flow data.

• The first rule that is satisfied is applied on the flow.

• The rest of the data collection policy (include/exclude fields, anonymized fields) is also applied on the flow if it is allowed by the filter policy.

• With instances of multiple rules,

  • No action is taken on the flow if no rule matches the flow data. The default behavior is followed, which is to collect the flow.

  • If a rule matches the flow data, the action specified in that rule of the flow is applied. Subsequent rules are not checked. The order of rules, as designated in the Network Visibility Module Profile Editor Flow Filter Rule parameter, indicates the priority if multiple matches could occur.

Use of Wildcard, CIDR, and Escape Sequence Support

When entering rule conditions, you can define a wider range of field values using wildcard characters or CIDR notations, in the case of IP addresses. Also, you can use certain escape sequences in the field value. For IP fields, the CIDR/slash notation can specify the IP address that the rule should match. For example, "192.30.250.00/16" would match all addresses that have the routing prefix "192.30.0.0" derived by applying the subnet mask of "255.255.0.0." For text fields, you can use wildcards (* and ?) and escape sequences (\*, \?, and \\) to catch a wider range of inputs. For example, logged in user "Jane*" would match all user names that start with "Jane."

Sample Configurations to Achieve Flow Filtering Scenarios

This feature allows the endpoint to configure options related to Osquery Data Template. Network Visibility Module uses Osquery to run the queries and send output in JSON format with the Osquery Data Template. Click Configure to set the configuration for Osquery Data.

Currently, Network Visibility Module only allows the sending of Browser Plugins Data using Osquery.You can enable the reporting of browser plugins and also configure the browser plugin report intervals. The Browser Plugins Report Interval is from 1 to 720 hours and is 24 hours by default.

Note	Currently Network Visibility Module is sending Chrome-Based Browsers' Browser Plugins and Firefox Browser Plugins.

Part of the Customer Feedback Module collection provides data about whether Network Visibility Module is installed or not, the number of flows per day, and the DB size.