Wednesday, October 04, 2006

Thoughts on Virtual Trust

I've said before that there is no return on security investment (ROSI). This argument appears to have morphed again in the form of a paper titled Creating Business Through Virtual Trust. A Technorati search will show you other comments on this idea. These are mine.

First, I agree with others who say "virtual trust" should not be "virtual" -- it's either "trust" or it's not. That's not a major point though.

Second, the thesis for the paper appears to be the following, as shown in the abstract.

Business is concerned with the creation of new entities and assets that generate cash. Information security, by contrast, is traditionally concerned with protecting these entities and assets. In this paper we examine a perspective which currently exists but is largely dormant in the information security field. We maintain that information security can be actively involved in the creation of business and that the skills required to create commercial activity must be added to the information security professional's intellectual tool set. We also present evidence to demonstrate that the capability of security to create business, which we designate by the term "virtual trust", may become a dominant paradigm for how to think about information security.

The authors provide this example:

Apple' iTunes employed Digital Rights Management (DRM) technologies to create a new product and, hence, a new revenue stream. Over 1 billion songs have been downloaded from iTunes. In the case of iTunes, DRM works by restricting the number of CPUs on which the .mp3 will play. The songs are also stored in a proprietary, encrypted format. These two factors, at minimum, erect a prohibitive barrier and thereby reduce the likelihood that an end user will trade songs. The various security mechanisms used by Apple's iTunes DRM created the Virtual Trust necessary to persuade the music industry that their rights will be protected digitally and be profitable.

I see nothing wrong with this statement. However, security is not making money in this example -- iTunes sales are making money. Imagine a world without DRM. Someone buys a song, then gives it to their friends. Apple and the music companies believe those extra copies are lost sales. What have we returned to? That's right -- a loss prevention model.

"Virtual Trust" is just another name for the Road House security model. Security is not making money for anyone in the bar Patrick Swayze patrols. Alcohol and food sales are making money.

Security may be a necessary condition for sales and a thousand other activities, but it doesn't make any money. Imagine this exchange between executives:

SecGuy: "Hey boss, I have a great idea for enabling business through virtual trust."

Boss: "What is it?"

SecGuy: "I'm going to secure a business initiative that will make millions!"

Boss: "What is the initiative?"

SecGuy: "Hmm, I don't know. But whatever it is I will secure it and enable business through virtual trust!"

Boss: "Sigh."

You can watch one of the authors of this paper post his thoughts on his blog.

11 comments:

Kenneth F. Belva said...

Remember, the whole point of this paper is to show that security is a business enabler.....

Richard, you write:

"I see nothing wrong with this statement. However, security is not making money in this example -- iTunes sales are making money. Imagine a world without DRM. Someone buys a song, then gives it to their friends. Apple and the music companies believe those extra copies are lost sales. What have we returned to? That's right -- a loss prevention model."

I dealt with the loss prevention type of objection as well as the "security is not making money" objection in a full disclosure post here:
http://lists.grok.org.uk/pipermail/full-disclosure/2006-September/049698.html

It applies to your argument. In your example you assume that the song on iTunes could be created without DRM. The point is that cannot because the necessary trust does not exist for it to happen. When you say that "security is not making money" this is not really an objection to the paper because you are assuming that security is a sufficient condition, which it can never be. (So, I agree with you.) It's a necessary condition for the creation of an asset. You cannot have iTunes without DRM.

Please reconsider the paper in the perspective of security as an enabler. Perhaps you will find merit in it.

Kenneth F. Belva said...

Quibbling over terminology!

Richard, you write: "First, I agree with others who say "virtual trust" should not be "virtual" -- it's either "trust" or it's not. That's not a major point though."

So do you also agree with the statement that:
"Electronic commerce" should not be "electronic" -- it's either "commerce" or it's not.

Perhaps you didn't read the paper because we write on page 16:

"From an historical perspective, how is such trust between entities established? Entities have used seals, signatures, contracts, deeds, treaties, notarized documents, handshakes and code words, among other methods, to create trust. These non-electronic
(and/or physical) tokens of trust may be categorized as Traditional Guarantors of Trust, mainly for historical reasons. Often there exists a system -- such as a government or coalition of governments -- to settle disputes should they arise between the parties that made the agreement. In a less abstract context, the U.S. state and federal court systems are examples of independent entities enforcing Traditional Guarantors of Trust.

In contrast to Traditional Guarantors of Trust, we categorize electronic, nonphysical tokens of trust as Virtual Guarantors of Trust. Examples of Virtual Guarantors of Trust include digital certificates, digital signatures, user names and passwords, public and private keys, the digital numeric sequence in two-factor authentication tokens, the electronic representation of a biological identifier, checksums and hashes.

Therefore, we make a distinction between Traditional Trust (which uses Traditional Guarantors of Trust) and Virtual Trust (which relies upon Virtual Guarantors of Trust)."

