The Six Dumbest Ideas in Computer Security

Frater 219 writes "The IT industry spends a huge amount of money on security -- and yet worms, spyware, and other relatively mindless attacks are still able to create massive havoc. Why? Marcus Ranum suggests that we've all been spending far too much time and effort on provably ineffective security measures. It may come as a surprise that anti-virus software, penetration testing, and user education are three of "The Six Dumbest Ideas in Computer Security"."

Comments

Re:Here it comes...

[MarkRose]

Why, would you rather I leave the door open to get some light in the basement?

zerg

[Lord Omlette]

Unless they ban the movie Hackers and eradicate all copies of it everywhere, they're not gonna make hacking uncool...

Re:zerg

[H_Fisher]

Forget the computer-security angle; I would suggest this be done as a humanitarian action.

Come to think of it, why the hell isn't the UN trying to do this already? Won't somebody PLEASE think of the children?

Re:zerg

[Kymermosst]

Unless they ban the movie Hackers and eradicate all copies of it everywhere, they're not gonna make hacking uncool...

Don't forget Sneakers, which was way cooler (IMNSHO) than Hackers.

Re:zerg

[chrysrobyn]

Unless they ban the movie Hackers and eradicate all copies of it everywhere, they're not gonna make hacking uncool.

There were precisely two cool things about Hackers.

1. Angelina Jolie.

2. Airbrushed keyboards.

Sneakers, on the other hand, Hollywoodified an already absurd idea..

Re:zerg

[EvilTwinSkippy]

No, no. Before Sneakers there was "War Games."

Cool by default because it was a movie about hacking before the world at large even knew about hacking (and phreaking, and blue boxes...)

Re:zerg

[Shishberg]

They could just give out free copies of Antitrust instead.

Re:zerg

[Bryan K. Feir]

No, no. Before Sneakers there was "War Games."

Cool by default because it was a movie about hacking before the world at large even knew about hacking (and phreaking, and blue boxes...)

Not to mention the fact that, unlike so many other movies about hacking, War Games involved actual research on the system being targeted on the part of the main character in the movie. Sure, most of the research was done as a montage because otherwise it's boring, but it was strongly implied that he spent weeks trying to figure out names based on what he could see.

Dumber Article...

[__aaclcg7560]

I thought the overall article was dumber than the six dumb ideas.

Re:Dumber Article...

[radish]

Agreed - this guy has his head in the clouds.

One of the points basically comes down to "write perfect code". Well, duh, why didn't I think of that before? Jeez. Patching is bad because your code should have been perfect in the first place? That's the dumbest thing I ever heard.

His argument that an OS should ask you before running something is also stupid. How many users do you know who would actually read & understand such a question? Never mind actually giving a sensible answer. Lets say I just downloaded some spyware infested screensaver and am installing it. How is asking me "do you want to install this screensaver" going to help anyone? Of course I fricking want to install it, I just went to the trouble of downloading it. What we need is a way to detect that the screensaver is a trojan and warn me that this is a bad thing. And that basically boils down to blacklists and heuristics scanning (or "enumerating badness"). Both of which most decent AntiVirus apps do a pretty good job of.

Re:Dumber Article...

[hattig]

Whilst I agree that his 'write perfect code' is a bit far reaching, he did point out that decent design beforehand can save a lot of time down the road. Yes, this should be common software engineering methodology, but I'm sure we all know of times when there's a deadline, the boss is angsty and you've got to get something working to keep your job, and a decent design document isn't what he wants to see.

If we limit the issue down to a corporate network, then refusing to run that infested screensaver because it isn't on the list of {Word, Excel, Outlook, Powerpoint, ...} would probably save an awful lot of hassle in the long run - well, apart from trojans, so you'd probably have to only execute applications with certain hashes rather than names. If the corporate IT infrastructure was well designed (hah!) at all levels then there would be far fewer issues. On the other hand, take Microsoft software - you need to run it in your corporation, yet you have no control over it.

I bet someone could come up with a Linux distribution that had a database of 'approved' applications (e.g., application name, application path, application MD5) - basically all applications that come on the install - and had a modified kernel that checked that database whenever starting a new process. Hell, it'd make an interesting programming project. In fact, this is something that I would see something like OpenBSD implementing first. You'd also have to do the same for library files of course, and scripts would be an interesting problem - you can run bash or perl for example, but if the script then does unlink on your filesystem because it is bad... you could limit it to only allowing the scripting language to access approved script files (yet another database, and each scripting language would need modification to use this database). As an alternative, possibly the filesystem itself could manage the entire scheme - you can't run something the filesystem refuses to load!

Of course, in the end with these more positive methods is that it still only takes one bad thing to get past the plethora of security systems you've set up.

Re:Dumber Article...

[kcbrown]

What we need is a way to detect that the screensaver is a trojan and warn me that this is a bad thing.

Well, no. What we need is for programs to have very specific sets of permissions that they operate under. Screensavers, for instance, generally should have permissions to do nothing but write to the screen and (depending on how the screensaver system works) read from the keyboard/mouse. They shouldn't be able to read or write any files, and they shouldn't be able to connect to the network.

That's the only reasonable way you can prevent trojans in that specific set of circumstances, and that only works for programs that can easily be restricted that way. If the installer itself is compromised then it's all over, because of the capabilities installers generally need in order to do their job.

In the more general case, there is no good way to prevent a trojan, because a trojan is, quite simply, code the user doesn't want to be executed being piggybacked onto code the user thinks he does.

The best you can do is minimize the damage, by providing a clean separation between the user who installs the code and the user who executes it, and by limiting the access rights of the user who executes it to a small subset of the system.

Re:Dumber Article...

[Krunch]

One of the points basically comes down to "write perfect code".

No, it comes down to "build a perfect design".

Of course I fricking want to install it

But maybe you don't want it to connect to the network or touch the filesystem.

Re:Dumber Article...

[ottffssent]

He's not talking about having the OS ask you if you really wanted to double-click on that icon. "Did you really want to do that" boxes would probably have made the list if he'd made the list a few items longer - they train users to default accept dialog boxes that come up, because they're just in the way and don't actually mean anything. Windows itself does this in numerous places. A dialog box asking if I want to send debug information to Microsoft about an app that just crashed is stupid. Do it, or don't do it, but don't bother users with a dialog box that has no impact on their experience with the OS - it just teaches them to ignore dialogs in the future.

He's talking about asking the user if you really want the trojan that the screensaver installed to start when you boot your computer next. If the computer properly protected the dozen or so apps you use and asked every time something new ran, people might actually start reading dialog boxes because most of them would contain useful information that will directly impact the user's experience.

The correct approach is not to try to algorithmically determine what is bad and warn the user about it, as you suggest. The correct approach is to algorithmically detect strangeness, deviations from the norm, that may indicate something wierd is happening. And then ask the user about it - even the dumbest user is better at sorting out new information than the computer.

Re:Dumber Article...

[An Onerous Coward]

If you read it as "write perfect code," then yes, the guy is crazy. But I think the article passed through a dumbification filter before it got to your brain. what I think he's really saying is, "Think about the security implications of new features before you add new features."

"What we need is a way to detect that the screensaver is a trojan and warn me that this is a bad thing."

This one makes the Halting Problem look like a walk in the park.

Whitelisting should work fine, in situations where the user isn't able to add to the whitelist at the click of a button. But even if the user can decide for himself whether to run a program, it would be nice if it were simple for the user to decide what privileges the program should have.

I don't see anything wrong with the idea, because there is no reason not to add an antivirus scanner into the mix. But the AV scanner alone is only as good as its latest definitions. Even if they're good enough to catch 99% of the bad stuff, you're still left with the glaring fact that the scanner can only protect against threats it knows about. A whitelist will protect against threats both known and unknown.

Re:Dumber Article...

[einhverfr]

Check the details against a database in memory of approved applications - can't that that long now can it, in comparison with the comparitively vast loading time.

Just how many applications do you propose to whitelist? I would say that an average Linux desktop would need to plan for at least 10000 entry checks for each application that would start up.

Now, as for bash scripts or Perl.....

Are you suggesting that users of the computer should be unable to write their own scripts to automate boring stuff?

IMO, a better way of doing things is to define a good security perimiter and attempt to balance security with usability on both sides. Then you can aggressively filter what comes through.

Trying to download that great screensaver from your web browser. Nope... Ain't gonna work. Trying to open that attachment? Not on the approved types. Sorry.

Note that this is pretty much doable today with current technology. Indeed, I don't see why one cannot arbitrarily decide that users cannot have the executable bit set in their home directories (it is a mount option you know). It certainly makes sense not to allow the suid bit set (another mount option). And this will get you 99% of the way there with only 1% of the management overhead and a lot less computing overhead.....

Re:Dumber Article...

[hattig]

I don't think you get who I am defining as a user in this case.

Not you. Not me.

I'm talking about your average office person that uses Word, Excel, Powerpoint, maybe a couple of other applications. The people that can barely operate a computer beyond what their job entails. People that are the number one cause of the propogation of worms and viruses and spyware because they click Yes on everything that pops up, because it is a computer, and computers are giant brains that know everything. Okay, I exaggerate, but you must get my point?

Mac OS X has Automator. Let them use something like that to automate tasks.

You are a big proponent of sticking all the security at one location, however I believe that security should be everywhere.

You can bypass the noexec mount option by running ldlinux.so directly with the application name.

Re:Dumber Article...

[10101001 10101001]

I'd like to counter your arguments.

One of the points basically comes down to "write perfect code".

I'd say his argument is closer to "don't write in C". Primarily exploits like buffer overflows are a resulting of using C. Now, as you point out, if one wrote perfect code, then using C would be fine. But clearly people don't write perfect code. So, the next best thing is to use a language that is designed to handle a lot of the problems that are experienced in incorrectly using C.

Of course, there's nothing about using Java or another language that makes your system immune from attack. But Java/Lisp/another high level language, design-by-contract, and checks for overflows (or using a language where overflows basically can't occur) would go a long way to turning exploits into loggable DOS attacks. The best way to design well is to use tools geared toward that end. Sadly, C isn't one of them.

His argument that an OS should ask you before running something is also stupid. How many users do you know who would actually read & understand such a question? Never mind actually giving a sensible answer.

Few. But the users he's primarily talking about are those on company workstations/desktops, not home users. In such an environment it makes perfect sense to lock down the system and give the IT department the control on whether a user can run programs. To that end, the user never has to give a sensible answer. They just need to have their IT staff "do the right thing". The fact that no OS seems to support such well isn't a good thing (Linux sort of supports it, but you have to go through hoops to set it up).

Now, what about the home user? The fact is, while most home users are incapable of knowing whether something is "good" or "bad", there's nothing to stop the OS from figuring out if a program was installed properly and only allowing such to run. Further, there's nothing stopping the OS from setting to so it's trivial to block a program from running ever; imagine, for example, being able to easily keep MSN Messenger from loading. The fact is, modern OSs are a long way from allowing the sort of fine-grain control over program behavior. Zonealarm seems a great example of a step in the right direction, allowing independent blocking of in/out network traffic.

Users might know very little of how to do "the right thing", but that doesn't mean the OS can't do a lot on its own. Nor does it mean that the user can't try and succeed a lot of the time. Of course, don't be surprised when you'll have to reenable Java for granny after you disabled it one day because of an annoying web ad but the next can't get a web game to work. Of course, the real answer then is more granular control. And of course, as was stated, the opt-in, not opt-out mentality so that granny never had to disable the web ad in the first place, but instead she's the one who enabled support for the web game.

Re:Dumber Article...

[einhverfr]

I'm talking about your average office person that uses Word, Excel, Powerpoint, maybe a couple of other applications. The people that can barely operate a computer beyond what their job entails. People that are the number one cause of the propogation of worms and viruses and spyware because they click Yes on everything that pops up, because it is a computer, and computers are giant brains that know everything. Okay, I exaggerate, but you must get my point?

Ok, then substitute macros in office documents for Perl/Bash scripts.

The best goal of security, IMO, is to prevent what can be prevented without impinging on operations and contain the rest of the damage. It is not that you *cannot* prevent the occasional incident, but rather that preventing the occasional incident is far more costly in some cases (viruses on Windows for example) than managing the damage.

Sure Linux is better. In that case we can substitute Python macros in Gnumeric....

