RFP = Really Fast Paperwork

paperworkNow I am in a management role that balances “individual contributor” with a healthy portion of “resource leadership” I have a better understanding of the impact sales has on the SE organization.

While we may have a great library of RFP responses, every new RFP has those challenging questions that will require creative writing. They’re always scenarios that no vendor (including the competitor) can address because prospects are looking to combine functionality from multiple security projects and have the SIEM tool save them budget or provide a “Swiss Army Knife” solution. These sorts of questions require clarification, advanced technical writing skills and consume hours while you ponder the final response.

An average RFP will be between 100-200 questions in length and take each resource approximately 20 minutes per question to research, cut and paste the answer, embellish, format and correct grammar before moving to the next question. With that in mind, it’s no wonder why a 100 question RFP would take an SE 30-40 hours to complete, much to the sales reps chagrin. Final formatting, cover letters and waiting for 5-10% of responses that have been farmed out to engineering, marketing or sales teams to complete, usually adds another 16-20 hours, thus totalling more than a week’s worth of work for the SE.

Now, if you don’t have an in-house, dedicated RFP response team, extensive knowledgebase or boilerplates, and you have limited SE resources that are busy with customer meetings, demos or POCs, now you have to increase the response time given that the SEs will only have time in the evenings to work on the RFP.

Having written RFPs in the past, I know it takes months to put together the requirements and agree on what product features you seek from vendors and then do your homework so you know what vendors to include in the response – yet the response deadline is usually between 7 to 15 days.

To streamline and provide appropriate resource coverage here are some things we tend to do:

  • Assess the product fit and decline to respond if the RFP is clearly influenced with competitor differentiators
  • Immediately ask for an extension (sometimes this is best done by the SE manager – never say you are too busy!)
  • If working with a channel partner, ask them to assist in the responses (provide them with boiler-plates, past RFP responses)
  • Evaluate the schedules of your SE team and determine who has the most cycles to contribute to the bulk of the work
  • Consistently update a central repository of RFP knowledge with any unique questions discovered during an RFP
  • Build response templates and distribute to the SE team immediately
  • Get the Sales Rep involved during the RFP event, providing cover letters, company background, perhaps some of the easy technical questions
  • Farm out a portion of the RFP to other SE organizations outside of your region
  • Seek out internal project management teams that may be dedicated to RFP responses – they may be able to answer the easy questions, manage formatting, printing, binding and can manage the resource deadlines
  • Establish and maintain relationships with some of the prospect’s technical owners, getting them to assist in wording, proposals or additional clarification questions after the question deadline (this is a gamble)
There are probably many other strategies for the response but one key area of focus with prospects is to try and position your solution as “sole-source”, meaning you have a set of features that no other competitor can match and this could lead to avoiding the RFP all together and move straight to the demo or evaluation of your solution, thus increasing your chances of winning.
Good luck and happy selling.



Some Generic SIEM Requirements to Ponder

Being tasked with selecting a Security Information and Event Management (SIEM) tool for your organization can be a bit overwhelming. I’ve been there and chosen poorly (in my last life)! The questions you need to ask the SIEM vendor you are buying from are limitless as every customer’s needs are different and the business drivers range from “check-box” compliance to actual enterprise incident handling and response.

Numerous customers have approached me with what they thought were straight Log Management (LM) requirements, since they have only ever had the luxury of manual log review using the “Grep”, “Awk”, “Sed” approach or “spreadsheet Kung Fu”, while others have the budget and want to “boil the oceans”. There are hurdles with both approaches, while the former may be the way to “grow” into a mature concept such as a SIEM tool and the latter will never be outgrown.

In fact, before you can perform real-time analysis on all of the logs to detect threats as they occur, you need to capture all of the event data from the plethora of heterogenous event sources and store the logs in a centralized location. Therefore, I believe log management is an essential part of SIEM because, with the right tool, 100% of your logs are readily available with automated archiving and retention. Additionally, since you have mandated all of the logs from the various technologies to be sent to your central facility, the teams that manage the devices will need an easy-to-use tool that will allow them to do their day-to-day tasks such as troubleshooting network issues, application development debugging, long-term investigations and possibly the last six months of an employees activity for HR or litigation purposes.

Regardless, you should have a strong command of what it is you need SIEM for and use vehicles such as Request For Information (RFI) or Request For Proposal (RFP) to rate each vendor on the top mandatory requirements vs. the “nice-to-have’s”. For this purpose, I have compiled a list of questions that you may determine to be useful when creating your vendor ratings criteria. Here are what I believe to be essential 70+ requirements for the ultimate SIEM and Log Management tool:

Continue reading