Cisco Network Visibility Flow Protocol Specification

Transcription

1 Cisco Network Visibility low Protocol Specification This document contains the protocol specification for the Cisco Network Visibility low (nvzlow for short). This document is property of Cisco Systems, Inc. and is shared under NDA

2 Table of Contents Introduction... 3 Design Goals... 3 Cisco Network Visibility low (nvzlow) Information Elements... 4 Endpoint Exporter IPIX / nvzlow Templates... 6 Endpoint Identity Template (ID 262)... 6 Interface Info Template (ID 265)... 6 IPv4 Per-low Data Template (ID 263)... 7 IPv6 Per-low Data Template (ID 264)... 8 Data Model and Correlation IDs... 9 Implementation Considerations uture Considerations References... 11

3 Introduction This document defines the new IPIX Informational Elements that Cisco Network Visibility low (nvzlow) adds to IPIX (RC ). These data types carry information that is useful for providing better visibility of the endpoint in a network. The new information elements are defined using the abstract data types defined by IPIX (RC 7012, Section 3.1). Design Goals Cisco Network Visibility low, or nvzlow (pronounced: en- vizzy- flow) is designed to provide greater network visibility of endpoints in a lightweight manner. The protocol extends IPIX to include a small set of high- value data in order to convey the following: Mary visited Salesforce.com from an unmanaged Windows laptop using a company approved browser, while she was connected on her local Starbucks Wi- i network. The 5 key visibility categories conveyed by the protocol are: User Device Application Location Destination 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 (minimal network, battery or CPU impact; no DPI required; etc.)

4 Cisco Network Visibility low (nvzlow) Information Elements The following table identifies the new Information Elements in the same format as the standard Information Elements defined in All string values shall be encoded in UT- 8. Element IDs below are shown with and without the Enterprise Bit being set. There are 3 templates as part of the nvzlow Protocol: Endpoint ields that are associated with an Endpoint Device, such as OS Name. Interface ields associated with the network interface, such as Adapter Name. low ields associated with the flow itself, such as L4 Bytes Out. 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. Element ID with/without enterprise bit Name Data Type Data Type Semantics Description / nvzlowudid octetarray identifier 20 byte Unique ID that identifies the endpoint. Template Member E = Endpoint, I = Interface, = Per low (M) = Mandatory E, I, (M) / nvzlowloggedinuser string default This is logged in user on the device, in E the form Authority\Principle. This is different from username (id: 371), which is user associated with the flow / nvzlowosname string default Name of the operating system. E E.g., Windows, Mac OS X / nvzlowosversion string default Version of the operating system. E E.g., or / nvzlowsystemmanufacturer string default Name of the manufacturer. E E.g., Lenovo / nvzlowsystemtype string default Type of the system. E.g., x86 or x64 E / nvzlowprocessaccount string default Authority\Principle of the process associated with the flow. E.g., ACME\JSmith, <machine>\jsmith / nvzlowparentprocessaccount string default Authority\Principle of the parent of the process associated with the flow. E.g., ACME\JSmith, <machine>\jsmith / nvzlowprocessname string default Name of the process associated with the flow. E.g., firefox.exe / nvzlowprocesshash octetarray default SHA256 hash of the process image on disk associated with the flow / nvzlowparentprocessname string default Name of the parent of process associated with the flow. E.g., explorer.exe / nvzlowparentprocesshash octetarray default SHA256 hash of the process image on disk of the parent process associated with the flow.