But you still have some of the issues. Unless your system focuses heavily on damage containment, the security will be brittle and when someone does succeed in breaking in the damage will be very serious. This is what the article misses BTW (and what is generally wrong with the way people use firewalls).

A much bigger problem

[a_greer2005]

is the unpatched laptops that are fine while in the cacoon of the company LAN/WAN/VPN, but are all too often connected directly to the net by workers who take them home or road warriors who get on the net the second they hit the hotel room.

These people get the crap and then bring it into the cacoon, thus negating the hundreds of thousands of dollars of security infrastructure

Re:A much bigger problem

[dhasenan]

Or use a wireless network for the laptops, going through a separate server, and put extremely restrictive firewalls on that server.

It's not as fancy, but it works. Just use decent encryption.

Re:A much bigger problem

[Johnny Mnemonic]

We give our users Mac laptops, which largely corrects this issue.

Re:A much bigger problem

[Jetifi]

Yep, that's because companies spend too much time and money on border security (company firewalls, email filters etc.), while creating SPOF's in trying to minimize maintenence and admin budgets while forgetting that defense in depth is far, far more effective.

Given that users today like to use a variety of tools that use far more ports than just 80 and 25, it's more sensible to have protection at multiple levels: vlan, proxy, mail server, software firewalls, and AV/IDS from top to bottom, updated in as close to real-time as you can get.

The architecture proposed in this article goes to the opposite extreme, eliminating the DMZ and striving to minimize the need for a corporate firewall. I think it goes a little too far, but he's definitely got some good ideas.

(Also, in their defense, the road warriors are normally the salesmen keeping the company afloat :-)

Re:A much bigger problem

[MightyYar]

I'm a luzer as well, and I frankly find IT's antics pretty entertaining. They have a mixed environment of Win95-WinXP running on everything from crap 90MHz machines up through the latest-and-greatest.

My first frustration with them started when they put up the internet content filter. This I had to bypass by turning on my apache proxy at home and accessing the internet through my home machine (using ssh, of course). The local helpdesk guy just rolled his eyes at me when I showed him playboy.com. I wasn't just being a pain, though - they had the filter tuned so tightly that even some of our vendor websites were filtered.

The next thing they did was run this horrid agent via the login script that lets them do whatever they want. On the surface, it seemed okay because they were just using it to make sure your machine was patched and running the latest anti-virus. However, it seemed to crash or seriously effect the performance of most machines that were still running 95 or 98. Their solution? Put 2000 on all of those machines. Ever run 2000 on a 200 MHz machine with 32-64MB of RAM with Norton running? Unusable. So, I figured out that you could easily trip up their startup script by strategically placing a single text file. The IT guys know this and leave me alone, and in fact refer people to me (with a wink and nod) when they have this problem. :)

Password management is a disaster. If you use Outlook or webmail, occasionally you might get a warning that your password will expire in n days. One of the options is to change your password. Almost everyone does. Uh-oh, now you can't log in to the network... why? I don't pretend to know. All I know is that you must make the password change when you first log in to windows and never when prompted after login. I'd ridicule the people that haven't grasped this - but really, they are just following directions, aren't they?

What is next? I don't know, but there is a reason that us Luzers find the IT management to be an obstacle rather than a help.

Re:A much bigger problem

[mr_z_beeblebrox]

thus negating the hundreds of thousands of dollars of security infrastructure

They didn't negate it. The stateful firewall still stopped traffic at it's border etc... What they did was expose the lack of hours spent planning the security. here is what I do and you are free to do it, improve it or ignore it (that makes it free). In my company every network jack that does not have a direct attached device on it is plugged into a bank of switches that are seperated from my network by a pixfirewall. The firewall has rules that allow basis e-mail, web and specific application data to go accross. Most traffic is denied. If anyone plugs a laptop in they are able to do those things but are unable to do Windows file share, domain login etc... If they need to use those I have to be given control of the box and it does not leave the building.

Re:A much bigger problem

[Creepy Crawler]

Comments by people (like you) who post worthwile content is why I'm still here.

It really is neat-o when I read about personal stories about hell-desk or being that "luzer" (when we know you arent... luzers dont even know what ssh is).

Thanks. (no, this isnt satire, I really am pleased that slashdot can still generate what it originally did years ago.. real people commenting about their problems.)

Re:A much bigger problem

[RollingThunder]

Actually, if his points were implemented properly on those laptops, then they wouldn't be capable of being carriers of infection.

As well, any network that can get completely owned by a road warrior is inherently brittle. It needs more defense in depth.

Re:A much bigger problem

[hey!]

I'm a luzer as well, and I frankly find IT's antics pretty entertaining. They have a mixed environment of Win95-WinXP running on everything from crap 90MHz machines up through the latest-and-greatest.

[snip]

Their solution? Put 2000 on all of those machines. Ever run 2000 on a 200 MHz machine with 32-64MB of RAM with Norton running?


Well, if you read between the lines here, it's clear that at least one reason that your IT department does stupid things is because there isn't a proper capital budget for replacing old machines. In fact I'd bet they don't have a proper operating budget either. It's typical enough: not enough resources to prevent problems, barely enough resources to mount a pantomime of a response to them when they arise. The only thing you'd need to get a perfect trifecta of dysfunctional management is a culture of scapegoating masquerading as "accountability".

The typical game plan:

(1) Willful ignorance
(2) Wishful thinking
(3) Make a show of responding
(4) Look for somebody to blame.

IT is overhead, and overhead is the devil when you run a company. That means in a well run company you seldom can expect everything you might wish for. But you can't just wish overhead away: you have to be smart enough to know when spending less on one piece of overhead means you spend more in ten other plances. Sounds like your senior management fails this test.

Dumbest security policies?

[Anonymous Coward]

What are some of the dumbest security *policies* you've encountered?

I worked for a firm earlier where we had to change our passwords every week where the password had to 1) be exactly 14 characters and 2) be ~60% different to the previous four passwords.

The result was of course that almost every user had their passwords on post-it notes.

Re:Dumbest security policies?

[Freexe]

My current password is "ilovepigs" and all i have to do to find it is look through my slashdot post history on another PC.

I don't understand why people bother with postit notes

Re:Dumbest security policies?

[Anonymous Coward]

Post it notes are not necessarily a security hole. It depends whom you are trying to protect yourself from. If the goal is to prevent external attacks ( via password cracking, etc ) then you're fine. If you don't trust your co-workers then they may be an issue. But then they have physical access to your equipment anyways.

Re:Dumbest security policies?

[nunchux]

Five years or so ago I did freelance work for a short-lived "online greeting card company" (shut up, I know.) Basically I'd go to a control panel to get an order, adjust the proof in the Flash template and send it back. I had absolutely no access to any other part of the site, the databases, not even the customer's contact info (much less credit card #'s.)

I still had to change my password every two weeks, with conditions similar to what you describe-- IIRC ten or more characters, mix of numbers and letters, had to be substantially different than the one before. I eventually a system down for remembering what it was, but I'll be the first to admit I was using my Mac's "stickies" to keep track of the password for the first six months. Considering they were dealing primarliy with graphic designers, not programmers, I can only imagine what some of the other employees were doing. Since they also weren't the easiest employers to deal with, I can only imagine that the lack of give-a-shit factor kept many employees from trying to hard to keep that ever-changing password a closely guarded secret. Let me stress that the damage that could be done if my password was compromised was completely negligible-- maybe someone could have inserted a dirty message in a greeting card, but it still had another check to go through before it went online!

Basically my point is, there's a point where security for security's sake is an annoyance. I'm certainly not an expert in these matters but IMO making low-level users go through hoops is just going to foster ill will, better to lock down their privileges in the first place and make sure no damage could be done if that account was compromised. Frequently changing admin passwords is of course another matter, but that's part of the responsibility that comes with the job.

Re:Dumbest security policies?

[HermanAB]

That is actually not too bad, unless you have webcam pointing at the sticky note. The point being that someone on the other side of the globe cannot see your sticky notes and cannot easily crack a 14 character password either, while locally, you probably have some form of physical security - you do lock the door right?

Re:Dumbest security policies?

[Otter]

I worked for a firm earlier where we had to change our passwords every week where the password had to 1) be exactly 14 characters and 2) be ~60% different to the previous four passwords.

For real effectiveness, though, you have to implement this the way we have it at work -- every webapp, from travel reservations to sexual harassment, training has a different account with different login names and mandatory strong, rotated passwords.

Re:Dumbest security policies?

[Haeleth]

I worked for a firm earlier where we had to change our passwords every week where the password had to 1) be exactly 14 characters and 2) be ~60% different to the previous four passwords.

Man, you had it easy. My current place uses iris scans for authentication. We have to swap out our eyeballs every 30 days, and our new eyes can't be the same colour as the last pair.

Re:Dumbest security policies?

[bryhhh]

The password policy at that firm sucks, but writing passwords on post-it notes isn't such a bad idea. Consider these two different policies:

A. User allowed to use simple passwords that they can easily remember such as 'password', or 'abc123'. This user doesn't have to write their password down to be able to remember it.

B. User with a complex password, but writes it on a post it note because they don't stand a chance in hell of remembering it.

If user B is also requested to take the simple step of placing the post-it note in their purse/wallet, the password instantly becomes many more times secure than the password of user A.

Re:Dumbest security policies?

[Dolly_Llama]

My current password is "ilovepigs" and all i have to do to find it is look through my slashdot post history on another PC.

Better not do that on your girlfriend's PC.

Make that your ex-girlfriend's PC.

Re:Dumbest security policies?

[Timbotronic]

I taught a programming course at an Australian government department where they had a "no unauthorised software" policy. Unfortunately, the language I was teaching wasn't on their list, so they wouldn't allow me to install it on the training room computers that weren't even connected to the office network!

Needless to say the course was less than effective and illustrates what should be the seventh dumbest idea - "Security policies have no effect on productivity". The amount of grief caused to companies by rigid, pedantic security nazis is astounding.

Real security has to be build into the foundation

[kcbrown]

Viruses occur because the foundation of the system the users are using isn't secure. The same is true (perhaps to a somewhat lesser degree) of worms.

To illustrate, ask yourself this question: why do most corporate computer users have permissions on their computer to download and execute arbitrary programs?

Now, it should be noted that even Linux gives the average user this capability. But that needn't be so.

Antivirus programs are a bandaid, not a solution. But most people treat them as a solution, and therein lies the problem.

If you really want to take care of security issues, you have to do so at the foundation.

Unistalling right now

[snuf23]

Yeah, I'm taking all my anti-virus software off the computers right now. I don't know why I ever though it was useful anyway. It's more efficient to deal with the infections as they come in then it is to try to prevent it.
I'm gonna stop using condoms too while I'm at it.

Re:Unistalling right now

[JourneyExpertApe]

I'm gonna stop using condoms too while I'm at it.

What does making water balloons have to do with preventing a computer infection? I don't get it.

Re:Unistalling right now

[Temporal]

Incidentally, I have never run anti-virus software, and yet I have never had a virus. And I run Windows. And, yes, I would know if I had a virus; I regularly help other people remove viruses from their systems. Of course, the people I help typically are running AV software; little good that did them.

If you're careful about what you install, stay away from Kazaa and warez, and keep an eye on your windows\currentversion\run registry entries, and for god's sake do not open file attachments, you can stay safer than any AV software would make you. AV software generally can only detect viruses it knows about, and you better believe most viruses that exist in the wild are not in the AV companies' databases.

Highly applicable

[gunpowda]

The Internet has given a whole new form of elbow-room to the badly socialized borderline personality.

Woah, he's not talking about Slashdot?

He mixed up hacking and cracking

[TelJanin]

In #4, "Hacking is Cool", he obviously means "cracker." Also, the last part of that section says that security professionals should not know how to crack. Bullshit. If you don't know how exploits are used, how can you block them? How can you write a secure program if you don't know what a buffer overflow is?

Re:He mixed up hacking and cracking

[TLLOTS]

I think you misunderstood his point with #4. My understanding of what he was saying was that time spent learning how to hack into a system with xyz could be better spent simply learning about good security practices (such as how to prevent a buffer overflow). Rather than spending the rest of your life learning about each new exploit, you simply focus on why those exploits are occuring, and fixing them at the source, rather than trying to simply keep patching.

Re:He mixed up hacking and cracking

[caller9]

