Stuxnet's Legacy: Get Back to Basics or Get Owned

Gunkerty Jeb writes "Attacks such as Stuxnet, Operation Aurora or GhostNet are not what most enterprises and organizations need to be worried about. The plain fact is that most organizations are falling far short in protecting against the same threats that they've faced for the last 10 years. SQL injection, phishing, malicious attachments, social engineering. Old, every one of them. And yet, still incredibly effective at compromising networks in some of the best-known and theoretically best-protected companies."

Comments

Security is hard

[Anonymous Coward]

No matter how much companies (and individuals) would like to pretend otherwise, security is really hard to do. It's not just a matter of having the right technology in place; people have to follow some inconvenient rules and exercise self control and common sense.

So we're always going to have some of these problems.

Re:Security is hard

[WrongSizeGlass]

Exactly. Vigilance ... and trying to protect clients/users/family from themselves ... is the only way to be sure.

Re:Security is hard

[AvitarX]

Sometimes the slow drag of being protected against oneself costs more than the risk being averted though.

For example, the cost of code generators to access bank accounts online in Europe surely prevents some fraud, but how much compared to the cost of every generator, and the inconvenience of not having access if you lose it.

Similar with active protection virus software not too long ago. It caused instability and slowed things down immensely.

Re:Security is hard

[Anonymous Coward]

Exactly. Vigilance ... and trying to protect clients/users/family from themselves ... is the only way to be sure.

if somebody needs to be protected from themselves i say fuck it, let them get 0wned. see if they ignore your advice next time. if they do it enters this beautiful category called not your problem. there is nothing cruel about that. you cannot help people who do not want to help themselves. you can only respect their decision.

everything that follows is hypothetical in nature. i do not advocate anybody actually do this. but if it happened anyway even though i do not advocate it, i will explain what the results would be.

in my personal opinion i almost wish somebody would just go ahead and make some truly destructive malware. something designed to spread for a little while and then securely wipe every last writable partition it can access. let it use already patched vulnerabilities only. that'd be the best way to take the insecure machines offline until their owners get a clue or hire somebody with a clue. i like that better than isps becoming the malware cops. i like that better than organized criminals having a steady supply of huge botnets to do their bidding and give them anonymity.

less pain for everybody involved that way. the irresponsible idiots don't turn into spam-spewing ddos-attacking botnet members and that benefits everybody else. the irresponsible idiots also don't have to worry anymore about keystroke loggers and other shit taking their financial details since those dont run so good on totally blank hard drives...

see folks that would be addressing the source of the problem. the problem has two aspects really. aspect one - people refuse to secure their systems and resent you for telling them that expecting them to be experts is unreasonable but they should at least do a little reading and attain at least basic competence. aspect two - the same people think "oh my computer is just slow these days" instead of realizing this is a problem they need to do something about NOW. malware designed to destroy as much data as possible that only uses security flaws they should have already patched is ideal for preventing the incompetent from inflicting their stupidity and laziness on the rest of us.

Re:Security is hard

[MstrFool]

No kidding. The only perfect security just happens to lock out all legitimate users as well. So long as some one can access the info, then some one else can find a way in as well, the more people that need to be able to access it, the more ways in there will be. It doesn't help that traditionally, security tends to be the lowest item on the list. Need to save money, most companies will skimp on security before they will skimp on janitorial. Guess they want to be sure the place looks nice for any one that breaks in. Same goes for computer systems. The order of importance seems to be, Make it look nice, Make it simple to use, Make it work, and make it secure. Sadly, it pays off to work it that way. If it looks good, people assume any problem with it is their own fault and not the program. Make it simple and most people don't realize just how few options they have and just how little they can really do with it. Make it work, well, folks expect problems and blame them selves, so we can fix the bugs later. Make it secure, but don't do anything that prevents to legitimate users from doing what they should... Good luck on that. Best example of how people react to a company making an attempt at doing the right thing and getting hammered for it is, and I /really/ hat to say this, but... Microsoft and their access controls in Vista/win7. They started to do it right and put in real security, and people went ballistic. Problem is, people didn't get pissed that it only locked the user out and let hackers through, they got pissed that it asked them before just doing things. Now, I'm not saying it couldn't be done better, it could have. But look at what people complained about, 'it's in the way', not 'it's insecure'. Right there shows why things will never be secure. People want convenience, not security, and people are the ones that pay for the work.

Re:Security is hard

[RichardJenkins]

But SQL injection vulnerabilities are pretty easy to avoid. I'd say in the general case SQL injection problems point are a good indication to avoid a company.

If you inadvertently allow malicious access to your DB via SQL injection - fine. Just don't fib by saying your company should be taken at all seriously when considering their security credentials.

Re:Security is hard

[Anonymous Coward]

You're quite then douche bag aren't you? We can only hope you fall victim to some "truly destructive malware". I wasn't in favor of "truly destructive malware" but now I am if it means you get hit with it. Thanks for the perspective.

Re:Security is hard

[blair1q]

Security is only hard to do if you don't know what you're securing.

Code is fractal and dense. It's an implosion of vulnerability.

Think of it instead as a building with a hundred doors. You know you can secure all those doors. But open one and behind it are a hundred more. Okay, so you can secure the first hundred, you can secure these. But behind these may be more doors, and you don't know which doors where are unlocked and can allow the outside world in.

The only way to handle this situation is to ensure your entire building is known to you, and that you have a way to check every door to be sure it's locked.

But the way people code with any efficiency is to import a whole new building behind a few new doors, thus bringing in a non-finite expansion of your insecurity.

Efficiency in coding is therefore the enemy of security in coding. Until we get back to the nuts and ensure that we can know where all the doors are and that we can check them to be sure they are all locked.

Re:Security is hard

[commodore6502]

>>>trying to protect clients/users/family from themselves ...

(takes scissors to ethernet cable leading into generator, centrifuge, etc) SNIP. Okay it's secure. Never should have been on the internet in the first place.

Re:Security is hard

[Anonymous Coward]

My issue with Vista was simple, I don't need to be asked 3 or 4 times if I'm sure i want to open Windows Explorer in a manner that will allow me to view/modify my system as I see fit. Like it or not, once it's installed it is my computer and my Operating System(License), while security is important, if that security is circumvented I should be able to modify ANY file or directory structure on my computer as needed to remove said security breach. If I don't have access to do that due to something you've put in, you are do nothing but exacerbating the problem.

Re:Security is hard

[dkleinsc]

Some things really aren't hard, though: There are plenty of well-known programming practices that make SQL injections and XSS attacks a thing of the distant past.

What is absolutely true in your post is that any company that says "buy this security product and you'll be perfectly safe" is talking nonsense. And yes, I'm including McAfee and Symantec in that kind of company.

Re:Security is hard

[postbigbang]

No. It's not that tough. You make it out to be layering against different kinds of vulnerabilities. It's much different than that.

You have an OS with its faults, access RPC with its faults, code with its faults, and libraries with their faults. You can control only parts of this in your code. The rest is choosing solid OS and RPC support, and libraries with known code and behaviors.

Then you build parsers with as much concrete as you can, update platforms, rinse, repeat.

Re:Security is hard

[flappinbooger]

Yes, security is inconvenient. I even have a hard time getting organizations to use passwords longer than 3 characters, let alone "complex" and expiring once a quarter. More than one password?!?!?!? It's a disaster. Can't put up with it. Not gonna happen.

I think implementing biometrics is the way to go, swiping a finger is much easier than typing. Also don't have to remember it or write it on the post-it note stuck to the monitor.

Common sense? Well, social engineering is one of the biggest security holes, but I think a hacker would have a hard time with some people I've ran into because they probably wouldn't understand his social engineer questions.

"What's your password?" "You mean the thing I type in first in the morning, or the thing I type in later when I want to fire up the hard drive?" "uhhhh.... The first one?" "Hold on... Mabel! What do I type when I come in? P .. A .. S .. S... W .. O ... R... D... What was that last part Mabel? P.... A .... No, not that, The first thing I type!" "!@$#!@#! .... click."

Re:Security is hard

[Andy Dodd]

I forget who to attribute it to, but the quote "There is no patch for human stupidity" remains as appropriate as it ever did.

Re:Security is hard

[Anonymous Coward]

You're quite then douche bag aren't you? We can only hope you fall victim to some "truly destructive malware". I wasn't in favor of "truly destructive malware" but now I am if it means you get hit with it. Thanks for the perspective.

we've tried coddling them. we've tried telling them to update. we've tried being "the computer guy" and letting them take up our free time while we remove their preventable malware infection for the Nth time. where has that gotten us? oh yeah, rampant malware everywhere and a ready supply of botnets for online criminals to spam, threaten, ddos, steal financial data and otherwise harm everybody else. you find that acceptable? you are more concerned somebody might get their feelings hurt by feeling their own irresponsibility?

somethin's gotta give. the sheeple need a wake-up call in my opinion. the malware authors understand one thing very well - a good parasite does not wipe out its host. they learned that from every other parasite in nature. what we need is a bad parasite. overnight average joe sixpack users will start to insist on security.

instead of calling me names tell me what you prefer. would you rather government make you have to get a license to use the internet like they do now with cars? would you rather the security situation keeps getting worse and online criminals keep prospering? what we are doing now isn't working. it is not even reducing the problem and has no hope of solving it. only an insane person wants to keep trying the same thing expecting a different result.

we tried all the easy ways. they all have one drastic flaw - they require average users to give a damn. that is why they have all failed. obviously average users wont start giving a damn and looking after their own damn interests without a fire lit under their asses. they resent every suggestion that they take responsibility for their systems, they actively resist learning anything new. far as i am concerned they reap what they sow. i have no sympathy for people who are their own worst enemy and if you really have such a big heart then you don't support someone's maladaptive behavior in the name of kindness.

Re:Security is hard

[PaladinAlpha]

Yeah, I mean, I think they should make cars that blow up if you don't check the oil, belts, timing belts, brakes, transmission, coolant, tires, hoses, spark plugs, wires, distributor caps/rotors, and air filters precisely at the best mileage for each! That way, people who refuse to help themselves by daring to drive a car without knowing the full maintenance schedule (and implications of missing parts of it) will be taken out of the education. Those stupid, incompetent, lazy people.

