Forgot your password?
typodupeerror
Businesses Security The Internet News

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

Posted by samzenpus
from the all-your-files-are-belong-to-us dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Security is hard (Score:5, Insightful)

    by Anonymous Coward on Wednesday February 23, 2011 @04:04PM (#35293092)

    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.

    • Exactly. Vigilance ... and trying to protect clients/users/family from themselves ... is the only way to be sure.
      • by AvitarX (172628)

        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.

        • 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
          • by Duradin (1261418) on Wednesday February 23, 2011 @05:33PM (#35293934)

            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.

            • 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 [arstechnica.com] http://arstechnica.com/tech-policy/news/2011/02/black-ops-how-hbgary-wrote-backdoors-and-rootkits- [arstechnica.com]
              • by mjwx (966435)

                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 vecto

              • 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.

            • by roman_mir (125474)

              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 :(

      • >>>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 (Score:4, Interesting)

          by dudeman2 (88399) on Wednesday February 23, 2011 @04:52PM (#35293562) Homepage

          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.

          • 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.

            • by vegiVamp (518171)

              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.

    • by MstrFool (127346)

      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 br

      • by 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

        • by MstrFool (127346)

          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 does

    • 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.

    • by blair1q (305137)

      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 ensu

      • 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.

        • by blair1q (305137)

          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..."

          • 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.

      • by Draek (916851)

        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 programme

    • by dkleinsc (563838)

      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.

      • by grumbel (592662)

        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.

    • 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 hol
      • Re: (Score:3, Insightful)

        by maxume (22995)

        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.

    • by Andy Dodd (701)

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

      • It's derived from a prior expression: "There's no tools to fix stupid."
      • 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: (Score:3, Insightful)

      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 i

    • by mlts (1038732) *

      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.

    • 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.

    • by hairyfeet (841228)

      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

    • by gbjbaanb (229885)

      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 m

      • 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 d

    • by hitmark (640295)

      "common sense" is anything but common...

  • by IgnitusBoyone (840214) on Wednesday February 23, 2011 @04:06PM (#35293118)

    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.

  • 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.

  • by Dunbal (464142) *
    Maybe one day people will take little Bobby Tables [xkcd.com] seriously. Frankly there is no excuse for stupidity. But you must bear in mind also that we will never run out of stupid people.
  • Perspective (Score:5, Insightful)

    by TheRealMindChild (743925) on Wednesday February 23, 2011 @04:08PM (#35293134) Homepage Journal
    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.
    • by Dunbal (464142) *
      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!
      • by AB3A (192265)

        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!

    • 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.

      • 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 (Score:5, Insightful)

        by Rary (566291) on Wednesday February 23, 2011 @04:31PM (#35293346)

        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.

        • "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 a

        • by mcrbids (148650)

          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

    • Re:Perspective (Score:5, Interesting)

      by COMON$ (806135) on Wednesday February 23, 2011 @04:25PM (#35293284) Journal
      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.

  • by arth1 (260657) on Wednesday February 23, 2011 @04:08PM (#35293136) Homepage Journal

    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.

    • 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.

  • by Culture20 (968837) on Wednesday February 23, 2011 @04:10PM (#35293150)
    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.
  • 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.
  • 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!?!"
    • by mcmonkey (96054)

      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

      • "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 acceptin

    • 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.

    • by sjames (1099)

      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.

  • 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

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

  • 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

    • 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."

  • As long as humans are part of the equation, security will always be weak.
  • by Animats (122034) on Wednesday February 23, 2011 @04:50PM (#35293536) Homepage

    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.

    • by Shados (741919)

      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 t

      • by TheCarp (96830)

        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

        • by Shados (741919)

          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

      • 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.

        • by Shados (741919)

          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 n

          • 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. Someth

            • by Shados (741919)

              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.

  • Besides "SQL injection, phishing, malicious attachments, social engineering", what other types of realistic attacks are there?
    • by hesiod (111176)

      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!

  • 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 [arstechnica.com] of the HBGary attack. Nothing spectacular involved. Just nuts-and-bolts hacking with impressive results.

    Seth
  • ...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 with

    • 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, th

      • by master_p (608214)

        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 don

Some people have a great ambition: to build something that will last, at least until they've finished building it.

Working...