ditto. You shouldn't learn how to hack, you should learn how to prevent it. Drawing a line between the two is pretty hard though. Learning how to hack is tightly related to learning how to prevent hacks. I think the author's point is that learning from practicioners is less effective than learning from "best practices" because you are forever behind the curve if practicioners are out of the loop. The fact is that many practicioners are simply highly skilled outsider, engineers very much in the loop with nearly limitless spare time dedicated to messing you up.

Learn what good coding means and do it, then you can ignore hacking practices. This is very idealistic as most people don't build a system thinking that it is vulnerable intentionally. Unless the vulnerability is "obscure enough" to be valid. No wait, that's MS common practice.

His point is to developers. Compartmentalize, secure, and validate EVERYTHING. Guilty until proven innocent. User, Processor, and network/storage overhead be damned. Check the stack every microsecond and verify in tandom. Generally, be perfect and only make perfect things. It's as easy as 1,2,3. Relegate computer use to experts only and found a colony of uber hackers that will process all informational transactions henceforth, forever.

Re:He mixed up hacking and cracking

[Tim C]

In #4, "Hacking is Cool", he obviously means "cracker."

There's little point fighting battles that you can't win, unless you mean to make an example in your loss. In this case, you can't possibly win and there's no example to make (except perhaps that language evolves - big deal); I'd suggest saving your effort for something you *can* make a difference to.

Poor Article

[hoka]

The article really fails to address any real issue with security. What the article really read like was something more along the lines of, "Six Things Dumb Management Sometimes Do In Relations to Computer Security". The real problem with technical computer security is the poor quality of software (software designed without security, or without enough security in mind), and the general lack of general system protection (NoExec memory, Stack Smashing/Active Bounds Checking, Targetted/Strict ACLs, etc). The damage worms/viruses/hackers can cause on a much stricter system is really far less than a normal system, if the penetration can even be achieved in the first place.

Re:Poor Article

[X.25]

The article really fails to address any real issue with security. What the article really read like was something more along the lines of, "Six Things Dumb Management Sometimes Do In Relations to Computer Security".

I guess that people who comment like this have never done any serious security work in their life.

If you had, you'd acknowledge all the points (plus the extras) easily...

Either stupid or obvious

[Chris_Jefferson]

1) Default deny instead of default allow.

Actually, default deny is just as stupid as default allow, as if you have default deny, people just get sick of being asked if they want to allow something, and end up clicking "yes" on every box they see.

2) Enumerating Badness

So you want to write a virus scanner that somehow can recognise viruses without being told which programs are viruses. Modern virus checkers already mostly do this. With spyware it's very hard for a computer to tell the difference between a program you wanted installing and one you didn't. How do you expect it to tell?

3) Penetrate and Patch

So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?

4) Hacking is cool

You think people should learn how to stop hacking and intrusion without learning how existing hacks work? Then you are stupid. Shush.

5) Educating Users

So you are saying that we have to do security without teaching users how to do it. That just isn't going to work unless you never let users install their own applications or plug-ins. Yes teaching users is hard, but it has to be a vital part.

6) Action is better than Inaction

So, after saying the state we are in is rubbish, you now say we shouldn't actually change anything. Eh? Or are you saying "don't try something new without testing it first"? Well thats more than a little obvious.

This is just trolling, crap, and obviousness. Your average slashdot post really.

Re:Either stupid or obvious

[Hektor_Troy]

3) Penetrate and Patch

So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?

That's not what he's saying.

Think of it this way:

int isPrime( long primeSuspect)
{
if(primeSuspect == 2 || primeSuspect == 3 || primeSuspect == 5 )
return 1;
return 0;
}

How would you patch it? Test it for every prime and then add them to the check list? Or would you realise that the design is crap and change the design?

He wants you to change the design, rather than just fix the aparent flaw that 7 returned false.

Re:Either stupid or obvious

[TLLOTS]

1) Default deny instead of default allow. Actually, default deny is just as stupid as default allow, as if you have default deny, people just get sick of being asked if they want to allow something, and end up clicking "yes" on every box they see.

Why on earth would you allow your users to select what is acceptable? I believe his proposition was stating that you as the systems admin should set what people can use, and block everything else, otherwise if users could specify what was allowed, then you're back to square one like you say.

2) Enumerating Badness So you want to write a virus scanner that somehow can recognise viruses without being told which programs are viruses. Modern virus checkers already mostly do this. With spyware it's very hard for a computer to tell the difference between a program you wanted installing and one you didn't. How do you expect it to tell?

Simple, you have a fixed set of programs that are allowed to run, and you don't allow users to install additional programs. Anything not designated as allowed to run therefore gets stopped in its tracks before harm can be done.

3) Penetrate and Patch So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?

Actually I think his point is that code is being written insecurely when it really could be written securely. Look at how things are now, the buffer overflow is a security flaw that has been known about for quite some time, and there are very easy ways to protect against it, yet buffer overflow exploits are still quite common. The point is we shouldn't be trying to understand the flaw and try to patch it, we should try and understand how the flaw ever came to existing, and fix that!

4) Hacking is cool You think people should learn how to stop hacking and intrusion without learning how existing hacks work? Then you are stupid. Shush.

As I explained in an above post, his point is that time could be better spent learning about the root cause of the security exploits (things like buffer overflows) and how to prevent them, rather than spending the rest of your life trying to guard against the countless flaws that the various programs you'll run may have.

5) Educating Users So you are saying that we have to do security without teaching users how to do it. That just isn't going to work unless you never let users install their own applications or plug-ins. Yes teaching users is hard, but it has to be a vital part.

His point here was that users shouldn't even be able to cause harm in the first place, and if they can, then no amount of education is likely to prevent them from inadvertantly harming others. That said though I do believe users should be educated, but I agree with his point as well.

6) Action is better than Inaction So, after saying the state we are in is rubbish, you now say we shouldn't actually change anything. Eh? Or are you saying "don't try something new without testing it first"? Well thats more than a little obvious.

It should be obvious, but how many companies got burned because they switched to very insecure wireless networks early on?

All up the points he raises are interesting, if idealistic at times. Next time you should try reading better

Re:Either stupid or obvious

[Arathrael]

Your example is bad and you should feel bad.

Actually, I take that back. It's an accurate representation of the article. Which was bad.

The example implies that the only application of 'penetrate and patch' is for idiots to check a design that's so obviously flawed you could simply correct it by thinking about it. And it assumes that if that flaw emerged, the developer would be sufficiently dumb to just fix the flaw as related to the specific test data and not anything else related, like, say, the underlying design.

Which is indeed seemingly what the article says. It basically summarises to 'If you do this in a really stupid way, then this must be a dumb thing to do. Stop being dumb.' There's logic for you. The author of the article actually uses the example of testing for Apache bugs on a system without Apache as justification for the 'penetrate and patch' approach being dumb. You've got to be kidding me. What about on a system with Apache? Would that be dumb?

I mean, I do agree that the 'penetrate and patch' approach is pretty futile if the design is put together and maintained by an idiot. But I'd say it's rendered redundant by the idiocy rather than being intrinsically redundant in itself.

At the other extreme, as the grandparent poster was saying, it's also redundant if you have a perfect design without any bugs and holes. Great. Let's just do that then.

Or, if we want to visit Mister Reality for a moment, we're going to in most cases have a design somewhere inbetween. Security will generally have been considered. But it most likely won't be a perfect design because we're just not capable of it (sidenote: how come users are so dumb they're just not worth educating, but software engineers are capable of perfection? I mean, to paraphrase the article, if educating software engineers was going to work, it would have worked by now...)

Anyway, given the probable failure to reach perfection in design (and the uncertaintly of knowing it even if you did), it might be a good idea, maybe, to actually test the live implementation, and maybe fix any flaws? Or if you wanted to give it a jazzy name, you could call it... penetrate and patch?

Or we could all just aim for perfect designs, assume we succeeded, and bask in the warm glow of our godlike egos. That's not a dumb idea at all.

On my webservers...

[Space cowboy]

I patch PHP to set a constant in the namespace of the script whenever a 'dangerous' function is called (eg: system(), shell_exec, the backtick operator etc., others :-). The webserver also prepends (php.ini: auto_prepend_file) a PHP file that registers a shutdown-hook. Those constants can then be examined in the shutdown hook code to see if any of the dangerous functions have been called, and if so, check to see if *this* script is allowed to call them.

If the script is allowed to call the functions, all well and good, it's just logged. If not, the offending IP address is automatically firewalled. I purloined some scripts from the 'net that allow shell-level access to manipulate the firewall.

So, now I had a different problem - the webserver wasn't running anywhere near the privilege needed to alter the firewall, and I didn't want to just run it under sudo in case anyone broke in. I wrote a (java (for bounds-checking), compiled with gcj) setuid program that takes a command string to run, an MD5-like digest of the command, and a set of areas to ignore within the command when checking the digest. The number of areas is encoded into the digest to prevent extra areas being added. If the digest doesn't match, the program doesn't run. This is a bit more secure than 'sudo' because it places controls over exactly what can be in the arguments, as well as what command can be run. It's not possible to append ' | my_hack' as a shell-injection.

So, now if by some as-yet-unknown method, you can write your own scripts on my server (it has happened before, [sigh]), you're immediately firewalled after the first attempt - which typically is *not* 'rm -rf /' :-) Perl and Python are both unavailable to the webserver uid, so PHP is pretty much the obvious attack vector.

Well, PHP and SQL injection of course, but the same script is used there - if the variables being sent to the page are odd in some way (typically I look for spaces after urldecoding them as a first step - SQL tends to have spaces in it :-), then the firewall is called on again. It's all logged, and the site-owners get to see when and why the IP is blocked. Sometimes it's even highlighted problems in their HTML :-)

What would be nice would be a register within a PHP script that simply identified which functions were called. In the meantime, this works well for me...

Just thought I'd share, because it's similar to what the author is saying regarding only trusting what you know to work, and everything else gets the kick (squeaky wheel-like :-)

Simon

DRM

[Kelerain]

That nice list, and they didn't include Digital Rights Management? The link is to a Cory Doctorow talk that explains and argues these points (it was for a talk he gave to microsoft)

1. That DRM systems don't work
2. That DRM systems are bad for society
3. That DRM systems are bad for business
4. That DRM systems are bad for artists
5. That DRM is a bad business-move for MSFT

A very good read if you are in the position of explaining this to someone in a position to mandate DRM.

Re:DRM

[Wesley Felter]

Because DRM has nothing to do with computer security. Lumping them together just causes confusion.

DailyDave

[tiny69]

There's already been some entertainment over Marcus's article on the DailyDave. Dave Aitel doesn't agree with Marcus.

http://lists.immunitysec.com/pipermail/dailydave/2 005-September/002347.html

Dave's "Exactly 500 word essay on "Why hacking is cool, so that Marcus changes his web site"." http://lists.immunitysec.com/pipermail/dailydave/2 005-September/002366.html

One good point this article makes

[suitepotato]

is the permit by default tendency. This is like having a fence that springs out of the ground only when certain people are sensed approaching it. It needs to be up and topped with barbed wire and the only gate needs to be locked until someone is given a key to it. NAT routers are like that. They can only forward traffic when you bother telling it to and until then sit there stupid making you wonder why your new SSH installation won't talk to the outside world.

OTOH, it is a collosal pain in the arse to deny all traffic and only allow what you want because so much code is network aware these days and designed to talk to some place across the net. Then again, it does tell you which apps are communicating in the first place.

On my Windows boxes I use Sygate Personal Firewall to create a specific list of allowed executables and block everything else with a block all entry at the bottom of the fall-through list. No match, no talk. Inbound and out. Combined with NAT it makes for very little traffic reaching my internal network. When I leave my desk for the night and Windows is running, remove a few check marks and save and it only allows the file sharing app to talk and I keep that updated and locked down at all times.
It also can be set to approve or deny execution of code that may have changed since last allow/deny challenge.

That which is not forbidden is not only not compulsory, but probably suspicious.

Re:users are teh greatest security problem

[dhasenan]

# chmod +x naked_sluts.exe
# ./naked_sluts.exe
Removing /home/iclod/porn...
Removing /home/iclod/work...
Removing /home/iclod/Mail...
Removing /home/iclod...
Removing /home...
Error: cannot remove /home: permission denied.
* Entering phase 2
Scanning ports for viral spreading:
No suitable ports available.
* Entering phase 3
Accessing sendmail...
Mailing...
Mailing...
Mailing...
Error: mail blocked: too many recipients. Wait ten minutes and try again.

