Find unauthorised network changes with Splunk or Elastic MCP and rConfig
rConfig knows what changed and roughly when (between two backups). Your SIEM knows who logged in and entered configuration mode. Your ITSM tool knows what was approved. Bringing the three together has always been a manual audit. An agent connected to all three can do it weekly and hand you only the changes nobody can explain.
Best for: security teams, internal audit, compliance controls that require change reconciliation.
Tools: rConfig, a SIEM MCP server (Splunk or Elastic), optionally an ITSM MCP server.
rConfig tools used: get_devices, get_config_history, get_config_diff.
How it flows
flowchart LR
R["rConfig MCP<br/>what changed, between which backups"] --> A["Agent"]
S["Splunk / Elastic MCP<br/>who configured the device, when"] --> A
T["ITSM MCP<br/>approved changes"] --> A
A --> O["Exceptions only:<br/>changes with no ticket"]
The SIEM side
| Splunk | Elastic | |
|---|---|---|
| MCP server | Splunk MCP Server app (Splunkbase), installed on the search head | Elastic Agent Builder’s MCP endpoint in Kibana (/api/agent_builder/mcp); the older standalone Elasticsearch MCP server is deprecated |
| Authentication | Splunk token with the audience mcp, for a user with the mcp_tool_execute capability |
API key with Agent Builder privileges, scoped to the indices you expose |
| Query tool | run_splunk_query (SPL) |
platform.core.execute_esql (ES|QL) |
Give the agent’s SIEM identity read access to the network device and AAA indices only.
What to search for depends on what your devices send. Common sources:
- Cisco IOS and IOS XE syslog:
%SYS-5-CONFIG_I: Configured from console by <user> on vty0 (<source IP>), logged when someone leaves configuration mode. - TACACS+ accounting: the commands entered, per user, from your AAA server.
- Other vendors: Junos
UI_COMMITmessages, FortiGate configuration change events, and so on.
The prompt
For the last 7 days:
- From rConfig, list devices in the Core and Edge groups whose running config changed, with the backup times either side of each change.
- From Splunk, find configuration events (SYS-5-CONFIG_I and TACACS+ accounting) for those devices in the same periods, with user and source IP.
- From ServiceNow, find approved changes covering those devices and times. Report only changes with no matching approved change, as a table: device, change window (between backups), user and source from Splunk, diff summary.
An illustrative result:
Device Between backups Splunk Diff summarydub-edge-02 Tue 01:00 - 03:00 jdoe from 10.9.4.22 at 02:41 ACL 120: permit any any added at line 5lon-core-01 Thu 01:00 - 03:00 no configuration event found snmp-server community addedThe second row matters most: a change with no login record means either logging gaps or access that bypassed AAA.
Limits to know
- Backup intervals set the precision. rConfig places a change between two backups. Hourly backups on critical devices make the match with log timestamps far tighter than nightly ones.
- Clock skew. Device clocks, the SIEM and rConfig must agree. Make sure devices use NTP before trusting time matching.
- Log coverage. A device that doesn’t send configuration events can’t be attributed. The agent should list those devices separately rather than blame anyone.
- This is a lead list, not a verdict. Treat every row as something to investigate.
Related reference
- Config diffs
- Webhooks:
config.changedfor near-real-time detection - Change window verification
- Using rConfig with other MCP servers
Frequently asked questions
How do I find network changes that weren't approved?
List every device whose config changed in a period from rConfig, find who logged in and configured each device from your SIEM, and match both against approved change tickets. Changes with no matching ticket are the ones to investigate.
Which logs show who changed a Cisco device?
Cisco IOS and IOS XE log SYS-5-CONFIG_I when someone leaves configuration mode, with the user and source. AAA accounting from TACACS+ records the commands themselves. Both are commonly sent to Splunk or Elastic.
Does rConfig know who made a change?
No. rConfig sees the configuration before and after. The person comes from device logs or AAA accounting in your SIEM, which is why this playbook combines the two.