Re:Security is hard

[dudeman2]

Actually, those centrifuges were never on the public Internet. Stuxnet was cleverly designed to infect the workstations running Step 7 PLC programming software, hijack the communications with the PLC to install its payload on the PLC. I don't know if the Step 7 workstations were on the Internet either; they may have been infected by sneakernet - USB keys, CDROMs, and the like.

Re:Security is hard

[Runaway1956]

You might ask HBGary Federal about the costs involved. That's a story I'll be laughing about for the rest of my life. And, according to Anonymous, the key player in bringing them down was a 16 year old girl. Key words there are "16 year old". A youngster, probably not terribly sophisticated, probably somewhat nerdy, and almost certainly not terribly educated (yet, at least) social engineered an "expert" "security" firm with government connections. Oh yeah, the "girl" part has really got to chafe those big, arrogant macho men.

Re:Security is hard

[khallow]

if somebody needs to be protected from themselves i say fuck it, let them get 0wned.

[...]

. if they do it enters this beautiful category called not your problem.

Unless you need to be protected from their actions as well say because they're introducing malware onto your network that you need for your job. Then it enters an ugly category called "your problem".

Re:Security is hard

[PhilipTheHermit]

There are a few things you can do, though:

1) Don't let your developers go berserk with their framework of choice. Standardize on something company-wide, thoroughly audit/evaluate it as a platform, assign staff to maintain and patch it, and train everyone else on how to securely develop for it. I know corporations hate to train or otherwise improve their staff, but at some point they're going to have to bite the bullet.

2) Build an internal team and use them for your development needs. Mentor them, build institutional knowledge, have a succession plan in place. Stop contracting everything out to the other side of the planet and then feigning surprise when it falls over in the first stiff wind.

3) SIMPLICITY IS YOUR FRIEND. Don't let your developers make your site complex because they want to work with a cool framework or show off their skills. Do design reviews and simplify, simplify, simplify.

4) Treat all new developers as apprentices, and make them work under a "journeyman" for their first year (usually their probationary period) until they prove themselves and have learned how you do things.

It's not rocket science, it's common sense. Well... Common among older programmers, anyway.

Re:Security is hard

[Anonymous Coward]

I'm what they call a "white hacker". I inject SQL with marshmallow filling turning computers into Twinkies.

Re:Security is hard

[Anonymous Coward]

Comments like this only come from people who have never actually worked on SCADA systems.

Now, I'd agree there should be 1 or more firewalls between the SCADA devices & the general user network, and at least 1 more firewall between the users and the Internet. But to say that these devices have no reason to be on the network is ignorant.

Re:Security is hard

[John Hasler]

I don't know if the Step 7 workstations were on the Internet either; they may have been infected by sneakernet - USB keys, CDROMs, and the like.

Rumor has it that USB keys were scattered in the parking lots.

Re:Security is hard

[mlts]

Three words: Defense in depth.

A company can't depend on one single thing for their security. These days, it does take network security, host security, having policies in place that people follow, and periodic (scheduled and unscheduled) audits/pen tests. Without all these, it is only a matter of time before a blackhat easily gets their way in.

This doesn't mean paranoia, but it also means that one can't hide their head behind a fence and expect a blackhat not to target the derriere that is exposed.

Re:Security is hard

[Anonymous Coward]

Yeah, I mean, I think they should make cars that blow up if you don't check the oil, belts, timing belts, brakes, transmission, coolant, tires, hoses, spark plugs, wires, distributor caps/rotors, and air filters precisely at the best mileage for each! That way, people who refuse to help themselves by daring to drive a car without knowing the full maintenance schedule (and implications of missing parts of it) will be taken out of the education. Those stupid, incompetent, lazy people.

Yeah, I mean, I think they should make cars that blow up if you don't check the oil, belts, timing belts, brakes, transmission, coolant, tires, hoses, spark plugs, wires, distributor caps/rotors, and air filters precisely at the best mileage for each! That way, people who refuse to help themselves by daring to drive a car without knowing the full maintenance schedule (and implications of missing parts of it) will be taken out of the education. Those stupid, incompetent, lazy people.

wiping the data on a hard drive doesn't make the computer explode. nice try at melodrama Sparky. typical slashdot bullshit - "I don't like what you said and instead of formulating a rational argument i'll just go all emotional". excellent strategy sir.

funny you should mention cars. government regulates those actually. the government requires periodic inspections for your car to verify that it is in good working order before they will allow you to put it on public roads. there are punishments for those who will not comply, usually fines. they acknowledge the problem and that is their solution for it. now most people are not auto mechanics so they hire mechanics to take care of this for them. likewise most people are not skilled computer techs but guess what, computer shops are full of people they could hire someone to secure their systems.

they cannot be bothered and that's the problem. why don't you face it? why can't you acknowledge that people taking care of their computers like they do their cars would all but eliminate the problem? why won't you admit that they choose not to and that's the only reason they don't? truth hurts that much when it interferes with your misplaced sympathy?

for computers i acknowledge a similar problem to the one you mention concerning cars and look at the denial everybody shows. what's the matter, the facts aren't what you wanted to hear so you'll blame the messenger? tell me, when you bury your head in the sand like that do you prefer full immersion or partial?

mark my words this problem is only getting worse. it will need a solution. government is only too happy to provide one. they love nothing more than a crisis that is solved by expanding their powers. that's a lot worse than allowing the incompetent to suffer from their incompetence for as long as they refuse to address their incompetence.

it is amazing how much vitriol there is against anyone suggesting that people who are irresponsible and stupid despite years of warnings and advice should be allowed to suffer the results of their irresponsibility and stupidity, the same results they'd otherwise be inflicting on others (botnets are not fun). what gives them that right? if you want to reject personal responsibility make your case for it. you won't because you can't. i doubt you even realize that personal responsibility is what you are resisting.

Re:Security is hard

[grumbel]

There are plenty of well-known programming practices that make SQL injections and XSS attacks a thing of the distant past.

And that is part of the problem. A lot of security is still only based on "good programming practice" and while it really should be just giving the user a compile errors.

Re:Security is hard

[Duradin]

Girls being used to social engineer men or using social engineering against men is as old as it gets. I'll leave it as an exercise for the reader to google up the reason why it works.

Re:Security is hard

[blair1q]

Then someone comes along and finds bug #32,767 in the browser you trusted, lathers you up, and repeats all over you.

Doors inside of doors, because "solid OS and RPC support" is a hall of doors you just tacked on because someone selling it said "uh, yeah, sure. it's secure..."

Re:Security is hard

[Thexare Blademoon]

I support personal responsibility. Stupid people often get what's coming to them.

That said, sir, you are still an arrogant, insufferable cunt.

Re:Security is hard

[hairyfeet]

Not to mention how badly we humans like to latch onto what I call "magical thinking" which is "If we have (insert product or technology) then we'll be safe!". You'd be surprised how many times I've walked into some SMB or large office and found a totally pwned network where they were just shocked! shocked I tell you! that the magical McGuffin they had based their entire security on had failed them. Hell there is a troll on this very website that subscribes to magical thinking with regards to HOSTS files and thinks they will magically protect him from all malware.

The simple fact is that NO OS, security technology or other magical McGuffin can take the place of good old fashioned best practices, with a top to bottom least privilege layout and sensible security policies. But all of that is hard, takes constant work, costs money, and is hard to explain to a PHB so in walks these companies offering magical thinking which sells like hotcakes right up until a company gets pwned.

Re:Security is hard

[postbigbang]

Then the solution is something like your own cut of BSD, linted of all extraneous code, hardened kernel, with your own control of your own written RPC APIs.

Re:Security is hard

[Flyerman]

The fact that she was posing as a man kind of negates all that.

Re:Security is hard

[Anonymous Coward]

Problem #1 here is the constant reinvention of the wheel that seems to be going on. Heck, we can't even decide on a browser right now and we're resigned to saying "Oh well, I think we 'need' 8 browsers in our ecosystem" so it's really security through obscurity again. Throw some weight behind a single piece of code and make sure it stands up to an audit. If you can't audit it, then it's useless (sorry M$, no cookie for you).

The constant OCD approach to running off and building yet another program that fails to address the problem is not a way to develop software; it's ill-intentioned ego stroking with a smattering of irresponsibility. You can't sell security (think of the TSA) so no solution on the market is going to address the problem.

Lets all throw our PCs away and start again, I have this idea for a new type of home computer...

Re:Security is hard

[gbjbaanb]

yes, security is hard to do, so we need to find alternative ways to protect the everso fragile code we run.

One suggestion I've seen is walling it off in 'fortresses'. Ie you do not directly run sql from code running in the web server, instead you pass fixed requests through to a back-end server process through a well-defined and small interface and have that run the sql (that you do not pass in as a parameter).

Even this is not going to be perfect, but it'll reduce the attack surface significantly. Too bad most programming frameworks and environments are geared up for exactly the wrong 'whatever is the easiest way to code' system. So yes, self-control and common sense.

Re:Security is hard

[PaladinAlpha]

A computer having its available data indiscriminately wiped is a comparable disaster to a catastrophic car failure in the amount of disruption it can cause. You are consummately guilty of not thinking about the implications of what you advocate, and in the classic manner are attempting to shout down anyone who might expose flaws in your reasoning.

Now, you've extended the analogy farther than it was originally grown, and in doing so invalidated it. Computers are not cars. Routine maintenance on a computer will not keep it in working order in the same manner as a car. An engine's enemy is entropy. Your computer's enemy is far more insidious, if a bit less relentless.

There is no 'routine maintenance' that can be performed on computers to safeguard them. There is no simple five-step program that any person can follow. The closest you can get is mass-market virus scanners and the like, and while those might stop 90% of the problem -- at considerable cost to the host environment -- the 10% remaining is the worst 10%. There isn't a period of warning with computers like there is with cars -- indeed, it's much the opposite. Once you've noticed a problem it's far too late. Preventive security on complex systems is hard.

