Enriching SIEM and SOC Workflows with Real-Time IP Intelligence
Modern Security Operations Centers (SOC) face a critical challenge: data volume vs. data context. While Security Information and Event Management (SIEM) systems ingest terabytes of logs, raw IP addresses offer limited actionable insight. Without enrichment, an IP is just a number; enriched, it becomes a distinct indicator of compromise (IoC) or a verified user.
This guide outlines the technical implementation of integrating IP intelligence—specifically VPN, proxy, and ASN data—into SOC workflows to automate threat detection and reduce Mean Time to Response (MTTR).
The value of Context: Beyond Geo-Location
Traditional IP enrichment focuses heavily on GeoIP. While necessary for compliance, GeoIP is insufficient for threat detection. Sophisticated attackers utilize Residential Proxies (ResIPs) and VPN services to mask their origin.
To filter noise effectively, SOC automation requires granular attributes:
- Connection Type: Is the IP a datacenter exit node, a residential line, or a mobile carrier?
- Privacy Status: Is the traffic routing through Tor, a commercial VPN, or a public proxy?
- ASN Trust: Does the Autonomous System Number belong to a hosting provider (high risk for user traffic) or a consumer ISP?
Integration Strategies for SIEM Pipelines
There are two primary architectural points for integrating IPASIS data into a SIEM (Splunk, ELK, Datadog):
- Ingest-Time Enrichment: Decorate logs as they enter the pipeline (e.g., via Logstash filters or fluentd plugins). This increases storage requirements but enables instant historical search.
- Query-Time Enrichment: Enrich data dynamically when an alert triggers. This is preferred for high-volume streams to reduce API cost and latency.
Implementation: Python Automation Script
The following Python snippet demonstrates a SOAR (Security Orchestration, Automation, and Response) function. It takes a suspicious IP triggered by a failed login attempt and queries IPASIS to determine if the user is masking their identity.
import requests
import json
def analyze_ip_risk(ip_address, api_key):
url = f"https://api.ipasis.com/v1/{ip_address}"
headers = {"X-Api-Key": api_key}
try:
response = requests.get(url, headers=headers, timeout=2)
response.raise_for_status()
data = response.json()
# Risk Logic
risk_score = 0
signals = []
if data.get('is_proxy') or data.get('is_vpn'):
risk_score += 50
signals.append("Anonymizer Detected")
if data.get('is_tor'):
risk_score += 100
signals.append("Tor Exit Node")
if data.get('asn', {}).get('type') == 'hosting':
risk_score += 30
signals.append("Hosting Provider ASN")
return {
"ip": ip_address,
"risk_score": risk_score,
"signals": signals,
"details": data
}
except requests.exceptions.RequestException as e:
return {"error": str(e)}
# Example usage within a Lambda or Tines workflow
result = analyze_ip_risk("45.33.22.11", "YOUR_IPASIS_KEY")
if result['risk_score'] > 75:
print(f"[ALERT] High Risk Login Attempt: {json.dumps(result)}")
Detecting Impossible Travel and Account Sharing
Static rules often fail when users travel legitimate business routes. By combining Geo-velocity with ISP context, you can reduce false positives.
Logic Flow:
- User logs in from London (IP A).
- User logs in 30 minutes later from New York (IP B).
- Check: Is IP B a VPN endpoint?
- If Yes: The user likely engaged a corporate VPN. Lower the alert severity.
- If No: This is physically impossible travel. Trigger account lockout.
Node.js Middleware for Request Tagging
For engineering teams building internal dashboards or API gateways, tagging requests with IP metadata before they hit the logging layer is highly effective.
const axios = require('axios');
const ipEnrichmentMiddleware = async (req, res, next) => {
const clientIp = req.headers['x-forwarded-for'] || req.socket.remoteAddress;
try {
// Simple in-memory cache check recommended here to save API calls
const response = await axios.get(`https://api.ipasis.com/v1/${clientIp}?key=YOUR_KEY`);
const { is_crawler, is_vpn, isp } = response.data;
// Attach context to the request object for logging mechanisms (Winston/Morgan)
req.securityContext = {
is_crawler,
is_vpn,
isp
};
if (is_vpn && req.path === '/admin') {
console.warn(`[SECURITY] VPN access to admin panel from ${clientIp}`);
}
} catch (error) {
console.error('IP enrichment failed', error.message);
}
next();
};
Use Case: Preventing Credential Stuffing
Credential stuffing attacks often rotate IPs rapidly. However, attackers rely on cheap proxy infrastructure. By analyzing the connection_type and asn of failed login bursts, you can write SIEM rules that block entire ASN blocks or connection types rather than playing whack-a-mole with individual IPs.
Rule Example:
IF (failed_logins > 10/min) AND (ip.is_proxy == true) THEN Block_IP
FAQ
Q: Should I enrich every single log entry? A: No. Enriching every HTTP request is cost-prohibitive and adds latency. Enrich logs at the "edge" (firewall) or only for specific events: authentication attempts, payment transactions, and admin portal access.
Q: How does IPASIS handle latency? A: IPASIS is designed for real-time applications with sub-50ms response times. However, for synchronous blocking flows, we recommend implementing a local LRU cache (TTL 10-60 minutes) to minimize network overhead for repeat visitors.
Q: Can I use this for whitelisting? A: Yes. Many SOCs whitelist specific ISP ASNs (e.g., residential broadband providers in the company's operating region) and flag traffic coming from hosting/datacenter ASNs as suspicious.
Conclusion
Raw logs are noise; enriched logs are intelligence. By integrating IPASIS into your SIEM or SOAR pipeline, you transform reactive logging into proactive threat hunting.
Ready to secure your infrastructure? Get your free IPASIS API Key and start enriching your data today.