Schneier on Security

Pat Cahalan • September 9, 2005 3:15 PM

The definition of “hacker” (and of “hacking”) is somewhat nebulous. If you just read “The New Hacker’s Dictionary”, you’d think that hackers are all brilliant engineers with odd work hours and perhaps strange personal habits. If you just watch network news, you might think that all hackers are people trying to break into things just because they can.

More people watch network news than read “The New Hacker’s Dictionary”.

You may bestow the title of “hacker” upon yourself because you like the idea of being a brilliant engineer, but the reality is that some large section of society is going to think you’re someone who is trying to steal their bank password. It doesn’t mean that they are correct, but when rap artists aspire for the label “gansta” they can’t really complain when whitebread american calls them “thugs”, either 🙂

Linguistics isn’t an individual science -> if a large body of people suddenly decides that “tubular” means “really cool”, then that’s what “tubular” means to them. If you’ve been calling yourself “anti-tubular” because you’ve decided it means “really smart”, uh, they’re going to make fun of you. Sorry, there’s not much you can do about that, except complain, I suppose.

Pat Cahalan • September 10, 2005 12:55 AM

@ Marcus

I was actually referring to your “cockroaches at dinner” editorial in my last post.

To answer your question, “What do you think of HIPAA, SARBOX, GLBA, FISMA, et al? Do you think they have helped security, or merely transferred billions of dollars to consultants, lawyers, and beltway bandits?”, I think your implied conclusion is right -> they’ve transferred billions of dollars to consultants, lawyers, and beltway bandits, and they’ve done very little to improve anything in a practical sense, except make CTOs and CIOs paranoid about the future (which could be a good thing, I suppose).

I agree with you that in the short run, software litigation will be largely a nightmare, and will largely increase costs significantly on software (costs that will be passed on to the consumer, of course).

However, taking your own point that “the industry is still in its infancy” into account, remember the state of the U.S. meat packing industry when Upton Sinclair wrote The Jungle? Oversight of any new industry (either by government through regulation or by the self-interested trial lawyers through liability litigation) is always a nightmare in the beginning. In a very real sense, the beginning of regulation almost always produces no net benefit, as everyone is scrambling to circumvent as many of the liabilities and regulations as they can to give themselves a strategic advantage over their competitors, and the regulatory agencies are unable to perform oversight.

I worked in a meat packing plant for a summer in college, though (Farmer John, for the record), and with a company-employed health inspector and not one but two on-site state health inspectors I can say honestly you could eat off the floor in most parts of the plant and you’d be perfectly safe. The horror stories of “Fast Food Nation” aside, I suspect most meat packing plants here in the U.S. are closer to the one I worked in than the ones in “The Jungle”.

That simply would not have come about without regulation of some sort. Companies, for the most part, act in their own self-interest, which in their case is the profit margin. If externalized costs aren’t transferred back to the corporate entity, it’s not going to bear those costs voluntarily… or if it is (because it’s run by an ethical board of directors), it will be unable to compete in a market where the competitors aren’t bearing those same costs, and can undercut prices.

I’m not an anti-corporate person by any means, and I do think that by and large corporations are run fairly ethically (maybe I’m deluding myself on this point). However, it only takes a few bad apples to ruin the balance of power for everybody, and an unregulated or unliable industry is going to attract the bad apples… and the software industry is both.

Take the power generating industry. Cut out regulation, and you get Enron’s price gouging in California (never mind the corporate malfeasance). Take the telecommunications industry. Cut out regulation, break up AT&T into the Baby Bells, and you get market competition driving down prices… but you also get Montana Power selling off assets to try and get into the unregulated data communications business and WorldCom and Global Crossing cooking their books. Is the gain that we as consumers saw in the drop in prices worth the hits we’ve taken to our 401ks and pensions? Maybe for me, I’m in my early thirties, but I doubt someone near retirement is overly thrilled.

Sure, the software industry is different from telecommunications and power generation and most other industries, for that matter – especially in the current infancy state of the industry. Even in the long run, you may very well be right -> imposing liability will have a net negative effect. I certainly agree that in the short run the effects will make me cringe.

However, the fact that you can use Office 95 or I can use Open Office (or vi or emacs or some other freeware, for that matter) doesn’t affect Microsoft in the pocketbook. Quite frankly, they don’t care if we’re educated customers, as long as the majority of the population is still willing to take their Mc Donald’s version of software. Even Fortune 500 companies that are careful customers probably aren’t going to stop buying Microsoft products (although they may demand lower prices) -> they’ve already dealt with the issue of the bad security by hiring people like us to work around it and make their systems recoverable. We may be telling them until we’re blue in the face how bad things are, but we all have anecdotes of having someone go over our collective heads to demand something insecure.

