Welcome to Learning Cisco Platform Exchange Grid (pxGrid)
Note: The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.
Note: From Cisco ISE Release 3.1, all pxGrid connections must be based on pxGrid 2.0. pxGrid 1.0-based (XMPP-based) integrations will cease to work on Cisco ISE from Release 3.1 onwards.
Note: From Cisco ISE, Release 3.3, minor changes have been made to the Cisco ISE GUI in some windows. For detailed information about these changes, contact your Cisco representative.
pxGrid Version 2.0, which is based on WebSockets, was introduced in Cisco ISE Release 2.4. We recommend that you plan and upgrade your other systems to pxGrid 2.0-compliant versions in order to prevent potential disruptions, if any, to integrations.
Cisco pxGrid is an open and scalable Security Product Integration Framework (SPIF) that allows for bi-directional any-to-any partner platform integrations. Cisco pxGrid uses a pub/sub model, and publishes Cisco Identity Services Engine (ISE) contextual information. In addition, pxGrid publishes this session directory topic and other ISE topics of information for ecosystem parters to consume. This results in a higher degree of efficacy in the ecosystem's security policy by including the identity information surrounding the event.
Initially pxGrid was released with ISE 1.3 and was XMPP-based, requiring an SDK containing the Java and C libraries, and sample code. This is now named pxGrid 1.0 and supported in ISE versions 1.3 and higher. If you are currently implementing pxGrid 1.0 as your development platform, please visit: pxGrid 1.0 for additional resources.
pxGrid 2.0 uses WebSocket and REST API over STOMP (Simple Text Oriented Message Protocol) 1.2 messaging protocol. WebSockets and STOMP are widely used in the industry. WebSockets allow the client and server to keep an open connection, so there is bi-directional communication as opposed to using long polling to keep the connection as was used in hacks prior to using WebSockets. STOMP is used over WebSockets to communicate with any STOMP message broker.
All new development needs to be done in pxGrid 2.0.
This provides the developer with the following benefits:
- NO SDK Dependency
- ease of clientless approach
- horizantal scalability of ISE pxrid servers.
Download the Cisco pxGrid Whitepaper
Please visit pxGrid 2.0 for additional resources
Below are the summarized use cases:
Consuming Session Topic information from ISE
Cisco Identity Services Engine (ISE) contains contains a wealth of session information that ecosystem partners can use in their security policy information. This session information provides user identity information and includes connection type, endpoint device and compliant attributes and more.
Dynamic Topics
The Cisco Platform Exchange Grid (pxGrid) allows you to integrate your application into the pxGrid, a multivendor, cross-platform network system that pulls together different parts of an IT infrastructure such as security monitoring and detection systems, network policy platforms, asset and configuration management, identity and access management platforms, to name a few. When you have new business or operational needs arise, you can use pxGrid to exchange context with Cisco products, such as the Cisco Identity Service Engine (ISE), or any other Cisco partner that supports pxGrid. Cisco pxGrid will provide you with an API that will open up a unified framework that will enable you to integrate to pxGrid once, then share context with any other platform that supports pxGrid. This hub and spoke architecture means that you integrate once to pxGrid and there is no need for you to adopt a host of individual, platform-specific
• Context Sharing Control - Because pxGrid is customizable, you can “publish” only the specific information (context) that you want to share and you can control which other pxGrid partner platforms that it gets shared with. • Bidirectional context sharing – pxGrid enables partner platforms such as yours and others to either publish context or to subscribe to context; you orchestrate and secure what is published and what is subscribed through the pxGrid controller which resides on Cisco Identity Service Engine (ISE). • Share context data in native formats – you share contextual information in pxGrid using the native data format of your platform - pxGrid does the rest. • Connect to multiple platforms simultaneously – pxGrid enables you to publish only the context data that is relevant to pxGrid partner subscribers. You can customize numerous context “topics” for a variety of partner platforms, yet always shared via the same reusable pxGrid framework. By sharing only relevant data both publishing and subscribing platforms are able to scale by eliminating irrelevant data.
Adaptive Network Control (ANC) Mitigation Actions
pxGrid also provides pxGrid-enabled platforms with the capability to take network threat-response actions on users or endpoints directly from the partner platform. For example, in a SIEM platform an operator may quarantine users or devices or take investigative actions by rerouting traffic. With pxGrid, all this can be done from the SIEM console, using the same pxGrid framework used for sharing and consuming context. In this scenario, the system calls a threat-response API within the pxGrid framework. It can then use threat-response capabilities that are already instrumented in platforms like the Cisco Identity Services Engine to carry out the response action. With this architecture, pxGrid-enabled platforms don’t need to understand how to take a response action. They just make a call through pxGrid to a platform, like the Identity Services Engine, that understands the network and has the instrumentation to carry out the requested action.
The below figure outlines the Adaptive Network Control (ANC) capabilities on the Identity Services Engine, as invoked by a pxGrid-enabled platform making a call to the threat-response API. The engine carries out a change of authorization and issues a security group tag
pxGrid Context-In (IOT) Available in pxGrid 2.0 only
Internet of Things (IOT) devices are considered ‘anything’ connected to the ‘network’ at ‘any time.’ Manufacturing tools and medical devices, such as infusion pumps and MRI machines, are common examples in a growing network of IOT infrastructure. With the proliferation of IOT devices, many of which are unpatched and unmonitored, organizations face an increasing security problem. As these new technologies connect to the enterprise’s network infrastructure, the biggest challenge is classifying these devices and providing them the appropriate network access based on the organization’s security policy for IOT devices.
For example, medical devices require specific access to areas of the medical facility and to the appropriate medical personnel. Are these devices allowed to connect via wired, wireless, or VPN? These are some considerations that define an IOT Security Policy.
As new technologies are being developed, there are safeguards in place to protect them from vulnerabilities that may exist in their code and from possible malware attacks. If these devices get compromised from changing the new technology vendors attributes defined in an ISE profiled policy, they will not be allowed network access.
Ecosystem partners can also publish Theat Information, or any other metadata into ISE.
How it Works
Cisco pxGrid Context-In augments device classification by using Cisco Identity Services Engine as the network enforcement and network authorization point. Classified endpoint access is determined when technology partners publish their IOT asset information to the pxGrid endpoint Asset Topic. The ISE pxGrid node subscribes to this topic. (This process is shown in Figure 1.) The IOT Asset ISE profiling policy is defined by the IOT Assets as in Figure 2. The logical profile consists of the defined ISE profiling policy (see Figure 3) to be used in an ISE Authorization policy for classified network access (see Figure 4)
in pxGrid and defining these assets in an ISE profiling policy. The ISE pxGrid node becomes the subscriber to this topic and enforces and authorizes the technology partners connection. The technology partner is also considered a pxGrid client.
Figure 1. ISE ecosystem partner publishes attributes to Endpoint Asset Topic
Figure 2. The IOT Asset Profiling Policy is created
Figure 3. The Profiling Policy is assigned to a Logical Profile
Figure 4. The Logical Profile is Assigned to an ISE Authorization Policy
