FYI, this piece has been especially created for LogManagementCentral (original post). It is reposted here for posterity.
Many organizations talk about “best practices” for security, log management, SIEM, etc. The definition of such practice is often fuzzy (and overrun by marketing influences…) but can be loosely related to what leaders in the field are doing today and what practices generally lead to great results. Following the same model, we can create a definition of a “worst practice”:
· What the losers in the field are doing today
· A practice that generally leads to disastrous results, despite its popularity
Here are some of the “worst practices” in the area of SIEM and log management that I have observed over the years:
1. Skipping the requirement definition stage of SIEM purchase is one of the worst, albeit common, practices one can take. It almost always leads to failed SIEM projects, unmet needs for customers as well as unjustified anger aimed at technology providers. “John said that we need a correlation engine” is not the way to define your requirements, by the way.
2. Postponing the environment sizing until the purchase is another generally disastrous practice. Even if you plan to eventually collect “everything”, the initial implementation will only have a specific smaller set of data. Careful sizing of that initial phase by watching your logs for a week or two is very important.
3. Choosing by price alone has led to many wrong purchases – and not only in the realm of SIEM. SIEM and log management products are priced from $0 to a few hundred to millions – and there is usually a difference in both capability and scalability between tools with dramatically different prices. Remember that tool can be 30% cheaper, but be “only” twice as bad…
4. “Saving time” by not checking references is another common bad practice at purchase stage. Your environment might be unique, but references is one of the few ways to know that the tool you’re planning to purchase has the will of somebody else. Skipping Proof-of-concept is even worse- that is your way to test a complex new tool in your environment!
5. Expecting the vendor to tell you what you need to log happens more frequently than you might think. Sadly, the only person who knows your needs and requirement for logging, log management and log monitoring is you – not the vendor. If you don’t know – then nobody does.
6. SIEM implementation is often a very “political” affair and thinking you can do it alone without involving others from you organization is definitely the worst practices. SIEM touches systems, network devices, possibly IdM systems and many other components – each with their own business owners and administrators. These people and teams have to be involved in SIEM implementation; and there is no way around it. Preparing the infrastructure is key for the deployment, even if you simply need to make sure that all log source systems has their time synchronized.
7. Ignoring your legal team is a quick way to FAIL with SIEM, especially if your project covers log data from multiple countries. Log data is covered by a conflicting laws and regulations and only your organization legal counsel can figure it out.
8. Deploying everywhere at once and not in phases is a way to run out of budget, management patience and other resources. Phased approach – both in terms of log source scope and SIEM capabilities (from simple to more advanced) – is the only way to go. Focus on “quick wins” in each phase.
9. The interface is “intuitive” so who needs training? Avoiding training is not the way to save money on a SIEM tool. SIEM and log management tools connect to many pieces of the infrastructure and applications. The vendor or consultants might teach you how to resolve many of these challenges, based on their experience with other customers
10. Not checking for changed needs as your SIEM implementation expands is another way to fail. Even though your SIEM may have a few problems, it does not necessarily mean that it can solve every problem you have. Notice how some organization deployed log management tools and then had to expand their deployments to full SIEM due to evolving needs. “We made the decision years ago – why fuss over it?” does not work for integration-heavy technologies like SIEM.
11. Finally, expecting immediate reduction in work after deploying a SIEM is unreasonable. Unless you deploy, customize and tune your system, it is likely that you will not see massive resource savings. SIEM is a great example of “to get value you have to work on it” rather than a magic box that “tells you what is wrong”…
What good or bad practices with SIEM and log management can you share?