At least, until some worm virus comes around that does significant real damage -> and I’m not talking “the US economy lost billions due to Melissa or Sobig” or whathaveyou, that’s largely a magic number -> things were down for a while, revenue wasn’t being generated, but nothing was really lost. There’s a difference between “we weren’t getting revenue for a while” and “all of our data is gone and our on-site backups are encrypted with keys we don’t have” or “all of our hardware just ate itself” or “all of the main routers on the internet just burned themselves out”. Then you’re not just losing revenue, you’ve lost critical infrastructure and you can’t get it back in days or even necessarily weeks (or ever).

At that point, we’re all going to be affected, even the uber geeks who’ve been writing their own bug free web servers and mail servers for personal domains, because our banks will be down, or our credit cards won’t work, or some other consequence.

In short, regulation and/or liability laws are the only things I can see solving the problem of externality. Me or you withholding our pittance from Microsoft and Intel doesn’t do much.

PS -> regarding your last post, which you apparently wrote while I was penning the Oxford English Dictionary here…

If I was running a company with an IT budget in the hundreds of millions or billions of dollars (and I know they’re out there), I’d get the highest up guy I could get at Intel and Microsoft and Sun and AMD together in one room and say, “Look, either you monkies give me a corporate workstation hardware/software platform that will (a) last 10 years and (b) that has a secure OS with a web browser, an email client, a spreadsheet program, a word processor, and an HTML authoring tool for presentations, or I’m taking my damn money and I’m starting my own damn corporate desktop company, even if it only serves me as a customer. You’ve got 8 months to give me a working proposal to keep my business”. Sure, the hit my stock would take on Wall Street may get me kicked off the board before I could follow through, but on this I agree with you wholeheartedly -> we pay for computing power that’s hundreds of times in excess of what we need, to run applications that are hundreds of times more complex for our requirements. But the point is moot, as I don’t control a pocketbook that large.

Unless you know somebody that’s looking to hire 😉

Pat Cahalan • September 10, 2005 11:46 AM

@ Victor

As soon as user understand that computers can do work by theirselves,
he began to write macros, scripts etc.

In my experience, this is not true. Generally speaking, I find that a very large majority of users (well over the 90% range) don’t code, and most of them have no desire to learn how.

Most people look at a computer as an appliance, not a platform for building tools. Of course, that’s looking at the current snapshot of computer usage in this moment in time -> it certainly was the case that 30 years ago people with computers were all coders, and it is probably true that sometime in the future the pendulum will swing the other way and a larger percentage of people will become coders.

I’m not afraid of computers, but I certainly don’t trust them. I really don’t trust networked computers – even my home machine that I’m writing this on doesn’t contain any sensitive information (not because I don’t think I could make it secure, just because I don’t want to expend the energy to make it secure “enough” for me to entrust it with my bank statements).

I have worked with enough users to know that only a percentage of them are “trustworthy”, regardless of their technical savviness. A non-trivial part of systems administration is cleaning up after people who knew just enough to get themselves in trouble 🙂

I’d say that if you were plotting trustworthiness as a Y axis and knowledge as an X axis, you’d have a curve that has two relative maximums for trustworthiness. Complete neophytes aren’t very trustworthy, as they’ll fall prey to social engineering attacks that moderately savvy people will know to avoid. Moderately skilled people are somewhat trustworthy, as they know what they want the machine to do, but they’ve seen enough bad things happen to “stick to what they know” -> they don’t explore the boundries of the machine, so they don’t often break things, but they know enough to not fall prey to simple social engineering attacks. Intermediate users (beginning coders) are generally less trustworthy than moderately skilled users, because they fall into the class of having enough knowledge to know how to break things, or they have enough knowledge to leverage things in a very insecure way. It’s only really advanced users who become trustworthy, because not only do they know enough to program with security in mind, but they usually don’t trust themselves when they start a project, so they take steps to make sure that if they do something wrong, it won’t cause catastropic failure 🙂

Poke around on this website and you’ll find one common statement to quite a few of Bruce’s posts is that security is hard, and even people who just do security for a living often don’t do it correctly on the first N attempts. If you’re trying to build a non-trivially secure system, you must implement things to make the system harder to abuse (which has the unfortunate side affect of also making them harder to use) -> I’ll agree 110% with Marcus that a “default permit” policy is utter folly.

Pat Cahalan • September 11, 2005 4:50 PM

@ Richard

One factor in the economic analysis is that regulations create a barrier to entry.

This isn’t necessarily always true, but is certainly a danger to protect against in many ways. You don’t want regulation (or liability) to halt innovation. Slowing it down in the name of quality is probably not a bad idea, though.

Sometimes that seems to be their primary purpose… beware of “self-regulating” industries!

Even governmentally-regulated industries have to be watch-dogged for this. It’s very true that companies can and do contribute to politicians to amend regulations in a way that benefits a single corporate entity, and this has happened in the past and will continue to happen, as long as we don’t hold our politicians accountable. It doesn’t mean that regulation isn’t the best tool we have for “de-externalizing” costs, it just means we need to keep our eye on the tool. In some instances it might be a better idea not to have formal regulations, but I stand by my earlier statement -> an unregulated and unliable industry is a bad thing. You’ve got to have some method of making external costs internal.

