Last month Cisco announced “Deeper visibility and control over endpoints and network access” via AnyConnect 4.2. It does this by using the new Cisco Network Visibility Flow Protocol (nvzFlow). The new nvzFlow (pronounced “en-vizzy-flow“) has some excellent details. Today, I’d like to outline a few of the advantages of nvzFlow support that we recently added to our IPFIX collection system.
With nvzFlow, IT administrators can now answer more of the unknowns about the traffic happening on their network from unmanaged devices. For example, most IT admins want to know where users are accessing SaaS services. In addition, most would want to know what services are being accessed from a given location. Knowing if the device is company-owned or BYOD is also important, as is determining if an approved version of an application was being used to access various services.
nvzFlow produces answers to these questions with great detail. According to Cisco, IT managers can easily learn that “Mary visited Salesforce.com from an unmanaged Windows 8.1 laptop using a company approved browser, Firefox version 42, while she was connected on her local Starbucks’ Wi-Fi network.”
What’s great about these metrics is that in order to be included in the nvzFlow IPFIX protocol, the data elements must meet five requirements outlined by Cisco:
- Convey information directly related to the five key visibility categories.
- User (Mary)
- Device (unmanaged Windows 8.1 laptop)
- Application (approved browser, Firefox version 42)
- Location (local Starbucks)
- Destination (Salesforce.com)
- Be clear, obvious, and of high value to an IT administrator.
- Be useful to analytics, while not requiring the use of analytics (raw-data value).
- Easily obtainable information across a wide variety of OS and device types.
- Lightweight and portable (no network, battery or CPU impact; no DPI required; etc.)
This means that you should have minimal network performance problems when sending these details in your flow datagrams. The only problem you may face now would be a NetFlow/IPFIX collector that can’t report on these new metrics. Most state-of-the-art collectors, though, will provide options for these types of reports.
I’ve included a list of the elements that Cisco supplied for reference. As you can see, the elements are quite remarkable, especially for gaining insight into remote employees traffic details.
| Element ID with/without enterprise bit
Template Member E = Endpoint I = Interface F = Per Flow (M) = Mandatory |
Name | Data Type/
Data Type Semantics |
Description |
| 45100 / 12332 [ E, I, F (M) ] |
nvzFlowUDID | octetArray / Identifier | 20 byte Unique ID that identifies the endpoint. |
| 45101 / 12333 [ E ] |
nvzFlowLoggedInUser | string / default | This is the logged in user on the device, in the form Authority\Principle. This is different from userName (id: 371), which is user associated with the flow. |
| 45102 / 12334 [ E ] |
nvzFlowOSName | string / default | Name of the operating system. E.g., Windows, Mac OS X |
| 45103 / 12335 [ E ] |
nvzFlowOSVersion | string / default | Version of the operating system. E.g., 5.0.2195 or 10.10 |
| 45104 / 12336 [ E ] |
nvzFlowSystemManufacturer | string / default | Name of the manufacturer. E.g., Lenovo |
| 45105 / 12337 [ E ] |
nvzFlowSystemType | string / default | Type of the system. E.g., x86 or x64 |
| 45106 / 12338 [ F ] |
nvzFlowProcessAccount | string / default | Authority\Principle of the process associated with the flow. E.g., ACME\JSmith, <machine>\JSmith |
| 45107 / 12339 [ F ] |
nvzFlowParentProcessAccount | string / default | Authority\Principle of the parent of the process associated with the flow. E.g., ACME\JSmith, <machine>\JSmith |
| 45108 / 12340 [ F ] |
nvzFlowProcessName | string / default | Name of the process associated with the flow. E.g., firefox.exe |
| 45109 / 12341 [ F ] |
nvzFlowProcessHash | octetArray / default | SHA256 hash of the process image on disk associated with the flow. |
| 45110 / 12342 [ F ] |
nvzFlowParentProcessName | string / default | Name of the parent of process associated with the flow. E.g., explorer.exe |
| 45111 / 12343 [ F ] |
nvzFlowParentProcessHash | octetArray / default | SHA256 hash of the process image on disk of the parent process associated with the flow. |
| 45112 / 12344 [ F ] |
nvzFlowDNSSuffix | string / default | Per-interface DNS suffix configured on the adapter associated with the flow for the endpoint. E.g., cisco.com |
| 45113 / 12345 [ F ] |
nvzFlowDestinationHostname | string / default | The FQDN (hostname) that resolved to the destination IP on the endpoint. E.g., www.google.com |
| 45114 / 12346 [ F ] |
nvzFlowL4ByteCountIn | unsigned64 / totalCounter | Total number of incoming bytes on the flow at Layer4 (Transport). [payload only, without L4 headers] |
| 45115 / 12347 [ F ] |
nvzFlowL4ByteCountOut | unsigned64 / totalCounter | Total number of outgoing bytes on the flow at Layer4 (Transport). [payload only, without L4 headers] |
| v2 fields | |||
| 45119 / 12351 [ E ] |
nvzFlowOSEdition | string / default | The OS Edition, such as Windows 8.1 Enterprise Edition |
| 45120 / 12352 [ F ] |
nvzFlowModuleNameList | basicList of string / default | List of 0 or more names of the modules hosted by the process that generated the flow. This can include the main DLLs in common containers such as dllhost, svchost, rundll32, etc. It can also contain other hosted components such as the name of the jar file in a JVM. |
| 45121 / 12353 [ F ] |
nvzFlowCoordinatesList | basicList of octetArray / default | List of 0 or more SHA256 hashes of the modules associated with the nvzFlowModuleNameList |
| 45122 / 12354 [ F ] |
nvzFlowCoordinatesList | basicList of float32 / default | List of 32bit floating point values representing Accuracy, Latitude, Longitude, [Altitude] respectively. Altitude is optional. Coordinate based location information such as GPS, Wi-Fi Approximation, etc., Accuracy in meters – defines the error margin. |
| 45123 / 12355 [ F, I (M) ] |
nvzFlowInterfaceInfoUID | unsigned32 / identifier | Unique ID for an interface meta-data. Should be used to lookup the interface meta-data from the InterfaceInfo records. |
| 45124 / 12356 [ I ] |
nvzFlowInterfaceIndex | unsigned32 / default | The index of the Network interface as reported by the OS. |
| 45125 / 12357 [ I ] |
nvzFlowInterfaceType | unsigned8 / default | Interface Type, such as Wired, Wireless, Cellular, VPN, Tunneled, Bluetooth, etc. Enumeration of network types, defined by this spec. |
| 45126 / 12358 [ I ] |
nvzFlowInterfaceName | string / default | Network Interface/Adapter name as reported by the OS. |
| 45127 / 12359 [ I ] |
nvzFlowInterfaceDetailsList | basicList of string / default | List of name value pair (delimited by ‘=’) of other interface attributes of interest. E.g., SSID=internet. |
Source: Cisco Blogs
If you have any questions about getting these new elements from your NetFlow/IPFIX exports, please reach out to our support team.