Computer Security, The Next 50 Years

bariswheel writes "Alan Cox, fellow at Red Hat Linux, gives a short-and-sweet talk at the European OSCON on the The Next 50 Years of Computer Security. Implementations of modularity, Trusted Computing hardware, 'separation of secrets,' and overcoming the challenge of users not reading dialog boxes, will be crucial milestones as we head on to the future. He states: "As security improves, we need to keep building things which are usable, which are turned on by default, which means understanding users is the target for the next 50 years. You don't buy a car with optional bumpers. You can have a steering wheel fitted if you like, but it comes with a spike by default." All of this has to be shipped in a way that doesn't stop the user from doing things."

Maybe the author doesn't

You don't buy a car with optional bumpers.

Speak for yourself!

Haskell.

We will likely see software security improve once languages like Haskell and Erlang are more often used.

There are, of course, some security issues that are independent of the language used. Some are inherent to protocols, for instance. However, buffer overflows and so forth are a thing of the past when using a language with proper memory management.

Security glitches caused by basic concurrency errors are also avoided when using a language such as Haskell, that can automatically parallelize computations.

Re:Haskell.

More importantly, the security models currently used in the kernel are broken, and we can formally prove that they are inadequate. Academic research in this area has been extremely productive, but there are major barriers to entry in the commercial world for the obvious reasons.

At the moment it looks like micrkernel architectures (real ones, none of this hybrid stuff) coupled with capability based security systems, should be able to provide real, formally verifiable security. As with most things there are a handful of practical barriers to overcome (primarily performance related), but another 5-10 years and those problems should be sorted out.

For a more in-depth discussion of capability systems, see the wiki page [wikipedia.org], and this essay by Dr. Jonathan Shapiro [eros-os.org]. (And to be perfectly honest, he's a professor of mine and my views are colored as such.)

Educating users

What the article is basically saying is that we have to teach people how to use their computers. >85% of all the computer problems I encounter are PEBKAC (Problem Exists Between Keyboard And Chair). It's like the old saying goes, make something idiot proof and the world will make a better idiot. If people just learn how to use their computers (you shouldn't download exe's from people you don't know, a firewall is a good thing to have, ActiveX controls aren't safe and your default response shouldn't be to install them no matter what IE says) a huge number of problems would be eliminated. Like it or not, users are the biggest computer problem today. The problem shouldn't be usability, it should be user-ability.

Two generatrions of safety engineering

Aviation went through this phase a long time ago. Accidents were called "pilot error" unless the airplane broke up in midair.

The field of "human factors" recognized that controls and displays need to be designed so that it's possible for a well trained human to get things right even in a hurry. Controls with opposite effects should not be right next to each other. Controls should give meaningful feedback. Important controls should be out in the open where someone can see them.

The aviation world fixed up the cockpit and many "pilot errors" disappeared.

You can't apply these lessons too directly to computer security because bad guys are actively trying to trick computer users. Nobody sends pilots email in flight saying "You must pull the red lever immediately to avoid running out of fuel!". But at least it should be easy enough to secure a computer that an employee from a security firm can do it. We're not there yet -- a recent security conference had vendors running open WiFi access points without firewalls.

Re:Two generatrions of safety engineering

Only thing? No. Interfaces also make common mistakes easier to recover from

However, some mistakes cannot be recovered from - for example, if you click the "yes" button on the "would you like to install this malware" dialogue. In this case you might be able to use journalling features of the filesystem to undo the damage, but if you've done other things since then you probably couldn't selectively roll back the filesystem changes associated with the malware without rolling back everything else too.

In this case the UI has to be designed to make unrecoverable mistakes difficult or impossible to do in the first place so the "how do I recover?" problem (almost) never comes up. This is a very hard thing to do unless you want to turn computers into appliances (most people wouldn't like appliance computers since they wouldn't be able to install their favorite software) and becomes even harder when the people who want you to make mistakes (malware writers) are actively trying to trick you into making them.

