The CISO as a Sales Person: Part 1 – Selling to the Security Architects

After years of working in sales for small- and mid-sized software vendors, I have gotten used to the idea that everyone in the company is a salesperson. Some of my colleagues in other departments often find this view a bit odd, but this approach can offer many benefits to senior managers and executives trying to 'sell' a project or secure additional budget or resources. This is the first in a series of experimental blog posts about using sales skills within a business, as opposed to using them to seek external business opportunities. In the early 1990s, while I was still at university, I volunteered to join a newly assembled team of academic researchers interested in the new-ish field of IT security. One of the few papers I published was a basic analysis of an open source sniffer for Unix platforms. Sniffer was mainly a basic packet capture program with very limited, if any, packet analysis capabilities. Not much came of this paper until I got my first job in the new IT solutions department of a large bank. At the time, I was very excited about early security technologies like COPS and SATAN – which were being developed at Purdue University and Eindhoven Technical University, respectively – and I was keen to introduce some of these ideas and tools to the bank. I was reporting to a very talented management team that understood technology and the industry trends very well. However, its exposure to IT security had been mainly influenced by security frameworks in mainframe platforms and in newly commercialised ideas like Kerberos and Internet firewalls.

Trying to sell my ideas against a backlog of key banking projects that were passing through our department would probably have failed if it would not have been for Sniffer. 

Therefore, I suggested to my manager that I could easily find what his departmental Unix password was. He accepted the challenge. Later in the day, I went back to his desk with a printout of a packet capture I ran that morning. His password and many others were listed under the FTP, Telnet and other authentication headers. Without hesitation, he called his boss, the department’s manager, and showed him the packet capture. Within a few months, other areas within IT were asking for meetings to learn more about IT security. That same year, I started writing a draft security policy and got the green light to introduce new IT security technologies, e.g. Intranet firewalls to create the first internal DMZs and network segments, as well as two-factor authentication, to the bank. That Sniffer printout was probably my first demo and first step into sales! Moving forward two decades, senior IT security executives face similar challenges to the ones I encountered when seeking additional budget and headcount. For the purposes of this blog, the target audience of our selling efforts can be split into three major groups: security architects, end users and senior executives. Selling to senior architects can be as challenging as selling to the other audiences – they have a tremendous ability to say 'no.' "No, this solution does not fit into our architecture or standards." "No, there are better solutions out there." "No, this product does not do what it says in the tin." When selling to the architects, and to minimise the risk of getting an early 'no,' I usually look for 2-3 bullets that summarise in simple but still technical terms what I am trying to sell to them. I then rehearse this message over and over until I get it right. Marketing people would call this a sales pitch with 2-3 unique selling points. For people that are passionate about IT security technologies, these are the 2-3 ‘cool features’ of one of the many pieces of the architectural puzzle. Hence, be sure you understand the company’s architecture before you pitch your proposal because reversing a ‘No!’ from a senior architect is very painful. The next blog post in this series will discuss how the CISO can sell to the end user. It is fascinating to see that sales people often forget to ask who will be using what they are selling on a daily basis. The users are the ones that will have to live with the solution once the architects have completed their job and moved over. More on this in the next article… _{^{Title image courtesy of ShutterStock}}