In short, users aren't a major problem because they should only be able to hurt themselves. The problem is that they often can and do hurt others. This is the result of poor design.

Dumbest Ideas in Corporate Email Security

[Anonymous Coward]

1) Restrictive password naming policies

Password must be 10+ characters in length, contain upper and lower case letters, 3 numbers and 2 special characters.

Result:

Users keep their passwords on post-it notes stuck to their monitors.

2) Constant password expiration

Passwords expire every 3 months. New passwords can not resemble old passwords.

Result:

Users keep their passwords on post-it notes stuck to their monitors.

Re:Dumbest Ideas in Corporate Email Security

[Neop2Lemus]

At one company I worked at
when the 3 month period came,
you changed your password thrice
and kept it just the same.

Quote: "nude pictures of barely clothed females"

[Anonymous Coward]

*head explodes*

Re:Real security has to be build into the foundati

[Alex Brasetvik]

noexec can be easily circumvented. Read here for more information.

Relevant example:


              alex@joker:/tmp# mount | grep tmp /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
              alex@joker:/tmp# ./date
              bash: ./date: Permission denied
              alex@joker:/tmp# /lib/ld-linux.so.2 ./date
              Sun Dec 3 17:49:23 CET 2000

#4) Hacking is Cool

[Quirk]

"Hidden in Parker's observation is the awareness that hacking is a social problem."

Crime as a problem of context is studied in Gregory Bateson's seminal book Mind and Nature: A Necessary Unity. Bateson addresses two flaws in our court system. One is to treat a crime as something isolated and somehow measurable in penal terms. Taking a crime out of context, i.e., the makeup of the criminal, is blind to the forces that generate criminal actions.

Bateson speaks of (crime) "...as not the name of an act or action; it is the name of a frame for action. ...( he suggests)... we look for integrations of behavior which a) do not define the actions which are their content; and b) do not obey ordinary reinforcement rules." In this context he suggests play, crime and exploration fit the description. As long as we are only able to punish according to some sort of arbitrary eye for an eye method of bookkeeping we will be unable to root out crime.

Bateson's second criticism of our judicial system addresses it's adversarial nature. He writes... "adversarial systems are notoriously subject to irrelevant determinism. The relative 'strength' of the adversaries is likely to rule the decision regardless of the relative strength of their arguments. Bateson's second

He further goes on to a brilliant analysis of the Pavlovian study of dogs in terms of the dog's view of the context; and, how the dog's context is violated when the dog's view of a "game" of distinction is morphed into a game of guessing without there being any markers to tell the dog the context of the game has been changed. This switch in context drives neurotic and violent behaviour in the dog. I suspect much anti social behaviour is driven by the criminal's inability to read society's context markers.

Re: #4) Hacking is Cool

[seabasstin]

very interesting, I am getting it.
your analysis of the Pavlov's dog, raises a number of interesting questions, but definitely support the "Dumbest lists author" in his assertion that their is a significant erasing of boundaries when talking of computer network crime, that makes the criminal completely separate the effects of his crime on REAL people.
This I feel is also a real issue in a Globalized Corporate economy where arbitrary invisible entities are considered equal to citizens in the judiciary of most countries.
thanks for the reference

Nope

[Knome_fan]

As the article rightly points out, and btw. if you had bothered to read it you would have been aware of this, there is no reason at all why joeuser should even be able to download and execute "naked_sluts.exe" on a companies network.

And I quote:
"Dealing with things like attachments and phishing is another case of "Default Permit" - our favorite dumb idea. After all, if you're letting all of your users get attachments in their E-mail you're "Default Permit"ing anything that gets sent to them. A better idea might be to simply quarantine all attachments as they come into the enterprise, delete all the executables outright, and store the few file types you decide are acceptable on a staging server where users can log in with an SSL-enabled browser (requiring a password will quash a lot of worm propagation mechanisms right away) and pull them down. There are freeware tools like MIMEDefang that can be easily harnessed to strip attachments from incoming E-mails, write them to a per-user directory, and replace the attachment in the E-mail message with a URL to the stripped attachment. Why educate your users how to cope with a problem if you can just drive a stake through the problem's heart?"

No "default permit" for application launch in OSX

[Phat_Tony]

"On my computer here I run about 15 different applications on a regular basis. There are probably another 20 or 30 installed that I use every couple of months or so. I still don't understand why operating systems are so dumb that they let any old virus or piece of spyware execute without even asking me."

Try OSX. As of some update about a year ago, OSX stopped having "default permit" for launching applications by double-clicking. If you double-click and that leads to launching an executable that hasn't been run before, it pops up a dialog to ask you about it.

Thus, no more executables bearing viruses disguised as documents.

The Final Solution

[rufusdufus]

There is a way to fix security problems on end-user machines completely.
The solution is to keep the operating system and applications on read-only media. The end-user operating system of the future should be designed around this idea, and they should reboot from readonly media on a regular basis, this way viruses cannot spread and worms cannot get a foothold.
Its doable. Its feasable. Its the future, once engineers really decide to solve the problem.

Re:Here it comes...

[JoeCommodore]

Actually it was more like whatever you are writing don't expect that your code will exist in a secure environment. Whenever you can, do what you can to keep your modules secure. Don't give the OS or other moddules the benefit of the doubt.

Scoop

[Anonymous Coward]

Agreed - this guy has his head in the clouds.

Maybe he's a friend of ESR's or RMS's. Trying for his own elevation to 3 char alias fame...

Re:users are teh greatest security problem

[benjamindees]

Users aren't the problem. Allowing users to run unvetted executables is a problem. Relying on users to decide what executables are acceptable is a problem with their admins and with Windows.

SELinux is the solution.

You missed one

[Wrangler]

Number seven: taking advice from a security expert whose great claim to fame is an ongoing quest for even greater hyperbole.

Jeez, Marcus, are you always going to be a self-promoting twat?

Marcus, your list is crap. Here's a list:

1) No one is watching. IDS, firewall logs, doesn't matter - no one is watching.
2) Most security people don't get it. They run NFR and think that they're safe.
3) Security is a low priority. Time to market matters. Security ranks below documentation and above performance tuning.

Raising awareness of network security is a good thing. Doing it with bombast and self-promotion is just being a media whore.

='^)

Re:Um wtf

[Arker]

Take the article for what it's worth. He makes some very good points, although it's hard to take him seriously when he doesn't even know what the word 'hacker' means... but still, some very good points. Security is something that needs to be designed in from the start, not patched on top later.

I disagree on part of default permit

[ColGraff]

From the article:

"On my computer here I run about 15 different applications on a regular basis. There are probably another 20 or 30 installed that I use every couple of months or so. I still don't understand why operating systems are so dumb that they let any old virus or piece of spyware execute without even asking me."

The author has a point here, but answer to his question is very simple - his computer doesn't ask for permission to execute most programs because most users would absolutely panic if their computer regularly asked for their input.

I base this on my own experience as a college tech, which is necessarily limited. That said, two points to consider:

I have never, ever seen a student running in a non-administrator account on their Windows PC, even though XP supports this feature. This would prevent much malicious software from running, and avoids the "default permit" behavior that the article author finds so odious. However, users do *not* want to see error messages when they try to run things, nor do they want to log into a different account to install their p2p flavor of the week. They want things to "just work". So, non-administrator accounts are fantastically unpopular.

Another example: Zonealarm. My school encourages students - in fact, tells students they are *required* to - install ZoneAlarm. So what happens? Zonealarm asks them if they want to let, say, AIM or Weatherbug access their network connect - and the user freaks out. They think it's an error, that their computer is busted, etc.

In short- desktop machines tend to be default-permit because desktop users are completely unwilling to deal with an alternative arrangement.

Re:I disagree on part of default permit

[entrigant]

I have never, ever seen a student running in a non-administrator account on their Windows PC, even though XP supports this feature.

Have you ever tried this? Precious few applications actually do this correctly. Most won't install start menu entries for All Users. Others are worse and install themselves in ways that make them not work at all in a limited user account. I think it'd be easier for the average user to install and learn Linux than try to get a limited user account in Windows XP working well.

Re:No "default permit" for application launch in O

[unoengborg]

The weak spot in this is, that for it to work, the user have deny the executable from running. Most users don't. Especially not if the e-mail containing an the executable contains some plausible explanaiton why they should allow ti to run. E.g. telling them that it is an important secrurity update from Apple.

Re:String comparison?

[SetupWeasel]

You expect a user that's writing passwords on post-it notes to be that smart?

Why the hell would writing you password on post-its be a stupid idea? Everywhere I've worked the IT people didn't give a shit about the guy in the next room or cube getting your password. It was the people outside the building that mattered.

You are telling me that you could come up with a unique 14 character password every week and not have to write it down? Listen, I'm a pretty fucking smart guy, and I don't have that ability. With the number of passwords I have to manage these days, I'm lucky to remember where I wrote that one down.

The Microsoft Way

[CustomDesigned]

Actually, all his "stupid" points fit in with the "trusted" computing paradigm. Let's look at the points from that point of view:

1. Default deny instead of default allow.
   When users are annoyed by questions they don't understand, support costs go up. Windows users really can't answer questions about whether to allow various TCP connections. Since only programs we approve can be installed on the "users" machine, there is no point in default deny.
2. Enumerating Badness.
   Just like currency security doesn't try to identify all the different kinds of forgery, so the idea of "trusted" computing is that all programs are bad except the ones signed directly or indirectly by Microsoft.
3. Penetrate and Patch.
   To be effective, "trusted" computing must be airtight against workarounds by end users. That is why hardware enforcement is an integral part of the picture. The XBox project has been very effective in eliminating holes in the "trusted" computing hardware, thanks to the many volunteer hackers attacking it.
4. Hacking is cool.
   Currency security experts don't spend time on basement printing presses. They spend time on creating currency features that are expensive to reproduce on a small scale. End-user freedom is not an issue in the "trusted" computing paradigm. We simply want an airtight system that allows *only* Microsoft approved programs to execute, and a hardware enforced way to retroactively delete content when Microsoft makes a "mistake".

   We want to ensure that defeating the hardware interlock on our machines requires resources way beyond what an individual or small company can muster. It doesn't matter if organized crime or Chinese corporations have the resources. Their exploits give us justification to tighten the screws on our captive users.

5. Educating Users.
   One of the main real selling points of our software is that we aim it at users who don't know or care about computing. They just want to use some applications. If our users had any desire or aptitude to learn about security, they would have defected to that "competitor" that shall not be named. Once we succeed in legally banning un-"trusted" hardware, any talk of user "education" will be banished to dark alleyways.

   You say, "never let users install their own applications or plug-ins". Darn tootin. The whole point of "trusted" computing is to prevent users from installing their own applications or plug-ins. That is 99% of the security problem with Windows. If a user doesn't know whether to allow a TCP connection, they certainly have no idea whether some no-name (i.e. non-Microsoft) program is safe to install.

6. Action is better than Inaction.
   We have 100s of millions of machines running our software in the field. We have a nearly complete monopoly on desktop software. Knee-jerk actions are simply out of the question. The damage done by an insufficiently tested patch is far worse than the damage done by the nastiest malware - because our users will blame it on *us*. (The rebels blame the malware on us, but that is irrelevant.)

Neither stupid nor obvious

[Frater 219]

Actually, default deny is just as stupid as default allow, as if you have default deny, people just get sick of being asked if they want to allow something, and end up clicking "yes" on every box they see.

Default deny makes more sense when you think of it at the organizational level -- like a firewall. Both default deny and allow mean that you have to respond to new needs ... but default allow means you have to respond to new attacks (by blocking them) whereas default deny means you have to respond to new user needs (by allowing them). I've operated both sorts of firewalls -- and when you are in good communication with your user base, default deny is both more reliable and MUCH LESS WORK.

So you want to write a virus scanner that somehow can recognise viruses without being told which programs are viruses.

Ah ... you didn't read the article, did you? Every program that's running on your system that you didn't authorize to be there, is a problem. It doesn't matter if it's a "virus" or not, or if it's on Symantec's bad-guy list yet. Consider the following dialogue I had with a Windows technician:

Me: Windows host foo.example.org is cracked. It's portscanning out and trying to break into things. I've blocked it off the network.
Tech: I just ran an anti-virus scan on foo, and it didn't find anything. The user wants to get back to work; please put it back on the network.
Me: I didn't say it had a virus; I said it was scanning out and trying to break into things. It's still trying to scan out. I'm not going to put it back on the network.
Tech: Antivirus software says clean!
Me: snort says scanning out!
Tech: Antivirus software says clean!
Me: tcpdump says scanning out! Go get Clueful Tech to look at it.
Clueful Tech: Oh yeah, it's got all these processes called "fuck.exe" running. It's hosed. I'm reinstalling it.
Me: Thank you, Clueful Tech.

If you need antivirus software, your problem is not viruses -- it is that you don't have any control over what programs are getting to run on your computer. Get that control, and you don't need antivirus software.

So you are saying we should write code without bugs and holes? What a great idea that is? why did no-one think of saying that before?

Anyone who tells you that all software has bugs is being honest. Anyone who tells you that all software is equally buggy is trying to sell you Microsoft IIS. We can go a long way towards "code without bugs" just by observing the history of software and going with those options which have proven to need much less patching in the past.

We can also -- and more importantly, I think! -- favor software that is architected in such a way as to minimize security exposure. That means privilege separation and least privilege. Running your Web server as root is a brain-dead idea. It means not using more complicated software than you need -- if boa or publicfile serves your needs, don't use Apache.

You think people should learn how to stop hacking and intrusion without learning how existing hacks work?

It's interesting, but it isn't essential to the job. What you need to know is that attacks work by exploiting mistakes in the design and implementation of programs. What you need to know about buffer overflows, for instance, isn't how to exploit one for fun and profit -- but rather, that any C program that uses gets() is broken ... and that programs written in higher-level languages that have checked strings can't suffer from them.

There is a place that I've found that "hacking knowledge" is useful -- in demonstrating incontrovertibly that a problem exists. Joe Moron has a Windows-based embedded print server that's vulnerable

Locking down users

[slashflood]

I was working as an IT Manager for a mid-sized company for a while. The main problem with "locking down users" is, that nowadays there is no respect for IT Administrators anymore. Especially in small/mid-sized companies, where every single employee goes directly to his/her boss or even worse to the CEO just to complain about their "inability to work", because of the locked down computer. "The bad admin locked down the computer and I can't work anymore!". Sure, the PHB, CEO, HR won't understand the difference between user/admin rights.

I have a pretty strong personality and a thick skin, but after a while, I gave up. Even brand-new interns complained about the situation that they were not able to install their "favourite software" or about the blocked ports at the corporate firewall.

After a while, the HR manager came to me and said, that in four years, half of the employees complained about me. Whenever I tried to change something (firewall, user rights, ...), there were another ten or twenty complains.

All of the users are working as administrators on their computers at home - I know that, because most of them told me about the troubles they have with spyware and viruses, but they would never accept to have lower permissions at work. The common sense is, that the computer at work is actually theirs.

The same with company laptops. Everyone connects it at insecure networks at home, friends, hotel rooms, other companies and so on and after a business trip, you have to either reinstall the machine or remove spyware/malware.

It's just the lack of understanding, the habit to always work with admin rights at home and the lack of respect for the job of an IT administrator/manager.

Re:Locking down users

[slashflood]

power-tripping network Nazis

See? You're the best example. I/We am/are talking about account restrictions for average users (no admin access) in business environments and you're calling me "power tripping network Nazi". That's exactyl what I mean. At work, it's not your computer and not your responsibility when something really bad happens.

Just go on with your administrator account at home.

Re:Locking down users

[GlobalEcho]

I appreciate the difficulty of dealing with users installing lots of software, but I have experienced the "lockdown solution" in three different organizations (two of them very large), and feel it worked poorly for me in all of them.

Here's why:
(1) Response times. When I made a request for installation of, or permission to install, software needed for my work responsibilities, response times ranged from 45 minutes to a couple days. 45 minutes is little enough time to find something else to do in. A period of days is not. I have yet to encounter a tech desk that can reliably respond to even such a simple request in a timely manner, never losing it.

(2) Interconnections. Those times when I installed a piece of software were often followed shortly thereafter by the need to install some other, related (or substitute) program. That meant another delay of 45 minutes to a couple hours (or more). Chain a few of those along, and you easily waste a day or two.

(3) Questioning and denial. Large organizations have a list of "approved" software and biases toward denying the use of anything not on the list. For example, at one point I had a strong need to do some time series analysis. Appropriate tools for this include SAS, SPSS, Matlab....and GNU R. The first three, since they cost thousands of dollars, would have required cost review, tech review, et cetera. Installation for those types of packages took months. (I think that Matlab took about 3 1/2 months when we bought it). We needed results within a week or so, so R was the obvious choice. But of course, few sysadmins have (and none of ours had) heard of GNU R. Before we could get it installed we went through a long and frustrating round of "what is this?" and "why do you need it?" and "why can't you use X instead". Had the sysadmins just trusted that we had done our research, it would have been far less painful.

It doesn't take more than one or two such experiences for the users to develop a deep distaste for dealing with a lockdown.

Re:Locking down users

[Detritus]

What many IT admins forget is that their job is to facilitate the operations of the company, not to run the world's most secure network. You're damn right that I'm going to complain to management when I need X to do my job, and there's some pencil-neck geek in IT who, without a thought, always says "NO" to any request.

Re:Locking down users

[Anonymous Coward]

I have a job much like your job, I have to keep track of 100's of users and their PC's and make sure they are not infected with viruses and malware, babysit the network, firewall stuff, website maintenance .. blah blah blah... you know the drill.

I have to say ... sorry man but you ARE a network nazi. Sorry. Yea I understand the problem that PHB's and users do not understand the things you have to do, but, you sir, are being a lazy ass.

Before I was promoted to my current position they hired a guy like you. He went around and locked down everyone's PC. He initiated ridiculous policies and installed tyrannical "security" measures all over the place. It was an utter joke. Productivity went to Zero. People just stopped working. They couldn't get anything done.

People hated this guy with a passion that I can not begin to describe. The reason is that they were being treated like idiots by default by some guy who doesn't even begin to understand what it is that THEY need.

What's the point of having security measures so tight that not even the users can use the system? Security measures should be mostly transparent to the end users. Security does not mean cripple the system.

Anyway, eventually this guy become such a terror that he was let go and I took his job. I do what he didn't want to do: babysit the ugly monster. I keep things lax and make sure people have what they need to do their jobs. I talk with people every day and give them what they need to do their work. I get along famously with most of the staff. Nobody said it was supposed to be easy, or fun, but your job is to keep the system useable.

I don't understand the God complex some IT people have.

Re:No "default permit" for application launch in O

[Have Blue]

Actually, the permission-to-launch dialog does not protect against malicious applications disguised as documents. If you double-click an app it will launch without question. What the dialog box defends against is an automated exploit that involves sending an application and a document to a system and then a request that the document be opened, which would launch the app before this dialog was introduced.

The Four Dumbest Ideas in One Paragraph.

[Allistair]

I can't decide whether it's obvious or stupid. So, I've come up with my own arbitrary list of dumb ideas directly from the article.

On the surface of things, the idea of "Educating Users" seems less than dumb: education is always good. On the other hand, like "Penetrate and Patch" if it was going to work, it would have worked by now. There have been numerous interesting studies that indicate that a significant percentage of users will trade their password for a candy bar, and the Anna Kournikova worm showed us that nearly 1/2 of humanity will click on anything purporting to contain nude pictures of barely clothed females. If "Educating Users" is the strategy you plan to embark upon, you should expect to have to "patch" your users every week. That's dumb.

I disagree with much of this statement from the writer's "educating users" section. I'm not only for educating users but I am also a big proponent of educating writers.

1. Suggesting that "if it (educating users) was going to work, it would have worked by now" is dumb. This statement is a fallacy of bifurcation -- suggesting that there are only two possible outcomes. Either it works or it doesn't. Of course, this leaves out a very real third possibility: the writer is an addle-minded moron for creating this either/or "test" of effectiveness.
2. Stating that "There have been numerous interesting studies" but failing to cite any of them. I am not familiar with the candy bar studies but I wonder... Do any of these studies look at how many of the same users will trade their password for a candy bar if they have had some security training? And what is the age demographic being studied if candy bars are so appealing? Unless, of course, the candy in question is Snickers -- 'cause Snickers really satifies.
3. Stating that it will be necessary to "patch" users every week. It may not be necessary to "patch" your users every week if you make "Educating Users" part of a larger approach to your computer security program. Don't try to educate your users about everything. Instead, educate them about enough to make them good network citizens. Besides, if you are stripping off all attachments without educating your users, you will have successfully identified one of the "six dumbest things to do to the CEO's email."
4. Writing "nude pictures of barely clothed females." Come on! Are they nude? Are they barely clothed? That is really going to skew that 1/2 of humanity statistic.

they missed a big one...

[pohl]

...the idea that it is only the ubiquity of a system (not its design & implementation) that is the greatest determining factor behind the likelihood of exploit.

Joke?

[foreverdisillusioned]

Sugar coat it however you want, but using any version of Windows is by far the single largest security risk, period. Partially this is because Windows is the predominant desktop OS, but it is also because *nix is generally secure by design, whereas Windows is user friendly by design.

If you install Windows, you are making a conscious decision to open yourself up to a plethora of attacks that simply aren't possible on any other platform. Maybe the benefits outweigh the risks, but don't pretend that the risk isn't there or that it's some outdated joke.

Re:Joke?

[Kadin2048]

I really hate to sound like an Apple fanboy by asking this, but I do mean it as a serious question and not a troll.

Where does the Macintosh OS fit in to your scheme of things? By all measurements it seems to have been built with user friendliness in mind, however it's also generally regarded as being pretty secure by design also.

Is it secure *only* because it's less popular than Windows? I.e., if it had Windows' marketshare, would it be regarded as insecure? Call me biased, but somehow I don't think it would.

User friendliness versus security is not necessarily a one-to-one tradeoff. It's possible to have something of both, although perhaps at the expense of some third quality (speed, or efficiency perhaps?).

Anyway, I'm not disagreeing with you outright as much as I'm just wondering where some other operating systems fit in on your continuum, if Windows is "user friendly" but insecure and *nix is "secure by design" but not user friendly.

Re:Joke?

[pembo13]

I think he meant Mac as part of *nix

Re:Joke?

[BrainInAJar]

Is your mac default user root or a root-like entity?

If so, then it's *not* secure by design, it's secure because of market share. The single biggest security problem with desktop windows is having system administrator be the default user

Re:Joke?

[extrasolar]

Do you have an argument there?

"Partially this is because Windows is the predominant desktop OS, but it is also because *nix is generally secure by design, whereas Windows is user friendly by design."

Why do I get the feeling that the basis for your belief here is simply because you have to type in a password before you can boot into your Linux system?

I think there's way too much complacency among Linux and Mac advocates. As far as I'm concerned, they are both Katrinas waiting to happen. Neither of these systems are very popular, but because of the rampant advocacy, fans of both systems come up with this fallacious assumption that just because Macs and Linux systems are almost never get hit by viruses or other forms of attacks, that they must be more secure by design. No! No! No! And if I was a manager for a small to large business, I'd prepare for such attacks *before* they happen and ignore all of this fanboy buzz.

Re:Joke?

[Kadin2048]

No, at least not by my definition.

On a standard Mac OS X box (not sure about Server), the root user isn't even enabled by default. You need to go pretty deep into the preferences in order to enable it.

The first user you create during the install process is an "Administrator," which means you can 'sudo -s' on the commandline and become root temporarily, but only by re-authenticating. I'm not sure if that meets your criteria for 'root-like entity,' but it seems a pretty good compromise to me.

Anything you run through the GUI (and anything you run through the CLI unless you specifically sudo and become root) executes as a non-root user. So email attachments, etc., cannot execute as root unless the user takes the very unlikely steps of enabling the root user, and then logging in as it.

There were a few privilege escalation bugs in past versions of the OS which allowed an Administrator to become root without properly authenticating again after login, but they were in early versions and I haven't heard of any recently.

Re:Joke?

[ltbarcly]

No. And it isn't possible to set an account up like this.

