Found content (found in my “Sent Items” folder, I’d forwarded it from one of my e-mail accounts to another a few months ago—persistent personal content-of-interest store—an analyst is only as productive as his/her personal library-caches): AnalystViews Weekly Report for Week of 12.22.2005, “Two Rights: The Restriction and Management of Digital Rights”
My take:
DRM is another name for flexible deployment of content-control policy-enforcement logic throughout networks.
The referenced article references another article (September 20005 EContent magazine) that wraps DRM into a larger phenomenon called “enterprise rights management (ERM).” According to the source article (as paraphrased in the referenced article), the “primary objective of these systems is to protect the intellectual property of an enterprise; in the field this is seen as having two components. The first of these is access to the digital asset itself, in the past systems were able to restrict access, but once the material was legally accessed there was little in place to restrict it. Thus maintaining post-access security becomes the second component. Many systems currently in place implement a number of various methods to address the first part of the challenge, asset access, and these range from simple password protection to biometric user verification. More advanced systems are beginning to apply controls which will protect the document post-access, these can prevent electronic screen capturing and the forwarding of files via email, and some can even be linked to peripheral devices to impede the printing or scanning of protected files.”
This brings us back to a notion I introduced earlier in this thread (DRM7, which is actually/paradoxically later in this thread if you follow the virtual scroll from top to bottom, numerically from 1—and you know I’m working up to DRM1—down to the alpha/omega of DRM9—got that?): “DRM is another name for cryptographic containers that wrap content in persistent policies under the control of the content’s creator and/or owner.” That’s another name for “advanced systems are beginning to apply controls which will protect the document post-access, these can prevent electronic screen capturing and the forwarding of files via email, and some can even be linked to peripheral devices to impede the printing or scanning of protected files.” My earliest exposure to these “post-access security” crypto-content-containers was a few years back, in the form of “self-destructing e-mail” systems from the likes of Authentica, Sigaba, and others whose names have self-destructed in my ancient memory.
Which brings me to a critical functional/architectural distinction in DRM (or ERM, whatever you like):
- Policy enforcement points (PEPs): This refers to any access management portal/proxy/front-end (e.g., CA SiteMinder, IBM Tivoli Access Manager) that authenticates and authorizes users to access/retrieve content “into the clear,” but doesn’t have any power to control what users do with the content once it’s been retrieved into users’ perpetual possession—in other words, this refers to identity and access management (I&AM) as it’s normally understood.
- Policy enforcement containers (PECs): This refers to (here’s the phrase of mine again): “cryptographic containers that wrap content in persistent policies under the [perpetual] control of the content’s creator and/or owner”—in other words, DRM (and “self-destructing e-mail”) as it’s normally understood.
It’s clear that these architectural approaches differ primarily in where they deploy the access control logic. Which explains why I&AM vendors are, as I blogged on November 4, 2005:
- “targeting DRM as the next great frontier beyond federation? Or, perhaps, they hope, DRM will leverage and extend their increasingly federated security infrastructures into a distributed permissioning infrastructure where the access-control policy enforcement points (PEPs) are more closely bound to the resources—apps, data, etc.—being protected? Epok’s federated data interchange environment—leveraging XRI and XDI--is one such example. Sun’s “storage encryption” or “storage security” roadmap (see article) is another. As soon as the morning coffee decompresses my wound-up nightfunk, I’m sure I’ll recall the other three dozen vendors I’ve come across recently who have similar roadmaps.DRM drifts and diffuses itself far and wide throughout IdM, security, e-commerce, content publisher, and storage vendors’ end-of-decade dreams. I think a lot of the renewed attention to DRM recently comes from the rash of identity-theft “data breaches” that have grabbed front-page attention. All that data in storage is sitting ducks and buried treasure for those intrepid identity pirates who find the buried map and go with flashlights in the night down into the caverns guarded by semi-reliable genies. Suddenly, encrypting all that stuff in situ—on piled-high disks and tapes and whatnot--becomes the absolute imperative for storage managers everywhere, dictated by the lawyers, bosses, and regulators.To make encryption—an ancient technology that has been used in storage systems for years in various capacities—seem suddenly cool—not simply mandatory--the vendors have started to lump it into the growing DRM umbrella. Acronym creep, equivalent to the vastly expanded scope of SOA in recent years. It’s not storage encryption anymore. It’s storage DRM. It’s breach-busting DRM. It’s federated DRM. It’s a new pipe DRM.”
If this blogpost is getting too self-referential for its own good. If you’re getting dizzy or disturbed by the ever-shifting context. Then I’m with you. I’ve had enough for now. Till DRM4 suggests itself. And it will. I can feel it.
Jim
