By Adrian Lane
Rich forwarded me this article on Boing Boing regarding "Kindle Books having download caps" on content. That just shattered my enthusiasm.
A kind word of caution to Amazon: If you allow embedded Digital Rights Management content into Kindle media, your product will die. You are selling to early technology adopters, and history has confirmed they don't tolerate DRM. It's an anti-buyer technology, and the implementation requires (wrong) assumptions be made as to how a user want to use the device. History has also demonstrated that if you do push DRM with the content, the scheme will be broken, and people will do it just because they can.
If you are worried about getting content, and feel you need DRM to appease content owners of major publishing houses, don't. This is a very cool device, and content will come from thousands of sources, and people will find ways to use it you never thought possible.
–Adrian Lane
By Rich
One of the more difficult aspects of the analyst gig is sorting through all the information you get, and isolating out any inherent biases. The kinds of inquiries we get from clients can all too easily skew our perceptions of the industry, since people tend to come to us for specific reasons, and those reasons don't necessarily represent the mean of the industry. Aside from all the vendor updates (and customer references), our end user conversations usually involve helping someone with a specific problem -- ranging from vendor selection, to basic technology education, to strategy development/problem solving. People call us when they need help, not when things are running well, so it's all too easy to assume a particular technology is being used more widely than it really is, or a problem is bigger or smaller than it really is, because everyone calling us is asking about it. Countering this takes a lot of outreach to find out what people are really doing even when they aren't calling us.
Over the past few weeks I've had a series of opportunities to work with end users outside the context of normal inbound inquiries, and it's been fairly enlightening. These included direct client calls, executive roundtables such as one I participated in recently with IANS (with a mix from Fortune 50 to mid-size enterprises), and some outreach on our part. They reinforced some of what we've been thinking, while breaking other assumptions. I thought it would be good to compile these together into a "state of the industry" summary. Since I spend most of my time focused on web application and data security, I'll only cover those areas:
When it comes to web application and data security, if there isn't a compliance requirement, there isn't budget -- Nearly all of the security professionals we've spoken with recognize the importance of web application and data security, but they consistently tell us that unless there is a compliance requirement it's very difficult for them to get budget. That's not to say it's impossible, but non-compliance projects (however important) are way down the priority list in most organizations. In a room of a dozen high-level security managers of (mostly) large enterprises, they all reinforced that compliance drove nearly all of their new projects, and there was little support for non-compliance-related web application or data security initiatives. I doubt this surprises any of you.
"Compliance" may mean more than compliance -- Activities that are positioned as helping with compliance, even if they aren't a direct requirement, are more likely to gain funding. This is especially true for projects that could reduce compliance costs. They will have a longer approval cycle, often 9 months or so, compared to the 3-6 months for directly-required compliance activities. Initiatives directly tied to limiting potential data breach notifications are the most cited driver. Two technology examples are full disk encryption and portable device control.
PCI is the single biggest compliance driver for web application and data security -- I may not be thrilled with PCI, but it's driving more web application and data security improvements than anything else.
The term Data Loss Prevention has lost meaning -- I discussed this in a post last week. Even those who have gone through a DLP tool selection process often use the term to encompass more than the narrow definition we prefer.
It's easier to get resources to do some things manually than to buy a tool -- Although tools would be much more efficient and effective for some projects, in terms of costs and results, manual projects using existing resources are easier to get approval for. As one manager put it, "I already have the bodies, and I won't get any more money for new tools." The most common example cited was content discovery (we'll talk more about this a few points down).
Most people use DLP for network (primarily email) monitoring, not content discovery or endpoint protection -- Even though we tend to think discovery offers equal or greater value, most organizations with DLP use it for network monitoring.
Interest in content discovery, especially DLP-based, is high, but resources are hard to get for discovery projects -- Most security managers I talk with are very interested in content discovery, but they are less educated on the options and don't have the resources. They tell me that finding the data is the easy part -- getting resources to do anything about it is the limiting factor.
The Web Application Firewall (WAF) market and Security Source Code Tools markets are nearly equal in size, with more clients on WAFs, and more money spent on source code tools per client -- While it's hard to fully quantify, we think the source code tools cost more per implementation, but WAFs are in slightly wider use.
WAFs are a quicker hit for PCI compliance -- Most organizations deploying WAFs do so for PCI compliance, and they're seen as a quicker fix than secure source code projects.
Most WAF deployments are out of band, and false positives are a major problem for default deployments -- Customers are installing WAFs for compliance, but are generally unable to deploy them inline (initially) due to the tuning requirements.
Full drive encryption is mature, and well deployed in the early mainstream -- Full drive encryption, while not perfect, is deployable in even large enterprises. It's now considered a level-setting best practice in financial services, and usage is growing in healthcare and insurance. Other asset recovery options, such as remote data destruction and phone home applications, are now seen as little more than snake oil. As one CISO told us, "I don't care about the laptop, we just encrypt it and don't worry about it when it goes missing".
File and folder encryption is not in wide use -- Very few organizations are performing any wide scale file/folder encryption, outside of some targeted encryption of PII for compliance requirements.
Database encryption is hard, and not widely used -- Most organizations are dissatisfied with database encryption options, and do not deploy it widely. Within a large organization there is likely some DB encryption, with preference given to file/folder/media protection over column level encryption, but most organizations prefer to avoid it. Performance and key management are cited as the primary obstacles, even when using native tools. Current versions of database encryption (primarily native encryption) do perform better than older versions, but key management is still unsatisfactory. Large encryption projects, when initiated, take an average of 12-18 months.
Large enterprises prefer application-level encryption of credit card numbers, and tokenization -- When it comes to credit card numbers, security managers prefer to encrypt it at the application level, or consolidate numbers into a central source, using representative "tokens" throughout the rest of the application stack. These projects take a minimum of 12-18 months, similar to database encryption projects (the two are often tied together, with encryption used in the source database).
Email encryption and DRM tend to be workgroup-specific deployments -- Email encryption and DRM use is scattered throughout the industry, but is still generally limited to workgroup-level projects due to the complexity of management, or lack of demand/compliance from users.
Database Activity Monitoring usage continues to grow slowly, mostly for compliance, but not quickly enough to save lagging vendors -- Many DAM deployments are still tied to SOX auditing, and it's not as widely used for other data security initiatives. Performance is reasonable when you can use endpoint agents, which some DBAs still resist. Network monitoring is not seen as effective, but may still be used when local monitoring isn't an option. Network requirements, depending on the tool, may also inhibit deployments.
My main takeaway is that security managers know what they need to do to protect information assets, but they lack the time, resources, and management support for many initiatives. There is also broad dissatisfaction with security tools and vendors in general, in large part due to poor expectation setting during the sales process, and deliberately confusing marketing. It's not that the tools don't work, but that they're never quite as easy as promised.
It's an interesting dilemma, since there is clear and broad recognition that data security (and by extension, web application security) is likely our most pressing overall issue in terms of security, but due to a variety of factors (many of which we covered in our Business Justification for Data Security paper), the resources just aren't there to really tackle it head-on.
–Rich
By Adrian Lane
I have a well-publicized love-hate opinion of Digital Rights Management. DRM can solve some security problems but will fail outright if applied in other areas, most notably consumer media protection. I remain an advocate and believe that an Information Centric approach to data security has a future, and I am continually looking for new uses for this model. Still, few things get me started on a rant like someone who says that DRM is going to secure consumer media, and DRM in the Cloud is predicting just that.
New box, same old smelly fish. Be it audio or video, DRM secured content can be quite secure at rest. But when someone actually wants to watch that video is when things get interesting. At some point in the process the video content must leave its protective shell of encryption, and then digital must become analog. Since this data is meaningless to someone unless they can view it or use it, at some point this transition must take place! It is at this transition point from raw data to consumable media when the content is most vulnerable- the delivery point. DRM & Information Centric Security are fantastic for keeping information secret when the people who have access to it want to keep it a secret. They are not as effective when there is a recipient who wants to violate that trust, and fail outright when that recipient has control of the software and hardware used for presentation.
I freely admit that if the vendor controls the hardware, the software, and distribution, it can be made economically unfeasible for the average person to steal. And I can hypothesize about how DRM and media distribution can be coupled with cloud computing, but most of these examples involve using vendor approved software, in a vendor approved way, over a reliable high speed connection, using a 'virtual' copy that never resides in its entirety on the device that plays it. And a vendor approved device helps a whole lot with making piracy more difficult, but DRM in the Cloud claims universal device support, so that is probably out of the question. But at the end of the day, someone with the time and inclination to pirate the data will do so. Whether they solder connections onto the system bus or reverse engineer the decoder chips, they can and will get unfettered access- quite possibly just for the fun of doing it!
The business justification for this effort is odd as well. If the goal is to re-create the success of DVD as stated in the article, then do what DVD did: twice the audio & video quality, far more convenience at a lower cost. Simple. Those success factors gave DVDs one of the fastest adoption curves in history. So why should an "Internet eco-system that re-creates the user experience and commercial success of the DVD" actually recreate the success of DVD? The vendors are not talking about lower price, higher quality, and convenience, so what is the recipe for success? They are talking about putting their content online and addressing how confused people are about buying and downloading! This tells me that the media owners think that they will be successful if they move their stuff onto the Internet and make DRM invisible. If you think just moving content onto the Internet alone makes a successful business model, tell me how much fun it would be to use Google Maps without search, directions and or aerial photos- it's just maps taken online, right? Further, I don't know anyone who is confused about downloading; in fact I would say most people have that pretty much down cold. I do know lots of people who are pissed off about DRM being an invasive impediment to normal use; or the fact they cannot buy the music they want; or things like Sony's rootkit and various underhanded and quasi-criminal tactics used by the industry; and the rising cost of, well, just about everything. Not to get all Friedrich Hayek here, but letting spontaneous market forces determine what is efficient, useful, and desirable based upon perceived value of the offering is a far better way to go about this. This corporate desire to synthetically recreate the success of DVDs is missing several critical elements, most notably, anything to make customers happy.
The "Cloud Based DRM" technology approach may be interesting and new, but it will fail in exactly the same way, for exactly the same reasons previous DRM attempts have. If they want to succeed, they need to abandon DRM and provide basic value to the customer. Otherwise, DRM, along with the rest of the flawed business assumptions, looks like a spectacular way to waste time and money.
–Adrian Lane