One possibility that has been suggested is kind of a halfway-house between computers as we know them now and appliance computers - the OS would require all executable code to be signed by a "trusted party". However, this brings up some serious problems:
1. Who can be a "trusted party"? Lets say it's the OS vendor, why should I trust Microsoft to guarantee that the signed software is malware-free (especially since they are probably getting paid by the software vendor)? There will certainly need to be stiff penalties for signing software which turns out to be malware.
2. The inability to run unsigned software could be used to lock out the competition - for example, Microsoft could refuse to sign OpenOffice.
3. How much would this "signing service" cost - you can bet that thoroughly inspecting the software to ensure it really isn't malware is going to be very expensive so you just locked out all the small vendors who can't afford it.
4. How are you going to run code you compiled yourself since it won't be signed by the trusted party? This could either be FOSS code that you choose to compile yourself, or your own personal code.

These are certainly not easy problems. I do, however, feel that the ISPs need to take more action against people running malware infected machines. It seems all too common these days for ISPs to ignore abuse reports, let alone run monitoring software to proactively drop the connection to infected machines.
The ISPs should monitor people's connections for malware signatures and upon finding an infected host they should drop the entire internet connection until it's fixed (probably redirecting all web requests at a server containing patches and instructions to fix the problem).

Part of the problem is definately that most of the malware doesn't actually cause a problem for the owner of the infected machine - they don't know or care that their machine is actively being a spambot. Cause hassle for the owners of infected machines and they might actually pay attention to the security of their own systems (viruses were considered a much bigger deal back in the days when their payload often trashed your data).

Re:Two generatrions of safety engineering

The field of "human factors" recognized that controls and displays need to be designed so that it's possible for a well trained human to get things right even in a hurry.

And there's your problem right there.

a) Most computer users are not "well trained", even by the widest possible streching of the definition
b) For a pilot, flying the thing is his main concern at the time. He might be in a hurry, but he wants to do things, and do them right. For a computer user, security is a nuissance, a distraction from his actual work. He doesn't care, or bother, and if you would pop up a dialog box saying "do you want the system to stop bothering you with security warnings and just allow anything no matter the risk?", I'd say 80% or so of the users would click "yes".

Re:Educating users

Well, I'd make the argument that the problem exists between the keyboard and chair of the software developer--not the user.

Comments like yours remind me of the automobile industry of the 1960s. The problem, they insisted, was not with the cars but with the people who drove them. There was no way to make cars safe and the only hope was better driver education. Of course, the reality is more that they didn't want to devote the time, effort, and money to making cars safer because they'd see no real benefit in regards to sales. And to a certain degree, they were right. It actually took the government to come in and mandate safety standards for cars.

To me, blaming the user is a typical programmer cop-out. "Well, if the user was as smart as me, they wouldn't have these problems." Yeah, I too have seen users do the stupidest things with my software. The difference is that I try to find out what they were thinking when they did this and then work to make sure that others aren't inspired to do the same thing.

Re:Educating users

"I can't tell you how many of my friends (really smart people) can't download a file, then find it later. They just click OK, they don't know what a file extension is."

Exactly. How many tech support stories have we all heard that started with customers who claim to be very smart and know all about this stuff and have made some stupid mistake. Heck, I can plead guilty to that (Oops! The Firewall is blocking FTP--that's why I can't get to your FTP site...).

But some of it comes from the fact that there are things that we don't need to know, but the computer insists that we do know. File extensions are a great example. What does the extension "jpg" tell me? That it is an image encoded in JPEG. What is JPEG? Why do I care what it's encoded in? Why is that different from an image with the extension "tif"? They both look like the same image to me. Why do I need to know whether it's JPEG encoded or TIFF encoded? Why can't it just be a picture?

Well, because some programmer decided it would be easier to detect what kind of file something was if we gave the computer a hint. Thus, if the file extension is "jpg", the program uses a JPEG algorithm to extract the image. If the file extension is "tif", the program uses a TIFF algorithm. This is alot easier for the programmer and faster for the computer rather than reading, say, the first four bytes and looking for FFD8FFE0 and saying, "Ah! It's JPEG," or looking for "II" or "MM" in the first two bytes and saying, "Ah! It's TIFF!" So the file extensions "jpg" or "tif" really aren't there for the user's benefit at all--they're there to make the programmer's life easier.

But what about all these other three letter extensions, like "gif", "pgm", "psd", "bmp"? How is the user supposed to remember this alphabet soup of extensions and what they all mean? Why can't they just hide them? Because then the user won't see the "exe" that denotes a program and may inadvertently run a program which does nasty things.

