Security Automation with AI
Objective
In this lesson you will configure security automation workflows that use AI-driven tools to accelerate threat hunting, incident response, and policy optimization. We will connect a firewall to an AI/analytics platform and to a Splunk collector, enable automated policy analysis, and create an incident response playbook trigger. This matters in production because automated, data-driven remediation reduces mean-time-to-detect (MTTD) and mean-time-to-respond (MTTR) — essential when alerts outnumber available analysts. Real-world scenario: when an anomalous host generates suspicious traffic, the AI assistant correlates firewall logs with telemetry, recommends a policy change, and triggers an automated containment action while creating a ticket for the security team.
Quick Recap
This lesson continues from the topology established in Lesson 1. No new physical devices are added; we add logical integrations and automation between existing components:
- Firewall: central enforcement point (management IP 10.1.1.1)
- AI Security Cloud (Unified AI Assistant / XDR controller): 10.1.1.10
- Splunk indexer (analytics / search): 10.1.1.20
- Ticketing connector (internal service): 10.1.1.30
ASCII topology (management plane only — exact IPs shown on each interface):
[Firewall-MGMT] Gig0/0: 10.1.1.1/24
|
| mgmt network 10.1.1.0/24
|
[AI-Security-Cloud] eth0: 10.1.1.10/24
[Splunk-Indexer] eth0: 10.1.1.20/24
[Ticketing-System] eth0: 10.1.1.30/24
All domain names in examples use lab.nhprep.com and default passwords are Lab@123.
Key Concepts (theory before CLI)
- Log collection and normalization: Firewall logs must be exported (syslog or API) to an analytics engine so that AI models have rich telemetry. Syslog packets are sent over UDP/TCP to the collector; reliable transport (TCP/TLS) ensures no lost event data.
- Correlation and enrichment: AI-driven XDR correlates events across sources (firewall, endpoints, cloud) and enriches alerts with context (user, device, geolocation). Correlation reduces noisy alerts into higher-fidelity incidents.
- Policy analysis vs enforcement: Policy Analyzer inspects existing firewall rules for overlaps, shadowed or overly-broad rules. Automated suggestions improve policy hygiene; automated enforcement must be gated with approvals to avoid service disruption.
- Automation playbooks (incident response): Playbooks define automated actions (block IP, isolate host, open ticket). They are triggered by high-confidence incidents; a secure orchestration model must include safeguards (whitelists, rate limits).
- API tokens and secure transport: Integration uses API tokens for authentication and TLS for confidentiality. Tokens should be scoped and rotated regularly to follow least privilege.
Analogy: Think of the AI platform as a senior analyst reading all the logs at once — it can see patterns humans miss and suggest or take actions based on confidence scores.
Step-by-step configuration
Step 1: Configure firewall log export to Splunk (syslog over TLS)
What we are doing: Send normalized firewall logs to the Splunk indexer so analytics and AI correlation can operate on full event data. Using TLS ensures logs are not intercepted or tampered with in transit — important in production for integrity.
configure terminal
logging host management 10.1.1.20 transport tcp port 6514
logging source-interface GigabitEthernet0/0
logging permit-hostdown
end
write memory
What just happened: The firewall will open a TLS-capable syslog stream to 10.1.1.20 on TCP/6514 using the management interface GigabitEthernet0/0 as the source. "logging permit-hostdown" (where available) allows logging even if the management plane is impaired. Persisting the config saves it across reloads. At protocol level, the firewall establishes a TCP session and negotiates TLS before transmitting events; Splunk will receive events in raw text and parse them using configured sourcetypes.
Real-world note: Use TLS syslog in production. UDP syslog can drop packets during spikes, losing critical forensic evidence.
Verify:
show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, xml disabled, filtering disabled)
Logging source-interface: GigabitEthernet0/0
Syslog server: 10.1.1.20 transport tcp port 6514
TLS: enabled for syslog
Step 2: Register AI Security Cloud (XDR) with the firewall via API token
What we are doing: Create an API token on the firewall and register the AI Security Cloud (10.1.1.10) so the cloud can ingest events and request policy analysis. Token-based auth is preferred to username/passwords for automation.
configure terminal
api token create name XDR-Integration scope read-write
api token show name XDR-Integration
end
write memory
What just happened: The firewall created a scoped token named XDR-Integration with read-write permissions and displayed its metadata (but not the secret). The token will be used by the AI cloud to call the firewall API to fetch events or apply automated changes. At the protocol level, API calls will contain the token in an Authorization header and be accepted by the firewall's management API.
Real-world note: Store tokens securely (vault) and rotate them on schedule; use least-privilege scopes for automation.
Verify:
show api tokens
Token Name: XDR-Integration
Scope: read-write
Created On: 2026-03-01 12:00:00
Expires On: 2027-03-01 12:00:00
Status: active
Step 3: Enable Policy Analyzer & Optimizer integration on the AI cloud
What we are doing: Tell the AI Security Cloud to analyze firewall policies automatically; the cloud will periodically fetch policy configuration (via the API token) and generate hygiene suggestions (e.g., overlapping rules). Automating analysis lets teams proactively find misconfigurations before they cause risk.
configure terminal
integration policy-analyzer add firewall 10.1.1.1 token XDR-Integration
integration policy-analyzer schedule firewall 10.1.1.1 interval 24h
end
What just happened: The AI cloud now has a registered integration with the firewall at 10.1.1.1 and will synchronize the rulebase every 24 hours. The analyzer compares rule order, overlapping permits vs denies, and highlights overly-permissive entries. From a behavior perspective, the analyzer pulls policy via the firewall API, models packet flows against rules, and looks for anomalies like shadowed rules or broad "any" permits.
Real-world note: Run policy analysis during low-change windows at first; changes recommended by automation should be vetted before enforcement.
Verify:
show integration policy-analyzer status
Integration: policy-analyzer
Firewall: 10.1.1.1
Last sync: 2026-03-02 03:15:00
Next scheduled sync: 2026-03-03 03:15:00
Pending recommendations: 5
Recommendation types: overlapping-rules, overly-broad, redundant
Step 4: Create an automated incident playbook to quarantine a host
What we are doing: Define a playbook in the AI platform that, when an incident reaches a high confidence threshold, performs three automated steps: (1) add a temporary deny rule for the offending IP, (2) open a ticket to the ticketing system, (3) notify the security team. This automates containment, documentation, and escalation.
configure terminal
playbook create name Quarantine-Host
playbook Quarantine-Host action add-firewall-rule firewall 10.1.1.1 rule-name "AUTO-QUARANTINE-{{host_ip}}" src {{host_ip}} dst any action deny timeout 3600
playbook Quarantine-Host action create-ticket system 10.1.1.30 template "Auto Quarantine - {{host_ip}}"
playbook Quarantine-Host action notify method email to secops@lab.nhprep.com subject "Quarantine Triggered for {{host_ip}}"
playbook Quarantine-Host set-trigger confidence >= 90
playbook Quarantine-Host enable
end
What just happened: The playbook named Quarantine-Host has been created and enabled. When the AI cloud detects an incident with confidence >= 90% involving a particular host, the playbook will issue API calls to the firewall to insert a temporary deny rule (AUTO-QUARANTINE-
Real-world note: Use temporary timeouts and automated rollback to avoid long-term service disruption from false positives.
Verify:
show playbook Quarantine-Host
Playbook Name: Quarantine-Host
Status: enabled
Trigger: incident.confidence >= 90
Actions:
1) add-firewall-rule firewall 10.1.1.1 rule AUTO-QUARANTINE-{{host_ip}} timeout 3600
2) create-ticket system 10.1.1.30 template "Auto Quarantine - {{host_ip}}"
3) notify email secops@lab.nhprep.com
Last run: 2026-03-02 04:21:10 (no actions taken yet)
Step 5: Test an incident flow (simulate suspicious traffic and validate automation)
What we are doing: Generate a simulated alert that mimics a high-confidence malicious host to exercise the end-to-end automation: ingestion, correlation, recommendation, and automated action. Testing validates that automated controls and notifications work without waiting for a real incident.
configure terminal
simulate incident create type network-anomaly host 192.168.100.50 confidence 95 source firewall 10.1.1.1
end
What just happened: A simulated incident was injected into the AI cloud with confidence 95 for host 192.168.100.50. This should trigger the Quarantine-Host playbook because the confidence threshold is met. The AI cloud will call the firewall API to add the deny rule and create a ticket. Simulations let you validate orchestration and rollback safely.
Real-world note: Always test playbooks in a staging environment or with safe simulations before production enablement.
Verify:
show incidents recent
Incident ID: INC-20260302-0001
Type: network-anomaly
Host: 192.168.100.50
Confidence: 95
Playbook executed: Quarantine-Host
Actions taken:
- Firewall rule AUTO-QUARANTINE-192.168.100.50 added to 10.1.1.1 (expires in 3600 seconds)
- Ticket created: TCK-20260302-45 on 10.1.1.30
- Notification sent to secops@lab.nhprep.com
Verification Checklist
- Check 1: Firewall sends logs to Splunk — verify with
show loggingon firewall and confirm events appear in Splunk search for sourcetype=firewall over the last 15 minutes. - Check 2: Policy Analyzer sync is active — verify with
show integration policy-analyzer statusand confirm Last sync is recent and Pending recommendations > 0. - Check 3: Playbook execution operates properly — simulate an incident and verify a deny rule appears on the firewall and a ticket is created on the ticketing system.
Common Mistakes
| Symptom | Cause | Fix |
|---|---|---|
| No logs seen in Splunk | Firewall syslog uses UDP or wrong port; TLS mismatch | Reconfigure logging to TCP/TLS on port 6514; verify certificate/trust on both sides |
| API calls failing with 401/Forbidden | Token not registered, expired, or wrong scope | Recreate token with correct scope, register it in AI cloud, and rotate into integration config |
| Playbook ran but rule not applied | Firewall API returned error or playbook mis-constructed | Check show api tokens and firewall audit logs; ensure rule syntax is correct and playbook action has correct firewall IP |
| False-positive quarantines | Overly-aggressive playbook trigger or low-quality detection threshold | Increase confidence threshold, add whitelist or manual-approval step in playbook |
| Recommendations show "overlapping-rules" but no fix applied | Policy Analyzer only recommends changes by default | Review recommendations and apply approved changes manually or enable automated enforcement after pilot validation |
Key Takeaways
- Exporting rich telemetry (TLS syslog or API) to analytics platforms is foundational — without logs, AI can't reason about incidents.
- Policy Analyzer finds hidden misconfigurations (shadowed/overly-broad rules); automation should recommend changes but require staged rollout to prevent outages.
- Playbooks automate containment and documentation (deny rules + ticketing) — always include safeties like timeouts and approval gates.
- Use tokens and TLS for integrations, follow least privilege and rotate credentials regularly.
- In production, adopt a phased approach: ingest logs → analyze passively → pilot automated suggestions → enable safe automation with monitoring.
Tip: Treat the AI assistant as a powerful analyst — it speeds remediation, but human oversight during initial deployment is critical to prevent automation-induced outages.