I've been evaluating the operational overhead of integrating external data sources into Splunk Enterprise Security (ES) for threat detection. A common recommendation is to use a low-interaction honey pot, like Cowrie, to generate attacker logs. The setup process reveals quite a bit about ES's data handling and CIM compliance requirements.
The core task involves three distinct phases: generating the logs, normalizing them for the Common Information Model (CIM), and creating a correlation search. Here's a condensed workflow from my test lab.
First, the log ingestion. After deploying Cowrie on a separate VM, the key is to configure `props.conf` and `transforms.conf` on the Universal Forwarder or Heavy Forwarder to break the Cowrie JSON into CIM-compliant fields. A critical extractor for the session field:
```
# In props.conf
[source::.../cowrie.json*]
KV_MODE = json
REPORT-cowrie_fields = cowrie_extractions
# In transforms.conf
[cowrie_extractions]
REGEX = "session":"(?P[^"]+)"
FORMAT = session_id::$1
```
Without this explicit field extraction, events will not map to the `Authentication` or `Intrusion Detection` data models, rendering them invisible to ESCU searches and dashboards.
Second, the normalization pipeline. Simply ingesting the logs is insufficient. You must ensure the sourcetype is tagged to populate the necessary data model accelerations. I created a custom `cowrie` sourcetype and added it to the `ids` and `authentication` data model aliases via the ES Data Model UI. The most time-consuming part was aligning field names—Cowrie's `src_ip` maps to `src`, `username` maps to `user`, etc.
Finally, the detection logic. A simple yet effective correlation search to flag multiple failed logins across different honey pot sessions:
```
| tstats `summariesonly` count from datamodel=Authentication where Authentication.action=failure by Authentication.src _time span=1h
| stats count as failure_count by Authentication.src
| search failure_count > 5
```
**Key Observations:**
* The setup is backend-heavy, requiring precise Splunk SPL knowledge for data normalization.
* Time-to-value is delayed; you must wait for data model acceleration before any meaningful detection.
* The benefit is that once normalized, the data works seamlessly with ES's correlation engine and security domain dashboards.
For teams already invested in the Splunk ecosystem, the integration is powerful. However, the initial configuration complexity is a significant barrier compared to more turnkey SIEM solutions. The true cost is in the ongoing maintenance of these custom data pipelines.
benchmark or bust
benchmark or bust