Your talk of responsibility is immature nonsense. No one is resisting responsibility. But your stance to 'solve' this problem is to say, well, just make everyone responsible for everything -- we'll take every person in America and make them get a four-year degree in system security, and then if anything goes wrong we'll have someone to blame it on! If anyone doesn't bother putting themselves through the highest level of education specifically on the topic of securing their systems, then they should obviously lose their data! It's a complete denial of reality.

So, tell me, is this how you feel about your banking institution? You really don't care if they are breached if they 'learn their lesson'? Your health care provider? Your employer? Your daughter? Do you really believe that data is only valuable to the person that possesses it?

We're all living in the Real World, and your views will someday -- when you're older, no doubt -- incorporate that. For now, you've built up some oversimplified model of society, and its application is not only undesirable, it is completely unfeasible.

Re:Security is hard

[Lemmy Caution]

... or onto the network on which your bank account information is stored, or your email is stored, or that runs the system that provides water and electricity to your home...

Re:Security is hard

[Lemmy Caution]

Considering how long humans have been around at, roughly, the same level of intelligence, what is really stupid is to design a system that is based on a level of human performance that a significant number of humans lack.

Re:Security is hard

[maxume]

Biometrics are terrible. You leave fingerprint everywhere, most fingerprint readers seem to be incredibly easy to bamboozle, it gives incentives to detach fingers, it is hard to get new fingerprints if you find out the ones you have are compromised, and on and on.

Now, for certain types of authentication they probably make a lot of sense, but not for medium value authentication across miscellaneous un-managed hardware.

Re:Security is hard

[Anonymous Coward]

You. Out.

Until you learn the meaning of 'security through obscurity' or understand what diversity and competition does to an ecosystem.

Re:Security is hard

[CannonballHead]

That wouldn't solve interpreted languages, though, would it? Unless the interpreter itself complains...

Re:Security is hard

[tqk]

... you cannot help people who do not want to help themselves. you can only respect their decision.

You can't help them, and your fighting about it can't change that. Face reality. This isn't laziness, it's accepting reality. Some things, you can't change.

Re:Security is hard

[MstrFool]

Quite so. The fact that they made it so that the security is really only aimed at watching the owner rather then protecting them is where they ended up going way wrong. I'm a fan of letting people break what they own. Protect me from others, but never protect me from my self. Sadly, real security is not popular, so companies fake it by getting in the way of the user, and most users assume it's getting in the way of the hackers even more. Real security requires that people think, and making people think doesn't seem to be a winning strategy in business. At least not as winning as telling them they shouldn't need to think.

Re:Security is hard

[hitmark]

"common sense" is anything but common...

Re:Security is hard

[tqk]

There is no 'routine maintenance' that can be performed on computers to safeguard them.

Pardon? "apt-get update && apt-get upgrade" works for me. You need to learn what things, and how to turn them off, but it's pretty straight forward from there.

Or were you thinking of Windows? Then I agree.

Re:Security is hard

[Runaway1956]

As Flyerman points out, the 16 year old was posing as a man, and she social engineered a female within the organization. So, no, the girl didn't manipulate a guy via his hormones at all. The "security experts" failed repeatedly, on a number of fronts. Would you like the links to the real story? http://arstechnica.com/tech-policy/news/2011/02/how-one-security-firm-tracked-anonymousand-paid-a-heavy-price.ars http://arstechnica.com/tech-policy/news/2011/02/black-ops-how-hbgary-wrote-backdoors-and-rootkits-for-the-government.ars http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars http://arstechnica.com/tech-policy/news/2011/02/the-ridiculous-plan-to-attack-wikileaks.ars Please note, that I do not agree with a lot of what Anonymous does, but sometimes, they really do get things right. http://mashable.com/2011/02/19/anonymous-westboro/

Re:Security is hard

[chapstercni]

Not only fingerprints.
Think of all the people before you that pick their nose, and you HAVE to touch that same spot....

Re:Security is hard

[Draek]

Efficiency in coding is therefore the enemy of security in coding. Until we get back to the nuts and ensure that we can know where all the doors are and that we can check them to be sure they are all locked.

By which point hiring an army large enough to impose martial law in the whole city so you can do your business in peace comes out as the cheaper option.

Modern applications require thousands of man-hours to complete in spite of the practice you call "[importing] a whole new building behind a few new doors". If developers were forced to build them from the ground-up the cost would be almost unmeasurable, and that's even without considering the problems of auditing the damn thing, since even the best programmers make mistakes every once in a while.

Re:Security is hard

[Unequivocal]

Good points. To add to this, if you let folks type free text and pass that back to sql then you are at risk. As you say if the number of ways to do this is small, the areas you have to secure are small, but it's not about passing sql back and forth, it's about accepting characters from users that eventually appear in a sql statement, something a lot of apps need to do. Parameterizing your queries is smart but it's not foolproof (of course you are not suggesting it is foolproof, I'm just trying to add some detail to the vulnerability).

Re:Security is hard

[raind]

Go ahead and steal, there is nothing worth stealing at least for me. Not that I'm not into security.

Re:Security is hard

[tqk]

You can't help them, and your fighting about it can't change that. Face reality. This isn't laziness, it's accepting reality. Some things, you can't change.

Did I really write that?!?

Can I take it back? Obviously some kind of "doesn't get the posting interface" serious cockup, sorry. Eew. Did it somehow append itself to the wrong story/thread? Eew. Embarassing.

Re:Security is hard

[mjwx]

As Flyerman points out, the 16 year old was posing as a man, and she social engineered a female within the organization. So, no, the girl didn't manipulate a guy via his hormones at all.

Same difference.

Social engineering via flattery or infatuation is about becoming what the other side desires the most, what is the difference between presenting a sex kitten to a man and the perfect gentlemen to a girl?

OP was right, they played on the targets desires. It's one of the simplest social engineering vectors. Probably the second most used vector (after fear).

Re:Security is hard

[vegiVamp]

I don't know if that's an actual rumour or if you're kidding, but that would probably work very well, as would leaving a simple CD with some interesting label around.

Autorun is one of the major culprits in such a scheme, although people would probably click on random innocently-named executeables, too. Guess I should try that sometime.

Re:Security is hard

[dave87656]

You seem to misunderstand what anti-virus software does and does not do. Anti-virus software only works for known viruses and virus patterns. It does not work for unknown patterns.

If you use an insecure operating system you are more vulnerable than if you use an operating system designed from the ground up with security in mind. Anti-virus software on an insecure OS is not as effective as a secure OS.

Re:Security is hard

[MareLooke]

They didn't, if you would have read the actual article(s). She basically impersonated Aaron Barr to get privileged access to some machines.

Re:Security is hard

[roman_mir]

I'll leave it as an exercise for the reader to google up the reason why it works.

- I was trying to google up the reasons but now I am just exhausted from all the porn and I still don't know why it works :(

Re:Security is hard

[Bert64]

Car drivers are more analogous to users on a controlled computer system...
Someone who (supposedly) understands the system better manages the technical details, and the users are only required to interact with a select few aspects of the system.

If you don't maintain your car, or drive it in a stupid fashion it will break sooner or later. If you don't know how to maintain it, you typically pay someone who does.

Some people do indeed buy cars and never service them at all, such cars gradually deteriorate until they stop functioning all together, some may even develop dangerous faults resulting fire or in extreme cases might actually blow up.

Re:Security is hard

[Bert64]

Regular updates to fix known vulnerabilities would be considered routine maintenance similar to whats performed on cars...

Preventative measures, analogous to rust proofing for instance, include hardening the system, changing settings to more secure defaults and removing unnecessary exploit vectors.

Regular maintenance to a car, like regular updates to a computer will not stop a user from doing something stupid... If someone drives a car into a brick wall, or fills it with the wrong kind of fuel etc then chances are it will stop functioning correctly.

Similarly, while some vehicle faults develop gradually and are easily picked up before they get worse, some faults occur rapidly and with no prior warning.

Also, there is always accidental damage which is not the fault of the driver or of the maintenance schedule, for instance a stone being flicked up by the car infront impacting your windscreen and cracking it.

Re:Security is hard

[Flaming Foobar]

As Flyerman points out, the 16 year old was posing as a man, and she social engineered a female within the organization.

The person who got scammed was Jussi Jaakonaho, who is male.

Her gender might still have something to do with it, though. Women are generally thought to have more social intelligence than men, which might make it a little easier for them to pose as someone else in an email.

Re:Security is hard

[juasko]

Yep, and particularly the latter one is where it fails most. Rules and self control can be easier to maintain. But common sense is the biggest failure. Or is it that sense isn't that common anymore?

Re:Security is hard

[The Wild Norseman]

I forget who to attribute it to, but the quote "There is no patch for human stupidity" remains as appropriate as it ever did.

So if I decide not to patch stupid but regress to an earlier version, is that a good thing or bad?

Re:Security is hard

[Coren22]

Yeah, I mean, I think they should make cars that blow up if you don't check ... hoses, ... wires, ...

Those items can actually cause the car to explode or burst into flames...just a thought, it isn't as impossible as you are making it out to be. When you are driving around an item with 10-40 gallons of highly flammable liquids, it can explode. Good reason to respect the maintenance schedule.

English

[Anonymous Coward]

Slashdot editor's legacy: Get back to english class or get owned

This is more of an open problem

[IgnitusBoyone]

Well, the problem with most of these is even if you know about them it only takes one lazy employee to introduce them. So, its hard to be 100% vigilant against the threats and because it only takes one crack to break the damn, this makes it impossible for most security companies to improve.

Of course it still works

[russotto]

Just because you can put a label on something doesn't mean it's simple or easy to defend against. SQL injection, yes. But phishing, malicious attachments, and social engineering aren't easy or simple to defend against. Well, you can get rid of malicious attachments by getting rid of all attachments, but even if that's practical, it leaves the rest.

Meh

[Dunbal]

Maybe one day people will take little Bobby Tables seriously. Frankly there is no excuse for stupidity. But you must bear in mind also that we will never run out of stupid people.

Re:Meh

[ArhcAngel]

Here's your sign

Perspective

[TheRealMindChild]

SQL injection, phishing, malicious attachments, social engineering. Old, every one of them.

And every one of them gets learned the hard way by the new batch of up-and-comers. It isn't like the average knowledge of us IT folk has gotten any bigger. Old, season folks leave, and new, green folks join. Also, management.

