Monday, November 15, 2010

How to Write an OK SIEM RFP?

Ok, some people think consultants are supposed to make money off helping enterprises write RFPs, but I am busy enough and so it goes. This is what happens if Anton is stuck in a metal tube for 5 hours in seat 1A Smile

Question: How do I go about writing a SIEM or log management RFP?

Quick answer: don’t. This “purchase method” is probably equally hated by vendors and end-users. As somebody who was “volunteered” to help sales folks with 1600 page (yes, really!) and smaller RFPs more than once during my “vendor years,” I can tell you that – with a tongue firmly in cheek:

a) if you ask a vague question in your RFP, you will get either a “Yes” or a nice blurb taken from a random location in vendor datasheet

b) if you ask a question starting with “How…?”, you will get a nice blurb taken from a vendor datasheet

c) if you ask a silly question (“do you have an Albanian language interface?”), you will get either a “Yes” or a nice blurb taken from a random location in vendor datasheet

d) if you ask a question that is impossible to answer (“Can your product handle the high load?”), you will likely get a “Yes” – surprise!

e) if you ask an honest question that might cast a product in a negative light (“will you every lose log data?”), what do you think you will get….?

See a theme emerge here?  Note that I am not trying to imply that any particular vendor would lie in their RFP responses – the term here is “defensible creative exaggeration.” BTW, what do you think happens when a standard enterprises RFP template collides with a standard vendor RFP “boiler plate” response? Boom! The explosion of high-grade concentrated idiocy…  And if you think that I am a bit cynical about this whole thing, than maybe you are correct… making sausage for a long time does distort one’s personality a wee bit Smile

Despite the above, there are two exceptions to this rule of not doing RFPs:

  1. You are obligated to do a RFP (government, etc)
  2. You’d like to use your RFP as a chance to distill and focus your SIEM/LM requirements.

Let’s address them both at the same time. If you are case #1 above, you should really turn it into case #2.  As you recall (if not, review these posts here), one of the most important things an organization should do before buying a SIEM is to set its own goals, requirements, use cases, etc. BTW, this recent SIEM presentation stresses the same point – esp. see slide 16 and around.  This older presentation has some things to avoid at the product selection stage – see “worst practices” 1-4.

So, based on my experience on both sides of the RFP “interface”, here are some of my SIEM RFP tips:

  • Keep it short! If you cannot express what you need in under 10 pages, go back and rethink it. “Every time an organization releases a 500+ page RFP, God kills an intern.” Yes, that very intern who is tasked with responding to that monster, of course.
  • Start from your REAL main reason for getting a SIEM, your problem statement – monitor PCI DSS CDE, perform IDS/IPS alert analysis, monitor servers for suspicious logins, protect web applications via log correlation, etc
  • Include your use cases – which simply means to describe how you plan to use the system and what you expect the system to do for you. Some examples are shown here  (more high level) and here (more detailed inside the whitepaper).
  • Based on your goals and use cases (and that is important!), describe SIEM product functionality that is essential for your mission: agentless collection, bandwidth throttling, rule-based correlation, visual dashboards, trend reports, whatever…
  • Include log sources / devices that you absolutely need supported and what you mean by “supported” (e.g. parsed, normalized, categorized, suitable for correlation, covered by default correlation rules, updated promptly when log source changes, etc). This area is notorious for extra-high volume of “creative exaggeration” (“of course we support VidgetMaster 7.2! – via our generic LogMahgic 1.0 (TM) collector … which  dumps log files right into storage without analysis … and then rotates them to oblivion within 7 days”)
  • Avoid or reduce the usage of vague terms: ”scalable”, “high”, “flexible”, “effective”, “advanced”, “automatic”, “proper”, etc. Why tempt the other side unnecessarily? Smile
  • Clarify most other terms, even those that look clear to you: “correlation”, “reporting”, “keyword search”, “trend”, “responsive”, etc
  • Size the environment before writing an RFP, as we discuss in LogChat #2. Baseline your log sources for 2-4 weeks to get your average EPS rate then include both the volume of data and number of log sources that you absolutely need supported. Also, specify response time for reports and searches while you are at it.
  • Make phases of your SIEM project clear up front – don’t say “400,000 devices and 4,000,000 EPS enterprise-wide.” I got news for you – you probably will never get there… Be very clear about your Phase 1-2 and simply keep later phases in mind for the coming years.
  • Try hard to avoid idiotic statements (sorry!): “Vendor MUST specify their efforts and processes to guarantee that products and services provided will completely satisfy us or exceed our expectations” (quote from a real RFP)

And – hold on to your pants – despite the above effort you should be prepared to take the responses with a HUGE grain of salt. One of my contacts on the enterprise side put it simply: “of course we ignore all the specifics in RFP responses.” Sad smile With this approach to RFP writing, you WILL still benefit even if you don’t read the responses…

Finally, a more useful question than “how do I write a SIEM RFP?” is “how do I buy the right SIEM for my organization?” Keep this in mind while tuning your RFP. Or just retain me to help – a $20k consulting project is known to sometimes save an organization from  a $500k SIEM failure….

Possibly related posts:

Enhanced by Zemanta

Dr Anton Chuvakin