An introduction to the new Cisco Network Visibility Flow Protocol (nvzFlow)

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 or nvzFlow for 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:

1. Where are the enterprise users accessing SaaS services from and what services are they accessing from a given location?
2. Are they using a company asset or a BYOD device when accessing these services?
3. Did they use an approved application or a potentially vulnerable version of an application?

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:

• User (Mary)
• Device (unmanaged Windows 8.1 laptop)
• Application (approved browser, Firefox version 42)
• Location (local Starbucks)
• Destination (Salesforce.com)

Here are some basic reports that you can build using the rich nvzFlow data 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, each data element must meet the following requirements:

1. Convey information directly related to the five key visibility categories shown above.
2. Be clear, obvious and of high value to an IT administrator.
3. Is useful to analytics, while not requiring the use of analytics (raw-data value).
4. Easily obtainable information across a wide variety of OS and device types.
5. Lightweight and portable (no network, battery or CPU impact; no DPI required; etc.)

There are 3 templates as part of the nvzFlow Protocol:

• Endpoint – Fields that are associated with an Endpoint Device, such as OS Name.
• Interface – Fields associated with the network interface, such as Adapter Name.
• Flow – Fields associated with the flow itself, such as L4 Bytes Out.

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