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

 NameData 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 ]
nvzFlowParentProcessHashoctetArray / defaultSHA256 hash of the process image on disk of the parent process associated with the flow.
45112 / 12344
[ F ]
nvzFlowDNSSuffixstring / defaultPer-interface DNS suffix configured on the adapter associated with the flow for the endpoint. E.g., cisco.com
45113 / 12345
[ F ]
nvzFlowDestinationHostnamestring / defaultThe FQDN (hostname) that resolved to the destination IP on the endpoint. E.g., www.google.com
45114 / 12346
[ F ]
nvzFlowL4ByteCountInunsigned64 / 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 ]
 nvzFlowCoordinatesListbasicList of octetArray / defaultList 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 / identifierUnique ID for an interface meta-data. Should be used to lookup the interface meta-data from the InterfaceInfo records.
45124 / 12356
[ I ]
 nvzFlowInterfaceIndexunsigned32 / default The index of the Network interface as reported by the OS.
 45125 / 12357
[ I ]
 nvzFlowInterfaceTypeunsigned8 / 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 / defaultNetwork Interface/Adapter name as reported by the OS.
 45127 / 12359
[ I ]
 nvzFlowInterfaceDetailsListbasicList 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