The software industry is famous for its low barriers to entry. Don’t destroy that lightly.

Not to disparage designers and coders as a group, but I’ve seen so much crappy software that a higher barrier to entry seems like a good idea to me -> I can’t count the amount of man hours I’ve seen wasted trying to uninstall/fix bits of freeware or shareware (or commercial software) installed by the unwary that broke a working computer, not to mention trying to secure garbage.

True, some major responsibility for this rests on the user who installed the software (and the sysadmin who gave them the rights to do so), and I’m not trying to pass the buck entirely to the coders of the bad software. I also realize, as Marcus pointed out, that non-coders (marketing guys or executives or customers) can demand changes in a product that cause these problems, too. I’m not entirely blaming the people that write the code.

But wherever the ultimate responsibility lies, it’s blindingly obvious that a large majority of software out there is seriously lacking in overall quality, of which security is only a part. Enforcing a minimal amount of quality seems to be a good idea to me.

Aside from all this is of course the problem of establishing a framework for regulation, which is admittedly a giant nightmare in itself. Bruce has posted quite a few notes on things like the “Trusted Computing Platform” here himself… I admit I don’t have an easy answer to this one.

Pat Cahalan • September 13, 2005 9:53 AM

@ I hope…

Why the hell not? What sense does it make to race ahead when practically the entire collection…

Because you don’t want a regulation to inspire “security for the sake of security”. If you agree with Bruce’s overall stance of “security is measuring trade-offs”, there are times when insecurity can be (relatively) a good thing.

If you’re writing a video game that is going to be played on a game console, having a buffer overflow that can be accessed by pushing all of the buttons on the controller 100 times in 3 seconds probably isn’t that big of a deal. Sure, someone can rig up a modified controller that will force input the junk into the machine and give you root on an Playstation4, but really, do we need to force game designers to write their code against that sort of an attack? It might be in the best interests of Sony to do so (and it might be good coding practice), but I don’t see how someone could leverage such a bug into a worm that is going to affect the general public, which is what a regulation is supposed to be for, right?

That’s precisely the sort of regulation that can be used to leverage a single corporation’s monopolistic position. Blizzard sends a letter to their congressman, “this upstart game company produces a game that has four buffer overflows in it”, and suddenly state inspectors are crawling over said upstart company.

Sure, it’s a silly example, but it illustrates the point (and analogy holds -> these sorts of things are done today). Simply passing a law that says “thou shalt not write buffer overflows” would be horrible regulation.

There are other reasons to be careful with your regulations. IMO, it’s perfectly fine to hold Big Tobacco liable for smoking related health problems (because we don’t want to pay for them with our tax dollars), but should we pass laws that make it illegal to smoke?

Pat Cahalan • September 22, 2005 10:05 AM

@ Jose

Any law generally shouldn’t apply to everyone in all cases.

Agreed. However, technical details are historically misunderstood by the non-technical. Remember the infamous FBI raid on Steve Jackson Games? Passing laws that regulate software writing can lead to bad interpretation of the law (note, I’m not saying it’s not a bad idea anyway, I was just agreeing with another poster that you need to be careful when you regulate things).

In case you haven’t noticed it yet, the example you gave is probably not
a good one because Playstation4 is likely to be a very network-ready beast.

Sure. Many game consoles are already network-ready. But the example is still a good one -> you can’t leverage a controller-input buffer overflow over the network. At least until they have networkable controllers. Did you not read the whole example?

I suppose that an application that runs on someone’s watch and can go no
further should not be regulated the
same way as if it ran on a watch
that was capable of participating in DDOS.

Right, that was my point. However, making distinctions in regulation isn’t easy. That’s all I was saying.

It’s like almost any law. We don’t care if you run naked around your farm…

And like almost any law, it can and probably will be misused occasionally. Your example of the naked guy isn’t accurate -> if he lives next door (or even in the same county) with someone who objects enough to his behavior and with a connection to the local legal enforcement community, he’s going to be harassed. Given his behavior, he probably deserves a little harassment, but you get my point.

When you pass a law you’re giving power to the legal enforcement community. You have to be aware of the trade-offs there. To assume that power will always be used the way you originally intended is naive.

Can the application use the network or not? — that could be a differentiating
criteria within a typical regulation, for example.

This is overly simplistic, and is an example of why regulation wouldn’t be easy -> You can have a local application that has a local overflow that enables someone to take over the machine remotely, if they can get remote access to the machine through other means.

As an example, they steal someone’s login, execute a local buffer overflow in some non-networkable application, gain control over the machine, and can now attack the network.

Any reasonably effective regulatory ruleset will be fairly complicated, and that much more difficult for a non-technical legal system to interpret.