See? File extensions seem basic to us, but they're pretty superfluous to most people.

Let's educate some UI designers, too

I'm with you here. My sibling post (correct term?) and you make nice points about lazy programmers, so I'm going to go and bash some bad designers, too.

I've found that Windows and its applications are really, really stupid with the way they handle dialog boxes. Kind of off-topic, I know, but since most security issues are luser error, I can guess that most of those are caused by blind click-click-clicking Yes to dialog boxes.

I get a dialog box when I try to delete a file. I get several dialog boxes whenever a program crashes - something about an error report. At my school, they've managed to set up Word so you get three dialog boxes when you open it: one asking you to disable macros (to which the average user goes What?), another telling you that macros have been disabled (yes, that's why I clicked that button) and another telling you that there's a window open.

With so many dialog boxes around, most of them unnecessary, I don't blame the average user for ignoring the important ones. If you press Yes, the nasty evil dialog box will go away. Sooner or later the times comes when you install some spyware trying to get rid of the dialog box.

And what has Vista done? Put even more of them in. Quoth even Paul Thurrott [winsupersite.com]: The problem with UAP is that it throws up an unbelievable number of warning dialogs for even the simplest of tasks. That these dialogs pop up repeatedly for the same action would be comical if it weren't so amazingly frustrating. It would be hilarious if it weren't going to affect hundreds of millions of people in a few short months. It is, in fact, almost criminal in its insidiousness. Gah, showering the user with more dialog boxes is useless, as they ignore them all anyway!

I'm on a roll here. What else?

When I want to Save a document, I go to the button marked Save. At least, I do on Gnome and OS X: Windows likes to have buttons called "Yes", "No" and "Cancel" instead. So instead of doing what I want (Saving), I have to read the dialog to find out which button Saves my document. And most people wouldn't even try to read it; they'd just click Yes and hope it was the right one. Oh, and the dialog text is often in a small font with no discernable main point about what it does.

Windows dialog boxes are obtrusive enough that people would rather make them go away (think: click Yes) than working out what they do. Here's [xvsxp.com] an example of a Mac one - I can tell what each button does before reading, and even if I have to read, there's some nice bold text so I don't have to read it all. Here's [xvsxp.com] the worst example of a Windows one I could find. Note none of the above things that the Mac does right. This isn't the best example, I know, but it points out where Windows fails best.

I reckon you could've eliminated a fair few spyware installs if the "Yes" button was labelled "Install Software", or the "Next" button was lebelled "Accept this Licence", or whatever it is. No more "Let's click Yes to make the nasty evil dialog box go away", but some people will think "Do I really want to install this software?" or "Do I really want to run this program?". It makes people think, and thinking is good when you're trying to make decisions.

Oh, and:

"How dare you try to type at another window when I am here, infidel scum!"

"And Vista dyes the rest of the screen black, just in case you didn't notice me the first time. See? [winsupersite.com]"

Where was I? Oh yes, computer security. I don't think it's fair to blame any and all spyware installations on user error. Windows places you on a path above a crevasse with a bicycle, and expects you to pedal to the other side. Sure, you might get blown off by wind (read: security holes in the OS). Many people

Oh, but we know...

Oh, but we know that Microsoft will be on top of the game. For sure. Absolutely. Windows 2050 will be THE safest, THE most secure version of Windows yet.

Re:Oh, but we know...

Oh, but we know that Microsoft will be on top of the game. For sure. Absolutely. Windows 2050 will be THE safest, THE most secure version of Windows yet.

I was really surprised to see someone arguing that Windows does kernel security really well [informit.com], and that the problem is that people don't want a detailed permissions control system so at all levels they enable everything. But they've provided a good security architecture as far as thread control goes -- it's just that coders down the line are ignoring it.

Of course, how many of those 'down-the-line coders' are at Microsoft itself?

The Eternal Weakness

Lusers - always the biggest security hole! Social engineering is the first fallback option.

Interesting points

and overcoming the challenge of users not reading dialog boxes,

That's true. So true. Tons of times I just clicked yes without reading or reading fully and then later on down the road...oops.

