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:

Where are the enterprise users accessing SaaS services from and what services are they accessing from a given location?

Are they using a company asset or a BYOD device when accessing these services?

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:

Convey information directly related to the five key visibility categories shown above.

Be clear, obvious and of high value to an IT administrator.

Is 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.)

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.