Richard Bejtlich said...

Ken,

I'm a security guy. You won't find me arguing that security isn't necessary. You won't find other security people arguing that security isn't necessary. If your core argument is security is necessary, what's new about that?

As far as a lack of business knowledge on the part of the security professional, the point is that the act of providing security for a project doesn't generate revenue -- the project generates revenue. You say [s]ecurity enables which in turn generates revenue. You forget to mention that the project generates revenue, not security.

Kenneth F. Belva said...

Richard,

What's new is that we show how security mechanisms can be used in a context which are not described as loss prevention. We can describe security as an enabler. We can demonstrate and show how this enablement itself works. This was not done in the past to an satisfactory degree. If it were you (as well as Mike Rothman) would be taking the paper as common knowledge.

When you write that it's "the project generates revenue, not security," again you are expecting security to generate revenue all by itself, a sufficient condition. As mentioned in the full-disclosure post I posted above, I never claim that. This is simply a slight change of the "security is not making money" (because it's now the project) objection already dealt with above. Also, the term project is too vague. You can clearly have projects that are not meant to generate revenue, but are business oriented. And, we can distinguish between a digital asset and a project.

I would also like to mention that I do not say we should or could discard the loss prevention model, only that there is another model that may be employed to describe how security functions.

Ken

Rob Lewis said...

This is clearly a cart-before-the-horse deninitional/semantics issue. I see some value in what Ken Belva says. If a project could not proceed unless security was assured, then it is an enabler. If that is the "road house effect" so be it. The problem as I see it is that many projects, past and present, have proceeded without adequate security. In fact, almost all businesses out there are guilty of ignorance or "it can never happen to me" thinking. Only since legislation has arrived on the scene (privacy, Sox, breach disclosure etc.) have company execs paid more attention to security, and those efforts are to avoid fines, lawsuits and jail time.

That being said, if the need for a certain level of security investment is identified as necessary to obtain an unacceptable level of risk that one can live with, then that becomes an identifiable sunk cost.

If a second,new security option materializes that delivers the same outcome (or more), but with less expense,then that is delivering same value for less money, and thus the cost saving as compared to the first option would be a legitimate ROI, would it not?

Anonymous said...

just a question ... wouldn't information security in the corporate world be more analagous to the insurance industry. Insurance/information security doesn't create revenue on it's own - it is an accepted practice and is budgeted because it provides a reasonable level of assurance that any tupe of loss can be mitigated financially.

