You can use NVM 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 three syslog data sources: per flow, endpoint identity, and interface info, 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:

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 Stealthwatch 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 Stealthwatch applications, refer to the Stealthwatch Enterprise Endpoint License and NVM Configuration Guide. If TND is configured in the NVM profile, then the trusted network detection is done by NVM 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 TND use. When configuring TND directly in the NVM profile, an administrator-defined trusted server and certificate hash determine whether the user is on a trusted or untrusted network. Administrators configuring TND for the core VPN profile would alternatively configure the Trusted DNS Domains and Trusted DNS Servers in the core VPN profile: AnyConnect Profile Editor, Preferences (Part 2).

• Desktop or Mobile—Determines whether you are setting up NVM on a desktop or mobile device. Desktop is the default. Mobile will be supported in the future.

• 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.

  • Secure—Determines if you want NVM to securely send data to the collector over DTLS. When this checkbox is checked, NVM uses DTLS for transport. The DTLS connection requires that the DTLS server (collector) certificate is trusted by the endpoint. Any untrusted certificates are silently rejected.

    The collector as part of the CESA Splunk App v3.1.0 is required for DTLS support, and DTLS 1.2 is the minimum supported version.

• 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, NVM 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 check box 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 AnyConnect release is opened in a later AnyConnect 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, NVM 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 NVM had no Data Collection Policy or had an include Data Collection Policy. If the profile in the older version of NVM had an exclude Data Collection Policy, and the profile was opened and saved with the newer 4.9 version profile editor. If the profile in the older version of NVM had an exclude Data Collection Policy but the profile was not opened and saved with the newer 4.9 version profile editor, then these four fields are included. If NVM 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.

      For AnyConnect release 4.4 (and later), you can now 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, and they are 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 applies for Knox Container traffic also, unless a separate Knox Container Data Collection policy is specified. To add or remove Data Collection Policies, see 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 NVM is configured. The remote user does not have a choice to decline NVM activities. The network administrator controls NVM using MDM facilities.

• Export on Mobile Network (Optional and Mobile Specific)—Specifies whether the exporting of NVM 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 an AnyConnect Android application. If you uncheck the Export on Mobile Network checkbox, NVM flows are not exported when the device is using a mobile network, and an end user cannot change that.

• Trusted Network Detection—This feature detects if an endpoint is physically on the corporate network. The network state is used by NVM to determine when to export NVM 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, TND 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.

  If TND is not configured in the NVM profile and the VPN module is installed, then NVM uses the TND feature of VPN to determine if the endpoint is in a trusted network. TND configuration in the NVM profile editor includes the following:

  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.

Save the profile as NVM_ServiceProfile.xml. You must save the profile with this exact name or NVM 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 NVM 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

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