Chapter 15: Security Automation — Policy Enforcement, Compliance, and Segmentation
Learning Objectives
Automate security policy enforcement using Cisco ISE ERS APIs and pxGrid
Implement continuous compliance monitoring solutions that detect and remediate security violations in real time
Automate network segmentation using Cisco TrustSec SGTs and SD-Access policies
Build end-to-end security automation workflows integrating ISE, Catalyst Center, and network devices
15.1 Cisco ISE ERS API Automation
Pre-Check — ISE ERS API
1. On which TCP port does the ISE ERS API operate?
2. Which authentication method does the ISE ERS API use?
3. What HTTP response code does ISE ERS return when a resource is successfully created via POST?
4. What does ANC stand for in the context of ISE automation?
5. Which ISE ERS endpoint is used to quarantine an endpoint by MAC address?
15.1.1 ERS API Architecture and Setup
The External RESTful Services (ERS) API is Cisco ISE's primary programmatic interface for provisioning and policy management. ERS operates on port 9060/TCP/HTTPS and must be explicitly enabled in ISE at Administration → System → Settings → ERS Settings. A dedicated ERS Admin user account should be created to scope API access independently from the ISE admin console.
ERS authentication uses HTTP Basic Auth — credentials are Base64-encoded and placed in the Authorization header. Every request also carries Accept: application/json and Content-Type: application/json.
Resource
URI Path
Operations
Endpoints
/ers/config/endpoint
GET, POST, PUT, DELETE
Network Devices (NADs)
/ers/config/networkdevice
GET, POST, PUT, DELETE
ANC Policies
/ers/config/ancpolicy
GET, POST, PUT, DELETE
ANC Apply (Quarantine)
/ers/config/ancendpoint/apply
POST
ANC Clear
/ers/config/ancendpoint/clear
POST
Security Group Tags
/ers/config/sgt
GET, POST, PUT, DELETE
Security Group ACLs
/ers/config/sgacl
GET, POST, PUT, DELETE
Egress Matrix Cells
/ers/config/egressmatrixcell
GET, POST, PUT, DELETE
Authorization Profiles
/ers/config/authorizationprofile
GET, POST, PUT, DELETE
15.1.3 ANC Quarantine and Remediation
Adaptive Network Control (ANC) policies define automated responses when an endpoint is flagged. Common policy actions are QUARANTINE, SHUT_DOWN, and PORT_BOUNCE. The ANC workflow removes the need for human intervention — a SIEM detects the threat, a SOAR playbook calls ISE ERS to quarantine the MAC, ISE sends a RADIUS Change of Authorization (CoA) to the switch, and the endpoint is moved to a restricted VLAN within seconds.
ANC Quarantine: Automated Containment Flow
SIEM
Detects anomaly
→
SOAR
Triggers playbook
→
ISE ERS /ancendpoint/apply
POST MAC + policy
→
Switch
CoA → Quarantine VLAN
→
Remediate & Clear
/ancendpoint/clear
flowchart TD
A([SIEM Detects Anomaly]) --> B{Identify Endpoint\nby MAC Address}
B --> C[SOAR Playbook Triggered]
C --> D[POST /ers/config/ancendpoint/apply\npolicyName=Quarantine]
D --> E[ISE Issues CoA to NAD]
E --> F[Switch Moves Port\nto Quarantine VLAN]
F --> G[Endpoint Network Access\nRestricted]
G --> H{Remediation\nComplete?}
H -- No --> I[IT / MDM Remediation\nAV Scan / Patch / Re-enroll]
I --> H
H -- Yes --> J[POST /ers/config/ancendpoint/clear\npolicyName=Quarantine]
J --> K[ISE Issues CoA — Restore Original VLAN]
K --> L([Normal Access Restored])
style A fill:#d9534f,color:#fff
style L fill:#5cb85c,color:#fff
style G fill:#f0ad4e,color:#000
Key Points — ISE ERS API
ERS API runs on port 9060/HTTPS; must be explicitly enabled; use a dedicated ERS Admin account
HTTP Basic Auth (Base64 credentials) is the authentication model — no tokens required
A successful POST returns HTTP 201; the Location response header contains the new resource URL
ANC quarantine is triggered with a single POST to /ers/config/ancendpoint/apply passing MAC address and policy name; ISE sends a RADIUS CoA to the switch within seconds
The ERS API supports the full endpoint lifecycle: create, update identity group, quarantine, and clear — making it the integration point for SIEM, SOAR, MDM, and CI/CD pipelines
Post-Check — ISE ERS API
1. On which TCP port does the ISE ERS API operate?
2. Which authentication method does the ISE ERS API use?
3. What HTTP response code does ISE ERS return when a resource is successfully created via POST?
4. What does ANC stand for in the context of ISE automation?
5. Which ISE ERS endpoint is used to quarantine an endpoint by MAC address?
15.2 pxGrid for Security Context Sharing
Pre-Check — pxGrid
1. What transport protocol does pxGrid 2.0 use for real-time publish/subscribe event streaming?
2. Which pxGrid topic provides real-time session data including IP address, username, SGT, and posture status?
3. What authentication mechanism does pxGrid 2.0 use for client registration?
15.2.1 pxGrid Architecture
pxGrid (Platform Exchange Grid) is ISE's real-time intelligence broadcast network. It allows ISE to share live security context — who is on the network, what device they are using, their compliance posture, and their SGT — with any platform subscribed to the grid.
pxGrid 2.0 uses two communication patterns: Publish/Subscribe (WebSockets over STOMP) for real-time event streaming, and Query/REST (HTTPS) for on-demand lookups. Authentication uses mutual TLS (mTLS) — the client must present a certificate approved by ISE.
sequenceDiagram
participant Client as pxGrid Client (SIEM/SOAR/FMC)
participant PX as ISE pxGrid Controller
participant ISE as ISE Policy Engine
participant NAD as Network Device (Switch/WLC)
Note over Client,ISE: mTLS Mutual Certificate Authentication
Client->>PX: Register (client cert)
PX->>Client: Account Activated
Note over Client,NAD: On-Demand Query (REST/HTTPS)
Client->>PX: GET getSessionByIpAddress(10.1.1.100)
PX->>ISE: Lookup active session
ISE-->>PX: Session: user, MAC, SGT, posture
PX-->>Client: Session context object
Note over Client,NAD: Real-Time Subscription (WebSocket/STOMP)
Client->>PX: SUBSCRIBE com.cisco.ise.session
NAD->>ISE: RADIUS Auth Request (802.1x)
ISE->>NAD: Access-Accept (SGT=10)
ISE->>PX: Publish session-created event
PX->>Client: SESSION EVENT: jsmith, SGT=10, posture=Compliant
15.2.2 pxGrid Topics
Topic
Data Published
Typical Consumer
com.cisco.ise.session
Active sessions: IP, MAC, username, SGT, posture
SIEM, SOAR, firewall
com.cisco.ise.radius
RADIUS authentication failures
SOC analytics, SIEM
com.cisco.ise.sxp
SXP IP-to-SGT bindings
Network devices, SD-WAN
com.cisco.ise.anc
ANC policy change events
SOAR, ticketing
com.cisco.ise.posture
Endpoint posture assessment results
MDM, SIEM
15.2.3 Closed-Loop Threat Containment via pxGrid
The com.cisco.ise.anc topic enables bidirectional ANC automation. Firepower detects C2 traffic, a SOAR platform picks up the event, applies ANC Quarantine via ERS, ISE CoA isolates the endpoint, and Firepower receives the updated session record confirming containment — all without human intervention.
Key Points — pxGrid
pxGrid 2.0 uses WebSockets over STOMP for pub/sub and HTTPS REST for queries — authentication via mTLS client certificates
The com.cisco.ise.session topic is the most widely used — a single session object contains IP, MAC, username, SGT, posture state, NAS port, and MDM attributes
pxGrid enables identity-aware policy across SIEM, SOAR, FMC, and SD-WAN without each platform maintaining a separate ISE API session
pxGrid Cloud (ISE 3.1+) extends access to cloud-based security platforms via a lightweight on-premises proxy using only port 443 outbound
FMC integration via pxGrid allows firewall rules to reference security group names (Employees, Contractors, IoT) rather than IP subnets — policy follows users as they move
Post-Check — pxGrid
1. What transport protocol does pxGrid 2.0 use for real-time publish/subscribe event streaming?
2. Which pxGrid topic provides real-time session data including IP address, username, SGT, and posture status?
3. What authentication mechanism does pxGrid 2.0 use for client registration?
15.3 Compliance Monitoring Automation
Pre-Check — Compliance Monitoring
1. Which Python library is used to collect structured YANG-modeled configuration data from network devices via NETCONF?
2. In a continuous compliance monitoring system, which severity level triggers immediate automated remediation plus a P1 alert?
3. Which tool is used in a CI/CD pipeline for pre-deploy network configuration analysis, checking routing correctness and ACL reachability?
15.3.1 The Four Pillars of Continuous Compliance
Continuous compliance monitoring replaces periodic audits with an always-on system. The four pillars are:
Baseline Definition — store known-good configurations in Git, mapped to CIS, NIST 800-53, PCI-DSS, HIPAA, or SOC 2 controls
Continuous Data Collection — NETCONF (ncclient) for structured YANG data, RESTCONF for JSON over HTTPS, SSH/Netmiko for legacy devices
Drift Detection and Classification — deviations classified as Critical / High / Medium / Low, each triggering a different response tier
Automated Remediation — RESTCONF PATCH to re-apply correct config, ISE ERS ANC to quarantine, ServiceNow API to open tickets
flowchart TD
subgraph P1["Pillar 1 — Baseline Definition"]
B1[Store baselines in Git\nCIS / NIST / PCI-DSS / HIPAA]
end
subgraph P2["Pillar 2 — Data Collection"]
B2A[NETCONF / ncclient\nStructured YANG data]
B2B[RESTCONF / requests\nJSON over HTTPS]
B2C[SSH / Netmiko\nLegacy CLI parsing]
end
subgraph P3["Pillar 3 — Drift Detection"]
B3{Deviation\nDetected?}
B3 -- No --> MON[Continue Monitoring]
B3 -- Yes --> SEV{Classify\nSeverity}
SEV --> CRIT[Critical — Immediate\nAuto-Remediate + P1 Alert]
SEV --> HIGH[High — Page On-Call\n+ Auto Revert]
SEV --> MED[Medium — Open Ticket\n+ Scheduled Fix]
SEV --> LOW[Low — Audit Log Only]
end
subgraph P4["Pillar 4 — Automated Remediation"]
REM1[RESTCONF PATCH\nPush Correct Config]
REM2[ISE ERS ANC\nQuarantine Endpoint]
REM3[ServiceNow API\nTicket + Hold for Review]
end
P1 --> P2
P2 --> P3
CRIT --> REM1
CRIT --> REM2
HIGH --> REM3
REM1 & REM2 & REM3 --> AUDIT[Update Git Audit Trail\n& Compliance Dashboard]
AUDIT --> MON
style CRIT fill:#d9534f,color:#fff
style HIGH fill:#f0ad4e,color:#000
style MED fill:#5bc0de,color:#000
style LOW fill:#5cb85c,color:#fff
15.3.2 Drift Severity Classification
Severity
Example Violation
Response
Critical
no aaa new-model applied
Immediate auto-remediate + P1 alert
High
Unauthorized ACL entry added
Page on-call + automated revert
Medium
Syslog server removed
Open ticket + scheduled remediation
Low
Interface description changed
Logged to audit trail only
Key Points — Compliance Monitoring
Continuous compliance replaces quarterly audits with always-on drift detection — exposure windows measured in seconds, not months
NETCONF (ncclient) is the preferred collection method for structured YANG data; RESTCONF over HTTPS for IOS-XE 16.6+ devices
Baselines are stored in Git for full version history and change audit trail; each element is mapped to a compliance framework (CIS, NIST, PCI-DSS, HIPAA)
Batfish is the canonical tool for pre-deploy CI/CD pipeline analysis — it catches routing, ACL, and BGP correctness issues before configs reach production
Automated remediation uses RESTCONF PATCH to re-apply correct config and ISE ERS ANC to quarantine non-compliant endpoints — no human approval required for Critical findings
Post-Check — Compliance Monitoring
1. Which Python library is used to collect structured YANG-modeled configuration data from network devices via NETCONF?
2. In a continuous compliance monitoring system, which severity level triggers immediate automated remediation plus a P1 alert?
3. Which tool is used in a CI/CD pipeline for pre-deploy network configuration analysis, checking routing correctness and ACL reachability?
15.4 Network Segmentation Automation
Pre-Check — Segmentation & SGTs
1. How many bits wide is a TrustSec Security Group Tag (SGT)?
2. Which protocol distributes IP-to-SGT binding tables from ISE to network devices that cannot perform native inline SGT tagging?
3. In SD-Access, what are the two complementary segmentation mechanisms?
4. When creating a new SGT via the ISE ERS API, which HTTPS method and path is used?
15.4.1 TrustSec and SGT Architecture
Cisco TrustSec decouples network segmentation policy from IP addresses. Instead of firewall rules based on subnets, policy is written based on group membership: Employees → Finance_Servers: permit. This is enforced through Security Group Tags (SGTs) — 16-bit numeric values assigned by ISE during RADIUS authentication as a Cisco AV-pair: cts:security-group-tag=10.
SGTs solve the mobility problem: a contractor laptop carries SGT=20 whether in the office, on VPN, or at a branch — and policy follows it everywhere.
Core TrustSec Components
Component
Function
SGT (Security Group Tag)
16-bit tag assigned to traffic based on user/device identity
SGACL (Security Group ACL)
Policy defining permitted traffic between source and destination SGTs
TrustSec Matrix
The full SGT-to-SGT permission matrix (allow-list model)
SXP (SGT Exchange Protocol)
Distributes IP-to-SGT binding tables to non-TrustSec devices
SGT Inline Tagging
SGT embedded in 802.1AE (MACsec) or Cisco metadata frame header
15.4.3 SGT Lifecycle Automation via ISE ERS
The full SGT lifecycle is automatable via three sequential ERS API calls:
Create SGT — POST to /ers/config/sgt with name, description, and numeric tag value
Create SGACL — POST to /ers/config/sgacl with ACL content (e.g., deny ip\npermit icmp)
Bind in Egress Matrix — POST to /ers/config/egressmatrixcell linking source SGT, destination SGT, and the SGACL
flowchart TD
A([Start: Define New\nSecurity Group]) --> B[POST /ers/config/sgt\nname=IoT_Devices, value=30]
B --> C{HTTP 201\nCreated?}
C -- No --> ERR1[Log Error — Check\nDuplicate Tag Value]
C -- Yes --> D[Extract SGT ID\nfrom Location Header]
D --> E[POST /ers/config/sgacl\nname=IoT_to_Corp_Deny\naclcontent: deny ip / permit icmp]
E --> F{HTTP 201\nCreated?}
F -- No --> ERR2[Log Error — Check\nACL Syntax]
F -- Yes --> G[Extract SGACL ID\nfrom Location Header]
G --> H[POST /ers/config/egressmatrixcell\nsourceSgt=IoT, destSgt=Corporate\ndefaultRule=DENY_IP]
H --> I{HTTP 201\nCreated?}
I -- No --> ERR3[Log Error — Check\nSGT IDs Valid]
I -- Yes --> J[SXP Distributes IP to SGT\nBindings to Network Devices]
J --> K[Run pytest: test_iot_to_corporate_blocked]
K --> L{Policy Test\nPassed?}
L -- No --> M[Rollback Matrix Cell\nDELETE /egressmatrixcell/id]
M --> ERR3
L -- Yes --> N([SGT Policy Active\nand Verified])
style A fill:#337ab7,color:#fff
style N fill:#5cb85c,color:#fff
style ERR1 fill:#d9534f,color:#fff
style ERR2 fill:#d9534f,color:#fff
style ERR3 fill:#d9534f,color:#fff
15.4.4 SD-Access Segmentation Model
Mechanism
Layer
VRF Impact
Use Case
Virtual Networks (VNs)
L3 macro-segmentation
Separate routing tables
Isolate IoT, Guest, Corporate at network level
SGT (Scalable Group Tags)
L2/L7 micro-segmentation
Within/across VNs
User and device role-based access control
The allow-list (whitelist) model is the recommended TrustSec deployment pattern: default TrustSec policy is Deny All between all SGT pairs, with explicit permits defined per pair in the Egress Matrix.
Policy enforced by SGACL at fabric edge — independent of IP address or location
Key Points — Segmentation & SGTs
SGTs are 16-bit numeric identifiers assigned by ISE during RADIUS authentication as a Cisco AV-pair; they follow users across locations, VPN, and topology changes
Full SGT lifecycle automation requires three sequential ERS API calls: POST /sgt → POST /sgacl → POST /egressmatrixcell
SXP (SGT Exchange Protocol) distributes IP-to-SGT bindings to legacy devices that cannot do native inline tagging
SD-Access uses Virtual Networks (L3 macro-segmentation with separate VRFs) plus SGTs (L2/L7 micro-segmentation) for defence-in-depth
The recommended TrustSec deployment uses an allow-list (whitelist) model: default is Deny All, with explicit permits defined per SGT pair in the Egress Matrix
Post-Check — Segmentation & SGTs
1. How many bits wide is a TrustSec Security Group Tag (SGT)?
2. Which protocol distributes IP-to-SGT binding tables from ISE to network devices that cannot perform native inline SGT tagging?
3. In SD-Access, what are the two complementary segmentation mechanisms?
4. When creating a new SGT via the ISE ERS API, which HTTPS method and path is used?
15.5 End-to-End Security Automation Workflow
The true power of these technologies emerges when integrated into a unified automation workflow. The scenario below illustrates a seven-step automated threat containment and remediation flow:
sequenceDiagram
participant SIEM as SIEM
participant SOAR as SOAR Playbook
participant PX as ISE pxGrid
participant ISE as ISE ERS API
participant SW as Switch SW-01
participant NC as NETCONF Agent
participant SN as ServiceNow
participant MDM as MDM / Endpoint
SIEM->>SOAR: Alert — lateral movement from 10.1.1.100
Note over SOAR: Step 1 — Enrich
SOAR->>PX: getSessionByIpAddress(10.1.1.100)
PX-->>SOAR: user=jsmith, MAC=AA:BB, SGT=10, posture=NonCompliant
Note over SOAR: Step 2 — Contain
SOAR->>ISE: POST /ancendpoint/apply MAC + policy=Quarantine
ISE->>SW: RADIUS CoA — Quarantine VLAN (SGT=99)
SW-->>ISE: CoA-ACK
Note over SOAR: Step 3 — Verify Compliance
SOAR->>NC: NETCONF get-config SW-01
NC-->>SOAR: Gi1/0/5 VLAN=Quarantine confirmed
Note over SOAR: Step 4 — Document
SOAR->>SN: Create P2 Incident with full context
Note over SOAR: Step 5 — Remediate
SOAR->>MDM: Trigger AV scan + patch workflow
MDM-->>SOAR: posture=Compliant
Note over SOAR: Step 6 — Restore
SOAR->>ISE: POST /ancendpoint/clear MAC + policy=Quarantine
ISE->>SW: RADIUS CoA — Restore original VLAN (SGT=10)
ISE->>PX: Publish session event — SGT=10 (Employee)
Note over SOAR: Step 7 — Update Dashboard
SOAR->>SN: Resolve Incident — Closed
PX->>SIEM: Session update — threat contained
Total human intervention required: zero until the endpoint remediation step, which can itself be automated via MDM integration.
Key Points — End-to-End Workflow
The workflow chains: pxGrid enrichment → ISE ERS quarantine → NETCONF compliance verify → ServiceNow ticket → MDM remediate → ISE ERS clear
pxGrid serves as the first enrichment step — resolving an IP address to user identity, MAC, SGT, posture state, and exact switch port before any action is taken
ISE ERS ANC is the enforcement arm: a single POST moves the endpoint to quarantine; a second POST restores it — no CLI or GUI access required
NETCONF is used post-containment to verify the switch correctly applied the quarantine VLAN and to detect any concurrent compliance drift
The entire loop — detection, containment, remediation, restoration, documentation — runs at machine speed with zero manual steps in the critical path
Integration Challenge
Pre-Check — Integration & Synthesis
1. In the end-to-end threat containment workflow, which technology is used FIRST to resolve an IP address to a user identity, MAC address, and SGT before any remediation action is taken?
2. Which ISE mechanism dynamically updates a network session without reauthentication — for example, moving an endpoint to a quarantine VLAN after ANC is applied?
3. A SOAR playbook needs to verify that a quarantine VLAN was correctly applied to a switch port after an ANC action. Which API/protocol provides the most reliable structured confirmation?
Post-Check — Integration & Synthesis
1. In the end-to-end threat containment workflow, which technology is used FIRST to resolve an IP address to a user identity, MAC address, and SGT before any remediation action is taken?
2. Which ISE mechanism dynamically updates a network session without reauthentication — for example, moving an endpoint to a quarantine VLAN after ANC is applied?
3. A SOAR playbook needs to verify that a quarantine VLAN was correctly applied to a switch port after an ANC action. Which API/protocol provides the most reliable structured confirmation?