Common Event Format (CEF)¶
Product - Various products that send CEF-format messages via syslog¶
Each CEF product should have their own source entry in this documentation set. In a departure from normal configuration, all CEF products should use the “CEF” version of the unique port and archive environment variable settings (rather than a unique one per product), as the CEF log path handles all products sending events to SC4S in the CEF format. Examples of this include Arcsight, Imperva, and Cyberark. Therefore, the CEF environment variables for unique port, archive, etc. should be set only once.
If your deployment has multiple CEF devices that send to more than one port, set the CEF unique port variable(s) as a comma-separated list. See Unique Listening Ports for details.
The source documentation included below is a reference baseline for any product that sends data using the CEF log path.
| Ref | Link |
|---|---|
| Splunk Add-on CEF | https://bitbucket.org/SPLServices/ta-cef-for-splunk/downloads/ |
| Product Manual | https://docs.imperva.com/bundle/cloud-application-security/page/more/log-configuration.htm |
Splunk Metadata with CEF events¶
The keys (first column) in splunk_metadata.csv for CEF data sources have a slightly different meaning than those for non-CEF ones.
The typical vendor_product syntax is instead replaced by checks against specific columns of the CEF event – namely the first,
second, and fourth columns following the leading CEF:0 (“column 0”). These specific columns refer to the CEF device_vendor,
device_product, and device_event_class, respectively. The third column, device_version, is not used for metadata assignment.
SC4S sets metadata based on the first two columns, and (optionally) the fourth. While the key (first column) in the
splunk_metadata file for non-CEF sources uses a “vendor_product” syntax that is arbitrary, the syntax for this key for CEF
events is based on the actual contents of columns 1,2 and 4 from the CEF event, namely:
device_vendor_device_product_device_class
The final device_class portion is optional. Therefore, CEF entries in splunk_metadata can have a key representing the vendor and
product, and others representing a vendor and product coupled with one or more additional classes. This allows for more granular
metadata assignment (or overrides).
Here is a snippet of a sample Imperva CEF event that includes a CEF device class entry (which is “Firewall”):
Apr 19 10:29:53 3.3.3.3 CEF:0|Imperva Inc.|SecureSphere|12.0.0|Firewall|SSL Untraceable Connection|Medium|
and the corresponding match in splunk_metadata.csv:
Imperva Inc._SecureSphere_Firewall,sourcetype,imperva:waf:firewall:cef
Default Sourcetype¶
| sourcetype | notes |
|---|---|
| cef | Common sourcetype |
Default Source¶
| source | notes |
|---|---|
| Varies | Varies |
Default Index Configuration¶
| key | source | index | notes |
|---|---|---|---|
| Vendor_Product | Varies | main | none |
Filter type¶
MSG Parse: This filter parses message content
Options¶
| Variable | default | description |
|---|---|---|
| SC4S_LISTEN_CEF_UDP_PORT | empty string | Enable a UDP port for this specific vendor product using a comma-separated list of port numbers |
| SC4S_LISTEN_CEF_TCP_PORT | empty string | Enable a TCP port for this specific vendor product using a comma-separated list of port numbers |
| SC4S_LISTEN_CEF_TLS_PORT | empty string | Enable a TLS port for this specific vendor product using a comma-separated list of port numbers |
| SC4S_DEST_CEF_HEC | no | When Splunk HEC is disabled globally set to yes to enable this specific source |