Medicating with Security

Welcome back to the blog. It has been a very busy April, punctuated by the annual pilgrimage to the RSA show, which has certainly grown far from the early days with an excitable Jim Bidzos railing about federal encryption export policy.

For those of you who could not attend, RSA is becoming more and more like an annual high school reunion. It is the place where you figure out where your colleagues have landed, where you sense whether acquisitions are working out, and where you can hear and speak about security with people who are often times as passionate, as enthusiastic, as frustrated, or as fatalistic, as you may find yourself.

I was speaking and listening at the America's Growth Capital show which does a Monday lead-in to RSA, and was struck by a question by 451's Nick Selby to a panel of security folks. He asked them for the way in which they positioned, or their customers understood, ROI for their products. At first blush, this is a question that we in the product/vendor role have heard or initiated countless times, and so it shouldn't have been such a big deal for me. I think though that it was its very familiarity, its omnipresent nature in so many of my interviews and presentations and customer visits, that caused me to suddenly think:

"ROI on security. Now that is a bizarre notion."

When I think about ROI, I think about "R", or "Return". Return means that for N dollars that I invest, I am expecting some amount of N back, and in traditional investments, I am expecting to get more than my initial capital. We all use ROI all the time to make decisions of where and how to spend our money, both personally and professionally. The reason why ROI fell apart for me, this year, after so many in the space, was that investing (the I) feels, sounds, is, so voluntary.

"I don't think I'll be investing in pork bellies, Winthorpe, the Return is just too paltry."
"I do believe that I will put my cash into Frozen Concentrated Orange Juice, Billy Ray. Quite an opportune frost this year."

All very voluntary, picking among the options, deciding where to lay a bet, or, in tough times, when to leave the money in the mattress. Security doesn't feel that optional to me.

I decided to circle the RSA exhibit floor on a quest to hear the variety of answers I would get from the booth-manning legions to Nick's query: "How do you or your customers describe the ROI from your solution?". I wanted to see if any of them made clear and credible sense. I was about 10 vertigo-inducing business concept contortions into this little project, disabused of any notion that people would have either perpetrated some alchemy of security spend into profits or would simply rebuff the premise of the question, when I ran into Intel's Steve Orrin, a long-time contact and colleague. I told Steve of my quest, and we ended up talking about the way that organizations approach security spending like people approach taking vitamins. "I should spend some money on this because people tell me it will make me feel better." After discussing and digesting this, I abandoned my ROI quest, because it was clear to me that we have a problem of a basic misapprehension. Security is not about vitamins, it is about medicine, and we are lacking the fundamental prescription.

When we talk about security, we most often are actually talking about insecurity: "Where am I vulnerable?", "Who can get into my systems?", "How am I detecting attacks?", "How do I keep the bad guys out?". We are only very rarely asking questions about our networks, systems, or applications, and how we will be improving them to stay ahead of potential issues, because we instinctively feel that we are already behind.

And that is true because, to torture the metaphor, most organizations are already sick. More advanced firms will have reduced the potential sources of their symptoms, novices will just not feel well, and some firms will just think they are always supposed to feel like this. Like a patient, who just feels too ill, or is visibly diminished, or who is told by a qualified physician that there is something wrong, there is no longer interest in the Flinstones Chewable, it is time for a prescription.

In security we are beginning to see this happen. When various industries reached the epiphany that they were in trouble from a security perspective, you began to see the rise of more prescriptive recommendations. You can look at the OWASP Top Ten, the BITS efforts in IT security, Basel II credit worthiness requirements, section 404 of Sarbanes, privacy standards in HIPAA, or most pointedly, the PCI DSS V1.N. These provided, to greater or lesser extents, some definite actions that organizations could take that would help to make them better. Noone asks, "What is the ROI of protecting customer data?", or "What is the ROI of complying with Federal mandates?", because they are not optional, they are necessary, and the "R" is solvency and viability as a firm.

Unfortunately, security remains a discipline that is shrouded in complexity, fear-mongering and quackery. Our industry is still at the stage of development where the underlying needs are not described in common terms, but rather there is constant rehashing of the symptoms of the problems, and these become the objects of discussion and treatment. As a result, there is far too much time spent thinking about what technique or technology can address a symptom, instead of being spent on understanding the business goal, required protections, and the most effective ways to implement, deploy, and manage them.

In my conversations with customers, partners, and the press, there is little argument that most, if not all, organizations are burdened with some meaningful type of insecurity and threat. It is important for us all to take responsibility for that knowledge, and to begin to treat our security improvement differently. I would propose the following habit change and litmus test:

1. Before I talk to vendors, have I specifically defined my problem?


2. When I think about my problem, am I addressing the cause of the problem or am I only focused on the threats to my security?


3. Have I thought about the simplest ways to fix the problem, including less technical moves like moving data, removing connectivity, and limiting access?


4. As I engage with vendors, do I have a list of the functions that I need, including deployment capability and flexibility, prioritized and communicated?


5. When I make the selection, am I investing only in the necessary protection to keep my organization safe?


6. When I envision the organization post-purchase, how do I feel about its security?

At the end of the day, ROI is a horrible metric for most security investments of people or products. This is because it is very rare for security to drive profits, and because it is so common for bad security to reduce profits. As a result, any security investment should be limited to that which must be done to remain secure, and should be reassessed frequently to ensure that it is still sufficient. More spending than that on security or security technologies will be wasted, never showing the kind of return that product, process, or promotional investments will. This prescriptive approach will create the most effective and balanced mix of investment and security, and will enable evolution and advancement over time.