Cisco Secure eStreamer Client (f.k.a Firepower eNcore) Add-On for Splunk
Overview
Details
The following event types are supported with complete schema coverage through the eStreamer API specification for Threat Defense Manager version 6.2+.
• Discovery Events
• Correlation and White List Events
• Impact Flag Alerts
• Intrusion Events
• Intrusion Event Packet Data
• User Activity
• Intrusion Event Extra Data
• Malware Events
• File Events
• Connection Events
This app was developed for and tested on Linux platforms only. Windows support is not currently available. Please check with Cisco for any change in status.
Secure eStreamer Client (f.k.a. eNcore) for Splunk is a plugin based eStreamer client built from scratch in Python designed to deliver fully qualified event data to Splunk from Secure Firewall (f.k.a. Firepower) 6.x platforms. If you have experienced problems getting the Cisco eStreamer for Splunk app version 2.2.1 and 2.2.2 working with Secure Firewall 6.x you should move to this new application so that you can leverage the many improvements listed below.
Secyre eStreamer Client for Splunk is a Technical Add-on (TA) designed purely to collect data and be installed on a forwarder.
New in this solution:
- Complete API Coverage: Allows Splunk to collect all Secure Firewall event data via the eStreamer API from Threat Defense Manager version 6.x. Note: Will not work with Secure Firewall version 5.x
- Plugin Architecture: Combines the Python ‘Client’ with a Splunk plugin to write data into Splunk in the Splunk format
- Dashboard Support: Backwards compatible with older solution’s dashboards A new version of the dashboard is available here: https://splunkbase.splunk.com/app/3663/
- Full Event Qualification: Client writes clear text for all of the eStreamer API’s referential model
- Comprehensively Documented: Detailed Operations Guide is available here: https://www.cisco.com/c/en/us/td/docs/security/firepower/70/api/eNcore/eNcore_Operations_Guide_v08.html
For Splunk 7.x and TA version 3.x use https://www.cisco.com/c/en/us/td/docs/security/firepower/630/api/eStreamer_enCore/eStreamereNcoreSplunkOperationsGuide_354.html - Multi-Process Design: Will scale with additional compute resources to support event rates
- Cisco TAC Support Option Available: Optional TAC support service available with identical paid version purchased from Cisco. Order details: FP-SPLUNK-SW-K9 Free to use otherwise.
Resolved Issues in V 3.5.0
- An issue where Security Intelligence Category was not populating properly in Connection events. It is now populating correctly.
- An issue where the egress interface was populating with the id instead of the interface name in Intrusion events. It is now populating with the name.
- An issue where the fw_policy field name was appearing in Splunk file event output even though the firewall policy name is not part of the file event. The field name has been removed.
- An issue where the log reported a process poll timeout error even though the process is healthy and operating normally. The issue has been corrected.
- An issue where the name of the source user field was not populating correctly in connection events, intrusion events, file events, and malware events. The field is now populating correctly.
- An issue where the sid field in intrusion events was populating with an "internal sid" instead of the "rendered sid". If a user imports a custom rule file with rules that specify the sid, that sid is the "rendered sid" that appears in the FMC interface. The sid field in intrusion events is now populated by the rendered sid.
- An issue where the DNS Query field in connection event was not populating correctly. It is now populating correctly.
- An issue where in malware events, the virus name/detection name field was not populating correctly. It is now populating correctly.
- An issue where eNcore reported the following error: "UnicodeEncodeError: 'ascii' codec can't encode characters … ". The issue has been resolved.
- An issue where the packet payload output included layer 2-4 headers for TCP and UDP packets. The issue has been corrected and only the payload (without the layer 2-4 headers) appears in the payload field.
- An issue where in correlation events, the cs1 field (for access control policy name) was populating with the uuid instead of the name. The issue has been corrected.
Release Notes
Version 4.8.3
Added support for Splunk status in .splencore.sh script
Fixed App Inspect failure due to no default settings in app.conf for estreamer.conf reload triggers
Version 4.8.2
*Added additional error handling for local cache storage
Version 4.8.1
*Fixed bug associated with "JSON settings error" in estreamer.log which would periodically stop the encore process since the configuration file could not be read into memory.
*Specifically modified the 'stop' command to safely terminate existing estreamer python connections to the FMC
More Detail: This latest update, v4.8.1 in Splunkbase, should provide more robust handling of the FMC connection, and eliminate the "JSON settings error" from the encore logs. Additionally, we have created CSCvz51007 to address the potential FMC condition of reaching too many client connections. I would highly encourage an update to 4.8.1 if you are seeing any timeout issues, as always please reach out to our mailer here if you are experiencing problems or create a Cisco Support TAC case so we can promptly investigate.
Version 4.7.1
*Modified the ./splencore.sh stop command to wait for TCP termination vs pkill, this is likely the issue behind "JSON settings" error and additional idle timeouts as the FMC server was receiving multiple session requests before older sessions were properly terminated
Version 3.8.8
*Fixed incorrect value in the disposition field for malware events
Version 4.6.4
*Fixed incorrect disposition field value in malware events
Version 4.6.3
Fixed errors in the stop command which not consistently terminate encore processes and remove pid files
Modified handling of XFF events
Version 4.6.1
*Modified clean script which is believed to cause issues with the bug "Invalid JSON settings"
Version 3.8.7
*Updated stop script for multi-thread mode
Version 4.6.0
Added additional transforms to the props.conf to support dashboard 1.60 updates
Modified the stop utility to remove temporary pid file and terminate all estreamer client processes, whereas in versions this only worked in single thread mode
Version 3.8.0
Added support for VPN connection events, record types 170/171, user login/logoff attempts
Added additional fields to support XFF HTTP URI events
Version 3.7.5
Fixed encoding bug "UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0' in position 20: ordinal not in range(128)"
Updated multiple rec types with src_host_ip field, this requires FMC host discovery policy to be set
Version 3.7.4
Added "src_host" field to multiple record types, this field provides traceability do the original host ip.
Version 4.0.9
*4.0.9 Update
Removed ORIGINAL SOURCE IP error, this potentially would cause applications errors due to the reference of a non-existent data type. Please reference the full setup guide for Splunk 8.0/Cloud changes
Version 4.0.8
Splunk 8.0 release, please see full guide for install/setup details
4.0.8 includes
reordered event format to include time in the beginning of the record, reset default MAX_LOOKAHEAD accordingly for increased performance
Version 3.7.1
Encore version 3.x support only legacy Splunk 7.x with python2
Modified event structure to include event_sec in the beginning of the record for increased performance
*Added additional ipv6 formatting for XFF events
Version 3.6.8
Corrected performance issues associated with outputting various pcap data types, this feature will be revised and re-released in a future version
Modified definition of event_sec for connection events, in the FMC all connection events start at first packet time which is now the value used for indexing. The first_pkt_sec field is still preserved to support backward compatibility.
*Fixed bug with the initiatorIpAddress field in correlation events
Version 3.5.8
Project Summary
This is the rewrite for the SourceFire eStreamer client.
The Cisco Event Streamer (also known as eStreamer) allows you to stream System intrusion,
discovery, and connection data from Firepower Management Center or managed device (also
referred to as the eStreamer server) to external client applications.
eStreamer responds to client requests with terse, compact, binary encoded messages – this
keeps it fast
eNcore is a new all-purpose client which requests all possible events from eStreamer, parses
the binary content and outputs events in various formats to support other SIEMs
*Updates for 3.5.8
*Bug fix - microseconds on pcap data now use the proper field name 'upacket_sec', and seconds use 'packet_sec'
Version 3.5.7
Version 3.5.7 Updates
*Added back aliasing for action/blocked fields
Version 3.5.6
Version 3.5.6 Updates
Removed default disabling of the cisco:estreamer:data source type
Removed duplicate aliasing for action/blocked fields
Version 3.5.4
- Fixed encore settings which did now allow for control the writing of metadata
- Added additional notes to readme to address performance improvements and the use of worker processes/batchSizes
Version 3.5.3
eNcore v3.5.3 resolves issues with previous v3.5.x versions where eNcore would crash under certain conditions.
All eNcore v3.5.x versions provide significant performance enhancements over pre-v3.5 versions.
Version 3.5.1
Version 3.5.0
eNcore version 3.5.0 features performance improvements – the ability to process a significantly higher event rate. This improvement requires no additional configuration on the part of the user.
However, if the eNcore platform has four or more cores, then additional performance improvement can be gained by adjusting a parameter in the configuration file, estreamer.conf. This parameter is called “workerProcesses” and is highlighted below:
{
"connectTimeout": 10,
"enabled": true,
"workerProcesses": 4,
"handler": {
--- rest of config file omitted ---
The highlighted line shows the “workerProcesses” to be set at 4. It can be set anywhere from 4-12, but with four or more cores, testing showed the best performance when set to 12.
See Details section for more Release Notes on Version 3.5.0