Re:Perspective

[Dunbal]

Gee, here's a thought: old, seasoned folks one day will pass their knowledge down the line to the new generation. We can call it "education". Heck, we might even be able to charge money for it!

Re:Perspective

[MozeeToby]

Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible? Then all you have to do is convince the green new up and comers to use the existing tools. Only downside is that the newbies don't learn the lesson, but this particular lesson is pretty costly to learn the hard way.

Re:Perspective

[COMON$]

Now this is a mixed message because coming up through the IT field it was the old timers causing the security problems. "What? I have to clean my inputs? This is the way I have always done it and this is how I am going to keep doing it" as well as "bah, our company is not a target".

Now it is 10 years after I entered the field full time, things are FAR FAR FAR FAR FAR better. Yes there are still old sites out there, there are still companies that don't update their security because they are struggling to keep the lights on. But seriously as opposed to 10 years ago, Infosec is widespread, companies have security training seminars for employees, Pentests are a regular phenomenon. This increased security is largely because those of us who grew up with tech, intentionally went into the field, and really enjoy the work are now getting to the 10-15 year range on experience and fixing all the damn problems our predecessors set before us. All the while doing our best to defend against the up and comers who are trying to push out projects as fast as possible to pad their resume.

Re:Perspective

[somersault]

The best solution is, as always, in between. You don't want people in 50 years time having no clue how to write a secure database library.

Re:Perspective

[Rary]

Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible? Then all you have to do is convince the green new up and comers to use the existing tools. Only downside is that the newbies don't learn the lesson, but this particular lesson is pretty costly to learn the hard way.

In IT, there is this general belief that the seasoned professionals, also known as "old timers", are filled with antiquated and useless knowledge, while the green newbies, also known as "cutting edge fresh talent", know all the whiz-bang new way of doing things.

Sometimes, this is true, but sometimes it is not. As long as we continue to view this industry as being one that changes so rapidly that everything learned last week is obsolete, we will continue to make the same mistakes and reinvent the same flawed wheels.

Re:Perspective

[Anonymous Coward]

They can't 'use the existing tools' because there is always a mandate to 'update the technology.' That usually means replacing well working code with obfuscated OOP, rewriting in Java/.Net/language of the day, etc. I lament now and then about updating the technology just for the sake of updating the technology and the PHB's without insist that isn't the mandate. I rarely see a business case for the updates. On the rare occasions I do see a business case if's full of nonsensical 'evangelist' lingo (see Agile, OOP, etc).

Re:Perspective

[Barefoot Monkey]

Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible? Then all you have to do is convince the green new up and comers to use the existing tools. Only downside is that the newbies don't learn the lesson, but this particular lesson is pretty costly to learn the hard way.

It's not only possible, but it's already done in the case of stored procedures and prepared statements. When a newbie first arrives, inform him that his code should access the database using stored procedures and that when he absolutely has to construct statements directly then those statements must be prepared and never constructed from user input. No more SQL injections. If the newbie ever takes a moment to stop and consider why that rule is there then he will most likely (I hope) learn the lesson for himself through contemplation.

Re:Perspective

[Anonymous Coward]

Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible?

Yes, it's called using a damned prepared statement. You have to use the damned library if you want it to do any damned good. I wouldn't want a language stopping me from string concatenation, which is how this crap happens. I will never understand why people don't use parametrized prepared statements, then act like preventing SQL injection is some magic voodoo that can only be done with extensive, magic RegExps and extensive input washing that true wizards know. Just use parametrized prepared statements!

Re:Perspective

[HomelessInLaJolla]

Shouldn't it be possible for the old seasoned professionals to write libraries and tools that make SQL injection all but impossible?

Not really. At the library level the faults are embedded in the hardware. Everything you need for network communications will fit in less than 3k. How large is the size of your BIOS? Your monitor's BIOS? Your HDs BIOS? Your network card's BIOS? Your video card's BIOS? Computer technology did not begin today. The people who knew the problems with the vacuum tube room sized adding machines knew the problems with the next generation, knew the problems with the next generation, knew the problems with the next generation.

All of this talk about software security is smoke and mirrors. The real problem is in the hardware. There is very little which you are able to do about that.

Re:Perspective

[turbidostato]

"As long as we continue to view this industry as being one that changes so rapidly that everything learned last week is obsolete, we will continue to make the same mistakes and reinvent the same flawed wheels."

Ask any "seasoned tech professional" what does he think about seasoned tech professionals being old timers and newbies being cutting edge fresh talent. The day they stop saying "bullshit" is the day you will be right.

No, the problem is not "we viewing industry this or that". There will be problems as long as tech unsavvy PHBs get to decide about complex tech things instead of those tech savvy "old timers".

Re:Perspective

[Anonymous Coward]

Secure database libraries are easy. It's admitting that you've written a function like hash prepare_execute_and_return_one_row(db_handle, query, parameters) so that it doesn't take 10 lines of binding bullshit to do what "select * from user where id=$x" does insecurely that makes progress so slow.

Re:Perspective

[lonecrow]

Doesn't take old seasoned professionals just DBA's.

1. Proper use parametrized stored procedures.
2. Use the narrowest permissions possible for website data access accounts
3. Use permission chaining so that actions outside of the purpose of the stored procedure are denied outright.
4. Lock down the tables that allow an attacker to iterate through database objects.eg. "sysobjects"

Re:Perspective

[mcrbids]

As long as we continue to view this industry as being one that changes so rapidly that everything learned last week is obsolete, we will continue to make the same mistakes and reinvent the same flawed wheels.

I've now been in the field for 11 years. Some things have changed; now I write in PHP/javascript, most of my programming now is event driven, nearly all with prototype, etc.

But lots hasn't changed one iota. Arrays are still arrays, strings are still strings, and security holes are still security holes. Values are still passed by reference or by value, input needs to be validated, algorithms are largely the same regardless of the language, namespaces are still namespaces, etc.

I think that one of the biggest mistakes made in this industry is to think that everything does change. It doesn't. Even when the acronyms change, the basics are still the basics and probably always will be.

Re:Perspective

[Anonymous Coward]

Our "seasoned" developer are some of the worse offenders for insecure code, so I welcome new faces as they usually are better. What I'm purposing is after a project passes developer's tests (unit and integration), I get a chance to try and break it and show them how I was able to get in. Its been a fight, though.

Recently I had an http response split vulnerability and they tried arguing that no one would think to try that (it was a pretty obvious candidate as they redirected to an error page and used part of a form). I've also head the "senior" developer who was suppose to be over all the developers argue that if no one linked to the admin pages, the authorization avoidance vulnerability wasn't a problem. Based on his word, I couldn't get authorization to fix it (although I'll admit it "accidently" got fixed when I did get authorization for an enhancement). The sql injection doesn't surprise me as so many people take away use stored procedures and your safe; that's not necessarily true.

Re:Perspective

[AB3A]

Uh, yeah, good luck with that.

Seriously, it is hard to codify decades of experience in to a simple class that can be easily transmitted to the next generation. Furthermore, the concept of apprenticeships has been neglected in favor of the bureaucratic and idiotic practice of Human Resources (formerly known as Personnel Management). Now we have well certified people who have absolutely no experience applying anything they have learned. They are nearly worthless in real life; but wow, they look good on paper!

Apprenticeship deserves re-examination. We have bureaucratized so many skills and experiential sets that managers are lead to believe that workers are humanoid units that can be applied to any problem to make a result. Tell that to your football coach next time and ask them whether how well this could work when building a team.

In any case, today we have decades of experience walking out of the door every day and nobody knows how to "download" that well of experience before it evaporates and dies. I suggest apprenticeships on the job instead of formal classroom theory. Don't get me wrong, theory has it's place. But eventually that theory needs to be applied. And for that, you need real experience. You can get that experience on your own, or you can have someone help you by showing you where their experience came from. I know which I would choose.

Meanwhile, security is like safety. It is best taught by people with real battle scars. The reason older tricks are still working is because we have made a profession of securifying other things and other people instead of showing people how to do this for themselves. Clearly people are learning how to make this work, but they're making the same mistakes over and over because they don't have others to show them what worked and what didn't work when applying theory to practice.

And yes, it is true: we can't even get most people to lock the doors of their homes and cars until they've been burglarized.

Social Engineering

[arth1]

I thought phishing was a type of social engineering?

And social engineering isn't a technical problem likely to be "fixed" - it's a continuous education of users that can never be considered done or even successful.

Re:Social Engineering

[IgnitusBoyone]

I don't know if we can educate people in social engineering unless getting scam becomes a basic part of our education system and upbringing. I mean its the natural abuse of common human behavior. A 2 hour seminar isn't going to cut it for most people.

phishing, malicious attachments, social engineerin

[Culture20]

If you fire the dummies, they just end up at someone else's company (and you get other companies' dummies. Ain't no technical fix for stupid, son.

Won't get fixed in this release...

[Anonymous Coward]

Fact of the matter is:
        - Maintaining security is a cost
        - Security breaches are not a cost

Corporate policy dictates "costs are bad", ergo there's zero incentive to fix this until it's regulated.

Have a nice day.

Re:Won't get fixed in this release...

[AvitarX]

As a customer I want cost minimized too though. If regulation increases overall cost the cure is worse than the disease.

Cost of a breach can be shared by more than the prevention though, which would be a case for regulation to step in, as total cost could go down, even if corporate cost goes up.

Re:Won't get fixed in this release...

[Dunbal]

If this were true, then you would expect corporations to ignore labor laws, tax laws and pretty much every other rule and regulation from how many toilets per employee to what goes in the First Aid kits. Yet somehow corporations manage to comply with all these little rules and regulations despite the fact that doing so involves a cost. Therefore I don't think the argument is as clear cut as you make it. Now on the other hand if you want to argue that the guy in charge of hiring the techs in the IT department has no idea what security is and is relying on junior employees to "provide" security, then I am all for you.

Re:Won't get fixed in this release...

[Darth_brooks]

Fact of the matter is:

        - Maintaining security is a cost

        - Security breaches are not a cost

