Cisco has an amazing set of products like AMP for Endpoints and Cisco Umbrella protecting devices from advanced malware threats.  There were other user and endpoint scenarios that remained unsolved until we introduced the new Cisco Endpoint Security Analytics (CESA) solution that was recently announced.  CESA provides an unprecedented level of endpoint and user networking visibility built on Cisco AnyConnect Network Visibility Module (NVM) endpoint telemetry and Splunk Enterprise.   Underlying the NVM technology is a protocol called nvzFlow (en-vizzy-flow) that I have blogged about in the past. In This Article: Why We Built CESA Working with Great Partners like Splunk and Samsung The Technology Behind CESA Why Did We Build CESA? The CESA solution was originally developed by the Office of the Security CTO and then integrated into Cisco AnyConnect and Splunk products to solve a set of issues for Cisco InfoSec.  Cisco InfoSec realized that getting all the endpoint visibility they needed to perform incident response was a challenge. There were also endpoint security blind spots as more Cisco employees were working off premise and connecting to both enterprise and cloud resources.  They needed a way to collect and store a year of data for analysis of incidents while also getting information in real‑time to see what is happening in the network.  You can read more about the Cisco InfoSec use case in their case study on CESA.  The Office of the Security CTO looks at current and future customer problems that are not being solved by existing technology and then come up with ideas on how to solve them.  My fellow coinventors, Andrew Zawadowskiy and Donovan O’Hara from the CTO Advanced Development team built the initial Proof of Concept and then worked on the final product release with the AnyConnect development team.     As we thought about ways to solve the problems Cisco InfoSec was facing, we wanted to do it in a way that built on standards technology so that not only could Cisco Stealtwatch and Cisco Tetration support it, but also provide an ecosystem for key partners to participate.  This is why we chose to build on IPFIX.  It is the perfect protocol to build the enhanced  context found in nvzFlow.  What do we mean by "Enhanced Context"? The 5 key endpoint visibility categories conveyed by the protocol or "Enhanced Context" are: User Device Application Location Destination At the end of the blog will be a helpful table to show you details of the enhanced context that is provided. Working with Great Partners like Splunk and Samsung One of the key features of CESA is Splunk Enterprise, which performs the analytics and alerting on the NVM telemetry, turning it into actionable events. The new CESA Built on Splunk product, available exclusively from Cisco, provides a Splunk package customized and priced specifically for analyzing NVM telemetry.  Cisco InfoSec has been using the CESA solution for over two years now.  As noted earlier, you can read more about it in their Case Study.  Spunk Enterprise is a fantastic tool.  It was really easy for us to take the Cisco AnyConnect NVM data and not only import it into Splunk, but to also quickly create a high value set of dashboards and reports from the data.   There are two components in the Splunk store that make up the solution: Cisco AnyConnect Network Visibility Module (NVM) App for Splunk and Cisco NVM Technology Add-on for Splunk.  Because NVM produces so much high value data, Splunk created a special per-endpoint license available exclusively from Cisco that makes budgeting predictable and saves you money.  We also put together a helpful deployment guide to get you going. Below is an example of the dozens of reports available in the AnyConnect NVM Splunk Dashboard. As you can see the solution provides visibility into what applications are connecting to what domains and how much data is being transmitted/received. From there, you can then drill down on the specific application and obtain finer grained details including the SHA256 hash of the process, the names of domains and IP addresses it connected to, what account it is running under, etc.  Just click on the specific element and it will take you to an investigation page for that observable. You can easily integrate your favorite investigation tools right into the Splunk Enterprise dashboards.  For example, you can pivot from a DNS domain name observable into Cisco Umbrella, Talos Intelligence or Cisco Threat Response with just a couple lines of HTML.  This will allow you to obtain a threat disposition on the domain. Similarly, you can take the SHA256 hash observable and pivot right into AMP for Endpoints, ThreatGrid or Cisco Threat Response.  This will allow you to obtain a threat disposition on the binary. We’ve provided those integrations for you in the default dashboards. You can easily add more just by editing them to include your favorite tools.  Let us know if there is anything else that would be useful in the default screens. Samsung has been another excellent partner from the start.  We have worked with them closely on their Knox program for a number of years with AnyConnect integrations and neat features like per-app VPN.  When we explained to them what we wanted to do with Cisco AnyConnect NVM, they were excited to help and developed the Network Platform Analytics (NPA) framework to make it possible.  It is the only framework available on mobile platforms to support Cisco AnyConnect NVM.  The best part is that you can enable and provision this capability using your favorite Enterprise Mobility Management (EMM) solution – no special device-mode needed!  Keep an eye out for a forthcoming quick‑start guide on this technology.  NVM is also available on Windows, MacOS and Linux platforms. Those are some of the high points of the CESA Built on Splunk solution.  If you’d like to get into further technical details on the solution architecture and NVM telemetry itself, see below. Deep Dive into the Technology Behind CESA Here is a high-level overview of the components that make up the CESA solution: Now let’s take a deeper dive at the awesome visibility data you get from AnyConnect NVM and the nvzFlow protocol.  Below is a table that describes all of the rich visibility data that accompanies the IPFIX network flow information. 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. 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 [one-way hash] or not sent at all. Name Description       *all string values are encoded in UTF-8 format Template Member E = Endpoint, I = Interface, F = Per Flow (M) = Mandatory nvzFlowUDID 20 byte Unique Device ID that identifies the endpoint. E, I, F (M)   nvzFlowLoggedInUser This is the logged in user on the physical device in the form Authority\Principle. E.g., ACME\JSmith or <machine>\JSmith   I nvzFlowOSName Name of the operating system. E.g., Windows, Mac OS X   E nvzFlowOSVersion Version of the operating system. E.g., 5.0.2195 or 10.10   E nvzFlowSystemManufacturer Name of the manufacturer. E.g., Lenovo   E nvzFlowSystemType Type of the system. E.g., x86 or x64 E nvzFlowProcessAccount Authority\Principle of the process associated with the flow. E.g., ACME\JSmith or <machine>\JSmith   F nvzFlowParentProcessAccount Authority\Principle of the parent of the process associated with the flow. E.g., ACME\JSmith or <machine>\JSmith F nvzFlowProcessName Name of the process associated with the flow. E.g., firefox.exe F nvzFlowProcessHash SHA256 hash of the process image on disk associated with the flow. F nvzFlowParentProcessName Name of the parent of process associated with the flow. E.g., explorer.exe F nvzFlowParentProcessHash SHA256 hash of the process image on disk of the parent process associated with the flow. F nvzFlowDNSSuffix Per-interface DNS suffix configured on the adapter associated with the flow for the endpoint. E.g., cisco.com F   nvzFlowDestinationHostname The FQDN (hostname) that resolved to the destination IP on the endpoint. E.g., mail.google.com   F nvzFlowL4ByteCountIn Total number of incoming bytes on the flow at Layer4 (Transport). [payload only, without L4 headers] F nvzFlowL4ByteCountOut Total number of outgoing bytes on the flow at Layer4 (Transport). [payload only, without L4 headers] F nvzFlowOSEdition The OS Edition, such as Windows 10 Enterprise   E nvzFlowModuleNameList 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. F nvzFlowModuleHashList List of 0 or more SHA256 hashes of the modules associated with the nvzFlowModuleNameList F nvzFlowCoordinatesList 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. F nvzFlowInterfaceInfoUID   Unique ID for an interface meta-data. Should be used to lookup the interface meta-data from the InterfaceInfo records.   F, I (M) nvzFlowInterfaceIndex The index of the Network interface as reported by the OS.   I nvzFlowInterfaceType Interface Type, such as Wired, Wireless, Cellular, VPN, Tunneled, Bluetooth, etc.  Enumeration of network types as defined below.   I nvzFlowInterfaceName Network Interface/Adapter name as reported by the OS. I nvzFlowInterfaceDetailsList List of name value pair (delimited by ‘=') of other interface attributes of interest. E.g., SSID=internet. I nvzFlowInterfaceMacAddress Mac address of the interface.   I nvzFlowLoggedInUserAccountType Account type of the logged-in user. As per the enumeration of AccountType as defined below.   F nvzFlowProcessAccountType Account type of the process account. As per the enumeration of AccountType as defined below.   F nvzFlowParentProcessAccountType Account type of the parent-process account. As per the enumeration of AccountType as defined below.   F virtualStationName Standard IPFIX Element 350 is populated with the configured device/computer name. For example, Jane-Doe-WinPC.   E   Enumeration Types   AccountType All Platforms Unknown – 0x0000 Domain User – 0x8000  (Mask. 16 th  bit set for Domain user. Eg., a Domain-user administrator will have 0x8002 as the type). Windows Standard User – 0x0001,  Admin User – 0x0002,  Guest User – 0x0003 Not Elevated – 0x4000 (BitMask. 15 th  bit is set for users who are admins, but not UAC’ed yet. Eg., an admin user that hasn’t elevated shall have an AccountType of 0x4002) Elevated – 0x2000 (BitMask. 14 th bit is set for users who are admins and are currently running in elevated mode) Mac/Linux Standard User – 0x0001, Root user – 0x0004   Not Elevated – 0x4000 (BitMask. 15 th  bit is set for sudo’ers who aren’t root yet. Standard users who have sudo privilege but not yet elevated into root, shall have an AccountType of 0x4001)   Elevated – 0x2000 (BitMask. 14 th bit is set for sudo’ers users who are currently running in elevated mode as root) Bit Mapping for AccountTypes 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 Domain User Bit Not Elevated Bit Elevated Bit Reserved for future bit-masks Specific AccountType values   InterfaceType 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 – NFC, 11 – Cellular, 15 – Unknown/Unspecified   Here is what would be included in an IPv6 nvzflow record IPv6 Per-Flow Data Template (v3 ID: 268, v2-only ID: 264)   protocolIdentifier (IPFIX standard information element : 4) (MANDATORY) sourceIPv6Address (IPFIX standard information element : 27) (MANDATORY) sourceTransportPort (IPFIX standard information element : 7) (MANDATORY) destinationIPv6Address (IPFIX standard information element : 28) (MANDATORY) destinationTransportPort (IPFIX standard information element : 11) (MANDATORY) flowStartSeconds (IPFIX standard information element : 150) (MANDATORY) flowEndSeconds (IPFIX standard information element : 151) (MANDATORY) nvzFlowUDID (MANDATORY) nvzFlowLoggedInUser nvzFlowLoggedInUserAccountType (v3) nvzFlowProcessAccount nvzFlowProcessAccountType (v3) nvzFlowProcessName nvzFlowProcessHash nvzFlowParentProcessAccount nvzFlowParentProcessAccountType (v3) nvzFlowParentProcessName nvzFlowParentProcessHash nvzFlowL4ByteCountIn nvzFlowL4ByteCountOut nvzFlowDNSSuffix nvzFlowDestinationHostname nvzFlowInterfaceInfoUID (MANDATORY – v2) nvzFlowModuleNameList (v2) nvzFlowModuleHashList (v2) nvzFlowCoordinatesList (v2)   Data Model and Correlation IDs The following graphic shows the data model of the nvzFlow 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. If you have any questions about the underlying technology post them below in the comments.   Let us know what you think of the new CESA solution too! ... View more