Support has determined that the correct CEF key name for deviceMacAddress is dvcmac. Please update the doco.
I will open a ticket to have this updated with the correct information for device mac address.
Also, there are 2 other errors in this version which will be addressed as well.
1. The correct key name for "External Id" is "externalId" not "externalID"
2. Request Context is missing from the guide. it's key name is "requestContext"
Sorry for any inconvenience,
And? Has this been fixed into a latest version?
If so, could this latest and greatest be shared?
El mejor ajo
Is the latest version (REV.20 - June 05, 2013) of CEF guide? Any update in 2014?
What are you after mate?
Sent from my iPhone
We are looking into supporting CEF format in our product line.
One question on the "Name" field in the header.
Is it mandatory?
The details are a little more complicated.
Use 'name' descriptively to enhance, differentiate and amplify the specific and unique message that justifies your events existance. And for that play on words also consider populating 'message' with its equally meaningful content.
Now read the CEF guide for explaination on field meanings and also populate other fields, both those that are common, but also maybe things like deviceCustom.... including label to expose the value of your event. Remember that the more you populate and the quality of your consistency enhance the utility of your event, and who knows it might dven then correlate with other event sources.
Sent from my Verizon Wireless 4G LTE Smartphone
Thanks for your quick response. Let me give you some background why I am asking.
We just finished integration with IBM QRadar. They have external file (QIDmap) that contains "Name" and "Description" for each log identified by msg-id.
So we do have such an external text file, but we don't have such info with the log message itself.
We could load this text file in memory and extract the "Name" on the fly when generating CEF header, but that would put some processing burden on our side.
Do you support anything similar to QRadar's QIDmap file? How do other vendors handle this when they did not have such data previously?
Don't know anything about QRadar so won't offer any thoughts.
You may be able to use 'map' files. Search Protect724 and Connector guides (flex?) for topic how-to.
As for 'burden' your point is well taken however to generate 'CEF' the work has to be done somewhere and while you can spend time customizing and maintaining Connector modifications, and I would not steer you away from that unnecessarily, I would opine that you would possibly be better off standing up a 'simple' CEF Syslog Connector and then do all the CEF generation work at your source end and then only forward along to the Connector events that are fully formed CEF formatted.
Just skimming through the FlexConnector Developer's guide, that seems to require more effort compared to complying to the CEF format with syslog from our side.
Since "name" is static information on an event type, it would be nice that can exist outside of the actual log.
Yes the mapping of an event ID to an event name can exist outside of the actual log. It will need to be implemented using a map file.
However, I do agree with Doug that it is best to have the actual log contain all the event details whenever possible. I would recommend only using the map file as a temporary solution. A map file will have to be distributed to a customer and then copied over to a specific folder on their connector. It will have to be updated, re-distributed and re-copied, etc every time you add an event or change an event. If the processing is done prior to the event being sent over, you will not need to maintain the map file.
We are using the JSON output of QRadar and created a JSON parser for capturing the Name and Categorization mapping from QRadar.
Have you looked into this option?
There is a clarity issue, if not outright error in the CEF Guide (version 20). It is so blatant, I'm wondering what is it I am not understanding.
The following is given (on page 6 of the current version of the doc) as the CEF Header format:
CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|[Extension]
The field Signature ID is explained as follows
Signature ID s a unique identifier per event-type. This can be a string or an integer. Signature ID identifies the type of event reported. In the intrusion detection system (IDS) world, each signature or rule that detects certain activity has a unique signature ID assigned. This is a requirement for other types of devices as well, and helps correlation engines process the events.
However, anything placed in this field actually maps to the Device Event Class ID field.
Seems to me this field should be referenced and titled as just that "DeviceEventClassID" to avoid misunderstanding.
In fact, I can find anywhere else in the Arcsight Documentation that even references the term "Signature ID"
(Reported as HP Openview Issue : 4649088876)
This seems like a great question, I'd love to get some confirmation of this.
Yes you are correct that Signature ID does get mapped to Device Event Class ID. Originally I think it was chosen to help clarify what the field actually represented as more people would be familiar with the term "Signature ID" than the term "Device Event Class ID". Not all fields used in CEF are a direct map to the schema field names within ArcSight. For example, the "Severity" field in the CEF header does not map to the "Severity" field within the ArcSight schema. It actually maps to the "Device Severity" field. Similarly, there is no field named "suser" or "duser" in the schema, but rather "Source User Name" and "Destination User Name" (or "Attacker" and "Target" if you want to go there ). However, those fields are listed out in the guide with their full name counterparts, so I can see where the Signature ID could be confusing. I will discuss with the Doc team and see what we can do to make this more clear.
I'm developing something more sofisticated than the "test alert" connector.
So, if i want to send events in CEF format, I can't represent fields like Category Behaviour or Category Outcome?
I know that this categorization is made after the event is received.
Thanks in advance,
Is there a definition for the "art" field available for the doc? (I believe it is agent receipt time - the time the SmartConnector started processing the event - however I'd like to get confirmation.)
Was there any recent release of this document? The document talks about v5 ESM and now we are in ESM6.8.
With ESM6.5/6.8 it seems that some of the fields length are changed and I would like to know if so.
thank you for V22. Just as a side comment it would be nice if the front page continued to carry the document version number, e.g vrsion 22, which I think had been included in the past.
Agree, version control should remain in place.
The version has been added back onto the cover page.
Thank you for the update,
in, out, end are Vertica's keywords.
Should we change them to bytesIn, bytesOut, endTime in the next version?
Retrieving data ...