Security attributes of data and data should be inseparable
I was having lunch last week with a good friend, Kurt Stammberger, discussing various security technologies and the state of the industry in general . If you’re not familiar with the name, think RSA Security Conference, as Kurt successfully guided that event from its origins as a small conference room gathering to one of the largest security events around. During lunch Kurt brought up the Transactor project, a Digital Rights Management platform that proposed a method of creating unique objects that the two of us had worked on together. That dredged up a lot of old memories and war stories. Reminiscing over the amazing people who worked on that project, how advanced the security was in both design and execution brought to mind many of the same old problems we are trying to solve today. But as with many tech startups, there was some incredible work never saw the light of day. The crux of the conversation was this is a great idea, but one who’s time had not yet come.
Ironic that when I got back from lunch I ran across Gunnar Peterson’s article on SOA security. I think the Gunnar is dead on target! The introductory examples that it is about the car, and not about the garage is precisely the point. How do you protect data in a distributed environment, not just when parked but also when in motion? Who do you trust and what rules do you enforce? This must be part of the design if the system is to have a chance for success, and to extend that one step further, wrapped around or embedded with the data. The car is secured, not the garage.
It is based upon these concepts I have proposed that the ability to protect data without some form of wrapper or ‘meta data’ is difficult to impossible in an SOA environment, either at rest or in motion. And coincidentally, this is much of what the Transactor project was about, and quite specifically what the Limited Edition Digital Object was meant to provide a medium for this type of transfer. In a nutshell, a LEDO is a container with embedded use and ownership rules, private & public components, with each component maintained by its respective owner. I have even gone so far as to propose that perhaps we do away with the concept of unstructured data altogether in the corporate environment. If it is valuable, wrap it up, and let the data bring its own security and ownership along for the ride.
In the late 90s the Transactor team members at large viewed this type technology as fundamental to Internet commerce, as security and ownership are critical elements to conducting commerce, so the need was obvious to this tiny minority. There was considerable conviction that we were building ‘the right thing’. Many people outside the team thought we were a cursed group of morons, bringing our unneeded security to their projects, and told us as much. Especially members of other projects in house projects, who had our beta version DRM technology rammed down their throats under the guise of ‘eating ones own dog food ‘. While surprised at the hostility we generated at the time, it did prepare me in the coming decade as how those who are not worried about security perceive it as pure hindrance to their own activities, and willing to go to great lengths to avoid dealing with these additional challenges. I have come to expect that security is still not typically part of the development process because it is not part of the specification, process or mindset of the development teams.
I have talked with several members of the security community about this over the last few months and the concept of a data centric security model is starting to gain some momentum. I will delve into some of these concepts and variations more thoroughly in the future, as there are many potential variants. There is no hurry because the market is still 3-5 years away at best. We are a long way away from viewing data security as an enablement for conducting transaction in open – and subsequently more risky – environments. I hope that Gunnar’s article will get some attention by software architects in the meantime, as less time discussing the use of POJO’s, and more time discussing security in a distributed processing environment is needed.
Comments