Macs have 'administrator' accounts which are actually just members of a 'wheel' like group for sudoing. There is a 'root' account on OSX, which you can't even log into by default. You can set a password for it by doing a 'sudo -s' and then 'passwd'. This account can't be logged into in the GUI, merely on the command line. The vast majority of users will not use this functionality.

Whenever a program needs rootlike privileges to install software (which is rare, as macs use app-folders) or to do system maintenance, they OS requires you to actually type in your password. This is the 'wheel' like functionality.

This security model is more secure than having only 'root' and 'user' accounts, which is why many Linux distributions, like Ubuntu, now default to this exact behavior.

So in OSX anyway, there is NO user account with root or root-like privileges.

Re:Joke?

[MikeFM]

I think most of the points in the article can be used to point out why Windows is insecure starting with the big #1 of default permit. Default permit makes things easy for users because it doesn't require they know anything about what they are doing or to configure anything. The approach has the major downside though of making it equally easy to infect, hack, and otherwise mangle the system. Microsoft is really in a bind with this one ebcause even though they've figured out that this apprach is a really bad idea there isn't much they can do about it without damaging the percieved user-friendlyness of Windows and Microsoft software. THEY trained users to think this way and now they either have to just live with the way these users think or they have to take the risk of retraining users. Before Mac OS and Windows most users expected to need to know things to run the computer and they simply just did it. Now that is largely no longer true even of the same users.

Enumerating badness.. virus scanners and default permit firewalls.. these damn things are the bane of Windows. Instead of blocking unknowns or at least asking for permission Windows and Windows apps tend to rely on blacklists to tell them what is unsafe. With thousands of apps being released daily and probably thousands of hacks too that is a pretty tall order. IMO greylisting unknowns while blacklisting known threats is a good solution. That way the user can't easily screw up and allow through known threats and they're prompted before allowing possible threats through.

Penetrating and Patching is mostly only a problem in Windows because Microsoft and other companies release beta (or less) quality software as final releases and use paying customers to do the testing. Any program can have flaws and it is wise to test them and patch them. Sometimes those flaws are small errors in an otherwise good design and a patch will fix them. Other times those flaws are huge design errors that require whole features or even applications to be rewritten and then patching is useless. Either way it isn't a problem except when you've sold the broken useless crap to some unsuspecting consumer before doing the testing.

Hacking is cool. The guy is an idiot on this point. Knowing your enemy is a good lesson in security. So is knowing your own weaknesses. You learn those things by first copying your enemy and then by stepping ahead to guess what your enemy may do next. You're not a real engineer if you don't understand ways in which your creations can go wrong either by bad luck or by ill intent.

Educating users is a must. That doesn't mean you need to educate users on every single threat. It means that you don't dumb users down in the MacOS/Windows way and that you teach them basics of what is expected and unexpected behavior of their computer.

Inaction is cheaper than action but action can be a better defense so long as you're willing to keep changing as you find out more. Microsoft often takes the route of inaction which is cheaper. They wait to see what happens, again using customers as test subjects, and then buy or copy the strongest response. This has lead them to bad designs in general though. If they'd taken action they could have designed better software to begin with. They can afford to make early actions in defense of their customers so there is no excuse for them not to. On the other hand the customers may not have that kind of money so for them inactivity can be a better idea.. or would be if Microsoft was doing it's job.

Overall, Microsoft has again and again proved itself asleep at the wheel when it comes to security (and most other things). Fortunately they are starting to take action finally as they finally reached the point when customers were looking at better options. Smoke and mirrors works for a while (sometimes a long while) but eventually people get tired of always being victims. This is the situation Microsoft has put itself into and one that most other software venders are close to. With the industry maturing and customers becoming more savvy they'll finally have to start paying attention to these things. Five years ago customers thought I was weird for mentioning the security of the systems the were using. Now they ask about it. BIG DIFFERENCE.

Re:Joke?

[JesseMcDonald]

That would be more practical if users could create their own limited UIDs. As it is, the system adminitrator would have to manage a number of limited, e-mail-only UIDs (one for each user), or enable some kind of sudo or "run as" procedure (without authentication) with a common UID. Either way, there are still system services that could not be protected in this manner, and the mechanism would be system-specific and thus difficult to design into an e-mail client. A chroot-jail design would at least protect the user's files, but requires root priviledges to work.

One way of "jailing" attachments would be to run them inside a User-Mode Linux process, with no access real network devices or the host filesystem. AFAIK, that would prevent the attachment from altering the system in any way, and could be automated without access to the root account. Of course, this is not all that different from limiting (executable) attachments to Java programs and running them within a limited JVM...

Re:Joke?

[irc.goatse.cx troll]

Why would it need to modify /etc/rc.d/rc.local? Why cant it just modify ~/.bashrc, ~/.login, ~/.profile, ~/.bashlogin, ~/.xinitrc, ~/.startkde, or any of the many other badly docced autoinit scripts for the user?

Re:Joke?

[Fred_A]

Shouldn't MS force better practices on developpers rather than users ?

If software actually ran on unpriviledged accounts, you could then start educating users. Until that hapens it's hopeless.

Re:Joke?

[tengwar]

Yes. And I wish people would realise this!

You don't get a root login by default, but any user in the admin group has rw privileges in the Applications directory. If, for the sake of argument, you replace some common application such as the Safari web browser with a trojan subsitute, can either run with the privs of any user who starts it. If you replace an app which normally requests authentication to run as root, you can get full privileges by getting the user to enter their password exactly as they are expecting to do. Although the default user is not the Unix root, this hole means that there is little difference between the security of Windows and Mac.

There is an easy fix: create an account which has admin privileges, then remove these privileges from your normal account. This works almost as easily as the default installation. For a few operations (such as dragging an app into the Applications folder) you will be asked for the user name and password of an administrator, and for these you supply the details of the new admin account that you created. There really is no other down-side that I've come across in running MacOSX like this (unlike using a non-admin user in Windows).

Only for Documents that Launch Applications

[dfm3]

Try OSX. As of some update about a year ago, OSX stopped having "default permit" for launching applications by double-clicking. If you double-click and that leads to launching an executable that hasn't been run before, it pops up a dialog to ask you about it.

Actually, this will not stop you from launching an application (that is, an executable) by clicking on the application icon, it only prevents documents from opening applications that you have never run before. Say you double click what you think is a .jpg file expecting it to open in Preview, but another application is launched instead. You'll get a message that reads, "You are opening the application 'mysterious suspicious program' for the first time. Are you sure you want to open this application? ....to see the application in the Finder without opening it, click Show Application."

You can open the application by clicking it directly, and it will run without first presenting you with any warning. If I remember correctly, this was introduced by Apple to prevent users from inadvertently launching new (possibly malicious) applications that had somehow tricked the OS into associating certain file extensions with them. However, it's useless if you open a "document" that is actually an executable in disguise, as these will run without prompting you.

One more thing

[einhverfr]

You do realize that you can do essentially everything you are suggesting with SE-Linux without the overhead of maintaining a whitelist. This basically means turning the computer into an appliance.

Now in this case, with SE-Linux, you can even specify what files a given application can load. This can be used to limit scripting languages to known good scripts, or to prevent confidentail information from being sent via email.

The SE-Linux information is stored in the inode, so it is specified by the administrator at file creation time or inherits properties according to policies. This avoids the issues you see with trying to maintain a whitelist of hashes and apps.


The point is that the user cannot be given something like the pointless SSL certificate browser warnings that allow a user to click "I don't care, let me in anyway". Default Deny, not Default No.

And if someone in AR forgets to pay Thawte for your SSL cert and it expires for a critical server (say internal app for credit card processing), users will be locked out. Cute. I am a firm believer in manual override capabilities. That will never happen, you say. All I have to say is domain name registration exiration for Hotmail....

Here is the problem. People think of security in a vacuum. Real security is a piece of a larger availability/security/usability problem. You have to tackle all three at once and ensure that one does not preclude the others within reasonable parameters.

Well said

[X.25]

Really good points.

I worked in "security research" field for 10 years. I loved it.

Then companies got involved, certifications/courses/books appeared, pentesting became a business...

I moved to another field, for the very reasons MJR explained in his editorial.

Everyone wanted to be "secure", but noone wanted to invest time or brains in order to achieve that goal.

In 4 years of pentesting (and I'm talking about BIG players and companies with bright people, big budgets), I have only ONCE seen a company that actually took SERIOUS measures in order to improve its' security. I'm not talking about adding another layer of firewalls or installing new toys, but actually redesigning their security infrastructure/thinking.

All the others wanted signed paper which says "You are secure now".

I ended up pointing all of them to MJR's Ultimate Firewall

Whose ideas are the dumb ones?

[Ichoran]

The author may be right that the things he listed are dumb ideas for mission-critical ultra-secure systems. However, he seems to be advocating the five dumbest ideas for usable systems.

The price of Default Deny is loss of flexibility. If it is easy to avoid denial (e.g. automatic addition to a whitelist), it's just Default Permit by another name. If it's really hard, it will keep you from doing everything except that which you already know you want to do--in other words, nothing new, nothing clever, just the same stuff over and over. This would turn computers into the equivalent of a stereo system. They do thsoe narrowly-defined tasks that they were engineered to do, and nothing else.

People are going to occasionally want to do something new. When they do, there are certain things that they almost certainly *don't* want to do. Thus, you enumerate badness to help protect them when they want to use their computer as a flexible general-purpose device.

It's better to have systems that are secure by design. Duh. The point is, though, that even systems that are secure by design are likely to have flaws. If you look for flaws, and fix them, then you have a chance of staying ahead of other people who are looking for flaws to exploit them.

The coolness of hacking has nothing to do with security. Hacking is cool because it demonstrates our ability to manipulate our environment, to do things that are supposed to be impossible through ingenuity. In a factory of mindless corporate drones, hacking is not cool. But if you live in the real world where programs have flaws, there is even a security use for people who enjoy finding ways to use the flaws to accomplish things that the creators didn't intend.

Educating users is ridiculous--his point is that users should't be educated because they should be educated before you hire them. Okay, and how did *they* get educated? What happens if you have to hire real people who are talented but they haven't all gone to this magical security training school? His point *should* have been that there are only some things that can be taught, and that you shouldn't assume you can teach completely counterintuitive behavior. But you might be able to teach someone enough to avoid clicking on strange attachments without deleting photos in .PNG format sent to them by family (where .PNG was not a whitelisted attachment, nor was email from a random gmail account).

I don't want a secure, useless system. I want a secure, *useful* system. And that means compromises need to be made between security and usability. Reading this article gives very little clue as to how to construct a good balance.

You bet!

[shis-ka-bob]

I did remove all of my anti-virus software and move to code with many fewer vulnerabilities. Is it perfectly secure? No, but it is closer than any other OS I can use. All I can say is 'Thanks Theo'. Running OpenBSD does have costs for me, since its harder to access some multimedia and java applets and I am running slightly older packages than I would if I was running FreeBSD, or many Linux distros.

I also stopped using condoms, since I limit my activities to my wife. I'm also free from those sorts of infections because I was fortunate in my choice of a partner. This also has a cost, I'm sure that sex with other partners could be enjoyable. I also know that the 'zipperless f*ck' is more common in fiction that in my world, so I'm willing to stick with my spouse.

I know you are being tongue in cheek, but there is an error in thinking if you cure the symptom rather than the root cause. If you can't trust your partners to be safe, why don't you consider finding safe partners? In this regard, Microsoft is like the town *****. If you can't trust your partners, or if you are unwilling to live with some restrictions, by all means install antivirus software and use a condom.

Educating users...

[Skreems]

While I agree with some of his other points, I think it's really dangerous to just give up on the idea of educating users. In the long run, no matter how secure you make the rest of your system, the user is always going to be a potential weak point -- they can disable or work around your carefully implemented "perfect security" because they NEED this ability to be able to use the system. On home systems, for example, even if you go with a white list, default deny policy, the user still has to be able to add new programs. Watch them download x fancy new shareware game, give it execute and net access permissions, and totally screw your entire careful security setup.

To make a point using the author's own analogy... while flying on an airplane, it's basically common knowledge that you don't want to walk up to the door and pull the big silver lever. Bad things happen if you do. However, if the plane has crashed and you need to get out, that's exactly the action you want to take. We don't have fire sensors that only enable the handles if the plane cabin exceeds a certain temperature... we rely on user education to make people only use this option at the right time.

Even the author's own solution, of scraping off all email attachments and saving them via url doesn't help. If someone sends out a virus, and it gets saved to a remote server, the user can still copy it to their system and run it. But if the user is educated about the kinds of thing that can happen when they do this, and about the dangers of running software from unknown or even partially untrusted sources...

Re:Educating users...

[Alioth]

On a point of pedantry, if you did try and move the big silver lever in flight, you wouldn't be able to open the door anyway. Airliners generally use plug type doors. To find out the force required to open one in flight, take the surface area of the door, multiply by the pressure differential (say, 8 psi) and work out how many tons of force the puny human trying to open it would require.

Re:Zone Alarm

[Elminst]

A gret program yes... but (L)users don't want to be bothered to THINK about anything.

They won't read the box that comes up. they'll mindlessly click "Allow" even if the message said "This program would like to kill your wife and rape your dog. Would you like to allow it?"**

Whatever it takes so they can get on teh intarweb!!1

**Just like not reading EULA's. A while back company (don't remember who) made a EULA that actually said you get money if you call them. Several THOUSAND people installed the program before one guy actually called.

