ISE Pipeline Design

Pipeline design for ingesting, transforming, and routing Cisco ISE logs to Microsoft Sentinel.

This is a design document based on ISE log structure and Monad capabilities. Implementation requires hands-on testing with actual ISE syslog output.

CHLA ISE Environment

CHLA operates two separate ISE deployments:

CHLA ISE Environments

ISE RADIUS Deployment (Distributed)

Dedicated to 802.1X and MAB authentication.

Node Role

pPAN

Primary Admin Node

sPAN

Secondary Admin Node

pMNT

Primary Monitoring Node (log source)

sMNT

Secondary Monitoring Node (log source)

PSN x4

Policy Service Nodes (authentication processing)

ISE TACACS Deployment (Standalone)

Dedicated to device administration (network device CLI access).

Node Role

TACACS Node 1

All-in-one (standalone)

TACACS Node 2

All-in-one (standalone)

Log Sources by Deployment

Deployment Log Types Volume

RADIUS (MNT nodes)

Auth pass/fail, accounting, posture, profiler, guest

HIGH

TACACS (standalone)

Admin auth, command accounting, authorization

LOW (but high security value)

ISE Syslog Message Categories

Prefix Description Volume

CISE_Passed_Authentications

Successful 802.1X/MAB auth

HIGH

CISE_Failed_Attempts

Auth failures, rejections

MEDIUM

CISE_RADIUS_Accounting

Session start/stop/interim

HIGH

CISE_TACACS_Accounting

Device admin commands

LOW

CISE_Posture_Assessment

Endpoint posture results

MEDIUM

CISE_Profiler

Device profiling events

MEDIUM

CISE_Guest

Guest portal events

LOW

CISE_MyDevices

BYOD registration

LOW

CISE_Administrative_and_Operational_Audit

Admin changes

LOW

Pipeline Architecture

ISE Pipeline Design

Data Transformation Flow

How data moves through the pipeline:

Data Transformation Flow

Input Configuration

Syslog Input

Monad syslog input receives logs from ISE MNT nodes.

ISE Syslog Configuration (ISE Admin):

  1. Administration → System → Logging → Remote Logging Targets

  2. Add Monad syslog endpoint

  3. Configure TCP 1468 (recommended) or UDP 514

Key Fields from ISE Syslog:

Field Example

timestamp

2026-03-18T12:34:56.789Z

hostname

ise-mnt-01

facility

local6

severity

info, warning, error

message

Full ISE log message with attributes

Transform Chain

Step 1: Parse ISE Message

ISE logs contain key-value pairs in the message body.

Sample ISE Log:

CISE_Passed_Authentications 0000000001 1 0 2026-03-18 12:34:56.789 +00:00
UserName=jdoe, NAS-IP-Address=10.50.1.100, NAS-Port=Gi1/0/1,
Framed-IP-Address=10.50.10.50, Called-Station-ID=AA-BB-CC-DD-EE-FF,
AuthenticationStatus=AuthenticationPassed, ...

jq Transform to Parse:

{
  "operation": "jq",
  "arguments": {
    "query": ". as $orig | .message | split(\", \") | map(split(\"=\") | {(.[0]): .[1]}) | add | . + {raw: $orig}",
    "key": "parsed"
  }
}

Step 2: Flatten Structure

{
  "operation": "flatten_all",
  "arguments": {
    "delimiter": "_"
  }
}

Step 3: Normalize Field Names

Standardize ISE field names to Sentinel schema.

{
  "operation": "rename",
  "arguments": {"from": "UserName", "to": "user_principal_name"}
}
{
  "operation": "rename",
  "arguments": {"from": "NAS-IP-Address", "to": "switch_ip"}
}
{
  "operation": "rename",
  "arguments": {"from": "Framed-IP-Address", "to": "client_ip"}
}
{
  "operation": "rename",
  "arguments": {"from": "Called-Station-ID", "to": "client_mac"}
}

Step 4: Add Metadata

{
  "operation": "add",
  "arguments": {
    "key": "log_source",
    "value": "cisco-ise"
  }
}
{
  "operation": "timestamp",
  "arguments": {
    "key": "monad_ingest_time",
    "format": "rfc3339"
  }
}

Step 5: Drop Noise

Filter out high-volume, low-value events.

{
  "operation": "drop_record_where_value_equal",
  "arguments": {
    "key": "message_type",
    "value": "RADIUS_Accounting_Interim"
  }
}

Routing Configuration

Route 1: Security Events → Analytics

Auth failures, policy violations, posture failures.

{
  "from": "transform-normalize",
  "to": "output-sentinel-analytics",
  "name": "ISE Security Events",
  "conditions": {
    "operator": "or",
    "conditions": [
      {"type": "contains", "key": "message", "value": "CISE_Failed_Attempts"},
      {"type": "contains", "key": "message", "value": "AuthenticationFailed"},
      {"type": "contains", "key": "message", "value": "AuthorizationFailed"},
      {"type": "contains", "key": "message", "value": "PostureStatus=NonCompliant"},
      {"type": "contains", "key": "message", "value": "CISE_TACACS_Accounting"}
    ]
  }
}

Route 2: Bulk Events → Basic

Successful auths, session accounting.

{
  "from": "transform-normalize",
  "to": "output-sentinel-basic",
  "name": "ISE Bulk Events",
  "conditions": {
    "operator": "always",
    "conditions": []
  }
}

ISE Message Types - Routing Matrix

Message Type Security Value Volume Route To

CISE_Failed_Attempts

HIGH

Medium

Analytics

CISE_Passed_Authentications

LOW

High

Basic

CISE_RADIUS_Accounting (Start/Stop)

MEDIUM

High

Basic

CISE_RADIUS_Accounting (Interim)

LOW

Very High

DROP

CISE_TACACS_Accounting

HIGH

Low

Analytics

CISE_Posture_Assessment (NonCompliant)

HIGH

Low

Analytics

CISE_Posture_Assessment (Compliant)

LOW

Medium

Basic

CISE_Administrative_and_Operational_Audit

HIGH

Low

Analytics

Testing Checklist

Before production deployment:

  • Verify syslog connectivity (ISE → Monad)

  • Confirm message parsing extracts all fields

  • Validate field normalization matches Sentinel schema

  • Test routing conditions with sample logs

  • Verify dropped records don’t include security events

  • Confirm both outputs receive expected data

  • Load test with production volume estimate

Open Questions

  1. Parsing complexity: Can GJSON handle ISE’s key-value format, or is jq required?

  2. Volume estimation: What’s the expected EPS from ISE nodes?

  3. Retention requirements: How long to keep in Analytics vs Basic tier?

  4. Enrichment needs: Should we enrich with asset/user data before Sentinel?

Related