Anti-Clockwise versus Clockwise

The aha! came as I was contemplating a question posed to me in the Gherkin where I was presenting the concept of Outside-In Security and the importance of "Clockwise" security, my off the cuff response created a tension in me that was like grain of sand in an oyster. I only wish I could remember the name of the person who posed the question and the question itself, in order to give them appropriate acknowledgement.





So to refresh..
"Outside-In" is an LEF (Leading Edge Forum) concept, recognised by the researchers at LEF headed up by David Moschella. It holds that the power of technology is starting to move the most effective location of value creation from Inside the "Enterprise silo" to Outside the enterprise silo. Simply put in the future, more value will be created Outside-In, than Inside-Out. It is basically a different view of an Information Security concept that I have been involved in the development of through the Jericho Forum; that of De-Perimeterisation, which describes the impact of technology on the perimeters of organisations.  I will come back to the "different view" later, but let's identify the common factor in these concepts. It is the "Internet"

There are a number of parallel changes created by the most positive impact that the internet brings, which is that of removing the friction in the sharing of knowledge. There may be many who at this point would start listing all the negative implications, including the impact on previously successful business models. But I want to focus on the positive aspects of free flowing information and knowledge, and the implications on the approaches used to ensure the maximal creation of value.

Companies that are aware of the value of connecting customers and producers in this new era have already moved to take a position of power in this new nexus of power. Those in control of the flow of data will be the ultimate winners, is it not best that we work to maintain the right balance of personal, corporate, or governmental control over the flow of data?

The mechanisms or approaches for doing this are embodied in these things called IT Systems.

They are developed by often well meaning systems to achieve the desired and specified requirements or outcomes. [[As an aside I had once a very confusing interaction by an academic teaching the next generation of our computer graduates their craft. He stated categorically that Information Asset Management more broadly, and Information Security specifically, were simply requirements that need to be specified in the original design of the system by the procurer of the system. Simply put he stated that computer programmers had no right or obligation to build compliant, safe or secure systems. If a component was not specified it should not be built. Simples!

I tried to remind him that early cowboy architects had designed buildings that did not stay up in the winds normally expected in the area in which the building would be built. If professional architects design buildings that will meet these unspecified expectations, why should IT Professionals not also take on these responsibilities, he was adamant if the customer did not specify it, it should not be added.

In the absence of Systems Development Regulations, similar to Building Regulations, I believe that we should be developing Computer Professionals who understand the importance of Information Asset Management, and who build Systems that meet the Users specified requirements as well as those that may have been unspecified but enable the IT System to run in a compliant, safe and secure fashion. In retrospect I perhaps was guilty of imposing a different view without integrating it with the normal perspective. I do hold to my belief however that the un-named academic IS guilty of churning out computer cowboys rather than IT professionals.]]

There are two types of activities involved in the development of safe and secure systems. The development activities aimed at meeting the base need(s),  and those that create a compliant, safe and secure system.

The first is the basic System Outcome Specification process.

It is normally done in a clockwise manner starting from the need, and not taking into account compliance, safety or security requirements, then returning to test and implement.
One might call this a Clockwise Systems Delivery Process.

The second is the specification of the Compliance, Safety, and Security aspects.

This is normally started at the point when the System is about to be implemented, and is by necessity completed in a rapid Anti-Clockwise manner. (Invariably not focussing on the initial need or required outcome, but the threats observable to the proposed system.)  I call this Anti-Clockwise Information Asset Management. Whereas the more effective approach below is called Clockwise Information Asset Management.

The aha! basically states that at the point when a new need or outcome is identified, that both these activities, should be initiated in a Clockwise manner starting from the Need and operated in parallel to define and implement a complete set of system requirements, including the required controls..

Once the system is implemented the loop is applied starting from Threat and operated in an Anti-Clockwise manner to operate the system. However whenever a change is required the Clockwise approach of the two parallel requirements systems should be re applied.

It can thus be noted that rather than thinking Anti-clockwise versus Clockwise Information Asset Management we should be thinking when should the two approaches be applied.

In short the Information Asset Management Lifecycle should be appropriately integrated with the Systems Development, Testing & Implementation and Operations.

Sometimes stating the obvious takes ages to occur! I wonder when we will see Compliance, Safety and Security processes effectively built into Systems Delivery Processes? I hesitate to ask my academic friend, as I already know what he will say...  "When the Customers ask for it!"

Hmmmm??? We might be waiting a while.

When it comes to different views, I am reminded of two blind men trying to identify an elephant, one holding it's trunk the other one of its legs. Having never seen an elephant neither were capable of describing the whole elephant, from their two different perspectives. Sometimes it is important let go of one perspective and gain another to "see" the big picture. Sadly I have spent much of my career holding onto one perspective.; Inside-Out. When Outside-In holds so much more learning and value creation opportunities. Neither of the Blind Men ever did ask each other for their perspective, nor the perpective of sighted observers.