I updated outlook express for my mom the one time and it autmatically blocked attachments, confusing her. And me, until I found where to uncheck that.

The computer can be taught to enforce security policies that the users themselves are unlikely to uphold, given their propensity to ignore advisories and software dialog boxes. Software engineers must build in security that is active by default, and they must understand the user so that security tools are actually used.

But also keep in mind who the user will be. Some advanced users would probaly not need/want the security by default. New users or non-advanced ones would need it. We would need to find security to be adaptable.

In a comical way maybe the system can say "well you hosed /etc once, do you wanna do it again?"

Language Advancements

This article seems to focus more on security by design, which is of course important. However security also can be implemented at the language level, for example Java's sandbox. I predict that over the next 50 years languages will improve to prevent programmer from making "stupid" mistakes such as copying user input directly into a buffer that will be become an html document. Tainting already solves some of these problems, but there is still work to be done. (for example to discourage programmers from creating empty "de-tainting" routines when they don't have time to do it properly, de-tainting should really be done by libraries and by the language alone, but I digress)

What's the point of this?

Am I alone in finding this kind of topic - "The state of X in the year 2050" - really, incredibly pointless?

Given that no-one has been able to make accurate predictions about computer technology over a 5-year horizon, what possible basis is there for thinking that anyone can predict what the state of technology will be in 50 years time? By then we may be keeping our data secure by storing it in a hidden pocket of space-time in a parallel universe 10,000,000 years back in time and retrieving it through a wormhole when required. Or civilization may have collapsed, leaving us with the 'pointy rock tied to a stick' device as our best form of security.

My point is: no-one knows. It's pointless to predict this far into the future.

I would prefer people stick to making these kinds of predictions about large, relatively predictable fields (e.g.: the climate; oil supplies; population; tectonic plate movement) and leave their prognostications about ridiculous things like 'computer security' to something like a 2-10 year window.

Or we could, you know, read some *news* instead of some random predictions.

Another MS issue . . .

....and overcoming the challenge of users not reading dialog boxes....


I have to agree that this is a serious concern and as a tech, I often want to blame the stupid user since I deal with them frequently but on the other hand, can you really blame them? In any given day, an end user sees an unmeasurable amount of dialog boxes and our minds are designed to filter out things that are annoying. Instead of "Hey your email wasnt sent" you get 3 dialog boxes first that have no meaning. Of course, there is the next-next-finish epidemic as well. Does anyone really ready any options anymore? We all just go for the next button until it turns into a finish button. There are 2 huge problems with this. The first is that mixed in with all these stupid notices, there are important messages that go unnoticed. The second issue is that this is something that spyware companies thrive on for legalities.... in the middle of those next-next-finish games is the little line that signs your computer over to the dark side.

Computer Security ,The Next 50 Years

"In the long run we'll all be dead."

J.M.Keynes [wikipedia.org]

The next 50 years, 50 years ago

The future is not what is used to be. All the "the next 50 years" of 50 years ago predictions (on almost everything) were something wrong, something right, but if you read that you dont feel like being there (oh, we have some sort flying cars in a way or another, or civilians in space, to put 2 examples, but is not like for everyone, or everyday).

Wonder how many of those will become obsolete in 10 years only, not because the problem stopped to exist, just because terms of the problem changed giving little meaning for that to normal people. Today computing security is a tangible problem, even normal users have to worry about virus, trojans, worms, spyware, not having trivial keys, etc, but how much of that problems could remain for users in 20-50 years from here, or how they will be perceived?

We can be here discussing war strategy with sticks and stones while in 50 years (to be a bit exaggerated :) they use rayguns, but some of the things discussed now could remain valid then, some could work if some fallback must be done to something similar to stick and stones, and other things could had no meaning anymore.

Security stands and falls with responsibility

As a responsible parent, you don't give your kids alcohol. As a responsible driver, you don't drive 100mph near a school. And there are actually laws that, if you happen to be careless and negligant, you get fined or worse.

Only when it comes to computers and the 'net, you can be as irresponsible as you want and you won't get any negative feedback from the feds. You may click on every "please click here to become a spambot" message. You may install every kind of adware, while at the same time ignoring or even blocking updates for your system (and thus becoming the primary target for exploits like the recent WMF desaster). Nobody will hold you accountable for it. Even if you manage to fall for some cheap "please insert all your personal, bank and credit card info, and send us a copy of your passport" scam, more often than not your bank will cover for you.

