Slashdot Mirror
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"."
These people get the crap and then bring it into the cacoon, thus negating the hundreds of thousands of dollars of security infrastructure
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.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
The internet.
"Yields falsehood when preceded by its own quotation" yields falsehood when preceded by its own quotation.
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?
Actually, the article is a bit more general than that. It can be applied to any application. It's just that all the flaws seem to be present in MS Windows.
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.
Basically he said don't patch anything and design things that are secure. Pretty ignorant of security if you ask me. It's hard for the end user to design things that are secure when every layer of software/hardware they use is buggy. From the kernel, OS, network protocols, database, software language, drivers, routers, firewalls, and applications all contain bugs and design flaws. [1] Until you create the perfect human being there will be bugs and design flaws. [2] If a person can use a computer to do anything, then it can be hacked as someone can always get your password. [3] Why is that? Because a great portion of break-ins are inside jobs done by the Sys Admins or DBAs or other pissed off employees with access. Ultimately, you can never have 100% security unless a computer cannot be used by anyone. You have to at least try and improve the system as you go. This is the only way to *limit* the break-in possibilities, you will never prevent them all 100% outright.
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.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
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.
Can anyone tell me how to set my sig on Slashdot?
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.
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
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.
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
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?
Oh well, what the hell...
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.
What I'm listening to now on Pandora...
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.
"I assumed blithely that there were no elves out there in the darkness"
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.
='^)
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.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
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.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
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.
I'm the stranger...posting to
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.
God is REAL! Unless explicitly declared INTEGER
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.
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.
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.
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.
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.
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.)
Because DRM has nothing to do with computer security. Lumping them together just causes confusion.
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.
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.
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.
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
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.
High-speed Road Trip (18.000KPH)
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 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.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
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.
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.....
LedgerSMB: Open source Accounting/ERP
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.
LedgerSMB: Open source Accounting/ERP
Cool by default because it was a movie about hacking before the world at large even knew about hacking (and phreaking, and blue boxes...)
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
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.
.PNG format sent to them by family (where .PNG was not a whitelisted attachment, nor was email from a random gmail account).
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
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.
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...
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...
Slashdot needs a "-1, Wrong" moderation option.
The Urban Hippie
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?
Do what I say, cuz I said it.
-Meatwad
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
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.
YooHoo/2U2
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.
>> 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.
http://request-header.info
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.
Mea navis aericumbens anguillis abundat
#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.
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!"
Your CPU is not doing anything else, at least do something.
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?
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.
The way that you get software onto Linux, the very nature of open source, is a trojan horse disaster waiting to happen.
.. what is all this make install gnu auto configu stuff?
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.
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.
This is my sig.
we all needed admin rights of course - rather hard to write software without it
Man, that's just wrong. Developers shouldn't have admin rights at all. Leave admin work to the system administrator.
When developers have admin rights, it just leads to more programs that require admin rights to run, thus lowering security for the people who need to run the programs.
DRM has everything to do with computer security. Imagine you're setting up federated authentication with a partner company and you need to authorize access to particular records in a database. Perfect application of DRM. Do you think authorization of external entities isn't part of IT security?
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.