Jul 10, 2013

7 Tips to Follow When Evaluating
Security Tools

In today's Whiteboard Wednesday, Pia Flores gives you 7 tips to follow when evaluating security tools. Pia has been through thousands of evaluations with customers and these are the items she feels are most important to think about while assessing the tools that help protect your organization. Watch this quick video to learn more.

Read Video Transcript

Hi everybody. Welcome to Whiteboard Wednesday. My name is Pia Flores; I'm the manager of security solutions here at Rapid7. Today, we're going to talk about evaluating security tools and 7 tips that I really want to emphasize with my experience of managing evaluations. I've managed thousands of evaluations in my day, and these are the things that really stood out to me as how to make a really successful proof-of-concept for whatever security tool that you're evaluating.

First step is have a common goal. This is very important, especially when you're starting out the evaluation, making sure you really get the opinions of every person that will be involved in the project. Believe it or not, most of the people I talk to, they usually will do it on-the-fly, and when we start doing an evaluation planning call, they'll figure out what their common goals are. It's really helpful to just come prepared with that. That's the first step.

Second is create a criteria matrix. This is one that is often overlooked and will save you a lot of work in the long-run. A criteria matrix should include all of your requirements. It's really helpful also to weigh your requirements based on what your business needs and what your security needs are. Create that criteria matrix, very important.

Third is what problem are you trying to solve. What I mean with this is, oftentimes, a lot of venders will give you certain features and say, "Just take a look at this feature. This is one of our key differentiators." You really want to make sure you ask yourself while you're looking at that feature, "Is that feature really going to help my business? Is that feature really going to solve the problem that we're trying to achieve within this proof-of-concept?" Make sure that that's a question that you're asking yourself when you're looking at features, when you're addressing questions with the venders that you're dealing with: What problem are we really trying to solve here based on this proof-of-concept?

The forth one is test out scenarios that are relevant to your environment. A lot of times, we are strapped for resources, we're strapped for time, so you can't evaluate the solution within your production environment, plus you want to keep it safe and in a screened-off location or a screened-off environment. It's really important to take a look at maybe the scenarios that you'd have within your . . . meaning if I have a certain area in my network that has lower bandwidth/higher latency, and I'm concerned about the scan completing in a certain amount of time . . . this is all, of course, I'm concerned about the scan completing in a certain amount of time. Make sure you're testing that out in a test lab or maybe even choosing a couple of systems in your production environment to see how the product will handle those types of scenarios. Test out scenarios that are relevant to you instead of using just a sample environment.

The fifth one is look out for the intangibles. What we mean by this is things like support, for example, during your whole proof-of-concept; the experience of the proof-of-concept of the vender. Chances are, if you're getting poor support during the actual proof-of-concept, the customer support probably will mirror what you're getting, if not maybe be even worse. Make sure that you're looking at the response times of each vender. Make sure the vender is coming to the call prepared with whatever information you're asking for because that would be a really good indicator of the experience that you'll have once you're a customer. Another thing that could be an intangible as well is company vision: Where is this company going? What type of visions do they have around improving their solutions at or improving their security suite, whatever they're offering?

Sixth is product roadmap. What we mean by that is make sure . . . if it's possible to get an NDA, it helps to get a product roadmap to understand where the product is going. Also, look at how much has changed within the product over the last 6 months to 1 year. What that will give you a very good indication of is how much money and how much time and resources have been invested in the products that you're looking to purchase from that vendor? Another thing that you'll get with that question is how many RFEs have actually been fulfilled from customers over the last 6 months to 1 year? Chances are you'll have RFEs with whatever vendor that you're looking at, and you want to understand what their development process is like: How do they get feedback from their customers? How are they implementing that feedback? How often are they implementing that feedback? Make sure you look at, again, the development of the solution over the last 6 months to 1 year. Also, looking to see what types of investments the company's looking to make in the future.

Lastly, Number 7 is keep in mind future aspirations. What we mean by this is look at your current state, looking at also your ideal state. Where would you like to bring your security program? Where would you like to bring your solution sets? Make sure that whatever solution you're choosing will fit your needs now and will also fit your needs in the future.

That's all we have today. Thank you for joining us for Whiteboard Wednesday. This is Pia Flores. I will see you next week.

Free Security Assessment

How do your organizations mobile, endpoint, and
user-based risk stack up
to industry benchmarks?

Launch RiskRater