Security

General discussion

Locked

The Six Dumbest Ideas in Computer Security

By jdclyde ·
This came in a security newsletter I recieve. I read it and some of the ideas I thought were pretty obvious to me, yet some others made me have to think about them for a while as they are counter the conventional "wisdome" about computer security.

"Marcus Ranum released any interesting editorial entitled "The Six Dumbest Ideas in Computer Security." He gives his views on common security misconceptions that seem to be perpetuated throughout corporate IT environments. You can read this and other editorials at:
http://www.ranum.com/security/computer_security/editorials/dumb/"

After reading this, what is your take? Are we just chasing our tails so vendors can continue to make a profit?

Is this approach something that you use, or could use?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

False Positive?

by LectricToken In reply to The Six Dumbest Ideas in ...

Well what a load of twaddle!

I don?t know about the rest of you, but isn?t this the world in which no same 10 million lines of code can be occupy the same copyright, doesn?t all the goodness eventually become outdated badness anyway! Just think on the false positives that are being asserted here! default permit/default deny I just love it when people start making these sort of statements, know this; default permitting the goodness without sufficiently providing for the invariable event of your goodness turning into an exploited badness, leaves you where exactly ? down the river without a paddle my friend!

Enumerating badness, well again plugging the holes in the dam before we all get drowned, is preferable to being overwhelmed isn?t it, here is a small basic program to demonstrate:-
10 GOSUB LOOK_FOR_HOLES
20 IF HOLE_FOUND = FALSE THEN GOTO 50
30 GOSUB FIX_HOLE
40 GOTO 10
50 GOSUB CONGRATULATE_SELF
60 GOSUB EXPLOIT_POTENTIAL_NEGATED
70 GOTO 10

?if "Penetrate and Patch" was effective, we would have run out of security bugs in Internet Explorer by now. What has it been? 2 or 3 a month for 10 years, Space Shuttle! supposed to be hackable then it shouldn't be hackable?

Ye, bu, no bu ye bu no bu, again what the writer fails to point out is how many revisions and new functional elements have been applied to IE over the past 10 years, clearly far more benefit than detriment has been afforded Microsoft worldwide audience than ever the trickle of reported exploits.

?Doesn't that sound dumb? Your software and systems should be secure by design and should have been designed with flaw-handling in mind?

Er yes it does sound dumb actually, there is no such thing as secure by design, design involves people, people are not without fault does this make sense to anyone else?

Hacking is cool oh yes it is, finding other peoples faults? What you don?t read the tabloids, Penetrate and Patch is the part of any design that leads to comparable best practice. Hacking is way cool period.

?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 semi-famous 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.?

A. The first statement here is made up rubbish
B. The second statement fails as the other half of humanity never got to see Anna, Aw! As the vulnerability had already been squished, Penetrated and Patched, sorry about that!

Educating Jane Bloggs user, well the real real answer is maybe if I were more interested in the real world everyday usage of the myriad applications under our control and the idiosyncrasies of those systems, then who knows just maybe you could really help someone, educate yourself and instil an environment in which people are lead by your example of how to work smarter and save themselves the bother of continually having to call you for support, it?s a two way thing don?t ya know!

?It really is easier to not do something dumb than it is to do something smart. The trick is, when you avoid doing something dumb, to make sure your superiors know you navigated around a particularly nasty sand-bar and that you get appropriate credit for being smart. Isn't that the ultimate expression of professional kung-fu? To get credit for not doing anything?!?

No NO Sir, the trick is to let all your colleagues know how you navigated the sand-bar, or indeed how you fell foul of it, thereby extenuating the knowledge of your team, and hey don?t worry, if it was really that great a manoeuvre or crash your team will make it known to whom the adulation is owing, Win-Win!

Best advice:-

Worry not about that which is beyond your control, nor that which is under your control, for if it is under control there is little to worry about, if beyond your control it?s someone else?s worry.

Even the stupidest man knows by some instinct of nature per se, that the greater the number of conforming observations the surer the conjecture.

Happy hacking!

ElSteveo LetricToken

Collapse -

Excellent response

by Tony Hopkinson In reply to False Positive?

Proved the guy's point admirably.

Collapse -

Engineering 101

by jdgeek In reply to The Six Dumbest Ideas in ...

Engineering is about maximizing certain features by design. Each time you make a decision that maximizes a feature, you are doing so at the expense of another feature.

Most of the examples Mr. Ranum supplies trade security for flexibility or ease of use. Quite often these are the appropriate choices, sometimes they are not. The root of the problem might well be that maximizing security does not maximize profits.

Collapse -

