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.

Cisco nvzflow support CiscoAnyConnect-logo

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:

  1. Convey information directly related to the five key visibility categories.
    1. User (Mary)
    2. Device (unmanaged Windows 8.1 laptop)
    3. Application (approved browser, Firefox version 42)
    4. Location (local Starbucks)
    5. Destination (Salesforce.com)
  2. Be clear, obvious, and of high value to an IT administrator.
  3. Be 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.)

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.

Justin

Justin Jett is Director of Audit and Compliance at Plixer with roles ranging from system administration of web services to technical product marketing for Plixer’s incident response system, Scrutinizer. Jett, a graduate of the University of Maine at Farmington, is an avid learner of all things security, with a particular interest in TLS and DNS attacks.

Related