Corporate policy dictates "costs are bad", ergo there's zero incentive to fix this until it's regulated.

Have a nice day.

Recovering from breaches are a cost. A huge cost. A cost that keeps on drawing, thanks to negative publicity, pissed off clients, lawsuits, turnover. Sadly, the only way to prove that for some folks is to get hacked. The nice thing is that, as more and more hype mach......media coverage gets out regarding large intrusions, the more likely the people in charge are to sit up and take notice.

Re:Won't get fixed in this release...

[Dunbal]

As a customer I want cost minimized too though. If regulation increases overall cost the cure is worse than the disease.

I'll just whip those Chinese children a little harder to increase production a few more percent so that you're happy.

Re:Won't get fixed in this release...

[AvitarX]

Cost of being whipped is an expense to the children. The regulation could reduce over-all cost of the system, which in the end is what I want as a consumer.

Re:Won't get fixed in this release...

[blair1q]

Then think of it this way:

Maintaining security of something you don't understand is NP-hard, at best.

Securing a breach is finite.

The first is an unjustifiable cost. The second justifies itself.

Yes, this is as much a failing of corporate thinking as it is of software security design.

Re:Won't get fixed in this release...

[benjamindees]

I suppose it could reduce overall cost if there weren't new, different externalities built right into the regulations. Just like subsidizing subprime borrowers "could" have reduced the overall cost of housing, in fantasy land.

Re:Won't get fixed in this release...

[screwzloos]

If this were true, then you would expect corporations to ignore labor laws, tax laws and pretty much every other rule and regulation from how many toilets per employee to what goes in the First Aid kits.

This is absolutely the case where the cost of complying with the law is greater than the cost of the punishment for being caught. Realistically, only the regulations with sufficiently heavy penalties are adhered to, particularly for small business. Run things with strict compliance to every knit-picking rule in every book, and the competition is going to run you into the ground.

Re:Won't get fixed in this release...

[benjamindees]

That's more like it. Maintaining security is a definite, present cost. Securing a breach is a potential cost and, at worst, a future cost. Corporations tend to ignore potential costs. And they will always discount future costs. The first is because, if they didn't, their competitors would, and would grow faster than they do, secure more investment, capture economies of scale, and put them out of business. The second is because, thanks to institutionalized wage slavery, future costs will always be less than present costs.

Re:Won't get fixed in this release...

[natehoy]

Really? Then why is there still a line at Hannaford when I go to buy my food? Shouldn't the bad publicity have driven everyone to Wally World and Shaw's? Oh, wait, my options are terrible produce or paying more for my food? Well, Hannaford it is, then.

Good thing you never see anyone at the BP fuel stations any more! Man, the publicity of screwing up oil extraction really... ummm... oh, wait.

Some people remember stuff like this for a long time and use it as their primary criteria and avoid the company forever (several friends of mine still boycott Nestle over the third world formula fiasco, and Nestle caved and that boycott fizzled out before the average Slashdot reader was born).

Some people forget stuff like this immediately, or engage some sort of strange Stolkholm-syndrome type thing. I have a friend who now goes to Hannaford because he feels sorry for them. No, I can't figure it out either.

The rest of us have equally rational (to us) and irrational (to others) reasons for preferring or avoiding certain businesses. A hack or a huge screwup is rarely fatal to a business. Being behind the competition because you spent all your time dotting the "i"s and crossing the "t"s of every little security detail is a far larger nightmare to your average C?O.

Fear of being hacked makes a C{E,I,O,F}O nervous.

Fear of being irrelevant is what keeps them up at night.

Re:Won't get fixed in this release...

[turbidostato]

"If this were true, then you would expect corporations to ignore labor laws, tax laws and pretty much every other rule and regulation from how many toilets per employee to what goes in the First Aid kits."

Which is exactly what corporations do as much as they can. Why do you think outsourcing and fiscal paradises are so fashionable?

Re:Won't get fixed in this release...

[The Wild Norseman]

As a customer I want cost minimized too though. If regulation increases overall cost the cure is worse than the disease.

I'll just whip those Chinese children a little harder to increase production a few more percent so that you're happy.

Oh, please. It's not like you don't enjoy whipping those Chinese children anyways.

especially for idiots

[Anonymous Coward]

ya know like hollywood

Nothing to do with Stuxnet

[Anonymous Coward]

Attacks such as Stuxnet, Operation Aurora or GhostNet are not what most enterprises and organizations need to be worried about

So, in other words, we just put that in the title to drum up hits.

Stuxnet had nothing to do with SQL injection, phishing, or email attachments. It may have used social engineering, or it may have been introduced by a covert human agent.

The problem is people

[Drakkenmensch]

Anyone who would willingly give their banking info to the nigerian prince should have all of his office network passwords revoked instantly for being a moronic security threat.

Another take

[U8MyData]

I see a lot of comments about "dummies." Management needs to take a look at themselves as well. They hold the purse strings and the power of decision. In cases I have been exposed to, it's not the admins that are dropping the ball, it is the people making the decisions about things they do not appreciate or understand. Don't get me started on the overwhelming and pervasive attitude of users, "you mean I have to remember my password!?!"

Re:Another take

[Anonymous Coward]

...about "dummies." Management needs to take a look at themselves as well....

The difference is?

Seriously, business acumen != security knowledge.

Re:Another take

[Anonymous Coward]

Seriously, business acumen != security knowledge.

Slightly less succinct, leadership knowledge == assumption of security knowledge == ignorance of ignorance of security knowledge == Aaron Barr...

Re:Another take

[blair1q]

That's what your competitors hope.

Re:Another take

[mcmonkey]

I see a lot of comments about "dummies." Management needs to take a look at themselves as well. They hold the purse strings and the power of decision. In cases I have been exposed to, it's not the admins that are dropping the ball, it is the people making the decisions about things they do not appreciate or understand. Don't get me started on the overwhelming and pervasive attitude of users, "you mean I have to remember my password!?!"

As a user, don't get me started on admins & devs dropping the ball, making decisions about things they do not understand.

I spent 2 hours this week changing passwords for my work systems. I had 15 sets of credentials to update. Not all those systems are on the same 90-day expiration schedule as my main network ID, but I like to change them all at the same time. Otherwise, I'd never be able to keep my passwords straight.

And by 15 sets of credentials, I mean the user name is not the same for all of them, and for none of them was I able to choose my own user name. So that's 15 different combination of user names and passwords. And there is a 16th system I wasn't able to update because I don't remember the user name.

Some of these systems I rarely access. There's the company travel center and expense reports systems. I travel for business about once every 18 months. There's the benefits system I access once a year to update insurance information. I log on to those systems every 90 days to update passwords.

So here's our options: I write down my passwords. (Which of course is a big No No) I use the same password for all those systems. (Another big No No) I remember 15 different passwords, some for system I only access 4 or 5 times per year. (Impossible, for me at least)

Or the devs and admins can drop the BOFH attitude, and do their damn jobs. There is no excuse for these systems to not work with a single directory that lets me access them all with a single pair of user name and password. Management needs to stop accepting solutions which do not work with the company directory; the tech folks need to stop implementing solutions which do not work with the company directory.

So please, before you bitch about my inability to remember the 16 different passwords to the 10 or 11 different user names for the 16 systems I have at work, realize developers and admin are not the precious little snowflakes they sometimes act like.

Re:Another take

[sjames]

They're not paid enough to care. They are subject to being tossed out on the curb the moment the CEO needs to make his numbers on Wall street. Where's their motivation top care if the company gets hacked? To them, a password is nothing more than an obstacle to them making their numbers so their manager will give the other guy the axe instead.

Re:Another take

[turbidostato]

"As a user, don't get me started on admins & devs dropping the ball, making decisions about things they do not understand."

" had 15 sets of credentials to update [...] There is no excuse for these systems to not work with a single directory that lets me access them all with a single pair of user name and password."

Do you *really* think you have 15 different credentials because devs and admins? Really?

"Management needs to stop accepting solutions which do not work with the company directory"

Stop accepting!!!??? They are not accepting but *mandating* them each and every time they say "I want *this*, I want it *now* and I want it for peanuts". You can bet devs and specially sysadmins would be more than glad if managers would listen to them about minimal functionality, integration and maintenance.

Re:GODDAMN !! WHERE IS THE QUEUE FOR THIS APPLE !!

[Anonymous Coward]

Wait a few days and you can be sure there will be a Slashvertizement telling you where to go. All things Apple is good for page views, hence, ad revenue. I liken these to multi-car crashes, or train derailment, but some it seems like to read about it here, a few days late. Blimey!

10 years

[vgerclover]

protecting against the same threats that they've faced for the last 10 years. SQL injection, phishing, malicious attachments, social engineering.

10 years? Those attacks have existed for as long as those technologies have existed.

See

• SQL injection
• phishing

(Google won't go further than the '90s, but you get my drift.)

Re:10 years

[tqk]

10 years? Those attacks have existed for as long as those technologies have existed.

So, you're suggesting a class action lawsuit targetting computer science programs? Maybe you can get 'em for java too.

Can be solved, but usually won't be

[return 42]

I think the social engineering, phishing, and attachments could be solved, in organizations that made it a high enough priority, i.e., ahead of being nice to employees or not spending a lot of time and money on it. It breaks down into two steps. First, train everyone very well in how to recognize and avoid the threats. Second, have a dedicated tiger team continuously try to break security by sending phishing emails, emails with pseudo-malicious attachments, and trying to social engineer the employees. First time a given person screws up and breaks security, they go on the public list of screwups seen by everyone, it goes into their record and affects future promotions, and they have to attend training again. Second time, a formal warning, and more training. Third time, clean out your desk.

Not that real cracking attempts wouldn't slip through now and then; but it would certainly make the organization a much harder target.

Problem is, most organizations don't perceive it as important enough to go to these lengths. Intelligence agencies, sure (excepting the perpetually-clueless DHS); probably a lot more draconian than this. Military and FBI, too. Police? Probably not, they don't have the funding, for one thing. Corporate? Hardly ever.

Re:Can be solved, but usually won't be

[TaoPhoenix]

How about this quote of the day from the bottom of the page?

"Dow's Law: In a hierarchical organization, the higher the level, the greater the confusion."