Why is ignorance and irresponsibility an excuse when it comes to computers and the 'net? Because judges and legislators can't make sense outta it? At least, given some laws I'd get that impression.

Security starts with teaching the users, and most of all teaching them responsibility. Not better tech. You can have the best high secuirity door if you falls for the cheapest con job and let anyone in, you'll still have some things missing after every visit.

Effective configurability, please!

As we all probably have noticed, turning things on by default actually tends to make work more complicated for IT staff. Already now you have to do a number of little tweaks to have your computer run smoothly without all these annoying animated toys flying around.

Security is of course a different matter than these so called eye candy toys but I wish to have effective control over what is running in my computer and what isn't. For example there are performance-critical applications in which a workstation is running without a network connection. That's a far better protection against worms than any firewall, so I want to be able to switch all unnecessary software off from using the workstation's resources.

I just hope that the future developers will not forget about experienced users and support people while trying to meet the newbies' needs. Other than that, security's all good of course.

Dialog boxes

I always found the term "dialog" box to be an amusing misnomer. If they were really dialogs, I suspect the user would rarely have constructive things to say to their computer. On the other hand, monologue boxes would be far too dramatic, with the spotlight and all.

Are you joking?

50 years... The world has enough viable hydrocarbon energy left for only 5 or 10 more years [wikipedia.org]. It's amazing but true, the Internet was, indeed, just a passing fad... as were computers themselves, and electricity, and the horseless carriage, etc.

On a side note, here's something that tickled my brain the other day:

What I find fascinating is that in 150 years time, from as far back as Jules Verne, science fiction writers have explored almost every imaginable type of high technology, computer, robot, and space ship, as well as every concievable plot and story...

...except the one which has become our eventuality - a world who put every ounce of faith in its almighty petroleum god and woke up one morning to find it expended with a vital infrastructure which couldn't exist without it. Now THAT'S a plot!

Cars need licensed drivers, and rowdworthy certs

Remember - if you are going to extend the analogy:

1) You can't drive a car unless you have proven that you posess a minimum level of competency.
2) The car has to meet certain standards to be roadworthy
3) People by and large don't expect others to maintain their car for free
4) You have to pay the governmnet ragularly to be allowed to drive it on the road

I's either a bad analogy, or a very good one - you pick.

Shave and a haircut

Did anybody click on the article (yeah, yeah, I know) and actually look at that guy? I respect him, really I do - and the first thing I thought was, "Buddy, you really need to shave."

He's got to do something about the scrag before someone misidentifies him and his hoary mug ends up on Coast-to-Coast AM's web site. Or worse, someone mistakes him for Saint IGNUcious [stallman.org].

Security should be on by default

And it should also be easy to use.
Making security easy to use CAN be done.

Email encryption for example, when you install the mail client, it could generate a public/private keypair automatically and submit the public key to public key servers automatically.

Then when you send an email, it can automatically look up the public key of the person you are emailing and encrypt the email (unless you tell it not to).

When explaining it all to the user, dont call it "Encryption", just tell them that if they use this feature, it will mean that only the person you are sending the email to can read it and it cant be read by .

Facilities could be there so that businesses could configure it (via group policy) so that email encryption is active but keypairs are created by corporate mailservers and the mailserver (or the mail admin or whoever) has the keys and can look at the mail to look for whatever it is that email admins want to monitor email for. Or it could be disabled completly (or completly except for email going out of the company).

If email encryption was easy to use, everyone would start using it and the world would be a better place.

Ditto with other security features such as IM security (I would love to see a new feature in MSN messenger/AOL messenger/etc such that IMs were encrypted and only readable by the intended recipiant)

Computers do too much.

I think a less complex interface would do wonders for the PEBKAC angle of computer security. It seems to me that computers try to do much more than the average user wants or needs, which just creates more opportunities to screw up, and also makes the computer seem a lot more intimidating.

