Schneier on Security
A blog covering security and security technology.
« Hacking the Brazil Power Grid |
| FBI/CIA/NSA Information Sharing Before 9/11 »
November 12, 2009
Security in a Reputation Economy
In the past, our relationship with our computers was technical. We cared what CPU they had and what software they ran. We understood our networks and how they worked. We were experts, or we depended on someone else for expertise. And security was part of that expertise.
This is changing. We access our email via the web, from any computer or from our phones. We use Facebook, Google Docs, even our corporate networks, regardless of hardware or network. We, especially the younger of us, no longer care about the technical details. Computing is infrastructure; it's a commodity. It's less about products and more about services; we simply expect it to work, like telephone service or electricity or a transportation network.
Infrastructures can be spread on a broad continuum, ranging from generic to highly specialized. Power and water are generic; who supplies them doesn't really matter. Mobile phone services, credit cards, ISPs, and airlines are mostly generic. More specialized infrastructure services are restaurant meals, haircuts, and social networking sites. Highly specialized services include tax preparation for complex businesses; management consulting, legal services, and medical services.
Sales for these services are driven by two things: price and trust. The more generic the service is, the more price dominates. The more specialized it is, the more trust dominates. IT is something of a special case because so much of it is free. So, for both specialized IT services where price is less important and for generic IT services -- think Facebook -- where there is no price, trust will grow in importance. IT is becoming a reputation-based economy, and this has interesting ramifications for security.
Some years ago, the major credit card companies became concerned about the plethora of credit-card-number thefts from sellers' databases. They worried that these might undermine the public's trust in credit cards as a secure payment system for the internet. They knew the sellers would only protect these databases up to the level of the threat to the seller, and not to the greater level of threat to the industry as a whole. So they banded together and produced a security standard called PCI. It's wholly industry-enforced by an industry that realized its reputation was more valuable than the sellers' databases.
A reputation-based economy means that infrastructure providers care more about security than their customers do. I realized this 10 years ago with my own company. We provided network-monitoring services to large corporations, and our internal network security was much more extensive than our customers'. Our customers secured their networks -- that's why they hired us, after all -- but only up to the value of their networks. If we mishandled any of our customers' data, we would have lost the trust of all of our customers.
I heard the same story at an ENISA conference in London last June, when an IT consultant explained that he had begun encrypting his laptop years before his customers did. While his customers might decide that the risk of losing their data wasn't worth the hassle of dealing with encryption, he knew that if he lost data from one customer, he risked losing all of his customers.
As IT becomes more like infrastructure, more like a commodity, expect service providers to improve security to levels greater than their customers would have done themselves.
In IT, customers learn about company reputation from many sources: magazine articles, analyst reviews, recommendations from colleagues, awards, certifications, and so on. Of course, this only works if customers have accurate information. In a reputation economy, companies have a motivation to hide their security problems.
You've all experienced a reputation economy: restaurants. Some restaurants have a good reputation, and are filled with regulars. When restaurants get a bad reputation, people stop coming and they close. Tourist restaurants -- whose main attraction is their location, and whose customers frequently don't know anything about their reputation -- can thrive even if they aren't any good. And sometimes a restaurant can keep its reputation -- an award in a magazine, a special occasion restaurant that "everyone knows" is the place to go -- long after its food and service have declined.
The reputation economy is far from perfect.
This essay originally appeared in The Guardian.
Posted on November 12, 2009 at 6:30 AM
• 31 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
I've just started converting all my web servers to use https by default. I've started searching out active https alternates for the web sites I regularly visit (BTW https://www.schneier.com/blog/ works, but the comments form defaults to http.)
Https services are worryingly rare concidering the overheads are negligible for low activity servers and hardware enhanced encryption is available when you buy appropriate servers for busy sites.
Not even Google provides complete https coverage :-(
I've long advocated that we adopt IPSec (despite its complexities) at work, so far without success. One gets so tired of explaining again and again why using telnet on a network connected to the internet is NOT a good idea...
@Nomen "worryingly rare concidering the overheads are negligible "
"Performance hit" is the FIRST argument I hear from developers when the encryption issue comes. They don't even bother to qualify it. It seems to me they consider it a silver bullet for dealing with security issues.
Even high activity sites don't have to deal with a performance hit if the design takes it into account. One client had an F5 in place for load balancing. They didn't even realize it could also offload all the encryption from the webservers. Why didn't the Network and Application architects discuss it? Beats me until the OMB TLS mandate I don't think they even sat in the same room at the same time.
@BF: Offloading encryption on the F5 leaves you vulnerable on the internal network where you'd have to be very careful of logging and what gets recorded in the Web Server logs.
I have honestly come to the conclusion that for those sites that are that active where performance is an issue, accelarators should just be a cost of doing business, and those that aren't can do just fine with HTTPS on the Web Servers.
Encryption is not the silver bullet, neither are AVs. But they both protect you more than doing nothing and really don't hinder performance to the point where it is significant for MOST people.
Firefox isn't helping the spread of https services. Their treating of https as less secure than http unless someone has ponied up to buy a certificate they sanctioned is discouraging people from running https, particularly on non-commercial sites.
@"Not Really Anonymous": Your comment re: Firefox is pure ignorance. Encryption without trust is worthless. If an entity isn't willing to invest a small amount of money into an SSL cert for a service being offered to the public, what else are they skimping on?
For an internal or experimental application -- just load the public key into your certificate store and Firefox won't nag you anymore...
I hope StudiVZ/MeinVZ read that post....
"Encryption without trust is worthless" is incorrect. Specifically, it significantly raises the bar for mass collection of data.
Also it certainly isn't worse than not using encryption, which was my initial claim.
I think this attitude is a contemporary problem -- that you can trust reputation without a decent knowledge of what the underpinning are that you're trusting.
Folks I've known of the just past generation -- Americans who were pre-WWII, would now be approaching their centennial -- generally KNEW how things worked. They were interested in the electrical grids, the water supply, the chain of food from the farmer to their table.
I'm not just talking about engineers, but housewives; regular folks. You can't depend on reputation if you're ignorant of what that reputation MEANS.
Remember the AOL model for problems on their network and/or systems: if you can't find a way to tell them about the problem, then it doesn't exist. This is reputation (or public image) model, being in denial, while touting success with meeting the street, number of customers, and all good things you are doing.
reguarding the PCI issues. i never understood the complete unwillingness to simply delete the customers credit card information after the transacation is complete. i once worked at a place that had 14 years of credit card history unencrypted in a database accessible internally to the whole company.
me: Why do you still have all of this
some manager: just in case
me: in case what?
some manager: i don't know
me: who knows?
some manager: no one.
some places keep it for convienance so when the customer goes back to the site to order something else they dont have to re-type in their credit cards. i think thats just stupid. i would much rather be forced to type in my card number every single time and be reassured that my numbers are no in their database, but then again i'm not the average online buyer.
Encryption without trust IS worse than useless.
If the user has been trained to trust anything with the little padlock.
It must be perfectly safe to enter my credit card into this popup because it has https.
It's like installing AV and then telling your users it's perfectly safe to run any attachments/downloads without thinking.
I am talking about encryption, not padlock icons. I agree that there are down sides to changing the expectation of what padlocks mean. The firefox developers could not show a padlock for pages retrieved by https when the top signer is not one of their favored organizations.
The whole padlock thing is really a placebo for most of the people. The main threat to their credit card data isn't it being snooped nor is it dns spoofing misdirecting them to another site.
On the PCI question, one reason you want to keep credit card data associated with recent transactions is that if you need to give a refund, it is a lot easier if you still have that data available.
Nice timely article, especially after an earlier Schneier article mentioned the power of consumerism.
Might I add an obvious point, dark pools, gaming of insiders, and pump and dump warfare, to security in a reputation economy. Modern finance history is scary.
On the https issue, computer security is so bad, that https is almost a liability, any extra accountability that can be gamed is legally dangerous.
Perhaps trusted computing will redeem us all. :)
@AppSec "leaves you vulnerable"
True. If the site and system don't plan for it. In the case I have in mind there was a standard 3 tier firewall separation internally between app layers and between the server footprint and larger corporate network. they resolved the question of "how much do I trust my corporate network by saying "we don't."
Given that configuration (and we really need to ask Bruce to build a white board app into his blog) I don't see an unacceptable risk. The F5 hands off to the switch to the server barely more than 1 hop and limited chance of interception.
The silver bullet is not a product, or particular OS, but clear requirements built into system design and expressed in system configuration and operations. Since PM's have a hard time with security work packages and duration estimates they usually, in schedules I've seen, put down "security plan, resource tech writer, duration 5 days". That's the extent of their planning. "security testing, resource ISSO, duration 3 days" that included analysis, report writing and fix recommendations.
"On the PCI question, one reason you want to keep credit card data associated with recent transactions is that if you need to give a refund, it is a lot easier if you still have that data available."
No. There's too much danger when keeping that data.
Even if you store a salted hash of the card number, it's getting easier and easier to crack them with off-the-shelf video card GPU's.
I knew where you were going with it, I just don't think you want log files containing personal data sitting around and getting backed up because some application got bum rushed through the process.
And even with HTTPS all the way to the Web Server, I'd still segregate it off from the corporate network :)
@Not really anonymous: "On the PCI question, one reason you want to keep credit card data associated with recent transactions is that if you need to give a refund, it is a lot easier if you still have that data available."
Problem is, easier to do something means easier to do something inappropriate. If you make this information available so refunds can be processed, it is also available so fraudulent charges can be processed (or also fraudulent refunds, like if someone's roommate buys a huge TV for the apartment).
There are ways to process refunds that don't involve exposing everyone's credit card numbers "just in case" they want one.
The only time I'd recommend storing a credit card number would be for frequently returning customers in an online environment, for their convenience, as well as the limit the exposure through entry or transmission over the internet path. And even then, that's a decision regarding which risk to take.
"On the PCI question, one reason you want to keep credit card data associated with recent transactions is that if you need to give a refund, it is a lot easier if you still have that data available."
i dont really think thats a good reason. when the return is accepted the company could just say:
Sir i see you paid with a credit card, for your protection we do not keep your card information on file. could you please enter your card information into our return center's secure website / over the phone or whatever so we can process you return.
maybe some customers would see this a an inconvienance especially since they may already be mad about having to make the return. but it makes both the customer and the business safer. and by make the business safe i mean there is now no chance of a news article saying they just lost 10 million customers credit information.
@king: "there is now no chance of a news article saying they just lost 10 million customers credit information."
In other words, it makes little sense to take a huge reputation risk to avoid risking a minor inconvenience.
"The only time I'd recommend storing a credit card number would be for frequently returning customers in an online environment, for their convenience, as well as the limit the exposure through entry or transmission over the internet path. And even then, that's a decision regarding which risk to take. "
i would be ok with the as long as its the customers decision (they have to click a store my cc number checkbox or something) and the default is not to store the data. but you also can't use this to pass the responsibity on to the customer; if you have such a feature then the business still need to be responsible to taking approperate security mesaure to protect the info. and not just from the outside either but also internally. I'm not in marketing but i find it hard to belive the the increase in sales expierenced by storing the customers cc number for their convienance is more then the cost to properly safeguard their infomation and be in compliance with all PCI standards
@king: " would be ok with the as long as its the customers decision (they have to click a store my cc number checkbox or something) and the default is not to store the data. but you also can't use this to pass the responsibity on to the customer; if you have such a feature then the business still need to be responsible to taking approperate security mesaure to protect the info. and not just from the outside either but also internally. I'm not in marketing but i find it hard to belive the the increase in sales expierenced by storing the customers cc number for their convienance is more then the cost to properly safeguard their infomation and be in compliance with all PCI standards"
I agree, it should be the customers choice, and the default should be they do not.
One example for me is some of my bills that pay automatically. It's convenient, and I don't have checks or my credit card information passing through the mail or the internet.
A risk with companies that retain the information is there become so many of them that it becomes very difficult to determine where information was compromised at if fraud occurs.
Another reason to store a CC number (albeit hashed) long-term is to associate a sale with an already-known customer for CRM purposes when all you know about the sale is the tender used.
Keeping credit card numbers to facilitate returning money is something people want to do whether or not the risks out weigh the benefits. I am aware of one institution that keeps credit card numbers for a limited period of time for exactly that reason. There are certainly concerns about the risks of doing that, but in the end it was decided to keep the card numbers for a period of time.
"In other words, it makes little sense to take a huge reputation risk to avoid risking a minor inconvenience."
And with whom?
What has not been noted here is that an organisations reputation is not just multifacited it has multiple types of people it has to deal with as part of the supply chain.
As has been said by others regarding high end hotels they focus on their customers so convenience to the customer trumps security.
Then there are large retail chains that have lost millions of CC numbers, did it realy effect their reputation with 90% of their customers no. Those that both knew about it and thought about it may have shoped else where or paid cash for a while, but within a relativly short time their old habits due to "conveniance" would bring them back to their old ways.
You could say that 99% of managment choices are short term, because that is how there renumeration is decided. Even senior execs making "direction" choices rarely think further than the next years figures because that is how the shareholders think.
The risk of lost CC info does not realy figure in managment thinking "cost reduction", "efficiency improvment", "quaterly figures" are what they are judged by...
Security of abstract information is of no real interest to them because it is something that cannot be quantified to them...
Oh and banks recent "bonus" behaviour is a clasic example of short term thinking over reputation.
To be blunt reputation does not figure highly on most managment radar self interest and short termisum does.
The exception to this is organisations where it is in the senior execs interest to think longterm because they have a significant stake in the organisation personaly.
Which might account for why one or two politicos are calling for a mandatory change in the "bonus culture" world wide.
And sadly it won't happen due to political short term outlook caused by "self interest".
The delay in the effects of lost reputation are generaly longer than the short term outlook so people will "game" the system and jump ship before it hits home. Or when in a monopoly position just tweak the political nose and wait it out.
Just where's the borderline between content "offered to the public" and "experimental or internal" one? Is a private homepage one or another? And no, I am not going to spend $100+ a year for a "blessed" cert when my VPS hosting costs less than half that much.
Of course if one's going to make some money (or publicity or boast value or whatever) off a website, a large-company-signed cert is the way to go. A private homepage in some dark corner of the Web doesn't really need any, it's the browsers who insist on having some. Anonymous encryption without BigRootCA-trusted cert is worthwile - for not sending your "AuthType basic" tokens and some session cookies in the clear. Virtually nobody is going to mount a DNS spoofing attack against your petty site. Firefox's behaviour is just a nuisance for it's users.
And talking about trust - the cheapest certs offered (not much cheap, actually) have very little trust embedded in them. All they prove is that whoever has installed the cert at the site www.whatever.com can receive email at email@example.com. The name and address on the cert can be whatever you like. Companies that actually make an attempt at establishing substantial trust sell their certs for hundreds if not thousands of dollars per year.
@ Peter A.,
"Companies that actually make an attempt at establishing substantial trust sell their certs for hundreds if not thousands of dollars per year."
That's news to me and quite a few others I suspect.
The last time I looked the main certificate signing organisations did not establish or attempt to establish "substantial trust". In point of fact their T&C paperwork disclaimed any and all responsability with regards to the certificates they issued other than they had issued them (and even that was doubtfull on some T&C's).
I suspect that the only checking of "substantial trust" was that the payment cleared.
The last time I purchased one (which was a while ago) the procedure was,
1, Email CA with your details etc.
2, They then faxed back a form you had to fill in.
3, You returned the form plus photocopies of various documents and a headed letter and payment by post.
4, They sent you the certificate by EMail.
As far as I can tell the only law to stop dishonisty on the purchaser side was US "postal fraud" legislation (that does not apply out of juresdiction).
It might have changed a bit in the intervening years but like you I see absolutly no value in a "paid for" signed certificate.
In fact as far as I could tell back then the only advantage in a signed cert from most CA's is to advertise the CA's logo and earn them more money...
As was once said about "verbal contracts",
"It ain't worth the paper it's written on".
The up todate version for CA Cert's would be,
"It ain't worth the electrons it's EMailed with"
If anybody knows a CA that actually does make proper checks and does take legal and financial responsability without asking for the keys to a Swiss Gold Repository then I would be interested in looking at their T&C's.
I have never bothered to read the lengthy T&Cs of the Big Ones let alone try to check if their attempts at validating names&addresses make any sense - I am not wiling to spend THAT much just in the name of science... So you may have a pretty valid point here.
There is not as far as I could find.
I liked Bruce's suggestion. Trust the cert up to the amount of liability that the cert issuer is prepared to be liable for.
Since in all cases i have check that is zero... then well I see the padlock as better than nothing.. but not much better. While i buy a 100EU of books or something i don't sweat it.
But transfer of say the daily transactions between banks... I hope they do something decent with certs.
If my memory still works, Bruce said (in "Secrets and Lies") that a certificate authority will protect you against anybody whose money they won't take. There's a certain conflict of interest here, particularly since the only reputation at stake is with browser distributors.
BTW, my standard security measure against credit card fraud is to scan the bill when it comes, verifying that the transactions are likely mine. I wouldn't notice if somebody got a tank of gas at a gas station I frequently go to, or bought a few books from the local B&N, but I'd catch anything significant. Under current US law and credit card practice, could somebody tell me what my risk exposure is?
@Clive: "To be blunt reputation does not figure highly on most managment radar self interest and short termisum does."
I agree with that (and most your post, btw).
Most entities never think they will end up in the news for a million credit card breaches, so they accept that risk to avoid inconvenience.
BF Skinner writes: "Even high activity sites don't have to deal with a performance hit if the design takes it into account. "
The https performance hit that most devs care about is the increased latency and lack of caching for the client. The server side performance hit is usually not the concern.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.