What is pxGrid?

Cisco Platform Exchange Grid (pxGrid) enables multivendor, cross-platform network system collaboration among parts of the IT infrastructure such as security monitoring and detection systems, network policy platforms, asset and configuration management, identity and access management platforms, and virtually any other IT operations platform. When business or operational needs arise, ecosystem partners use pxGrid to exchange contextual information with Cisco products that support pxGrid.

Cisco pxGrid provides a unified framework that enables ecosystem partners to integrate to pxGrid once, then share context either unidirectionally or bidirectionally with many platforms without the need to adopt platform-specific APIs. pxGrid is secure and customizable, enabling partners to share only what they want to share and consume only context relevant to their platform.

Key features of pxGrid include:

• Ability to control what context is shared and with which platforms: Because pxGrid is customizable, partners can "publish" only the specific contextual information they want to share and can control the partner platform that information gets shared with.

• Bidirectional context sharing: pxGrid enables platforms to both share or publish context as well as consume or "subscribe to" context from specific platforms. These features are orchestrated and secured by the pxGrid server.

• Ability to share context data in native formats: Contextual information shared via pxGrid is done in each platform's native data format.

• Ability to connect to multiple platforms simultaneously: pxGrid enables platforms to publish only the context data relevant to partner platforms. Numerous context topics may be customized for a variety of partner platforms, yet always shared via the same reusable pxGrid framework. Furthermore, only sharing relevant data enables both publishing and subscribing platforms to scale their context sharing by eliminating excess, irrelevant data.

• Integration with Cisco platforms: pxGrid provides a unified method of publishing or subscribing to relevant context with Cisco platforms that utilize pxGrid for third party integrations.

Concepts

Architecture

At the heart of pxGrid is a server and participating nodes as shown in the pxGrid architecture overview.

Nodes typically reside on separate hosts, but within the same network. Nodes can connect to any of the pxGrid servers in a cluster, which is typically a 2-node cluster. Each node goes through authentication, registration, and authorization to communicate over pxGrid. Each node establishes itself as a provider or consumer of capabilities, which are information channels or topics for sharing contextual information. The pxGrid server provides message routing and control based on the context data being shared and a participating node's authorization. Queries, notification, and bulk download of the context data is supported. For bulk download, depending on the context, pxGrid can establish an out-of-band channel.

Nodes don't communicate directly with pxGrid. Instead, nodes make programmatic calls to the Grid Client Library (GCL) that in turn connects and communicates with pxGrid. Currently, Java and C/C++ versions of the GCL are available. Support for other languages is expected shortly. Check with your Cisco contact for details.

Depending on the use case, one deployment may only have a few nodes, while others may have thousands. pxGrid is designed to scale upward.

Model

A model must be specified such that nodes speak a common language. Cisco has developed the identity model to be used in the context of security products, supported by the Identity Services Engine (ISE). The identity model will look very different from a model used in a different context. However, all models extend core elements provided by pxGrid. A model defines one or more entities, relationships between entities, and interfaces for invoking functionality. The identity model defines entities such as Session, User, and PostureAssessment as these concepts relate to the identity services space. It further establishes that a Session contains one User and one or more PostureAssessments. A model also defines one or more interfaces. Interfaces establish a contract between a consumer and a provider of information. The identity model defines interfaces such as getSessionByIPAddress and getSessionByMacAddress.

An information channel or topic for sharing contextual information is referred to as a capability. A model defines the capability, context data and interfaces or operations allowed on the capability. A model can define multiple capabilities. In the identity model, the session directory capability consists of interfaces for consuming information related to session logins in a network.

Communication

With a model in place, pxGrid enables communication between pxGrid nodes. Nodes can be both providers and consumers of capabilities. As the provider of a capability, a node handles queries, generates notifications, or both. As the consumer of a capability, a node initiates queries, receives notifications, or both. The figure below shows the anatomy of a pxGrid node and breaks down a node's communication capabilities.

Node Registration

Before a node can communicate with pxGrid, it needs to be registered in pxGrid. pxGrid allows auto registration of nodes based on certificates. When a pxGrid node connects to pxGrid the first time, the node is registered and allowed to communicate over pxGrid if the certificates are valid. The access level of the pxGrid node is governed by the authorization group that the node is part of. pxGrid also supports restricted manual registration mode wherein each new node must be approved by an administrator and assigned an authorization group to communicate over pxGrid. Once a node is registered, it is allowed to be a provider or consumer of a capability only if it has the required authorization for that capability.

Auto registration mode can be used if the deployment is a secure or closed deployment. In an open deployment where security is a concern, manual node registration mode is recommended.

Query

A query is a synchronous call initiated by a consumer and serviced by a provider. Using the GCL, the consumer utilizes a query caller to initiate the communication. The provider implements a query handler to programmatically process requests and generate responses. pxGrid passes the request through the consumer GCL and into the provider GCL, likely on another node in the network. Using custom code implemented by the developer in a query handler, the provider generates a response that pxGrid then sends back to the consumer. The consumer waits until the response is received.

Notification

A notification is an asynchronous message generated by a provider and received by a consumer. The consumer must first register interest in a topic of information. Using messaging terminology, consumers subscribe to a topic and providers publish to the topic. The GCL handles communication with pxGrid so the consumers and providers can focus on writing code to consume and provide the information. Unlike in the query flow, consumers do not wait for information. The GCL uses a separate thread to invoke a notification handler supplied by the consumer. The figure below details the flow.

Integrating with pxGrid