If we were to hide most of what the computer can do, then users could focus on what they really need it to do. As it is, non-technical folk just learn to tune stuff out, which isn't exactly good when we want them to pay attention to security (like just where that attachment came from, and whether that wonderful program they see is going to screw their computer). A normal user doesn't hope to comprehend everything that their computer is doing, so they don't think about the effects of their actions so hard. The computer is a wily and unpredictable beast. How will they know if it was something that they did that messed the computer up, or whether it did it on its own. Users need to be able to get comfortable with the machine before they'll really worry about it. User interfaces these days are just too much for anyone without an affinity for machines (like many of us here) to come to grips with. They just learn the tasks they need to do and hope the thing doesn't break.

Most users need to be able to use a word processor, a web browser, and maybe an IM client and music player. Why do computers give them lengthy lists of programs which can be run, windows that can obscure each other and take on funny proportions (I hate those things), zillions of little icons in the tray and even more on the desktop, and why do they sprinkle system settings in with all that? That's a lot of stuff to tune out.

If I were designing an interface for noobs, I'd get rid of all that stuff.

I'd have just one menu bar, which would contain at minimum the four essential applications that I mentioned. There would probably also be a couple of popup menus for less frequently used programs (less commonly used office apps, games). Programs would be sorted by function, and the guys writing installers would absolutely not get to create a new submenu for their company, to prevent the mess that any Start Menu will turn itself in to after a while.

Programs would always run full screen. I know there are plenty of slashdotters here who are very upset by that, but this interface wouldn't be aimed at you. You can do whatever you like with your giant monitors. On a screen only a thousand pixels across, overlapping resizable windows are just a complicated waste of time. Most any program will require all the screen real-estate to be useful, so it makes sense to just let them have it.

My four main apps would not only be launched by clicking their icons; the same icons would also give them focus. There's no reason do duplicate them (I realize that this means those four would have to be MDI apps. Tabs seem like a good solution.). When users want a web browsers they'll be able to always click in the same place. Additional apps launched from the menu would just hop into the bar next to them. (This sounds a little like OS X's dock, but I'm not too familiar with it, so I'm not sure how close it is.)

I might also put in a file manager. It wouldn't display system files, or even hint to the user that they exist. I think it would be search based, but it's way too late at night for me to put serious thought into it. A file manager might not be the best idea any way. If users can just start up their apps and let them handle the file types they know about, then the old "porn.jpg.exe" attack gets pretty much foiled.

That's about it, really. I think that would accomplish most everything that needs doing for most users. Naturally an admin mode of some kind would be required. I envision a simple one that would allow users to tweak the OS's look and install software from repositories (either online or from CD). Real admins could go yet further. Maybe just a CLI. It doesn't matter much. Anyone with the will and the know-how to muck around with the sys

I somewhat agree...

The problem with IT security, historically, has been a "Default Allow" approach. This is getting better, but still has a LOOOONG ways to go. Things should not be automatically allowed, they hsould have to be turned on.

Consider Windows 98/98SE. File sharing is off. And the OS itself was more or less a fairly secure (for it's time) OS on a DEFAULT install. Compare to Win2k/WinXP. Default admin shares open, often in upgrade cases we have Administrative accounts with NO password, which (with the exception of XP) could log on remotely. XP at least was intelligent enough in it's design so as not to allow remote logins with blank passwords for Administrative accounts (UNLESS ENABLED). THAT, my friends, is the correct approach to security. Default = NO!

Once this has been accomplished, and the general mindset of programmers when considering security (and Admins, etc.) is to assume the user knows NOTHING, and that things just should NOT be permitted without full warning of the consequences (this is where figuring out how to get users to read dialogue boxes comes in handy) security will be much tighter. And lets not forget about vendors and programmers just ignoring security glitches. It's sad to see a Buffer Overflow attack remain a vulnerability in a program beyond a single patch release, once identified. Even sadder, is when further program releases STILL have not addressed the issue (see, Medal of Honor Voting)). The 'solution' is disabling a bonafide FEATURE. This type of nonchalant approach to security will always land the general populaec in the grips of security vulnerabilities, with no clearn end in sight.

My thoughts.

Security in 50 years is an easy vision

More crap, more crapware, and fewer rights. WHERE DO I SIGN UP?!?!?! :D

The password

Give me one thing in the next 50 years and it'll be the death of the password. Security through obscurity at its finest.

1956 version of Computer Security in Next 50 Years

1) Topic: Securing your mainframes from insects and rodents.
2) Wasted CPU cycles and how you can prevent them.
3) Proper punch card disposal protocols.

