Caveat emptor 101

I try to read as much as I can. Whether it's articles, books, journals, blogposts doesn't really matter. If it is infosec related I'll soak it up and if it's any good I'll probably blend it into a corpus of knowledge I've gathered over the year.

In the past half decade our industry and community has been finding out what it takes to be relevant. A lot of relevancy is to be customer focused. Note that "customer" does not always imply that you have a commercial relation with the group or person you categorize as that. Naming the entities you deliver for "customers" helps you realize that it is your sole obligation to deliver value instead of firewall rules or anti-virus or secure code.

Caveat emptor is a very old principle (that's why it's written in Latin right?) that boils down to "buyer beware". It basically means that whenever you are in a buying position, you have to be careful that the thing you are being sold is what you asked for and not something else or worse ... something incomplete.

With that said, I introduce you to this post on the HP Enterprise Security blog.

The post is constructed around the failed interpretation of an RFP process, that in the author's experience apparently goes a little something like this :

1. Customer issues RFP
2. Customer makes purchase decision
3. Customer buys just the widget
4. Customer attempts to implement the widget themselves
5. Customer fails to leverage full capability of widget, project falls to the wayside, considered a failure or abandoned.

From this he continues to pass blame for everything that goes wrong in corporate security programs to the customer ... obviously preparing us for the next ground-breaking offering that will wipe out all of our collective sins of the past. We shall be whole again.

I take issue with may things in that premise. I'll try to address them seperately.

1. This RFP process is overly simplified for the purpose of your post. It disregards the role that both vendors and integrators/resellers play in forming the opinion of a customer, often shoving their concerns under the rug with an extra discount or a shiny presentation. 
2. It's easy to put blame on the customer and their "buying" behaviour. In various roles at various organisations in the past I have spent time on all sides of the table in RFP processes. I've written them, I've answered them and I've evaluated them. If there is one thing vendors/resellers can do it is not jumping on any opportunity for the sole monetary benefit it will get them. Honesty goes a long way, even in business. 
3. If you have any experience in running such projects at scale you will recognize the occurences where scope was suddenly interpreted differently because the reseller found out they would not deliver on time if the real scope needed to be covered. In this case it is often the customer that doesn't grasp what is happening to them and they're actively being ripped off. No worry, the project was a success and nobody noticed. 
4. Lastly there is the issue of knowledge transfer. I haven't seen a single RFP where knowledge transfer was not an item. The answers at the beginning of the process promise a unique approach enabling the customer resources to develop themselves into experts. The reality a few months later is bleak, knowledge transfer exists of a 2 page admin manual and a stock preso about the awesome features of widgetX. Box checked, project delivered, let's get drunk!

The post further elaborates on specific experience from the author. The first example (Project ADD) is an example of failure that is rooted rather in a failed project management approach than a failed infosec program approach. This is not something a "reboot of your infosec program" can necessarily fix.  

Now back to "caveat emptor". 

As old as it is, the warning still stands. If you are looking to buy a widget to protect your infrastructure or a consultancy service "to reboot your infosec program", be suspicious of the promises made.