Security Lost and Recovered (1)

What have I learned in the 15 years I have been active in the Security profession? One thing, centrally: that Security must be complete or it will be meaningless.

I need to explain what the term “complete” means in this context, first to avoid misunderstandings, but also to introduce a qualitative approach to Security. In doing so, I write with the Security lead or architect in mind, the Security professional, and I appeal to his or her own experiences, knowing that what I have to say is part of our common experience (although not something that is frequently discussed and much less fully analysed!)

It is a known fact that Security initiatives that are focused only on the IT function (the IT “department”) can be very positive for all the parties involved. It is particularly positive for the IT department, as it obtains critical guidance and resources, technology support for example. In many cases this support and complement of the IT function is decisive for the business organisation to be able to achieve regulatory compliance and other objectives.

Contrariwise, for the Security professionals, the results of consultancy work, aside of the business benefits they may bring, substantially depend on the level of the engagement, and the possibility of addressing the root causes of the Security problems. More concretely, the truth is that every particular Security engagement with the IT Department, while being productive or even satisfactory within the posture of that part of the organisation, and while being also successful in terms of delivery and revenue generation, may still be fundamentally unable to analyse and improve the Security position of the organisation.

This paradoxical situation is not rare in the consultancy industry, and –beyond the realm of Information Security– other consultancy professionals may be able to identify similar situations. It is the case that frequently Security engagements are limited from the start or else become limited to the immediate desires of the IT Function, that is, to the urgent “short term” requisites for remediation or compliance. All participants are ostensibly just “doing their jobs” in these cases. All participants are focused on what “needs to be done without delay,” and nothing else!

It is at that point when these projects or programmes become severely limited as the teams involved begin avoiding the analysis and correction of the root causes, and ultimately settle for work that barely touches the surface of the complex organisational issues that actually determine the situation.

Security –in this sense–, becomes its opposite. It becomes incomplete as a consequence of the absence of the proper organisational scope, perpetuating the lack of strategy and architecture (that is: the absence of a security model for the organisation). That is what I mean by Security not being “complete.” In other words, Security work that does not start from the business commitments of the organisation, its business goals, and that does not improve nor transform its organisational levels.

I always emphasise –for example– how deeply Identity management depends on data ownership and business involvement in the definition and validation of access controls. I like to show how this root problem immediately voids the ability of the organisation to reasonably regulate user access and user enablement. In doing so, I run against the usual but unhelpful belief that these aspects can be ignored or else resolved by means of IT “tools" and “quick wins."

My “programme” for Security certainly addresses and resolves technology requirements (I have personal fascination with Identity data processing systems and have long worked with world class technologies) but I never do this in isolation and constantly advice against doing so. The point is that Security, to be complete, integral, business-orientated, has to cover the Four Perspectives: Trust Definition, Establishment, Enforcement and Verification.


Technology can and in some cases must be employed –to different degrees– in each of these moments of the Security space, but the whole structure should always be articulated, comprehended and addressed as a matter of organisational transformation. I repeat: Either Security is managed at an “organisational” level or it hardly raises beyond repetitive “fire-fighting” exercises with no expectations to substantially, reliably improve the position of the organisation.

In other words, the IT-centric view of Security misses the essence of the Security aspects; indeed, it misses the essence of the profession itself.

To further clarify the organisational focus we just need to analyse with care how current organisations work and use technology. What is technology used for? What is Security in the this context?

I think it can be established that technology adoption means incremental mediation of organisational processes (business, administrative, social, etc.) by computer-based networks. We can rightly say that in current business organisations everything consists of machine-mediated transactions.

Even the most superficial analysis would then reveal that “Security” must mean Security of those transactions, and that Information Security must be seen as an organisational discipline focused on the exchanges and human activities that compose these transactions.

I doubt that a different conclusion could be drawn regarding the essential task of the Security Profession. I doubt it: to think otherwise would mean assuming that Information Security does not care for the transactions, interactions and information exchanges, but that it is centred on the machines that are only the tools and carriers of these.

Here is the fundamental error of IT-centric security: it takes the tool as the origin of interaction, and it limits itself to the instruments and objects of the action, while losing the context and the subject of it. This is counterproductive and self-defeating, because organisations are primarily, at bottom human structures, and only secondarily technology-mediated entities.

Therefore, when we speak about Security, we first must consider human-to-human interaction. Access controls, the bread and butter of Security, must be understood as access controls between people, and not between people and machines. All should be centred around human interaction, seeing that when a user invokes a technology tool (a “process” executed by means of technology), we have in reality an individual calling another, indirectly, through “resources” and “processes" which require particular permissions. In all cases (if we consider it carefully) all resource calls are themselves mediated and refer to other people (or groups of people). These are layers upon layers of mediation and indirection which obscure the human nature of “socio-technical” environments.

The actors in these interactions are users (natural persons), subjects (natural persons as they exist for the technology systems), resources (named services or capabilities), platforms (run time environments), zones (connected platforms), programmes (executable-executing code), and data (at rest and in transit). The combinations of these actors can become overwhelming, but, precisely because of that, a proper Security Architecture should be mandatory.

In considering these layers, the careless observer may latch of the mechanical and technical parts,  especially those dedicated to “security enforcement” because these are more numerous (and also because these appear as making the interaction possible). In fact, technological mediation tinges human exchanges in a way that makes the technology appear “alive” as if it were the only really existing part of the exchanges, while the human origins and purposes of the whole scenario recede into darkness and oblivion.

To avoid this slant and the techno-centric focus, I always follow as a guiding thread four key aspects which can be found in every social system, despite the complex linkages that may exist. These are the four fundamental models of action, those of the Person, the Subject, the Agent and the Object. They correspond to the four Security perspectives of Trust verification, definition, establishment and enforcement. (See:

I will come back to this structure or model as I progress in this exposition of the current state of the Security profession.