Re:Here it comes...

[gui_tarzan2000]

"On the other hand, TFA seems to be saying that you shouldn't write flawed software. That's pretty much impossible when working on a large project."

I don't disagree while the program is in developement, but there comes a time when the code should be bug free. Humans make mistakes, but they also need to correct them. Sloppy code is not acceptable.

What!?

[red990033]

I'm confused by the title. Is this meant to be *dumb* ideas, or a dumb *list* of ideas? "Hacking is cool" and "Educating Users"?

WTF!

And where the hell is "Security by obscurity" on that list?

The #1 dumbest idea in computer security?

[BoneFlower]

The idea that security is about technology.

It isn't. Sure, certain engineering and design principles can help security a great deal, but when it comes down to it, security is about the human brain. If you don't run the system intelligently, it doesn't matter how well designed it is, or how well the design is implemented. You will get p0wned.

I'd trust an all Windows 98 network without a firewall, run by someone who knows what they are doing, over an OpenBSD network locked down against everything run by my mom.

Re:Here it comes...

[Tassach]

On the other hand, TFA seems to be saying that you shouldn't write flawed software. That's pretty much impossible when working on a large project.

I disagree. It is possible to write secure software -- TFA uses postfix as an example of a program that was designed from the outset to be secure. It's entirely a matter of mindset and discipline. If you approach a programming project with the attitude that you and your programmers are fallable and will write flawed code, and design your system from the outset to contain the damage that will result WHEN (not IF) a component fails, you will write good reliable secure software. A good example this is Google. Google's system was designed to work on dirt-cheap commidity hardware with little to no redundancy at the server level. Having a box die is a routine event; they actually EXPECT a given number of boxes to die on any given day. The entire architecture is designed around the premise that any box can fail at any time, so it is designed so that the overall system will keep on working even after multiple failures. The problem is that most pointy-haired bosses are not willing to invest in the up-front engineering expenses it takes to come up with a secure design -- they want to get something that solves the immediate problem done in the least amount of time for the least amount of money, and then refine it over time. In other words, they want you to hurry up and pinch off a turd, and then spend the next 10 years polishing it. Programmers are not without blame either. Programmers are generally natural optimists -- they have a natural tendancy to assume that their code will work perfectly, even after years of experience have demonstrated that this is not true. It takes a constant, concious effort to remind yourself that your code WILL fail at some point. It takes discipline to consistantly design systems that will compensate for your human limitations. Unfortunately, most managers tend to encourage programmers' optimisim rather than forcing them to take a more pessimistic approach.

uneducationable users

[Jessta]

Uneducationable users will always be the main security problem with computer systems.
I find it hard to believe that users still run random attachments to emails.
After 10 years people are still doing it.

You can't just remove all attachments from emails, so what should one do about it?

Software is not here to make up for the stupidity of people, it's here to help them utilises their intelligents. If you're not intelligent enough not to run random attachments to your emails, then you probaly won't find a computer very useful.
- Jesse McNelis

Re:sigh

[pinko-rat-bastard]

Yes MS OSs have issues with viruses and other security holes but if the MAC OS or *nix was the huge commonly used OS it would have the same problems so please get of the MS bashing bandwagon.

You know, I've heard this hogwash from the MS camp many times, so let's just examine it for a minute, shall we?

Usually when someone drags out this tired old argument, they are referring to the number of *desktop* machines. I'll grant that the vast majority of desktops run Windows. Anyone would be a fool to argue otherwise. However, what value do these machines represent to the cracker other than spam & DDOS zombies? Why would anyone want to crack Joe Sixpack's PC to steal one credit card number when there are commercial sites out there with thousands of accounts? I'll tell you why: Because it's too hard for the average script kiddie to do. Consider this:

According to Netcraft, Apache runs aproximately 70% of all web sites. This number has been fairly consistant for several years, so we will assume the number is reasonably accurate. Next, if we look here we see that without exception, ALL of the Apache sites holding the top uptimes are running on some flavor of Unix -- mostly *BSD with a few running Solaris or Linux. IIS obviously only runs on Windows and the table (at least at the time of this writing) has only a single Windows site in the top 50. Personally, I believe that the majority of sites that run Apache also run *nix, but to make the MS crowd happy lets assume the whole web is 50/50 -- half *nix and half Windows. According to Netcraft's September 2005 survey, the web currently has something like 71,723,098 web sites. Using our assumed 50/50 ratio, that means that there are over 35,000,000 *nix machines hooked up to the Internet and serving up web pages. Now, you expect me to believe that 35,000,000 machines isn't a large enough target to attract the virus & worm writers? Especially since a great many of those machines are big, fat jucy businesses targets? I don't think so.

The simple truth, whether or not *you* are too ignorant/cocky/stuborn to admit, is that Windows is targeted not because it's so ubiquitous, but because it's so easy to crack.

Re:OK.

[Sancho]

Agreed.

Further, points 1 and 2 are essentially the same things, just reworded.

Point 4 is somewhat mistitled. I do think learning the basics of how exploits work is important to creating sturdier code. Otherwise, you'd just write stuff that's vulnerable to buffer overflow constantly.

Point 5... Where do I begin? The problem is NOT self-correcting. I work for a university, and every year we get students asking us how some bank got their university e-mail address and "Should I respond to them?" For every one that does that, probably 10 actually respond. He also seems to think that there is a technical solution to "attachments and phishing" but never explains the technical solution to phishing. Presumably it is to only allow e-mails from a whitelist, given his default-deny ideas. Well frankly, that isn't going to work for most people.

Point 6 I agree with to an extent. The problem comes when everyone adopts this strategy--no innovation actually gets implemented! Also, technologies that are developed to fill a need often cannot be "waited on" in the manner that he describes. Also, on the patch-level, this may not be workable either. If you have a critical vulnerability, you can't afford to wait until everyone else has tried the patch. You definitely want to test it before deploying it, but that's along a different line of thought.

Overall, some interesting ideas, but as you say, many aren't really security ideas. They're SOP for lots of companies, though.

"skip the testing, it looks fine"

[Anonymous Luddite]

>> Humans make mistakes, but they also need to correct them. Sloppy code is not acceptable.

Have you ever written code for idiots?

When I'm creating software I have to hide my work in progress from management. By that I mean, show them chunks only. I can never let them see something that looks like an operational product till its' been up and running and tested six ways from Sunday, because if they see a working prototype, they'll try to force me to roll it out as productive immediately. Telling them it's "not done" doesn't work either - I've come it to work and found a demo project distributed as productive. I mean wtf? - Some PHBs just don't get it at all. You tell them its' running against a test database, needs 3 more weeks work and bang, its' out the door. - It's not on fire right now so it must be done, right?

In those circumstances, I don't really give a sh*t if it fails and costs them money, except the blame (and 3 am phone calls) fall to the team that wrote it.

You're %100 right, there is no exuse for buggy code, but there is tonnes of it out there, being used productively that was never really finished. Sometimes it's got less to do with the lazy developers than managers who don't listen.

Re: "skip the testing, it looks fine"

[seabasstin]

I am so with you!
I worked on an IM project where the demo showed the send process of the IM transaction.

The business manager saw this and in his ecstasy of being able to launch early said put it on the production server ASAP, the production manager panicked and told him we needed a week to tie loose ends; and then told us we needed to get done the project done a month ahead of schedule because she couldn't get herself to remind the business manager that IM is 2-way communication process.
So when we didn't make it, and it was declared OUR failure (the production team) and we didn't really care since being creatives in our heart of hearts we knew that it was only because of business for being STUPID.

Re: "skip the testing, it looks fine"

[JediTrainer]

if they see a working prototype, they'll try to force me to roll it out as productive immediately

You think that's bad? I've had project managers try to do that to me when they saw a Powerpoint mockup of a new app!

Why M. Ranum is an idiot

[russotto]

#2: Enumerating goodness.

Guess what. You've just pretty much gone back to the dark ages. Everyone has a set of programs installed on their computer by the priesthood, and that's all they can run. Might do something about viruses. Definitely reduces the utility of the machines.

#3: Hacking worthless
Holding your adversary's skills in contempt is generally not a good idea. Refusing to learn them is just plain stupid. And, of course, hacking (even the black-hat sort the PC prefer to call "cracking) isn't what he says it is. Learn a particular exploit? Any script kiddie can do that. Figuring out how to identify holes and develop exploits, that's another thing entirely, and as useful for a security professional as lock-bypassing is for Medeco.

#6: Sit on your duff and let the other guy take the lumps.

Sure, you CAN do that. But there's reward as well as risk in adopting the new stuff. And consider that if everyone took that strategy, progress would be entirely stifled. His IT exec who waited two years to put in wireless may have saved money -- but he also had two years without wireless, which may have cost him more.

Re:Why M. Ranum is an idiot

[Alioth]

On enumerating goodness, in a corporate environment, that's exactly what you want: you don't want everyone to use their computer as a general do everything tool - you want them to use their computer to do the job they are supposed to do. They don't need Comet Cursor or Kazaa to do that.

Of course, then there's the developers who (should) know what they are up to, and will need to be able to install things without having to go through the IT department for every scripting tool they need to get their job done. So you put those guys on a separate network segment, firewalled off from the rest of the office workers - so if a developer manages to clobber the network, they don't clobber the entire company.

Re:Real security has to be build into the foundati

[glens]

Not that it hasn't been mentioned already, but here's an example from slackware 10:

$ mount | grep /tmp/hdb9
/dev/hdg9 on /tmp/hdb9 type ext2 (ro,noexec)
$ pwd
/tmp/hdb9/bin
$ ./hostname
bash: ./hostname: Permission denied
$ /lib/ld-linux.so.2 ./hostname
./hostname: error while loading shared libraries: ./hostname: failed to map segment from shared object: Operation not permitted
$ ls -l /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 11 May 16 2004 /lib/ld-linux.so.2 -> ld-2.3.1.so
$ ls -l /lib/ld-2.3.1.so
-rwxr-xr-x 1 root root 672140 Mar 5 2003 /lib/ld-2.3.1.so
$ uname -r
2.4.26

MOD PARENT UP

[CaptainPinko]

That is really a point worth considering. There are many Dilbert cartoons that use it as a punchline but I never paused to think that that ALL security have a negative productivity aspect (not necessarily net negative, but there is always something negative) to them. Perhaps a standard part of any security procedure should be to list negative aspects because I think people are too idealistic as with "Hey! Lets change passwords everyday!"

Weird mixture of stupid and trivial

[BobaFett]

The first point is entirely on the money. At least 10 years too late, but totally accurate.

The second is just too overreaching: would you like a computer which can run 30 programs from a master list and nothing else? There are many cases where "enumerating goodness" is exactly the right thing to do, and - guess what - that's exactly how such cases are done, for example, sudo.

The rest of the article is basically boils down to this: if you don't want your system to be hacked, don't make it hackable. Sure thing. Don't debug your programs, just write them correctly. Don't install airbags into cars, just avoid crashes. Stupid us, doing all the precautions and safety things for years. Just don't make mistakes, see how easy it is?

Late but...

[burns210]

So this is way late to the thread, but I will mention it anyway.

This guy has a couple good 'no duh' points and several really stupid ones. Let me elaborate:

#1) Default Permit