Depends oh how you look at it...

by Praetorpal In reply to Engineering 101

How effective is cobbling together piece-meal security technologies as opposed to a comprehensive model that provides a complete solution? A lot of what is being used now in the enterprise impedes optimization of the business model, adds to system load (20-30%), and causes headaches due to lack of interoperability.

The question to ask is how much better could the organization do with increased uptime, lower maintenance costs and fully optimized IT/business models?

Collapse -

A certain giant in the software industry

by Tony Hopkinson In reply to Engineering 101

agrees with you wholeheartedly, which when you come down to it isn't all that comforting.

Feature set is not the problem, anything that can be done by foreign code on my system can be done by either by running native code or by server side execution. Exactly what features are we gaining for the compromised security ?

Collapse -

flexibility

by jdgeek In reply to A certain giant in the so ...

Native code == everyone has to have the code beforehand. How would Microsoft, or any other software distributor know ahead of time that you might want to watch Elf bowling? Wether you accept it or not, email is a very flexible way of distributing programs.

Server side execution == enlarged IT infrastructure and less meaningful access to your own system (i.e. the exact same file level access you are trying to avoid).

Now, I am not arguing that a completely flexible approach provides any security. On the contrary, I believe it occupies the opposite end of the spectrum. An engineer's problem is to balance and maximize security and flexibility to the level appropriate for the system.

Microsoft's or any other distributor's failure to balance, or maximize security and flexibility may constitute bad design, but it does not change the underlying dynamic I am discussing.

Collapse -

secure flexibility

by apotheon In reply to flexibility

Allowing for things like watching elf bowling is fine. Allowing for things like remote execution of elf bowling code is not so fine. Allowing for things like accessing privileged system internals by way of remote execution of elf bowling code is even less fine.

I've yet to see anything ActiveX can do that you can't do without it (or something like it), excepting the manner in which it allows you to completely bypass almost all security controls without trying.

Collapse -

Criticism of 6 ideas

by blarman In reply to The Six Dumbest Ideas in ...

#1. This is the way all software SHOULD be written. You don't let anyone do anything they aren't explicitly allowed to do. This is the way Novell, UNIX, and Oracle have handled their security since day one. Its too bad Microsoft abandoned this concept.

#2. This one is a little more contentious, in that this isn't currently practical for many companies. I won't point fingers at who is to blame for this, because it is fairly self-evident. It would require a certain proprietary software company to divulge their communications specifications in order to make this a reality.

#3. This one has both fact and fiction. Penetration testing can be useful information, but I agree with the underlying premise - that because the original software wasn't built securely in the first place, that it is inherently (and possibly intentionally) flawed. Noone is expecting anyone to write a non-trivial application securely the first time. That's why there is beta testing and trial before it goes out to customers. But I have to agree that the sheer volume of patches indicates a haphazard underlying programming framework.

#4. This is right on the money. Of course, if it weren't so easy to hack things, much of this would disappear.

#5. Ultimately, this one is more a business decision than a technical decision. This is a question of whether or not the effort to train employees in basic IT practices is worth the reduced instances of viruses, misuse, etc. From a human resources perspective, companies are required to train employees on what constitutes misuse of company property for legal and employment reasons. While I can understand the logic, I disagree with the conclusion not on security principles, but on business principles.

#6. This is also a business decision. I think the crux of this one comes down to the trust relationship that exists between the decision-maker (management) and the IT staff (recommendation team/implementers), and comes down to whether or not the manager knows IT. If the manager knows IT principles, he/she is much less likely to make poor decisions, and much more likely to rely on the IT department/staff for recommendations and implementation plans. If the manager DOESN'T know IT, however, they have to rely on someone else's knowledge. To me, this is more of a management issue of knowledge and trust that a security problem.

Collapse -

Easy to implement

by douglasjohnledet In reply to The Six Dumbest Ideas in ...

Just switch to an IBM MVS system.

And that's the problem.

The "reason" PCs/LANs/WANs exist is because of the inflexible nature of M/F operating systems.

So, you can be secure OR you can be flexible. I don't believe you can be both.

Doug

Collapse -

Excellent Article!

by heml0ck In reply to The Six Dumbest Ideas in ...

Well written, well thought out.
We quarantine all attachments in Notes, and examine them for malware before releasing them. Used to make the users grumpy until it was pointed out that unlike every other site in our division, we had not had a disruption of service due to viruses in over two years.
We also only allow vpn'd connections through our firewall ( inbound) and proxy access with URL scanning/blocking outbound. If we don't want you in, you don't come in.

Related Discussions

Related Forums