11 Log Management WORST Practices
Friday, January 14th, 2011 | Author:

by Brian Singer on January 11, 2011 in Log Management

Many organizations often talk about “best practices” for security, log management, SIEM, etc.  The definition of “best” practice is often fuzzy but can be loosely tied to what leaders in the field are doing today, and which practices will 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:

  1. Skipping the requirement definition stage when purchasing SIEM is one of the worst, albeit common, practices organizations can take. It almost always leads to failed SIEM projects, needs being unmet 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 disastrous 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 a tool can be 30% cheaper, while “only” twice as bad…
  4. 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 is performing well for somebody else. Skipping Proof-of-concept is even worse- that is your best chance 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 requirements 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 one of the worst practices. SIEM touches systems, network devices, possibly IdM systems and even applicationsand databases – 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 (and possibly end up in an orange jumpsuit), 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. Building reports and correlation rules also requires intricate knowledge of the vendors systems and taxonomy, even if you are a level 9 SIEM ninja. The vendor or consultants can teach you how to resolve many of these challenges and be more productive with their tools, based on their experience with other customers.
  10. Not checking for changing 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”…

Contributed by: http://logmanagementcentral.com/11-log-management-worst-practices-anton-chuvakin-guest-post/

Category: Log Management