5 45112 / nvzlowdnssuffix string default Per- interface DNS suffix configured on the adapter associated with the flow for the endpoint. E.g., cisco.com / nvzlowdestinationhostname string default The QDN (hostname) that resolved to the destination IP on the endpoint. E.g., / nvzlowl4bytecountin unsigned64 totalcounter Total number of incoming bytes on the flow at Layer4 (Transport). [payload only, without L4 headers] / nvzlowl4bytecountout unsigned64 totalcounter Total number of outgoing bytes on the flow at Layer4 (Transport). [payload only, without L4 headers] v2 fields / nvzlowstring string default Generic UT- 8 string info- element for (sent as part of a list) lists / nvzlowloat32 float32 default Generic float32 info- element for lists (sent as part of a list) / nvzlowoctetarray octetarray default Generic octetarray info- element for (sent as part of a list) lists / nvzlowosedition string default The OS Edition, such as Windows 8.1 Enterprise Edition E / nvzlowmodulenamelist basiclist of nvzlowstring / nvzlowmodulehashlist basiclist of nvzlowoctetarray / nvzlowcoordinateslist basiclist of nvzlowloat32 default default 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. List of 0 or more SHA256 hashes of the modules associated with the nvzlowmodulenamelist List of 32bit floating point values representing Accuracy, Latitude, Longitude, [Altitude] respectively. Altitude is optional. Coordinate based location information such as GPS, Wi- i Approximation, etc., Accuracy in meters defines the error margin / nvzlowinterfaceinfouid unsigned32 identifier Unique ID for an interface meta- data. Should be used to lookup the interface meta- data from the InterfaceInfo records / nvzlowinterfaceindex unsigned32 default The index of the Network interface as reported by the OS / nvzlowinterfacetype unsigned8 default Interface Type, such as Wired, Wireless, Cellular, VPN, Tunneled, Bluetooth, etc. Enumeration of network types, defined by this spec / nvzlowinterfacename string default Network Interface/Adapter name as reported by the OS / nvzlowinterfacedetailslist basiclist of nvzlowstring default List of name value pair (delimited by =') of other interface attributes of interest. E.g., SSID=internet., I (M) I I I I

6 Endpoint Exporter IPIX / nvzlow Templates An endpoint client exporter, such as Cisco AnyConnect NVM, sends IPIX / Network Visibility low (nvzlow) records based on the following templates. The template section lists the Information Elements in each template. All fields can be anonymized ( - ) or completely absent unless indicated as MANDATORY. There are two revisions of the protocol. Version 2 (additional) elements are marked v2. Endpoint Identity Template (ID 262) The Endpoint Identity Template shall have the following Information Elements. virtualstationname (IPIX standard information element : 350) nvzlowudid (MANDATORY) nvzlowosname nvzlowosversion nvzlowsystemmanufacturer nvzlowsystemtype nvzlowosedition (v2) Interface Info Template (ID 265) Interface Info template records identify each interface instance on the endpoint. Any change in to interface attributes should trigger a new Interface Info record to be sent with corresponding details. Each record (not just an interface) is distinctively identified by a unique ID nvzlowinterfaceinfouid. Each Interface Info record shall have the following information elements: nvzlowudid (MANDATORY) nvzlowinterfaceinfouid (MANDATORY v2) nvzlowinterfaceindex (v2) nvzlowinterfacetype (v2) nvzlowinterfacename (v2) nvzlowinterfacedetailslist (v2) The exporter is expected to send the interface info record with a new UID if any of the attributes changes for an interface or for a new interface. E.g., if the same Wi- i interface connects to a new SSID. The UID is expected to be unique on a given endpoint. InterfaceType has the following values: 1 Wired Ethernet, 2 Wireless (802.11), 3 Bluetooth, 4 Token Ring, 5 ATM (Slip), 6 PPP, 7 Tunnel (generic), 8 VPN, 9 Loopback, 10 NC, 11 Cellular, 15 Unknown/Unspecified

7 IPv4 Per- low Data Template (ID 263) The Per- low Data Template (IPv4) shall have the following Information Elements: protocolidentifier (IPIX standard information element : 4) (MANDATORY) sourceipv4address (IPIX standard information element : 8) (MANDATORY) sourcetransportport (IPIX standard information element : 7) (MANDATORY) destinationipv4address (IPIX standard information element : 12) (MANDATORY) destinationtransportport (IPIX standard information element : 11) (MANDATORY) flowstartseconds (IPIX standard information element : 150) (MANDATORY) flowendseconds (IPIX standard information element : 151) (MANDATORY) nvzlowudid (MANDATORY) nvzlowloggedinuser nvzlowprocessaccount nvzlowprocessname nvzlowprocesshash nvzlowparentprocessaccount nvzlowparentprocessname nvzlowparentprocesshash nvzlowl4bytecountin nvzlowl4bytecountout nvzlowdnssuffix nvzlowdestinationhostname nvzlowinterfaceinfouid (MANDATORY v2) nvzlowmodulenamelist (v2) nvzlowmodulehashlist (v2) nvzlowcoordinateslist (v2)

8 IPv6 Per- low Data Template (ID 264) The Per- low Data Template (IPv6) shall have the following Information Elements. protocolidentifier (IPIX standard information element : 4) (MANDATORY) sourceipv6address (IPIX standard information element : 27) (MANDATORY) sourcetransportport (IPIX standard information element : 7) (MANDATORY) destinationipv6address (IPIX standard information element : 28) (MANDATORY) destinationtransportport (IPIX standard information element : 11) (MANDATORY) flowstartseconds (IPIX standard information element : 150) (MANDATORY) flowendseconds (IPIX standard information element : 151) (MANDATORY) nvzlowudid nvzlowloggedinuser nvzlowprocessaccount nvzlowprocessname nvzlowprocesshash nvzlowparentprocessaccount nvzlowparentprocessname nvzlowparentprocesshash nvzlowl4bytecountin nvzlowl4bytecountout nvzlowdnssuffix nvzlowdestinationhostname nvzlowinterfaceinfouid (MANDATORY v2) nvzlowmodulenamelist (v2) nvzlowmodulehashlist (v2) nvzlowcoordinateslist (v2)

9 Data Model and Correlation IDs The following graphic shows the data model of the nvzlow protocol and how the different correlation IDs are used to associate the different data collections. A collector will likely store 3 sets of data records, one for each collection of data. Analytics and reporting will correlate the 3 sets of data using the UDID as the key across the data sets. Additionally, for interface information, a correlation from the flow record to the interface information record will be done using the Interface UID.

10 Implementation Considerations There are a number of considerations that should be evaluated as part of a solution implementation. Of particular note is data retention and data suppression by an exporter. or example, an exporter should have some means of securely preserving data when it is unable to communicate with the collector (such as when an endpoint is not on the network where the collector is located). Additionally, configurable protocol suppression should be considered for the endpoint exporter. Of particular note is broadcast and multicast traffic as this can be significant. An implementation should allow for the ability to also limit the export of any field that is not marked as mandatory if an administrator so chooses. Anonymization can be done at either the exporter or collector. Note that exporter anonymization would mean that the data will never be recoverable, whereas collector anonymization can preserve the data for forensic needs while still meeting privacy requirements. Exporter anonymization should be done by either excluding the field or sending an empty field with no data or alternatively using an indicative data element, such as ( - ) for a string, to convey it was anonymized. Traffic that is bound to localhost should not be of consideration, unless some local network proxy function, on that endpoint, results in aggregation of flows. or example, a web security proxy running on the endpoint that binds web traffic flows to localhost for redirection to a cloud proxy, might be of interest for a local exporter implementation to consider. Performance impact should be a top consideration. In particular, when collecting and storing data locally or when sending bulk records that were previously stored on an endpoint. An exporter should act as a background service with low CPU and memory utilization. A collector should leverage lightweight hooking technologies and avoid approaches such as packet capture facilities so as to minimize system impact and reduce incompatibilities. Additionally, the exporter should throttle sending of cached records so as to not impact the normal network operation of a device. Caching limits should also be used to minimize impact on an endpoint device in terms of both storage and battery consumption. uture Considerations There are a number of future considerations for the nvzlow protocol. The following are some possible items that will be considered in the near future: Compressed IPIX records Because the nvzlow data set could exceed a single UDP packet, a future implementation might specify a template containing a single element that encapsulates a normal nvzlow flow record in a compressed payload. A collector would first identify the record as containing the single type nvzlowcompressedrecord and then expand that single payload into one of the nvzlow template payloads described above. IPIX over DTLS Endpoints may be in places in the network where integrity, authenticity and privacy are a concern. As such, it is recommended that an exporter and collector support sending and receiving nvzlow IPIX records over DTLS (with the ability to fallback to TLS when DTLS is not possible due to network, firewall or proxy restrictions).

11 Additional Exporter ormats In addition to IPIX, additional formats may be added, such as binary- JSON over HTTPs, to allow for a broader ecosystem of collector technologies. References 1. IP low Information Export (IPIX) Entities [ 2. Specification of the IP low Information Export (IPIX) Protocol for the Exchange of low Information [ 3. Information Model for IP low Information Export (IPIX) [ 4. Exporting Type Information for IP low Information Export (IPIX) Information Elements [ End of document - - -