Security is not a Product

Let’s start with a radical idea: security is not a product.

Despite a small army of advertisements aimed at individual consumers, companies, corporations, and governments, security as a product is a false claim.

It always helps to get the meaning of terminology squared away right off the bat – or else we are likely to end up talking right past each other, because the terms we use mean radically different things (see the post on Actionable Thought).

The main term to note is “security.” It comes from the Latin securitas – from the root secures – meaning “free from care.”[i] The OED[ii] lists it as “the state of being free from danger or threat.”

Our second term is “product.” It comes from Latin producer meaning to “bring forth.” The OED lists it as, “An article or substance that is manufactured or refined for sale.”

So, we have a thing – some sort of commodity – created for a particular purpose, with the intention of sale. That sale is aimed at providing the particular purpose to the buyer.

Now, if we imagine security as a product, what we are implying is that the state of freedom from danger/threat is something to be gained in a transaction. That is, security is a thing – an item – and is available as such. As noted in Dangers of a False Narrative, security as a product gives us the magic-box ideology of cyber security. However, if security as a product was a functional concept, then threat removal would be a simple matter – and most of you would be out of a job. There would be no hacks, no damage, no data breach or loss; in short – the world would be a happy place. However, the world is not a happy place. In March 2017 alone, over a billion records were compromised. Thus, the very idea of security as a product should make us all rather skeptical. The security as a product approach results in magic-box thinking, which leads to the problem of false assumption of security, as well as the failure to invest in the creation and sustainable creation of the CS elite.

So, if security is not a product, what is it?

Rather than throwing out answers and seeing what sticks, we should first look at what is wrong with the idea of product, and based on these failures figure out what security ought to be – and then simply find the correct term to match that concept. This approach is also known as zhengming and wu-wei in classical Chinese thought.

The product idea suffers from 3 major issues:

  1. A “one-and-done” transaction model
  2. Permanence in solution – the purchase works indefinitely
  3. Absolute resolution – categorical claim of protection (cannot fail)

Consequently, we can look at the flip side of the issues to derive the system features that would best describe security.

  1. An ongoing venture
  2. Continually adaptive solutions
  3. Contextually qualified resolutions – where certain types of failures are expected and/or acceptable.

The intersection of these features give us a rather different term: Process.

Etymologically, “process” comes from Latin procesus, meaning “going forward, advance, progress.” The OED lists “process” as “A series of actions or steps taken in order to achieve a particular end.”

Security as a process contains all the desired ideas, and negates the negative ones – as noted above. However, there is more. A process is indicative of continuous effort guided by intelligence. Of course, this negates the security as product idea, but it has a more important connotation: intelligence requires reflective, contextual thought, aimed at some specific purpose. Thinking of security in terms of a product, entirely removes the reflection, the context, and specificity from the equation.

What a process entails, is the context-based understanding and analysis of the system of operations, of specific needs, requirements, and capabilities of the system, and tailoring of security methods to the specific and ongoing, adaptive needs of the client. Security as a process can still use security products as basic tools for structuring and expediting its work, by not having to reinvent the entire toolkit. However, security as a process can never rely on products to provide security. The magic-box product idea gets the whole notion of security backwards, and results in serious failures in security when product replaces process.

By thinking of security as process, we acknowledge the critical role of CS personnel as the actual source of security. We recognize the need to treat them as experts that they are – rather than imposing often-ignorant requests on the basis of popular culture or trending buzzwords. We also acknowledge the need for the CS personnel to be the best: best educated, best incentivized, best performing, etc.

If security as product creates the magic-box mentality and its accompanying problems, security as process is the remedy. Incentivizing CS personnel means incentivizing the next generation of CS elites. Appreciation, recognition, positions, and salaries are all things that drive the interest in the field and allow us to not only recruit the best and brightest, but to help create them. Thinking in terms of a process is about effective CS team-building, about skills recognition, and incentivizing greatness. The CS elites are those people that bring meaningful insight into the field, and restructure CS capabilities through serious innovation. The creation of elites in any field is difficult enough, without the backwards ideas of security as product/magic-box providing yet another obstacle.

 

[i] Etymology of terms can be very useful – it helps us isolate the intent of the terms, and can often shed light on what is and is not supposed to be covered by the term usage. Etymonline.com is a handy resource for initial etymological analysis.

[ii] OED – Oxford English Dictionary – is always a handy reference guide to terminology.

1 thought on “Security is not a Product”

Leave a Reply

Your email address will not be published. Required fields are marked *