I definitely see INFOSEC as more than just loss prevention in terms of benefit to the corporation, but saying that it can be considered revenue generating for a company is a hard battle to fight when your talking to a CFO. You might argue that without this "insurance" you would lose customers and therefore reduce profit, but that is not a direct revenue source. I can see saying that by having security packaged around a product it is more trustworthy and therefore may increase usage. (How many of us would trust our money with the banking system if they were not insured by the FDIC?

In the military/government sector this is also partially true but other (not only financial) risks exist so the model is a bit different and not directly relevant to this conversation.

Kenneth F. Belva said...

Hi Rob,

Thanks for the support.

I would like to say that sometimes we can even make a stronger claim than simply that "If a project could not proceed unless security was assured, then it is an enabler".

I would like to say that some assets or processes (revenue streams) could not exist at all without the security. Take E-Z Pass in New York State and the east coast. Without authentication (security mechanism), this process / revenue stream could not have been created. See: http://www.nysthruway.gov/ezpass/ezwork.html The E-Z Pass tag is an RFID tag. Yes, there are loss protection mechanisms such as a video enforcement system but without authentication E-Z Pass could not exist. Security (authentication) enabled E-Z Pass: without the authentication mechanism everyone would need to pay in cash.

Can we not say that security is an enabler? Surely when we describe authentication as exampled with E-Z Pass we are not describing it as Swayze's character functioned (one of patrolling, enforcing and correcting) in the film Road House. This is certainly not a game of semantics! And, it's not security as the insurance or loss prevention model either!

To everyone interested, here is a link to the most relevant resources I created on VT:
http://www.bloginfosec.com/?p=75

Thanks for the interesting discussion Richard and Rob. Please keep up the dialogue.

Ken
http://www.bloginfosec.com
http://www.ftusecurity.com

John Ward said...

Ken,

I agree. Security can be an enabler, but it is not revenue generating, and the points of view you are giving are not supportive of your argument.

To support your argument, you need to look at it from a different point of view. In the case of E-Z Pass, the revenue stream in question has existed as long as there have been toll roads. This didn't open up a new revenue stream, nor was security a requirement for collecting tolls. It is the convenience that is the enabler in the case of EZ Pass, not the security.

Your example of I-Tunes, while in the right ball park, is not focusing on where the action is. The DRM that consumers receive is not an incentive for them to use I-Tunes, in fact it is quite the opposite. DRM is an incentive for the music industry to use I-Tunes as a distribution channel, and that is because of the increase in trust created by DRM. That’s producer to market, not market to consumer. DRM is not a valid market to consumer incentive, and does not increase trust. In the case of producer to market, I will say that security is indeed an enabler, but not for the consumer. I would change that example.

Using I-Tunes as an example, digital certificates, user authentication, SSL, credit card verification are examples of Trust mechanisms. But these too do not increase revenue stream for I-Tunes. These are overhead costs because they are necessary to ensure trust. While business can be conducted in this scenario without trust, it is neither in the company nor the client’s best interest to do so. In this case, security is not an enabler, but loss prevention for I-Tunes and its customers.

That’s the problem with theoretical arguments, since they aren't tangible, nor are they mathematically sound, they cannot be proven. Given any one persons point of view, it can be proven or disproved. But it is thought provoking.

Kenneth F. Belva said...

You write: "In the case of E-Z Pass, the revenue stream in question has existed as long as there have been toll roads." Not true. There was always ordering by mail before there was the telephone. People would say that the telephone created a new cash flow, right? In the same way, E-Z Pass created a new revenue stream / cash flow instead of paying by cash.

You write: "While business can be conducted in this scenario without trust, it is neither in the company nor the client’s best interest to do so." But that's exactly my point. People *assume* the trust here, do they not? Would you order with your credit card from a website without SSL? No. You don't trust it. So, again we are back to saying that trust is necessary for enablement.

Earlier you write: "DRM is an incentive for the music industry to use I-Tunes as a distribution channel, and that is because of the increase in trust created by DRM." And then write, "Using I-Tunes as an example, digital certificates, user authentication, SSL, credit card verification are examples of Trust mechanisms. But these too do not increase revenue stream for I-Tunes." Aren't these the trust mechanisms through which the distribution channel is created thus helping to create a revenue stream? Aren't you contradicting yourself here?

You write: "That’s the problem with theoretical arguments, since they aren't tangible, nor are they mathematically sound, they cannot be proven. Given any one persons point of view, it can be proven or disproved. But it is thought provoking." Well, we give real world cases (iTunes, E-Z Pass, Pay-per-click advertising) so the virtual trust model it is not any more or less theoretical than the loss prevention model.

John Ward said...

Ken,

Using the I-tunes model, I am pointing out that there are three parties involved, producer, distributor, and consumer. DRM is not an enabler between the consumer and the distributor, but it is between the producer and the distributor that is creating and additional revenue. Like wise, the I-tunes stores SSL certificates and user authentication are enable trust, but are not creating the revenue. The revenue is generated by demand, security in that example is just a property of the business transaction, and not necessary for all transactions.

If we combine the SSL Certificates, user Authentication, and DRM into a single, abstract product called security, then yes, it is an enabler and a revenue generator for I-Tunes. But specifically, the appropriate product needs to be associated with the proper party, and it is not a profit maker in all cases.

Kenneth F. Belva said...

Hi John,

You have raised some excellent points in your replies. It seems to me we are closer in perspective then previously thought.

You write: "DRM is not an enabler between the consumer and the distributor, but it is between the producer and the distributor that is creating and additional revenue." Well, by definition a consumer will not generate revenue. They are the spenders in the equation. Consumers will benefit from the DRM trust because they will know that their songs are not pirated and are legal copies. So I agree but this does not counter VT.

You write: "The I-tunes stores SSL certificates and user authentication are enable trust, but are not creating the revenue." Again, the "not creating the revenue" claim assumes that security can be a sufficient condition, which I do not claim it can be. See previous full-disclosure arguments in above posts.

You write: "Security in that example is just a property of the business transaction, and not necessary for all transactions." This an interesting claim, but I think this should be thought of in terms of trust. Different levels of trust are needed for different types of transactions. Security and security mechanisms are employed to guarantee that the level of trust exists for the level called upon by the transaction type. In other words, you might employ weak RFID authentication for E-Z Pass while strong biometric encryption for highly classified government documents. In commerce, normal IM message is often without digital signatures (non-repudiation) but SWIFT messages used to conduct transactions between financial institutions require them.

You write: "If we combine the SSL Certificates, user Authentication, and DRM into a single, abstract product called security, then yes, it is an enabler and a revenue generator for I-Tunes. But specifically, the appropriate product needs to be associated with the proper party, and it is not a profit maker in all cases." I agree, but two points. First, the argument is specific to iTunes. The E-Z Pass example only uses authentication. Second, I do not claim that security can be a profit maker in all cases. Only that there are real world specific examples that we can show security being employed as an enabler. It is a claim that could not stand ground before.

Virtual Trust is clearly a defensible model. I hope you see some merit in it and can use it pragmatically.