Security is only as strong as the weakest point

[JustAnotherIdiot]

As long as humans are part of the equation, security will always be weak.

PHP is a big part of the problem

[Animats]

PHP is a big part of the problem. PHP's interface to SQL encourages putting in parameters without proper escaping. Python has a slightly different interface, one where there's one SQL statement with fields represented by %s, and a tuple with the values to be filled in. The values are escaped automatically. If PHP had only such an interface, most SQL injection attacks would fail.

It would help if there was simply a restriction that only one SQL statement can be submitted per call. Since all the major SQL implementations now have transactions, there's no reason to put two statements in one call any more.

Another problem with PHP is a tendency to install a large number of standard PHP scripts which shouldn't be installed at all. Look at your server logs and you'll see constant attempts by hostile sites to call common bad scripts.

Hosting "control panels" implemented in PHP are part of the problem. If you have one of those, you can't just turn off PHP, even if you're not using it. Worse, "control panels" tend to run with very high privileges, and present a large attack face.

Re:PHP is a big part of the problem

[Anonymous Coward]

PHP:: PDO->prepare()

Re:PHP is a big part of the problem

[Anonymous Coward]

This is only a problem with the mysql_* functions. Every other database abstraction layer supports binding parameters to queries. This functionality is only missing from mysql_* functions because mysql didn't support this until 4.1. You can get access to it for newer mysql versions by using the mysqli functions instead.

Of course, you could also just use PDO. Even if your database doesn't support parametised queries, it will emulate the behaviour for you. It's existed since PHP 5 as a PECL extension and has been part of PHP since 5.1.

See: http://www.php.net/manual/en/pdo.prepared-statements.php

Although this strikes me more as a problem of people being uninformed about SQL Injection rather than a PHP problem. Even without parametised queries its still pathetically easy to stop SQL Injections in PHP; cast user input to its expected data type (so $id = (int)$_GET['id']) and pass any strings through mysql_real_escape_string. It's not hard.

Not that any of this is going to do much good, mind. I've found an awful lot of "professional" PHP developers are just copy and paste bodgers. The problem with PHP code from third parties is that it is usually written by well meaning idiots.

Re:PHP is a big part of the problem

[Shados]

I hate PHP too, but the problem there is PHP programmers, not PHP itself.

What you're talking about, as someone pointed out already, is prepared statements. Virtually all mainstream programming languages have the ability to use those, including PHP for almost as long as its been mainstreamed. The only issue is that the most commonly used MySQL interface didn't use them, and the community didn't push them.

They were available AND they were easier to use than the "bad" way of doing thing. You are NOT supposed to escape the data you send to the database, and its NOT what those interfaces you talk about do. The work done to make sure there's no injection is more subtle and lower level, as well as database dependent. Thats why no amount of string escaping is 100% safe.

