Section B.13 Consultants: The Good, the Bad, and the Slick | Real World Linux Security Prentice Hall Ptr Open Source Technology Series

B.13 Consultants: The Good, the Bad, and the Slick

Forrester Research is quoted as saying that in the two years between 1998 and 2000, corporate spending on security has risen by 900 percent.^[1] For many companies, the most cost-effective solution is to bring in a good consultant for a few days or weeks to analyze their needs, provide a solution, train their employees to handle the day-to-day matters, and provide the occasional ongoing consultation. It is very hard to distinguish the good consultants from the bad ones and the slick ones. Often, these latter ones seem better, on the surface. The one-person "garage" operation that is experienced in your type of setup may be far better than another shop that is buzzword compliant but which does not have the depth of experience, expertise, or desire to understand your needs and provide a cost-effective optimum solution. Often, the latter simply will "drop in" the same solution for everyone, possibly getting a commission from a software or hardware vendor. The small shop may not be flashy, choosing to spend time on the engineering and research rather than on the marketing.

^[1] June 30, 2000 issue of securityfocus.com's InfoSec News.

You will want to do the same research that you would do when looking for a key person for your organization, because you are. Ask for a detailed resume, talk at length with the supplied references. You want many years of experience and a proven track record of successful implementations; someone with a year's security experience has not seen enough problems to solve any but the simple problems. Investigate not only their top people that they want you to work with before the contract is signed, but also those that they will have you work with after the signing. Insist on meeting with and seeing the credentials of these latter people; do not hire the firm without this.

Look at their credentials, schooling, and published works. What percentage of their work is in Linux? How much of their remaining work is in UNIX? How long have they been working with Linux, UNIX, and security? How do they keep up-to-date? Have someone technical (in your organization or outside it) interview the consulting firm and insist on details showing what they know about security. Pick topics from the book or elsewhere and ask them to talk about the topics. If they must "get back to you" on most of them then their knowledge may be limited. Vague answers should be disqualifying too. For larger jobs, larger sites, or more sensitive sites, spending a few hundred to a few thousand dollars to have a detective investigate the consultant might be a good investment; this is routine for those in trusted positions.

Many of my clients have me conduct the technical interviews of people that they are considering hiring, both employees and consultants. Through skillful questioning I am able to determine whether a candidate is as skilled as his resume implies. Often, he is not.

Answers similar to "that is confidential and you will have to hire us first" also should be considered very negative. Use some common sense here. If they cannot explain public key encryption or the differences between PGP and SSH or between TCP and UDP, send them packing; do not expect them to tell you "10 ways to improve security at your site" for free. If they will not tell you two ways, do not be impressed. If your best technical people are not impressed, they are probably more hype than help.

Although they hopefully have some unique ideas that they want to protect, they also should volunteer some information. Ask them what security books they have read, what courses they have taken, what conferences they have attended, and what news groups, mailing lists, and Web sites they follow. Ask them how many past clients they have had and how long these have been running with their expertise. What percentage subsequently were broken into and why. Ask to talk to these clients.^[2] Do not expect them to tell you all of their secrets, though.

^[2] This is similar to the now common practice of asking what the success rate is for a surgeon and hospital performing a particular operation. Consider too that some may refuse the more "difficult" cases to improve their statistics. Thus, it is important to understand the circumstances of the breached clients.

If you have a large site to protect, you might consider hiring several independent consultants, with one as a primary consultant and one or more to inspect the proposal and the work of the first one for gaps and errors. See if they come up with similar answers independently. If not, ask them to explain their choices. There may be more than one "right" solution but they each should be able to explain the advantages and disadvantages of various possible solutions. You will want the advice of your consultants whenever you make significant changes to your site because there always is the danger of a "small" change opening up a large security hole.

Top