The point? We have *no clue* what the computer will look fifty years from now, to say nothing of the security environment. Todays threats will be laughable in light of the technology and practices of tomorrow (many of the threats we spend a lot of time worrying about, such as spyware, are features not of all computing, not even of a particular application class, but that plague one particular implementation of an application which just happens to have a majority share of the market today -- who can say whether a security researcher in 2056 will even remember the words "Internet Explorer" from his history class or whether browsing any analogue to the Internet will be a common activity?). Prognosticating the threat environment that far out is a waste of time. Look to the near term (next 5 years: spam, viruses, malware) and address the perinneals (dumb users, men on the inside, etc) rather than trying to prognosticate what year we'll have the computer equivalent of flying cars.

Stupid

Without RTFA, this is completely stupid. If someone in the 50s had thought to lecture me about computer security, in a world even without networking, it would be totally irrelevant to todays environment. I would think we can extrapolate maybe the next twenty years. At most. Already WebOSs are coming out, as are apps for those.

I could be wrong, without reading the article and all, but 50 years is a little long to be speaking authoratively. After all, my much respected pedagogue, Mr Tanenbaum, said Linux would never make it...

Computer Security, The Next 50 Years???

Yes, let's hope someone will actually invent some in that period. For I am afraid my graveyard identity could be stolen...

Go back to 1956...

...and tell me that you could've predicted where computer security was going for the next 50 years then.

DDoS attacks? Botnets? Spam zombies? "Old school" viruses (and by old school, I mean it seems like these kind of viruses have become less-common than they were in the early-mid 1990s) that wipe your whole HDD? Mail clients that auto-execute a scripting language that a maliciously-minded high schooler can understand? Exploit-discovery tools like Metasploit? (or heck, even the very concept of an "exploit"?)

These things weren't conceived-of then. Not on anybody's radar at all. Remember, this was a time when IBM was selling computers to the 5 people in the world they said might have a use for them...

Yet Alan Cox has the nuts to come to us, saying "listen to me! I hack on Linux's kernel, and now I have an MBA, so I can predict the future now!"? He may be as close to a good predictor of the future of computer security as we have, but my point is that there are FAR too many variables -- far too much emergent behavior and unpredictable events -- between now and 50 years from now for he or anybody else to make a competent projection out that far.

For all Cox knows, the human race could be exterminated in 2015 by a nuclear war with the >Russians [freemarketnews.com] and the Islamic world, fueled by rising inflation or even a currency meltdown somewhere (possibly even the U.S.). [chron.com]

Demolition Man-style identity theft

Hopefully, identity theft for biometrics won't be too gruesome.

Mathematically provably secure?

He cites this as if it is common knowledge. It isn't. All of the CS Theory and Math I've seen from the crypto world doesn't really inspire confidence. My wife is a crypto researcher and as a result she doesn't really trust anything. (She's typically right. I was fawning over GPG and she was extremely skeptical and said she'd never use it for anything important. Weeks later, there is a major security bug -- not in the crypto algorithms, but in the implementation.)

I'd be interested to see what he means by a mathematically provably secure system... even one that works in theory. I personally think he's just making stuff up.

Also, he says that OpenBSD's memory randomization causes esoteric debugging errors since no two programs run in the same way. I also think this is BS. Where is the proof? Has anyone else heard of this?

Very hard to defned against Trojans

2500 years ago some greeks invented an attack for which there is no defence. It's called the "Trojan Horse". It goes like this: Make something that looks to be very atractive to your enemy but is actually anything but that. Normal defences and security can't work when the user really _wants_ some program he found to run. The only thing that can work 100% is to take control of the computr away from the user.

50 *years* ?

How about 50 months? Not to diss anybody, but anyone who's talking 50 years out on computer platforms sounds like an old philosopher combing his beard. And if he can do it, so can I.