Using prepared statements (what you're refering to without realizing it) is very very possible in PHP, is now (today) mainstream, and makes sure you're not vulnerable to sql injection (unless you do something impossibly stupid or try on purpose, but you have to try very hard).

PHP sucks balls and no one should use it, but thats not among the reasons why it does.

Re:PHP is a big part of the problem

[Anonymous Coward]

Don't blame the tool - blame the Engineer! Yes you can write bad code in PHP, that would allow an SQL attack. You can do the same in almost any language. It is the job of the programmer and programming team, to insure the code sanitizes the inputs regardless if it is PHP, C#, perl or your tool of choice.

Re:PHP is a big part of the problem

[Anonymous Coward]

Virtually all .Net SQL interaction prevents this unless you go out of your way.

Django's DB API's... same.

Ruby on Rails... same.

Why PHP doesn't is completely beyond me.

Re:PHP is a big part of the problem

[Anonymous Coward]

PHP sucks balls and no one should use it, but thats not among the reasons why it does.

OK, PHP sucks balls...care to elaborate?

Re:PHP is a big part of the problem

[TheCarp]

Very much agreed. I can't say PHP is a problem so much as...it encourages the problem.

My experience with PHP went something like this, back when I was a professional newb.
Boss: "I need you to write this app, here are the specs, it should be done in PHP, that way we can hand it off to another group and we don't have to maintain it".

It SOUNDED great. The problem is, php is easy. its easy to start, its easy to mock something up real quick. its easy to think you are doing well and producing something good that works. Its no harder, however,m than any other language to make absolute hash of it.

Can you blame the PHP developers for making it easy to learn and get started? Thats like blaming the wheel and pedal interface for letting bad drivers on the road.

I think its a more subtle problem of competence. There were some great studies a bit back where they looked at how people rate themselves vs objective measures of their compence. Generally, the more cometent people (and this has been my experience) tend to rate their abilities lower than the less competent. Why?

Well one thing you hear a lot from very competent people "I don't know X". "I am not sure exactly how Y works...". Whereas the less competent tend to deal in absolutes "Oh I can do that", "I know how that works". The more competent people are more nuanced... they know that there are things that they don't know, and have an idea what many of those things are. They make less assumptions.

It is easy to get to the point where you can write a fairly non-trivial application. However, its also easy to think that this makes you some sort of expert, or espcially skilled, especially with all the work you put in to get to that point. Its another thing entirely to do it very well, and to understand the implications of all of what you are doing, especially when it goes beyond your narrow expertise.

Take databases and sql injection. These days, if I am working on code, I know its not my strong suit, so I compensate by stopping all work, and working just on the database. Designing a schema, writing stored procedures, THEN go to write the higher level code. I didn't do that when I first started out. I used to do what ALOT of people do.... I started with the bare minimum that I knew would "do the job" and only revisited it later if it turned out to be a problem (and then had to re-write large sections...which is usually where the project would die)

Slopping strings together haphazardly is easy to do, very quick....and it works. It works great. Its no surprise to me that it continues to be one of the most common techniques for working with SQL. Its just sad that this quality of code makes it into real products.

My first reaction when I read about the HB Gary hack was "SQL Injection and Rainbow tables? Haven't these people learned to handle SQL properly and salt passwords? I am no expert and all my recent code does BOTH". The truth is though,most people start out writting that sort of code and...it works so well its hard to distinguish. Well written secure code is great but, in practice its often indistinguishable from bad code unless you have the time and resources to audit it.

Re:PHP is a big part of the problem

[dkf]

Yes you can write bad code in PHP, that would allow an SQL attack. You can do the same in almost any language.

The issue isn't that you can blow your leg off in any language. The issue is that PHP does the equivalent of putting a big flashing red button in and daring developers not to press it. To be clear, the problem with PHP is that it was traditionally far harder to Do It Right than to Do It Wrong (a recipe for disaster in the hands of non-experts, and even sometimes experts) and that when you got it wrong, it still would work with the sort of input data that most people test with. It's just one giant collection of landmines, waiting to go off. (Maybe these things are fixed now, but there's a metric buttload of tutorials and books out there that still teach the bad old ways. Bad habits have a disturbingly large half-life...)

Re:PHP is a big part of the problem

[Anonymous Coward]

It's beyond you because you suck as a programmer.:

PHP:: PDO->prepare()

Re:PHP is a big part of the problem

[Shados]

Yup. It doesnt help that most samples you'll find online normally show the "easy quick way" of doing things, and often its the wrong way.

I'm an ASP.NET developer myself. ASP.NET has two "main" ways of working: WebForm (old), and MVC (new).

The MVC way has very good samples that generally show best practices. WebForm is technically superior in a lot of ways, but 99.999% of examples online show HORRILE HORRIBLE ways of using it.

Thus, virtually all WebForm code I've touched over a decade has sucked balls. Think worse than bad PHP code kindda sucked.

There's zero reasons for it to be that way: the "easiest" way of doing everything is actually the correct way. But all examples you'll find, all the blog posts, even huge commercial apps (SharePoint comes to mind, and its made by Microsoft itself!!) does it the wrong way according to the WebForm best practices.

PHP's just in the same boat as ASP.NET WebForms

Re:PHP is a big part of the problem

[tqk]

PHP sucks balls and no one should use it, but thats not among the reasons why it does.

OK, PHP sucks balls...care to elaborate?

I'd like to know too. WTF's the difference, essentially, between perl:DBI and php? Lot's of people complain perl's too hairy. Why's php getting a hairy rep?

You can write bad code in any language.

Re:PHP is a big part of the problem

[tqk]

Maybe these things are fixed now, but there's a metric buttload of tutorials and books out there that still teach the bad old ways.

How does O'Reilly's PHP Pocket Reference First Edition by Rasmus Lerdorf (what I've been thumbing through recently) stand up?

Re:PHP is a big part of the problem

[Anonymous Coward]

Wow! After what, a decade? It finally got around to :named parameters so people could pass $_REQUEST to the query without elaborate parameter counting bullshit.

Oh no, wait, you still have to execute bindParam() over and over and over and over. Is it any fucking wonder people still use *_query() and *_fetch_array()? Shouting "security!" doesn't excuse turning a one-line piece of code into 50, when it would have been trivial to make preparing and executing a one-off search query a oneliner. Oh and look, if you try to just bind everything in REQUEST, it shits itself on the unused variables.

Did they ever fix the shit where you can't re-use a parameter in the same query?

Fan-fucking-tastic. I'll just keep writing my own code, thank you. It took me an afternoon to write a class from scratch that could convert a :named parameter query to $n parameters for preparation in postgres, along with a map between :name -> $n (or even a list of $n's in case I needed a parameter more than once) so I could execute it against $_REQUEST to handle search queries where the user gets to decide if they want to look up a customer by name or account number or address, or maybe area code or possibly date of most recent order, or whatever else, and my code won't show up on thedailywtf for consisting of query_with_four_parameters() query_with_five_parameters() query_with_six_parameters() and so on.

Let me know when PDO gets around to being something other than an academic exercise in pointless pedantry, I'll take a look then.

Re:PHP is a big part of the problem

[Anonymous Coward]

PDO sucks as an interface. Let me know when it stops shitting itself if you try to bind all of REQUEST so you can map :named parameters to input fields without having to check each one individually, because if I have to check each one individually, I can just go ahead with that string concatenation, and I get to save several steps!

Re:PHP is a big part of the problem

[Flaming Foobar]

Thats why no amount of string escaping is 100% safe.

People like you think there is something mythical or mystical in programming. There isn't. Sanitizing user input is 100 % safe. It may not be the best way to do things most of the time, but there are times when it's the only way, like when the SQL statements are constructed from another SQL statement, which happens e.g. when pivoting a many-to-many relation.

Re:PHP is a big part of the problem

[Shados]

You can still dynamically generate prepared statements. Thats how ORMs do it. Most RDBMs will even let you dynamically generate a prepared statement and call it within a stored procedure.

There's nothing mythical about it: escaping still sends a string to the database, and relies on the conversion algorithms of it to deal the values. Every so often, as more research is done in vulnerabilities of string encodings and whatsnots, people find ways to confuse the engines with some really screwed up strings. Its not magic: the attack surface area is just waaaaaaaaay bigger, since you're letting your application layer guess the behavior of the database, so any change to either side, and boom! Or do you think SQL injection is just about sneaking a second command to the first one by adding --, ;, or whatever terminator the database uses, like what most script kiddy attacks do?

Re:PHP is a big part of the problem

[Flaming Foobar]

You can still dynamically generate prepared statements.

You can't use a prepared statement to dynamically turn rows into columns. Or if you know how, by all means tell me.

since you're letting your application layer guess the behavior of the database, so any change to either side, and boom! Or do you think SQL injection is just about sneaking a second command to the first one by adding --, ;, or whatever terminator the database uses, like what most script kiddy attacks do?

Sounds like folklore to me. I suppose you could run into problems if you use, say, mysql_real_escape_string() to escape a string going to, I don't know, Pervasive SQL. But what can I say... just don't fucking do it! Or did you think sanitizing input means string.replaceAll("'","''") ? In that case you'd be the naive one, not me. Also, the database engine won't just change all by itself. Something like 99 % of apps work on a specific RDBMS, and for the most part they won't even begin to work on another one without major refactoring. You have the occasional small project which uses simple ANSI SQL, but anything in the least bit demanding usually only works on a specific system:

Re:PHP is a big part of the problem

[Anonymous Coward]

It would help if there was simply a restriction that only one SQL statement can be submitted per call. Since all the major SQL implementations now have transactions, there's no reason to put two statements in one call any more.

/quote>

There is still a reason, and its importance varies based on your application, but runtime overhead is the reason. Even with transactions, additional calls have an associated overhead. That overhead may be negligible depending on your application, or it might not be such as in a batch update or massive import.

Re:PHP is a big part of the problem

[Shados]

The very reason there IS a mysql_real_escape_string is one of the more well known occurance of what Im talking about. There was another case with Oracle about 2 years ago. Escape functions are unreliable.

And you can just dynamically create the SQL with concatenation, as long as the source of the data is trusted, and you use parameters, thus how you can do a prepared statements to do it: again, all good ORMs do it like this to deal with databases without a decent pivot function/facility.

What else is there?

[pudding7]

Besides "SQL injection, phishing, malicious attachments, social engineering", what other types of realistic attacks are there?

Re:What else is there?

[hesiod]

Besides "SQL injection, phishing, malicious attachments, social engineering", what other types of realistic attacks are there?

When an army of machete-wielding pirates with stacks of floppies and USB drives break down the doors to your server room, you will know... yes... you will know!

Re:What else is there?

[hb79]

> what other types of realistic attacks are there?

The good old zero, memory / stack overflow attack? Or brute force password attempts. Random open ports. Windows machines.

Or, if you're enemy is really after you in particular: Blackmail, threats to your family, gun to your head. No-knock police raids, or other black-ops. In short, if your attacker is willing to pay anything, you are done for no matter what.

Re:What else is there?

[Anonymous Coward]

It's still commonplace for people to find in's to a network through portscanning and exploiting various software vulnerabilities in whatever applications are listening on those ports.

The success rate is fairly low, but the scans are done in such large volume that those types of attacks are very real. And it's none of the things that you listed.

Re:What else is there?

[HomelessInLaJolla]

if you're enemy is really after you in particular

Repeated anonymous telephone calls to your employer that you look at computer pr0n (because _nobody_ does that)--if your employer brushes off the anonymous telephone call then eventually they try to get rid of you just to make the telephone calls stop. Repeated anonymous telephone calls to your insurance (home/auto/health) that you look at computer pr0n (because _nobody_ does that)--if your carrier brushes off the anonymous telephone call then eventually they try to get rid of you just to make the telephone calls stop. Repeated anonymous telephone calls to your family that you look at computer pr0n (because _nobody_ does that)--nobody better than your family to keep secrets from you and follow up on any little tasty morsel of gossip they hear. Repeated anonymous telephone calls to the local PD that you look at computer pr0n (because _nobody_ does that)--if the police brush off the anonymous telephone call then eventually they put somebody on your case just to give them something to do. People you don't even know following you into every restaraunt, pub, shopping center, and library to tell the management that you look at computer pr0n (because _nobody_ does that)--if the managers brush off the anonymous tipsters then eventually they give you horrendously bad service because they don't want to hear it anymore.

And, once the anonymous telephone calls have been made enough times, then the court ordered network surveillance of all of the computer pr0n which you look at (because _nobody_ does that).

In short, if your attacker is willing to pay anything, you are done for no matter what

You have two options. Go to St. Vincent's, agree to change your name and kill off your identity, inherit an identity complex for the rest of your life, struggle to make it back to minimum wage slum living... or you may rot on the street next to the other homeless people because we don't like to feel obligated to give charity; if we feel obligated then we won't give anything.

how is stuxnet an example of old vulnerabilities?

[SethJohnson]

I'm not sure how stuxnet is a proper illustration of old vulnerabilities being ignored. From what I recall of stuxnet, it is a WORM that exploits multiple zero-day vulnerabilities, at least one of which was due to security certs stolen from a hardware vendor in Asia.. Sure, best practices were ignored wherein industrial centrifuge controllers should have been physically firewalled from any devices that connect with other networks or devices.

But seriously, stuxnet isn't as good an example of a glaring security incompetence as the recent HBGary intrusion. That started with a simple SQL injection, and ended up with executive emails revealing nefarious corporate dealings by a company pretending to be a security consultant.

Here is an EXCELLENT technical dissection of the HBGary attack. Nothing spectacular involved. Just nuts-and-bolts hacking with impressive results.

Seth

Give a damn

[Runaway1956]

Thank you, Anonymous Coward. You've helped me to figure out exactly why Linux is more secure than Windows. It isn't the operating system. It isn't the user. It isn't any application, set of applications, or combination of utilities. It's right there in your post. "average users wont start giving a damn" For the most part, Linux users are those who give a damn. The attitude - nothing more, nothing less. You've got to give a damn, or the best system is just a non-secure mess of code!

Re:Give a damn

[causality]

Thank you, Anonymous Coward. You've helped me to figure out exactly why Linux is more secure than Windows. It isn't the operating system. It isn't the user. It isn't any application, set of applications, or combination of utilities. It's right there in your post. "average users wont start giving a damn" For the most part, Linux users are those who give a damn. The attitude - nothing more, nothing less. You've got to give a damn, or the best system is just a non-secure mess of code!

I would add that there are reasons why systems like Linux appeal so much to this kind of user.

The biggest single one is that it doesn't assume you're an idiot. The system is built for users who intend to gradually become more and more familiar with how their systems work and how to maintain them. Users who traverse the learning curve at their own pace are rewarded with more and more ability to assume control and enjoy a system that does what they want the way they want to do it. You can also peek under the hood and see for yourself how things really work, with your skill level being the only limit. Generally things are made as simple as possible but no simpler, unlike Windows.

I would not classify Windows as easy to use, myself. I would call it easy to learn. Linux is quite easy to use if you have learned it. Learning how to use it is a one-time investment that continues to pay off. You can learn all about Windows but that won't make it much more convenient to automate, won't stop it from getting in your way whenever you try to do something advanced, and it won't stop it from trying to make you do things the way Microsoft intended.

The culture around Windows tends to encourage treating it like a black box and memorizing a set of steps to take in order to accomplish a specific task. The culture around Linux and Unix tends to encourage actually understanding how and why the tools work.

Linux also tends to be logical and predictable, the way you'd expect a machine to function. If something breaks, it broke for a good reason. It will stay broken until you fix it. When you fix it, it will stay fixed. You can actually get a meaningful error message that really does help you identify and isolate the problem. Windows has come a long, long way on these two points but it has yet to match the elegance of Linux and Unix. It's also helpful that all of the important configuration ultimately resides in plain text files. There is no opaque single point of failure like the Windows registry, which is a binary database that tends to become a mess over time.

I'd also say that the package management systems that come with Linux distros are vastly superior to the way software is acquired and installed on Windows. Instead of each third-party program having to chase down its own updates, often popping up nag screens requiring the user to complete the final step, you can update every last piece of software on your system with a single command. It's neater, less error-prone, and frankly less annoying. That counts for a lot considering how important it is to keep your system updated, considering how many Windows machines are compromised by exploiting already-patched vulnerabilities. Unfortunately I do not believe central software repositories would be possible on Windows, as the proprietary licenses of most Windows software would not allow third parties to redistribute them.

The users contributing the most to the rampant security problems are what I call permanent newbies. They hate learning new things. Somehow, they can use a tool for ten years without ever knowing much more about it than when they started. They don't even pick up knowledge here and there over time, let alone would they actively study anything. It is like they are too proud to do that. Asking them to do a bit of light reading for their own good is like asking an aristocrat to "fraternize with the help". It is a mentality to which I cannot easily relate. I cannot name anything non-trivial I do on a daily basis that I never learn new things about as I acquire more experience.

Re:Give a damn

[tsm_sf]

Managing an IT shop at a school, my biggest problem with the student workers was beating the "anyone who doesn't give a shit about computers is a stupid idiot" out of them.

I know it's a stage all geeks go through, but man is it irritating. The only thing that kept my rage in check was the knowledge that I was an even bigger douchebag at their age.

The thing to keep in mind is that for most of the planet computers are a means to an end. They are (and should be) practically invisible to the user when they work. The fact that we have to constantly harass users into sane behavior (e. g. "don't open that, it's a goddamn virus") isn't a reflection of their intelligence, it's a reflection of POOR DESIGN.

Re:Give a damn

[Bert64]

Well said...
Tools aimed at end users should be greatly simplified, they don't need a full blown computer with a complex OS, they need a simple system that satisfies whatever their individual needs may be (see ipad, games consoles etc). Leave complex general purpose computing to those who know how to deal with it.

Re:Give a damn

[causality]

Managing an IT shop at a school, my biggest problem with the student workers was beating the "anyone who doesn't give a shit about computers is a stupid idiot" out of them.

I know it's a stage all geeks go through, but man is it irritating. The only thing that kept my rage in check was the knowledge that I was an even bigger douchebag at their age.

The thing to keep in mind is that for most of the planet computers are a means to an end. They are (and should be) practically invisible to the user when they work. The fact that we have to constantly harass users into sane behavior (e. g. "don't open that, it's a goddamn virus") isn't a reflection of their intelligence, it's a reflection of POOR DESIGN.

That's one "side" of it if you like. Certainly I have never advocated that we make things needlessly complex.

I am wondering how best to explain this because it's a mentality, a willingness to invest, a recognition of a certain mental laziness. I'll concentrate on some basic everyday things, for computers have become everyday tools.

I know more about driving today than back when I first obtained my driver's license. I have learned by doing, through experience. Specifically this has to do with defensive driving, with leaving margin for error for both myself and other drivers, with not surprising other drivers, not being surprised by them even when they screw up royally, etc. I pick up things from time to time after having observed them empirically.

I know more about how to manage money today than I did back when I got my very first bank account. Same deal for the driving; I pick things up over time and I make it a point to remember them. For the 401(k) I learned where the money was actually going, what the various funds represent, how much risk they each involve, etc. In other words, I did my homework even though at least some of the time I could leave it alone and trust someone else to take care of it.

Now in both cases I could balk at the effort. I could refuse to invest in the things I do daily. Especially for driving I could make a bunch of excuses about how "it's not FAIR" that it can be so dangerous sometimes, that this isn't my fault, that everybody else should always obey the law, that I shouldn't be expected to have split-seconds to deal with the situations created when they don't, etc etc... basically the equivalent of "I am not a computer expert!" when what you're asking for is basic competence.

Likewise, "it's not FAIR" that some bad people just love to break into computers and use them for evil purposes. Am I going to whine about that and resent anyone who points out that I can take steps to mitigate it? Or am I going to accept it as a fact of life and plan accordingly, which (here's the apparently painful part for mainstream America) might involve having to read up on the subject? I know which one I would choose.

Besides which you actually enjoy life a bit more when you are more involved in how it plays out. When you actually have some appreciation for the interconnected complexity of the things around you, some sense of awe that it works like it does. When everything you touch isn't some black box but instead, a system that has fundamental principles which people have learned to harness. Especially when you have some confidence that you can handle unexpected problems that come up, not because you are such an expert but because you understand fundamental problem-solving and it's okay to have to do it sometimes.

Like I said I am attempting to describe a mentality. I believe this mentality, like so many things, is being sacrificed at the altar of convenience. The funny thing about that, is that few things would seem as inconvenient to me as the predictable, preventable problems so many people are having. Yet the idea that one should grow in knowledge and experience with sufficient time is one they soundly reject, and for that there are consequences. Not because I say so, of course, but because that's the nature of the situation and no amount of denial will change that.

What good is SQL injection...

[TheMidget]

... if you have no goatse.cx, nor goatse.cz, nor goatse.ch, nor goatse.fr to point the SQL-injected website to?

Re:What good is SQL injection...

[Anonymous Coward]

Goatse was never the only shock site. Hell, just redirecting to the website of their biggest competitor might cause a few heart attacks.

Re:What good is SQL injection...

[Anonymous Coward]

www.makemoniesonline.com == best site in the world.

Re:how is stuxnet an example of old vulnerabilitie

[Anonymous Coward]

Did you even read the summary?

They are saying that things like Stuxnet get the attention, but people are still having the most trouble with the basics, like HBGary you mentioned.

Not so much "hard" as "lazy won't make it".

[khasim]

Basic security is easy. Very easy. It's just not convenient.

The problem is that people are lazy. Even if it is easy, they want it convenient for them.

And when it becomes convenient for them, it becomes convenient for the crackers.

The more convenient for your users, the more convenient for the crackers. It's linear. If your users can access your systems from anywhere in the world, so can the crackers.

As seen with the HBGary crack.

A slightly different take.

[khasim]

In cases I have been exposed to, it's not the admins that are dropping the ball, it is the people making the decisions about things they do not appreciate or understand.

Most of the cases I've seen, of that type, have been ego issues.

They are management and YOU do NOT tell THEM what to do.

It is YOUR job to protect the network given the constraints of their requirements. If you cannot do that, well, there's another guy looking for your job who says he can.

derivation

[Gary W. Longsine]

It's derived from a prior expression: "There's no tools to fix stupid."

Re:how is stuxnet an example of old vulnerabilitie

[Goaway]

Well, I read the part that said "Stuxnet's Legacy", and then I foolishly expected some kind of legacy related to Stuxnet.

Most /.ers think technology is not to blame...

[master_p]

...but I think otherwise. Technology is largely (but not 100%) to blame for the security problems. Here are the reasons:

1) the usual programming language used for most desktop/system software (C or C++) has a lot of faults: unchecked array access, pointer arithmetic, arrays interchangeable with pointers, lack of non-nullable pointers, etc. This type of programming does not scale well in complexity and time.

2) the hardware, and more specifically, CPUs, do not provide a way to isolate software components within the same process, leading to an share-all-or-nothing approach. The share-nothing approach affects performance negatively, and so many software developers prefer the share-all approach, and thus a security breach in one component compromises all the other components.

3) the internet is not encrypted through out. DNS queries are raw text. Most web sites are HTTP. Without full encryption, there is no way to avoid man-in-the-middle attacks and phishing.

