Given that, when the PCI-DSS standard refers to the requirement of logging all events on the network, it cannot possibly be referring to the logging of each and every conceivable event. We must interpret that the standard be referring only to “significant events”. As any operator of a SIEM system will tell you that most of what you are logging is pretty much junk anyway. And, you will be required to keep this data for several years. The data will be as voluminous as possible (to satisfy auditors, but also forensics) and each passing year will make that operator more appreciative of how low-cost disk storage has become.
Within the terabytes worth of log data you have collected, there may be a few “significant events.” Hopefully, that number will be low, optimally zero. The other data is okay to log (actually required by auditors) but this data is not necessarily “event data.” It is simply data to support and clarify the more particular and important “event data,” which is what you need for SIEM to be at its most effective state.
Specifically:
- Pertinence. An event is distinguished from other log data based upon its relevance. How interesting is this event? How often does it occur? (It is important to note that, according to the basic tenets of information theory, the relevance of an event goes down the more often it occurs. An event that occurs regularly is not very relevant.)
- Context. The event must have enough of a context to make it understandable. For example, the statement “something very important happened at noon today” has no specific context. It could not be classified as an event by our definition. It may be pertinent (possibly based upon the source of this data), but there is not enough information to call this an event. Contrast the statement with something more specific, such as “You won the state lottery today at noon.” The latter statement is definitely an event, because you now know the context.
- Timeliness. Information cannot really be classified as an event unless it can be associated with a fairly precise time. The more timely the message, the more likely it can be considered an event. For example, stating that some long expected movie release will occur in the fall does not make that film into an event. It is simply information about an event. The actual event occurs at the precise day of the release, which in this case is the eventful movie premier. It has a specific time associated with it. In the best case, the event occurs in real-time.
- Actionability. If information is pertinent, and timely, it must still be actionable to be useful. The event requires something else that logically follows – perhaps further investigation, or corrective action. If a log message is not actionable, it can't really be classified as an event. Note that the event may not actually precipitate an action, but should still be actionable. For example, your birthday is an actionable event, even if you choose not to throw a party.