Two new resources about logging, log management and SIEM , written by myself, have just been published.
“The Complete Guide to Log and Event Management” (a lofty title, I know) was written for Novell Sentinel team (this doc is behind the sign-up form, but it is totally worth it :-)) BTW, if you mistakenly wrote off Sentinel from the SIEM battlefield, you are sadly mistaken!
Quote:
“What happens after an organization deploys a log management tool and starts using it effectively for security and compliance as well as operational purposes? The natural and logical progression is for organizations to graduate to near-real-time event management by deploying a SIEM tool.
This paper is the first document that formulates “graduation criteria” for such development. Organizations that graduate too soon will waste time and effort, and won't any increased efficiency in their security operation. However, waiting too long also means that the organization will never develop the necessary capabilities to secure themselves.
[…]
One of the paramount conclusions from this work it to remember that everybody has logs and that means that everybody ultimately needs log management. In its broadest form, log management simply means “dealing with logs.” And if you have logs you have to deal with them – if only because many recent regulatory mandates prescribe that.
It's also important to remember that logs are used for a very large number of situations: from traditional (incident response) to highly esoteric. Most of such uses of logs happen much later, after the event happens and is recorded in logs. It is much easier to be prepared to respond then to monitor.
Your organization might need to go “back to logging school” before it is ready to “graduate to SIEM.” Such graduation requires an ability to respond to alerts and customize and tune products.”
“PCI Logging HOWTO” (part 1) was written for Prism Microsystems, the home of 100 Uses for Log Management.
Quote:
“To satisfy those requirements, it is recommended that an organization create “PCI System Log Review Procedures” and related workflows that cover:
- Log review practices, patterns and tasks
- Exception investigation and analysis
- Validation of these procedures and management reporting.
[…]
First, do determine the scope for PCI compliance, including systems, databases that store the data, application that process the data, network equipment that transmits unencrypted card data as well as any system which is not separated from the above by the firewall. In the case of so-called “flat network”, the entire IT environment is in scope and thus must be made compliant by implementing DSS controls.
Second, identify system components that touch the data: apart from the operating systems (Windows or Linux, for example) databases and web servers need to considered as well as payment application, middleware, Point-of-Sale (PoS) devices, etc.
Next, a logging policy must be created. PCI-derived logging policy should at least cover logged event types for each application and system deployed as well as details for all systems in scope for PCI DSS. For custom applications, this logging policy needs to be communicated to internal or outsourced developers.”
Enjoy! And make sure you remember that I am available for consulting projects to deliver value to your organization as well.
Possibly related posts:
