As recently announced, Cisco AnyConnect 4.2 extends visibility to the endpoint with the Network Visibility Module (NVM). Users are one of the most vulnerable parts of any security strategy, with 78% of organizations saying in a recent survey that a malicious or negligent employee had been the cause of a breach. However, until now, IT Administrators had been blind to user behavior on their devices. NVM allows you to monitor and analyze this rich data to help you defend against potential security threats like data exfiltration and shadow IT, as well as address network operations challenges like application capacity planning and troubleshooting.
AnyConnect NVM supports the Cisco Network Visibility Flow protocol ornvzFlowfor short
(pronounced:en-vizzy-flow). The protocol is designed to provide greater network visibility of endpoints in a lightweight manner by extending standard IPFIX with a small set of high-value endpoint context data. Leading IPFIX vendors have begun implementing the new protocol to provide customers with an unprecedented level of visibility.
Here are some examples of the types of questions an IT Administrator would like to answer:
The nvzFlow protocol allows for an IT administrator to answer these questions as follows:
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.
From the above statement, the 5 key visibility categories are conveyed by the protocol as:
Here are some basic reports that you can build using the richnvzFlowdata set with any IPFIX reporting tool that can support the protocol:
What are the top 15 network applications by downloaded data over the last 24 hours at our enterprise?
What are the top flows by destination domain over UDP in the last 24 hours?
How many different versions of Cisco Jabber are users running in the enterprise?
Also, what destination domains is Cisco Jabber connecting to so I can set appropriate firewall, proxy and split tunneling policies?
The enterprise IT team learned of a recent incident with Fred on his BYOD device. The InfoSec team will need to determine where Fred was when he accessed the network over VPN and what destination domains Fred was connecting to.
As you can see, the protocol offers an impressive set of network visibility context. We have been running some advanced machine learning algorithms in the Office of the Security CTO on a few months of live nvzFlow data from several hundred AnyConnect NVM endpoints. We will share some of our findings in a follow-on blog.
Meanwhile, for those of you who are interested in the details of the protocol, please read on.
nvzFlow IPFIX protocol:
This new protocol was developed by the Office of the Security CTO at Cisco, and is planned to be moved to a standards track in the near future.
In order to be included in the protocol, eachdata elementmust meet the following requirements:
There are 3 templates as part of the nvzFlow Protocol:
The Endpoint and Flow templates are present in the initial release of the AnyConnect Network Visibility Module. Subsequent releases will support the remaining elements of the protocol.
Note that some fields will be present in multiple templates for cross correlation purposes.
These are mandatory fields, while all others can be either anonymized ("-") or not sent at all.
Finally, all string types are encoded in UTF-8 format.
Element ID with/without enterprise bit | 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 ] | nvzFlowModuleHashList | 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. |