Within the IT community, I'm sure you have heard the old slogan "no one ever got fired for buying IBM"? Our decision making processes always take in to consideration imitation of others within our community as well as our own independent understanding, or do they?

The problem begins with the social pattern that goes something like this:
it is better to fail within the norms of your community than it is to succeed outside those norms. It is not necessarily a bad thing to mimic others but to do so blindly and abandon any of your personal experience or knowledge is a bad thing.

You will make critical decisions based on your own private information (the tacit knowledge you know in your gut from your own experience) and public information (the behavioral and technical norms established in your community of peers and competitors). When is it a good idea to mimic others in their risk management practices and when is it a bad idea to do so? The answer is easy: it depends. If the decisions feels too complex and overwhelming, good, you're fooling yourself if you think it is simple.

Kaivan Munshi, a professor of Economics at Brown University, published a paper called 'Social learning in a heterogeneous population: technology diffusion in the India Green Revolution." Don't be put off by the title, the paper has a very useful pattern to understand.

Essentially, the pattern was the critical decision making process of two groups: the rice farmers and the wheat farmers. They both needed to decide whether or not to adopt a genetically engineered high-yield crop strain. As you can imaging, for a farmer, this is a very high stake decision which is what makes it so interesting to me.

The wheat farmers based their decision on what their neighboring wheat farmers were doing (imitation) while the rice farmers based their decision on their own personal information (independence). To understand why, we need to zoom out and take in to account the dynamics of their environment. Lets take in to account two factors: land conditions and crop performance among their peers.

Among the wheat farmers, there was very little variation. Land conditions and crop performance were almost the same from farm to farm. Whereas, among the rice farmers, the farms were very different in terms of land conditions and crop performance. So if you were a wheat farmer and your peer was doing well with this new crop strain, since you are like your peer, you conclude that you will do well also. Imitation at many levels were already well established. If you were a rice farmer, the public information of your peers told you very little so you would need to rely on your private information. They had to invest in their own private investigation and trust their independent knowledge for the decisions. As it turned out, the stakes were so high for these wheat farmers that in the end, they still considered some independent understanding before making their decision.

How much of your IT environment is like another? Are any two companies the same? Maybe a better question is at what level of detail does it start to become different? Taking the work of Dr. Munshi, I think the IT community is much more like rice farmers in that it is our differences that make us stronger and more competitive. When we look at IT operational risk, we need to be OK with the fact that our independent models and understanding might not be anything like others in our community.

The old slogan needs to read "no one [of like environments] ever got fired for buying IBM".

I hope you enjoy as much as I do the work of Robert J Lang.

http://www.langorigami.com/art/creasepatterns/creasepatterns.php4

I know this may not help you in terms of risk management but the beauty hopefully will lift your spirits.

Rose is a rose is a rose is a rose.

--tk

Behavioral economists claim that people rely on what they call 'anchors' when making decisions. Essentially, it is an arbitrary bit of information within a domain that a person first used to orient themselves to the state of affairs. For example, the price of a stock when they first purchased it. As new information streams in, they will always refer back to this initial purchase as an 'cognitive anchor'. Even far in to the future, decision to some degree are still based on this anchor.

In our decision making process, our ability to understand the ratio between what we know and what we are about to learn is where the party is happening. This is the difference that makes a difference and is fundamental to how we perceive and then understand change. How we understand change is core to decision making.

As we form new ways to communicate risk related information throughout our organizations, we should take some time to understand their cognitive anchors. Useful questions include: When this person experiences this new information, what prior knowledge or what anchor will they be using to form their understanding? If have the privilege of it being the first time they experience this information, what will be the most appropriate anchor for future updates?

Magicians are craftsmen in carefully dropping these anchors so that your understanding is being tailored by their actions and under their complete control. Lets take that magic and invert it. Lets make sure that our audience has the most appropriate anchors so that they are not being misled but informed on the possible and plausible outcomes they face in their decision making process.