This I agree with, in the case of firewalls in a corporate environment, where the input/output can be predetermined and controlled. Everything should be blocked except for the handful of things that need to get through.

#2) Enumerating Badness

This idea BLOWS for desktop applications, which is what he advocates. Why is it bad? Because while he only has "30"-or so applications he uses, as most people do, those 30 are different for most users. You can't enumerate all legit software, it can't be done. You can enumerate most of it. But then you get to a list comparable to 70,000 virus signatures you are trying to leave behind. Besides, if I write my own application, my anti-virus software would need an accurate, detailed signature of what the application looks and acts like to be able to identify and allow it... Something I cannot reasonably do. Which is why we have companies creates the signatures, for the (comparably) finite number of viruses and trojans. Default Deny on a desktop, especially personal ones, is a broken, unmaintainable, BAD idea.

Even in a corporate environment, which has more home-grown apps, you would need custom signatures for each internal app to function. Something not practical for an IT department to create. The idea just doesn't hold on a PC.

#3) Penetrate and Patch

His argument: if you had designed it securely, you wouldn't need to pentest it.

Ok, but how do you know your implementation was complete to the design, or that your design didn't have a hole in it? Well, you have to test it... pentest it, that is.

Yes, it is a great idea to securely design your apps, with secure-by-design principles. Afterwards, you STILL need to test it in a live environment to ensure you didn't forget or miss any steps. That is only a logical step. Pentesting even the most secure of networks is critical, to be able to PROVE they are secure. You can't just say 'because I said it was!' and expect that to fly.

#5) Educating Users

He contradicts himself. He says that you shouldn't have to educate users because they should already be educated... Which is a chicken/egg problem he never admits to. You should do both: hire competent, smart people, AND train them in the policies and guidelines of their environment.

A Fundamental Linux Security Flaw

[tjstork]

The way that you get software onto Linux, the very nature of open source, is a trojan horse disaster waiting to happen.

With Linux, installation is endless. How I so wish that I could just get one fricking package from online for KDevelop or any other tool I use and run one installation process.

Instead I have dependency hell.

KDevelop wants a package called Graphviz, something called Arts (the SUSE version isn't good enough), a new kind of source control system. I have to go to fifty different web sites that I find by Googling just to try and figure out what to get?

This is fraught with danger.

If I'm a hacker, I wouldn't even bother trying to find a buffer overrun somewhere, I would just put up a legitimate looking web site claiming I have a binary for something like CVS or RPM or any of the myriad packages that Linux uses, stuff my own code in it, and wait. Some Linux nooby would download it, run the rpm as root, and I'm in.

Source code devotees stay silent. I could probably put a tarball out there with rm -rf / in the middle of a makefile somewhere and no one would notice. Hell, I could just delete one file. .. what is all this make install gnu auto configu stuff?

Stupid stuff in RPMs would be useful.

a) the package should specify whether it requires root permissions

b) packages should have a list of certified sites for their dependencies. OR, there should be an https repository for ALL packages.

Until you eliminate people googling for dependent packages to be run as root, Linux is just as unsafe as Windows, if not more unsafe.

Re:A Fundamental Linux Security Flaw

[sbryant]

b) packages should have a list of certified sites for their dependencies. OR, there should be an https repository for ALL packages.

You appear to be using SuSE, yet you say you have to go hunting around for packages. This doesn't make sense.

If you use YaST to install packages, you can do so from one of the official mirrors. These contain all of the dependencies, so you don't need to go hunting. I've got the latest KDevelop, and everything it needed was installed automatically, so I'm wondering what on earth you did to have problems. The machine here has KDevelop 3.2.2 on KDE 3.4.2b, all installed via YaST with SuSE's own packages, and no googling for anything.

Furthermore, SuSE do appear to sign their packages. I'm not sure when this is checked though, so it may or may not be OK to rely on that. Using https for transfers won't really change anything; it wouyld stop eavesdroppers, but I don't think anyone is interested on eavesdropping on transfers of publicly available packages.

Your point is otherwise valid, and installing random packages from random/untrusted locations is an accident waiting to happen. Major distributions, however, do take steps to ensure that their packages are safe. Any distribution which provides a package which is dependent on an external package (ie: not provided by that distribution) is providing you with a bug, and it should be reported as such.

-- Steve

WinAmp crashes

[Scyt2]

I have never, ever seen a student running in a non-administrator account on their Windows PC

As even very common applications as WinAmp don't work without adminitrator privileges I find that very comprehensible. WinAmp crashes in a weird way without administrator privileges. I my opinion Windows XP is not ready for desktop use. E.g. you need to be Administrator to open the calendar.

Patching not working..

[mortrek]

While I admit, designing a system from the ground up to be secure is important, it's really quite hard to expect most software companies to do that. However, I don't feel that the patching game is all that worthless. If a product was totally static, then yes, it would eventually have most of its flaws patched, or so one would expect. However, products are changed, overhauled, and often completely rewritten. This always seems to introduce a lot of new security flaws. If Microsoft simply stopped adding so many 'useful' new features to their software, and concentrated on locking down their software, it would probably be much more secure. However, they are driven to 'innovate', and we end up with features like system restore, which can actually make it so you can't delete some worms... Also, a 'complicated' program does not have to be a 'bloated' program. I remember the good old days when Opera would add functionality and *reduce* the binary size & memory usage.

Other ways...

[featheredfrog]

There is at least one other way to improve security...

http://www.comics.com/comics/dilbert/archive/image s/dilbert2813960050912.gif

Re:measurements?

[Fred_A]

Well, for what it's worth, I just did a measurement of my Mac OS desktop which is 24.7 cm wide while my KDE desktop is 40.5 cm.
This was done with the time tested scientific method of sticking a ruler on the screen.

I'll let you interpret the result however you see fit.

Lost credibility on the chart/graph

[BlueMonk]

This article lost most of its credibility when I saw that his graph for enumerating badness came from the "department of vague pseudo-scientific statistics". Humorous though it may be, I don't think people should be making up charts to illustrate their "data" when there aren't real numbers to back it up. It's worse than providing 6 significant digits in a measurement for which you only measured two, in my opinion. It makes me doubt that any research or real data went into any of the rest of this article, and suspect that it's just one guy's opinion.

Re:Fair point

[jc42]

Actually, I think the basic problem is more complex than users execing files unpacked from a tar or zip file. The major reason for so many "accidental" execution of outside software on Windows systems is that many Windows programs execute things without the user being aware that this is happening. The most obvious culprits are mail GUIs, where you "open" an attachment by merely clicking on its icon. There's nothing in the word "open" that implies executing a program, but if the attachment is labelled as executable, that's what happens. So the user may know better than to execute a strange program, but they think they're just opening (i.e., viewing) a document.

This problem did pop up in unix software in the early 80's. Several mail readers (usually also editors) got a new "feature" of being able to automatically execute scripts embedded in messages. The user communities' reactions to this were immediate: They understood right off the danger, and insisted very loudly that this misfeature would be fixed right now. Companies found their sales on hold until this serious security breach was fixed. The problem was fixed in weeks, and whenever someone reintroduces such clever features, the same sort of blowup occurs until the vendor understands and repairs the damage.

The Windows user community is a different culture. They have accepted such misfeatures, because they don't understand the problem. Microsoft sees no reason to fix such problems, because few users are objecting (and it's not Microsoft's problem ;-). Usually such features are controlled by an on/off option setting, but the default is "on", because that's more powerful and convenient for users.

It really does come down to ignorant vs. knowledgeable users, of course. Unix users tend to know a lot more about their computers than Windows users do. No surprise there; we've always had that divide in the computer field. But I wouldn't call Windows users "stupid". Many of them are quite smart - in some other subject areas. The word is "ignorant", and we're all ignorant in most subject areas. There simply isn't time to become knowledgeable in all subjects.

You don't have a spare college degree you don't need, do you?

Y'know, I've often wondered about that. I've never used my high-school degree or my B.A. (math) from college. Nobody ever asks you about any degree except the highest one. The rest are sitting there unused. So why not sell them to someone who needs one? I'd think that the "market" people, from whom we hear a lot these days, would strongly approve of this.

OTOH, I suppose one could argue that this is "Intellectual Property", and as such, there's a strong move afoot to outlaw resale of all IP items. The recording industry doesn't want you to be able to resell your old recordings. The movie industry is getting the same idea. Microsoft's EULA alread outlaws resale of the software that you bought with your computer, so if you donate your computer to charity, the license for the software doesn't go along with it, and your charity org has to pay for the software again. Similarly, you can't resell old degrees that you're no longer using.

So why shouldn't all of these be resellable on the Open Market? ;-)

Re:Here it comes...

[Tassach]

You fail reading comprehension.

Postfix was designed so that failures are compartmentalized. No one ever said it was immune from failure -- just that the damage from an eventual failure would be contained.

The article you cite shows a bug which allowed a LOCAL USER to delete other people's mail. While this is indeed a flaw, the damage is completely contained to the mail system -- it is not remotely exploitable, does not allow privilige escalation, does not compromise root, and is trivially solved by not granting users shell accounts on the mail server.

Compare this bug to the numerous Sendmail bugs which allowed a REMOTE user to gain ROOT priviliges on the box. There is a HUGE difference in severity between a limited local denial of service attack and a remote root exploit.

Congradulations on proving the point you were trying to refute.

Guy needs a clue

[ebvwfbw]

Great premise but manages to mess it up. For example:

Deny by default. Depends on the situation. For a firewall that is a great idea. For executables it is a dumb idea. I think he has no clue just how many executable programs he uses. It isn't the 8 or 9 he cites. Linux for example has thousands of programs that most people never see - cat, cut, paste, grep, join, link, etc. Get rid of those problems and see if you can even boot. Even for programs that he does run - like an internet browser, not running remote executable code limits his ability to do much. Lots of javascript, java, and so on.

Enumerating baddness? WTH is he talking about? Nobody I knows enumerates baddness except idiots and companies trying to tell you how good they are.

Penetrate and patch: Still a good idea and this fits into his first suggestion - get rid of executables that you don't need. So he is contradicting himself. How do you know if something is running unless you do a penetration test? Pen tests can also show you if your configuration is set up right or if you managed to screw up the configuration file and therefore the program is doing something you didn't intend.

Hacking is cool: He suggests that people not understand how hacks work. This is a dumb suggestion. By looking at how mistakes were made by others you can therefore avoid those mistakes. Most holes were not there intentionally, it was because the programmer didn't think of how the code could be compromised. By learning these techniques, they can be avoided. Indeed again to his previous point.

Educating users: I can't believe he is suggesting that users not be educated. Most people are the equivelent of "Just off of the turnup truck." They don't know to not take the Nigerian scam or many of the other social engineering tricks. Most people are trusting by default. It is like allowing people to walk through a very bad part of town and not telling them about it.

His minor dumbs are what he should have put in the top. I see those far more often. I have to wonder if this is something he had to do for a writing class at school. Looks like it.

barely clothed nudes

[Orinthe]

Doesn't anyone else have issues with the following quote from the article?

nearly 1/2 of humanity will click on anything purporting to contain nude pictures of barely clothed females

(emphasis added)

Enumerating Goodness can work

[foniksonik]

Man is that wording pretensious... but anyways...

I use a little program called "Little Snitch" it is your basic network filter except it is active and dynamic. By this I mean that I don't have to go through huge documentation bibles looking up port number / protocol combinations to create a list of 'goodness'... I just let Little Snitch run, block every port on my machine and when one of my apps needs access to the outside Little Snitch asks me if I want to permit it!!!!!!

LS also asks me what sort of rules I want to apply to the application, ie: give appXYZ access to selected port/ all ports : selected server/ all servers : for just this once/ until the app quits/ forever.

It does the same thinng for incoming access requests.

This means that blocking all my ports by default doesn't impact the utility of my machine at all.

I recommend that anyone should check it out.. it provides all the power of having a dedicated network sysadmin for my local machine without the issues of another person trying to guess what i want to do all the time.

So to summarize, "Enumerating Goodness" is possible and indeed is a viable solution when you have a tool that lets you do it on the fly as you need it, instead of trying to precognitively guess what applications will be needed down the road.

The only case I can think of that could cause trouble is if you were to download a trojan that first altered your network filter to allow it access before doing it's dirty work. This is where a good AV tool that checks incoming connections through trusted ports like 80 and 25 would be required.