50 years out: The biggest technology security issue will be kidnap and forced slavery. People with expensive cybermods will regularly have their arms ripped off during drive-by "arm snatches". And those with neuralmods will regularly lose their heads to thieves working out of chopshops, or be bodily kidnapped, removed to remote locations, and hooked into local nets to provide undocumented processing power to organized crime syndicates who, due to NSA backdooring of mainstream commercial platforms, need to set up "bloodmarket" wetware computers to run their illegal casinos and submarket financial networks/scams. Those with really valuable information in their brains will have their very souls stripped out one memory at a time, a process than can take months, until they are completely downloaded and left an emaciated corpse. Meanwhile, most communitcations, including voice transmission in air, will be actively tapped either by governments or corporations and often both, and regulary edited on-the-fly to alter it's meaning in subtle ways before arrival. Thus there will be companies who offer communications services where the amount of such editing can be reduced to as little as 5% of meaning by multi-path transmission and quantum encryption. Likewise, electronic paper will be found to have a bug/feature where anyone nearby can get an exact copy of what you are writing, while you write it, just by tuning into the nanovoltage molecular transition events during the raster scanning process, a la TEMPEST of old.

So there you go. It's all totally wrong of course and the reality of 50 years out is sure to be stranger still. One thing is for certain, we've come a long way from "Moth in Panel F relay #70".

Transcript

Here's my rough transcript of Alan's talk.

I thought I'd talk about the next 50 years of computer security, partly because people say getting the next 50 years right is the hardest bit. So, if I get it wrong, I've got an excuse.

If we're going to talk about security, we need to talk about the threat. What is the biggest threat out there? Well, as far as we can tell--as far as I can tell, at least--in the longer term, the nightmare security risk is the employee, or the person in general using the computer system. They're really inconvenient things:

• You can't formally verify people; it just doesn't work.
• They operate inside of your security system, in most cases so they can actually do their job.
• They work for you. And worse than that, they mean well. If they were malicious, you could get rid of them. If they mean well, they're harder to deal with.

So a lot of security in the future has to be around stopping people who mean well doing things they shouldn't.

We'll start with the easy stuff. There's been a lot going on recently in terms of programming tools for verification. It's not new science: the mathematics, the ideas behind these are 30 years old. What's happened is that people have built useable tools based on these ideas. As computer systems get faster, they get more and more able to make use of these tools. Some of these are even now getting into the compiler. The newest version of gcc can do things like certain kinds of buffer overflow checks, the memory handling functions--strlen, strcpy and stuff--can spot running over the end of the stack. At Red Hat we compiled a very large number of applications just with these basic checks. And then we tried to run them. The results were not brilliant.

The bugs were always out there--they just weren't being found. Some of this code should have been hand-inspected again and again and again. Language tools are another one: it's something Sun in particular took up with Java--trying to build language systems where you can't have things like buffer overflows, where your locking model is based around making it schemes where it's hard to forget to do things like release locks. So a lot of your synchronization is implicit, or you just say "this is synchronized with the other" and don't handle locks directly.

With a lot of design improvements, people are starting to think much more about modularity in software. To improve code security, we need to think a lot more about modularity, dividing things into logical sections.

The final thing that which has come with this is mathematical models--which is the bit I really hate, because I don't like mathematics. You can do really detailed, full-on mathematical models of computer systems. We're at the point that you can build a mathematically provably-secure system. What we don't know how to do is build one which is usable. You also have to remember is that a mathematically-secure system is not necessarily correct. There's a real difference between being correct and secure. A secure system won't break its security properties, but it might do completely wrong things.

We're starting to think more about defence: we're seeing better hardware defence. Desktop PCs today have finally discovered non-executable stacks, something I think the mainframe people discovered in the late 1950s. We're learning from the virus world, and the real world. If we have randomization systems--which we're just starting to do a little bit of--if we randomize the way your memory is laid out, you randomize the way your machine behaves, then it's much much harder to write an exploit because it might work on one machine, but it won't work on another--or it could work on some fraction of machines in an office. What we have so far is fairly primitive: moving memory around, rearranging memory layouts. There's a lot of scope to do this--probably not within the Unix model, because the Unix model defines some things so rigidly.

Re:Not really an expert

you know he wrote the Red Hat FireStarter iptables GUI and various parts of the linux tcp/ip stack right?

somewhat an expert

I'd put Theodore T'so before Alan Cox, but Alan Cox ranks highly.