Over the past 8 years or so, the good people at the MITRE Corporation have contributed a set of identifiers that have proven to be very useful to the information security industry. With more on the way, I'd like to share with you my thoughts. Before I begin, I hope these comments are not taken in a negative manner. I have the deepest respect for these people and support them 100%. All of their energy and talent goes in to making our industry more efficient and accurate so next time you're at a trade show and see the MITRE booth, say hi and say thanks.

Everyone is familiar with CVE but you may not have heard of some of the others. I don't know if this is the complete list:

CVE - Common Vulnerability and Exposure
CCE - Common Configuration Enumeration
CPE - Common Platform Enumeration
CWE - Common Weakness Enumeration
CME - Common Malware Enumeration

(I'll refer to all of these at CxE's representing a set containing these members)

The value proposition is that if we all honor these namespaces, we can be assured common identifiers and therefore interoperate with greater precision; when any one of these enumerated objects are referenced either socially or technically, a unique identity is referenced. Other industries have faced this problem and have come up with very useful identifiers that help them address this problem of identity. Could you imaging what the book industry would be like without an ISBN number? Or how about the retail industry and its complex supply chains not having a UPC (Universal Product Code). There is a pattern and that is what I am here to talk about.

The pattern is a category or set containing members that are uniquely indexed. What is interesting is how common this pattern is in every system. What is enumeration and why is this pattern so useful? The dictionary says:

enumerate
v 1: specify individually;
2: determine the number or amount of;

I like to look at the pattern and appreciate its form. We create categories because we like to group like objects. Given any number of objects, we spend cognitive cycles trying to fit them into a set based on some attribute[s]. At the logical level of category there is a loss of individual identity; categorization is really just a cognitive difference-filter. At any point in time, we can jump from the flat category back down to the individual member by its ordered or unordered index. The beauty is in how simple and useful this pattern can be, that is as long as your definition of the problem is simple. What happens when it is not so simple?

Are you still with me? Lets skip ahead 3 years and suppose there are not five common enumeration namespaces but lets say that there are twenty or thirty? Are we better off? When does it end? At which point do these common enumeration need their own common enumeration: CCEE - Common Common Enumeration Enumeration?

What I am going to say right now is not meant to diminish the value of CxE's, it is to ensure that we can continues its success.

The next step is to formally build the RELATIONSHIPS between these objects. There is still value in these CxE namespaces ensuring a unique identifier but there is greater value to be gained by formally declaring how they are all related. Which platform (CPE) is related to a CCE (configuration) or CVE (vulnerability/exposure)? What you would end up with is an ontological representation of the information technology domain. I've spent the past 6 years thinking about this problem have a few ideas to share on how to pull it off. To be ultimately useful and sustainable, it would have to be:

-- cared for by an entity that had international appeal
-- cared for by an entity that has no commercial interest
-- the ontology delivered in machine readable feed
-- distributed authoring of relational properties
-- based on a social networking technology that binds the community together

Our industry requires this to move to the next level of evolution. The value is not in the object, it is in the stable relationships that object has with other objects. Who's with me? Lets get started!

--tk

A few days ago I saw a TV commercial where a mother was sitting down with her two children eating breakfast (or it may have been lunch). There was only one slice of bread left for their peanut butter toast so they began to argue on who would get the larger half. She gave the first child the task of cutting and the second child the first opportunity to pick which half he wanted.

This is the 1996 Brams and Taylor "Fair division" contribution to society. I recently sat on a panel at a conference and used it in one of my examples. Unlike the TV commercial, it is described in the Brams and Taylor book with cake cutting and not peanut buttered toast.

S.J. Brams and A.D. Taylor, Fair Division: from cake-cutting to dispute-resolution, Cambridge, 1996.

J. Robertson and W. Webb, Cake-cutting Algorithms, AK Peters, 1998.

I have often wondered why we have not seen this type of fairness pattern show up in IT workflow. Next time you have a fairness problem, either technical or social, see if this what game theorists call 'envy-free' strategies will help you.