Why trustworthiness? Why did I take on this challenge? Suffice it to say that I will take you on a journey towards trustworthiness in every edition as a columnist for the new IT Security Journal. I have been architecting, building, deploying and sustaining mission critical systems, which required elements of trustworthiness, for the past 40-plus years in defense, intelligence, homeland security, finance, transportation and other commercial environments.
In my first week at Sun Microsystems in 1990, one of my first tasks for the president of Sun Federal was to decide which of two competing trusted operating system development efforts would survive. In selecting SunOS CMW over SunOS MLS, I set the course towards the creation and deployment of Trusted Solaris. Because of this decision and my strong advocacy, I am often referred to as the “father” of Trusted Solaris. If you are interested in the two initiatives and why I picked one over the other, then let me know and I will discuss them in a later issue.
Prior work in mission critical cryptography, Command and Control systems and the Intelligence community — the initial targeted audience for Trusted Solaris – made this at least an educated decision. In later issues I will walk through that and other decisions (mine and others) that have shaped aspects of trustworthiness for the sensitive and mission critical communities. My interests and experiences will take us on a jagged course towards the elusive target of trustworthiness.
So, what is trustworthiness about, anyway? Consulting the ultimate oracle of all knowledge, Wikipedia, I came up with the following: “Trustworthiness is a moral value considered to be a virtue. A trustworthy person is someone in whom you can place your trust and rest assured that the trust will not be betrayed. A person can prove their trustworthiness by fulfilling an assigned responsibility – and as an extension of that, not to let down expectations.” This is appropriate and accurate but not exactly what I was looking for. Fortunately, the second description came closer to my objective: “A trusted component has a set of properties that are relied upon by another component. If A trusts B, this means that a violation in those properties of B might compromise the correct operation of A. Observe that those properties of B trusted by A might not correspond quantitatively or qualitatively to B’s actual properties.” Closer but unclear.
Basically, you can discuss levels of securerobe trust from a frame of reference of trustworthiness. A trusted Operating System as part of a broader solution can be measured as a level of trustworthiness based on the design, development, testing, and independent assessment and certification that were followed in its creation. Trusted Solaris was not trustworthy just because of the development regimen that was followed in implementing the critical controls, interfaces and display systems, but these in conjunction with independent evaluation by a licensed lab and staff. When we first had Trusted Solaris evaluated, it was under the auspices of the National Security Agency (NSA) Orange Book. The serious limitation that this presented was global acceptance of a U.S.-specific specification and certification. Later, the Common Criteria was developed by a consortium of nations as a replacement of the ‘Colored Books’ approach of the NSA.
Trustworthiness is far broader than operating systems though, and I intend to address many other aspects. The recent adoption of token technologies and Near Field Communications devices and software presents many trustworthiness challenges. At the grandest scale, what happens when your solution that is presumed to meet all of the aspects of trustworthiness, fails – or worse yet – is cryptographically broken after it is already widely deployed? The successful cryptographic attack on the UK’s Oyster trusted transit token is an example that I will address later. I introduced the EAL4+ trusted Felica NFC solution, from Sony, to the UK Home Office when the previous technology no longer provided appropriate aspects of trustworthiness. This was both time-sensitive and critical, as Oyster had been planned into the transportation trustworthiness architecture for the London Olympics. EAL4+ is a measure of trustworthiness assured under the Common Criteria Scheme accepted in more than 25 countries. I will address aspects of Common Criteria as an appropriate measure of trustworthiness in later columns.
An area of much confusion lies in the evolving world of cloud computing. I wrote a series of blogs on the reality of security in the cloud while at TIBCO Software. You can find the series here.
In future columns, I will delve into the realities versus what someone wants to sell you, in the cloud and cloud security spaces. I will also be going into the basic steps you need to take and what you need to know, when you put your treasures on someone’s cloud platform. Hint: The use of aspects of trustworthiness is critical to your choice.
securerobe 