Hardware, software, wetware, and tasking security

In the early 2000s I was working at a company called NCR for a customer called Sun Microsystems. We were implementing a product called Sun Remote Services as customer premise monitoring equipment of the Sun hardware. A job like that made complete sense since I had been senior technical lead on a project of similar goals at MCIWorldcom in 1999 and had a pretty good idea about deployment and integration models. This isn’t a story about implementation and large projects with tight timelines. This is a little case analysis of information as an asset.

I tell my students that it isn’t about the system it is about the information and they look at me quizzically. After all in their minds the container is the system and much like a bucket contains water without the container the information is useless. Yet, the discussion of security of information versus systems is very important. The likely problem of system versus information has roots in the cultural and personalities of the original electronic computational revolution. White lab coat wearing specialists tended monolithic machines and adherents approached timidly with their stacks of Hollerith cards as supplicants before an altar. That kind of subservience and cultural fusion has deep roots in the psyche of the community.

I though take a different tack and recount a small story of me talking to a CIO at a major company. I was trying to confer the security plan and the networking schema of the Sun Wide Area Network (SWAN) in such a way as the customer (the CIO) would be comfortable having yet another vendor area network (YAVAN) connection in his data center. Looking at the spreadsheet of Sun systems I countered his tepid enthusiasm with a statement that he had millions upon millions of dollars in hardware sitting on the data center floor and didn’t he have a duty to protect that investment. He was kind in teaching me a very important lesson.

He told me that though he had hundreds of millions invested in information technology that the investment represented less than 5% of his operating capital. That on the scale of things the landscaping and janitorial staff was larger and better funded. As a major corporation the assets that he was charged with protecting were the information assets inside the computers and that this is where he was focused at all times. He could literally give a flying monkeys butt for the hardware as he could insure that (thus transferring the risk). He could not give up at any time vigilance on the core information assets as they represented the product and future of the company.

And, there I was asking him for administrative privileges to the inner sanctum of his entire data center and the core repository of those very special information assets.

So, there has been a lot of ink spilled on enterprise architecture and systems security architecture. Many of those pieces leave me feeling a mild sense of shock. The better pieces I’ve read state that information must be encrypted at rest, encrypted in transit and only processed on trusted, vetted, watched processors. Once that is accomplished integrity should be validated often and information changes authenticated. This puts a significant requirement of a protected and hardened key authentication point, but it also alleviates a lot of other protection mechanisms from doing too much with too little.

Think about the goals of security and the requirements that you have to manage to reach those goals. Each trade off of usability for security increases the sophistication required to use the system and likelihood of a system based security failure. That is one reason I like the iPhone model where the original iPhone had complete sandboxing and as implemented lately a control on the hooks to various internal sensor/data packages. Usability and security fused together seamlessly. Of course in the later instantiations of the iPhone system some secure functions strategies were abandoned to create even more usability.

In other areas we see perimeter and network security as the mechanisms to protect information assets. Yet each of those are about mitigating attacks and vulnerabilities of computer systems (hardware and software). The focus is on stopping a known set of issues based on the architecture of the organization. That isn’t usually the best strategy as we’ve seen again and again. Since spearphishing and other forms of social engineering are predicated on passing traffic that looks normal until it reaches the leaves of the organization.

That brings us back again to the concept of protecting the information asset (in state) wherever that information asset is located. This is just some ideas to toss around, and think about.

 

Leave a Reply