For Security Pros, Building Vendor Relationships Is A Lesson In Diplomacy

The blood is in the water and the sharks are circling. Recent reports show that IT security spending is up --and as the quarter comes to a close, security salespeople are flooding our inboxes and voicemail with sweet, syrupy messages trying to get a foot in the door.

As security professionals, we aren't always the best "front line" for fielding these calls. First and foremost, we're busy. Second, we're mostly technical people, and we want to talk technology without dealing with all of the high-level sales pitches. The non-technical issues need to be discussed, but what we really want to know is whether or not the product will solve our problem(s) effectively without putting too much additional load on our operational duties.

There are a few different ways to deal with security vendors to ensure that your company's best interests are being met -- and not just the salesperson's monthly quota. Being honest and up front about the problem you're trying to solve -- and your expectations of the solution -- is probably the most important step to developing a good relationship. These elements are critical in your RFP, so that you're not stuck wading through useless bids.

However, being open with security salespeople is not always easy. Personally, I've been on a few conference calls where the vendor seemed bent on pumping me for information about what vulnerability scanner, penetration testing tools, and IDS we use. It's a frustrating feeling, but in some of the cases, it led to a discussion of something I was genuinely interested in. In those situations, I had to set some ground rules about what I was willing to share.

Being up front and honest does not mean telling the vendor everything. It does mean giving them enough information about your environment so they can size the solution appropriately and suggest ways to integrate it with existing tools. Don't be afraid to say "no" to a vendor when they ask for too much information. If you're not convinced that a question is pertinent to the discussion, move on.

Similarly, be careful what you divulge. IT security is a sensitive area, and you don’t always know who's on the other end of the line. For cold calls that you're interested in, take a message and call the salesperson back. Try calling the main corporate number and ask to be forwarded to the salesperson who called you. Why? You want to be sure that you're really talking to the vendor -- and not an attacker trying to social-engineer you.

Security RFPs are a different beast altogether. Crafting a solid RFP is critical to a project's success -- and often goes horribly wrong when rushed. There have been numerous articles about RFPs over the year, but the information I've found most useful in the past has been from Lenny Zeltser's "Information Security Assessment RFP Cheat Sheet."

The first step is to decide whether you even need to go through an RFP process. For some organizations, especially small organizations, a less formal process might be easier. Depending on the technical expertise of the team members and their understanding of the technologies involved, the cheat sheet suggests starting with a request for information (RFI). If you go through the RFP process and don't understand the proposals that come back, you may have to do it again, or worse, you might buy in to the wrong solution.

The RFP should contain the relevant information about your environment so that vendors can make an accurate proposal. Be careful about providing sensitive information here, also. It's perfectly acceptable to ask for a non-disclosure agreement with vendors before you divulge the more sensitive details. The sensitivity of your business and network can also help determine if it's better to send your RFP to a large group of vendors or to a select a smaller group of handpicked vendors.

Security professionals don't always have kind words to say about vendors and salespeople, but creating a good working relationship with both can help make your life easier. Keep in mind that they have a job to do, too -- and that it's okay to say "no." Just be nice in how you say it -- you might just have to deal with that person for something your organization needs in the future.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.