4) Operating systems do not provide a security model where sandboxing is the default. Normally, applications that send and receive data over a network should be run sandboxed by default.

5) Operating systems do not provide a well defined way of communication between software components with less privileges to software components with higher privileges, leaving this task to applications. Each application defines its own mechanism, which might or might not be secure.

6) The security models of operating systems do not extend beyond LANs. Over WANs, there is no security model.

7) no operating system uses capability-based security, which is one of the best ways to provide security.

8) SQL being text encourages copy and paste of the input to the SQL string, creating the Little Bobby Tables problem. Text should be internal to the API; SQL APIs should not provide the ability to write SQL text.

There are other issues as well; the above are just an example.

In the end, if a user is willing to let his machine be compromised, it will be compromised, no matter what. But I do not accept the fact that software and hardware is not to blame at all and that the software and hardware we have cannot be improved beyond what we've got now. H/W and S/W still have many design issues which are responsible for most security problems.

Security is not hard

[doperative]

"No matter how much companies (and individuals) would like to pretend otherwise, security is really hard to do. It's not just a matter of having the right technology in place; people have to follow some inconvenient rules and exercise self control and common sense"

No it isn't hard: seperate executable code from data, use read-only embedded devices to run your code, never download and run code over the Internet, run a second system that impliments a full irrevocable auditing trail.

Yes, if only...

[Anonymous Coward]

If only php had such an interface...

Oh, wait, I'm sorry, were you talking out of your uninformed ass to bag a "beginner" language that everybody here thinks that they are above and whore some karma points? Well, carry on then.

Hey, you are funny!

[marcosdumay]

1 - So, that is why buffer overflow is in evindence on "SQL injection, phishing, malicious attachments, social engineering"... Oh, wait, the author didn't even remember it exists. Also, post that at the "PHP code is flawless" section. People need unchecked memory access and pointer arithimetics, just because you never a saw use for it doesn't mean that there isn't one.

2 - There are plenty of ways to isolate code sections within the same process. Some of them are used all the time, others, rarely. Anyway, that has no relevance in a discussion about security.

3 - Keep it complex, stupid! Also known as KICS.

4 - You want to sandbox the software from the file system, right? I asked because it is not the only option, and one of the goals of every operating system is to sandbox processes. It is just that they usualy don't sandbox the file system. Ok, you also talked about applications, that means you weren't thinking about servers (where people do that kind of sandboxes all the time). Well, most people just don't want their browsers sandboxed.

5 - Err, they do. How would an application create a communication channel with the OS? They aren't allowed to do that.

6 - Humm, no. The security model of an operating system applies to the computer where it runs. For a network you need network security.

7 - Define it. Windows uses even the same name.

8 - KICS!!! It's a way of life! Also, post that under the "Nobody can hack a binary format" and "It's secure, I used the double ROT13 algorithm" labels.

Re:Hey, you are funny!

[master_p]

Oh, wait, the author didn't even remember it exists

So? unchecked memory access and pointer arithmetic has been established as a set of flaws that lead to security problems.

People need unchecked memory access and pointer arithimetics, just because you never a saw use for it doesn't mean that there isn't one.

I need it too, but it doesn't need to be the default.

There are plenty of ways to isolate code sections within the same process.

There are none. No CPU supports component isolation from within the same process.

Anyway, that has no relevance in a discussion about security.

I already explained in my post above why it is relevant to security.

You want to sandbox the software from the file system, right?

Not only the filesystem, but any resource a program should not touch.

that means you weren't thinking about servers

What I said is valid for servers as well.

Well, most people just don't want their browsers sandboxed.

No, most people simply don't care about that, as long as they get their job done.

How would an application create a communication channel with the OS? They aren't allowed to do that.

The protection should extend to all communication avenues, including system calls and other applications.

The security model of an operating system applies to the computer where it runs. For a network you need network security.

There needs to be a common security ground between operating systems.

Define it. Windows uses even the same name.

Please read the available online documentation about it.

post that under the "Nobody can hack a binary format" and "It's secure, I used the double ROT13 algorithm" labels.

If SQL strings were encoded in a such a way that the bytes preceding the string contained the string's length, then there would be no special SQL string characters, and therefore no need to filter the strings, and therefore no SQL injection.