Ten reasons you will be unhappy with your SIM solution – and how to avoid them

As the market matures we are increasingly being contacted by prospects that are looking not to implement SIM technology, but instead are looking to replace existing SIM technology. These are people that purchased a couple of budget cycles ago, struggled with their selection and are now throwing up their hands in frustration and moving on. From a high level, the reason for this adoption failure was not that SIM was bad or unnecessary. These people were, and remain, convinced of the benefits of a SIM solution, but at the time of their initial purchase many did not have a detailed understanding of both their business and technical requirements, nor a clear understanding of the actual investment in time and effort necessary to make their SIM implementation a success.

For new prospects just getting into SIM – is there a lesson to be learned from these people? The answer to that is a resounding “yes”, and it is worthwhile digging a little deeper than a generic “understand your requirements before you buy” (that is a really good thing, but a bit obvious!), and let you hear some of the more common themes we hear.

Just as a bit of stage setting, the majority of the customers Prism serves tend to be what are classically called SMEs (Small and Medium Enterprises). Although a company might be considered SME, it is not uncommon today for even smaller enterprises to have well in excess of a thousand systems and devices that need to be managed. Implementing Security Information Management (SIM) poses a special challenge for SMEs, as events and security data from even a thousand devices can be completely overwhelming. SMEs are “tweeners” – They have a relatively big problem (like large enterprises), but less flexibility (in terms of money, time and people) to solve it. SMEs are also pulled by vendors from all ends of the spectrum – you have low end vendors coming in and positioning very inexpensive, point solutions, and very high-end vendors pitching their wares, sometimes in a special package for you. So the gamut of options are very, very broad.

So here they are, the top 10, in no particular order as we hear these all too frequently:

  1. We did not evaluate the product we selected. The demo looked really good and all the reviews we read were good, but it just did not really fit our needs when we actually got it in house.
  2. Quite frankly during the demo we were so impressed by the sizzle that we never really looked at our core requirement in any depth. The vendor we chose said everyone did that and not to worry — and when we came to implement we found that the core requirement was not near as good as the sizzle we saw. We ended up never using the sizzle and struggling with the capability we really should have looked at.
  3. We evaluated the product in a small test network, and were impressed with results. However, deployment on a slightly larger scale was disappointing and way more complicated.
  4. A brand name or expensive solution did not mean a complete solution.
  5. We did not know our security data profile or event volumes in advance. This prevented us from running load or stress tests, but the vendor response was “don’t worry”. We should have. The solution scoped did not scale to our requirements, and the add-ons killed us as we were out of the cheap entry level bundles.
  6. Excessive false positives were generated by the threat analysis module of the SIM solution. It was too complicated to tune, and we failed to detect a real threat when it happened.
  7. Deployment was/is a nightmare, and we lacked the tools necessary to manage and maintain the solution. Professional Services was not in the budget.
  8. Once we gained experience with the product and decided to tune it to meet evolving business objectives, we found the architecture inflexible and licensing limitations in terms of the number of consoles and the separation of duties. In order to meet our new business requirements it was just too expensive, and we were annoyed at the vendor as this was not what they represented to us at all.
  9. We bought on the cheap, and realized the solution does not scale up. It works very well in a small domain with limited requirements but beyond that the solution is wanting.
  10. We bought the expensive solution because it had a lot of cool stuff we thought we would use, but the things we really needed were hard to use, and the stuff we really didn’t need, but impressed the heck out of us at demo time, we are never going to get to.


Is it better to leave some logs behind?

Is it better to leave some logs behind? Log management has emerged in the past few years as a must-do discipline in IT for complying with regulatory standards, and protecting the integrity of critical IT assets. However, with millions of logs being spit out on a daily basis by firewalls, routers, servers, workstations, applications and other sources across a network, enterprises are deluged with log data and there is no stemming the tide.