pxGrid provides the necessary libraries for developers to integrate their nodes with the pxGrid server. The figure below shows the high-level relationship between pxGrid, the GCL, the model for a particular domain, and custom code written by the developer. The model, as discussed earlier, consists of entities and interfaces common to the domain (security, for example). Interface implementation refers to the actual functionality for how a node will behave. The developer extends this model's interfaces and uses existing classes in the GCL to implement this functionality.

Using Models

Modeling concepts is important to developing software systems. A developer must understand the domain's entities, relationships between entities, and interfaces for how various components interact. In object-oriented design and analysis, the developer must understand classes and relationships between them. In data modeling for databases, the developer must understand tables and relationships between them. Similar concepts apply to pxGrid.

pxGrid supports the use of one or more models. A model defines entities, relationships, and interfaces used by pxGrid nodes. As an example, consider the identity model supported by Cisco's Identity Services Engine (ISE). It defines entities such as Session, IPAddress, Posture, and User. It also defines relationships between entities. A Session takes places through an IPAddress and Interface. In the model a Session contains an Interface and an IPAddress. Many other relationships exist; this is a subset of the overall model.

Implementing Functionality

Knowing which model to use, the developer can customize node behavior. After connecting successfully, the node does not have to reconnect. The same connection can be used for both providing and consuming capabilities. The node further interacts with pxGrid by registering the appropriate query and notification callers and handlers as detailed below.

Query Handler

A provider must register a query handler with the GCL to service a query that it needs to expose over pxGrid. When a consumer initiates a query, the GCL invokes the corresponding query handler on the provider's node to service the request and return response.

A query handler is created by implementing an interface. API details vary depending on the programming language. A realistic implementation would contain extensive business logic and would likely interact with external components such as databases. The handler is registered by associating the handler with a pxGrid connection. The handler remains active and can potentially process requests until the thread disconnects from pxGrid. Before a query handler can be registered, the provider must establish its intent to be provider of a capability. This will be successful only if the node is authorized to be a provider for that capability.

Query Caller

To be able to invoke a query, a node must establish its intent to be a consumer of the capability by invoking a subscribe capability method on the pxGrid connection and must be authorized to be a consumer of the capability.

A query caller is created by assembling a request and calling the query method on the pxGrid connection. Then the query method is called. Since queries are processed synchronously, the query method blocks until a response is received from the provider (or a timeout occurs). Note that the query is not directed to a provider by the caller, this is done internally by pxGrid. If there is no registered provider for the query, then an error is returned.

Notification Handler

A consumer node registers a notification handler with the pxGrid connection to receive notifications for a capability. Before a notification handler can be registered, the consumer must invoke a subscribe capability method to establish itself as a consumer for a capability.

The developer creates a notification handler by implementing a notification callback interface. By registering an instance of this implementation with the pxGrid connection, notifications will be received whenever a provider sends them. Note that this communication is asynchronous. The handler remains live until the node is disconnected from pxGrid.

Notifier

To be able to publish notifications, the provider node must first invoke a publish capability method on the pxGrid connection to establish itself as a provider for a capability. If the node does not have the right authorization group, the pxGrid server will return an authorization error. Calling notify on the pxGrid connection sends the object to any nodes connected to pxGrid that have registered for notifications of this class. Note that the notify method does not block.

ISE as a Provider

This section goes over the contextual information shared from ISE using pxGrid. ISE publishes active user session information as well as configuration information, such as TrustSec Security groups and configured device profiles. ISE also exposes the Endpoint Protection Service (EPS) API thru pxGrid.

• Session Directory Capability: Provides information related to active sessions in ISE.

• Endpoint Profile Meta-Data Capability: Provides Device Type related information configured in ISE.

• TrustSec Meta-Data Capability: Provides TrustSec Security Group information configured in ISE.

• Endpoint Protection Service Capability: Allows EPS action to be taken and also provides EPS action status.

The query API and notifications that are exposed through these capabilities can be invoked as detailed in previous sections. Additionally, a client stub API on top of the GCL for these capabilities that hides the details of request/response model and exposes these queries as direct method calls is provided.

Session Directory Capability

ISE provides active user session information which includes user identity and the associated context including IP address, user group, location, and device type using the Session Directory capability. This information can be retrieved on demand, for example by invoking query and bulk download APIs as well as through notifications.

A typical use case for the session information in a network can be an upstream device that needs the user identity and context information for the network traffic and applying policy based on the user context, such as a user group, device type, or security group. The upstream device can register with pxGrid server as a consumer of Session Directory capability. Once the connection is established, it can invoke bulk download API to retrieve all active session context and also subscribe to notification for any further session updates.

A client stub API that is built on top of the GCL provides an easy way to invoke queries associated with the Session Directory capability.

Endpoint Protection Service (EPS) Capability

Endpoint Protection Service (EPS) capability allows EPS actions to be initiated from a pxGrid client. Examples of EPS actions include endpoint quarantine, endpoint unquarantine, or shutting down an endpoint. The EPS Actions can be performed using the IP address, mac address or session id on online or offline endpoints.

Endpoint Profile Metadata Capability

Endpoint Profile Metadata capability provides a query API to retrieve the list of endpoint profiles or profiling policies, such as iphone, ipad, and android, configured in ISE as well as notification if an endpoint profile is changed. If the profiling policies and probes are enabled on ISE, then an endpoint can be profiled to one of the configured endpoint profiles which is published as part of the session model.

TrustSec Metadata Capability

TrustSec Metadata capability provides a query API to retrieve list of all security groups configured in ISE as well as notifications of changes in security group configuration.