Why is security usually an afterthought?

Why is security usually an afterthought?

Summary: You can stumble onto an ActiveX vulnerability with a little help from Google and a 5 minute tutorial on fuzzing. When you ask and technology executive about potential security issues with virtualization you get a blank stare.

SHARE:
TOPICS: Software, Security
24

You can stumble onto an ActiveX vulnerability with a little help from Google and a 5 minute tutorial on fuzzing. When you ask and technology executive about potential security issues with virtualization you get a blank stare. And we're stuck on this patch-go-round that never ends.

All of these issues are side effects of one illness: The software industry and the customers that implement applications rarely think about security first. You see it with Web 2.0 apps, shoddy browsers and the huge patches (basically code rewrites) that plug holes in some of the more favorite Web software (IE, Skype, QuickTime etcetera). Does it strike anyone as odd that we were hit by patches for four major vulnerabilities in 24 hours this week?

Here are the priorities among software developers:

  • Cook up applications quickly;
  • Gain massive distribution;
  • Get people to install it;
  • Monetize it.

Among customers the priorities go something like this:

  • Save money;
  • Ease of use;
  • Ease of installation;
  • Enable the business somehow (and save more money).

In this state of affairs little things like security is bolted on once these applications are widely adopted. Does that make sense?

Why should we need an attack on (pick your hot software of the moment) to think about security and all of the processes that enable it? The only explanation is that developers and software companies are lazy and know there's no immediate return. It's a far easier business model to turn out crappy software and then sell us stuff to fix it. Bizarre.

Simply put, security would be a lot better if companies gave just a smidge of forethought to vulnerabilities. Sure there are a few bright spots--I thought MySpace's move to put its third party apps through some security testing before unleashing them to users was a great idea. But far too often I'm wondering why security isn't at least thought about a bit before we move on to the latest and greatest thing.

Thoughts?

Topics: Software, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

24 comments
Log in or register to join the discussion
  • The reason it isn't a priority among customers

    is because when you get a list of goals from your boss, rarely is security of data at the top of the list. It is in some business sectors, but in most sectors when an employee gets his list of goals to accomplish, it says things about getting the job done right, getting the job done on time, and staying within budget. But security is merely assumed to be achieved through common sense approaches. Meaning as long as there is no intentional security breach, that's the main concern, otherwise software is assumed to work as planned.
    Michael Kelly
    • Also...

      Not only that, but a lot of the customers are still using the mentality "it's never going to happen to me" or "it'll never happen here, it's too secure." But those people don't realize that it's extremely easy to have any kind of security breach unless you take specific measures to not allow it to happen. They think that just because a breach hasn't happened, it never will, and so they are safe to do as they please or go where they want without taking precautions.
      ilovebacon
  • Well, completely agree

    In the early 1980's, truly object-orientated programming languages became available for general use. With these, it is duck soup to code up and test very useful modules that you can just plug in to provide safety actions.

    An example - a controlled String object. Manages its own memory, refuses to write beyond buffer size you tell it on creation. Can easily add safe versions of any operations you want to apply to it. Extensible later without busting any earlier code whatsoever. Part of the example framework for C++ and doubtless other languages like Java that I don't remember.

    What more could you want, right? But most programmers never did learn to think this way. To be fair, the team developing C++ became far more concerned about esoteric details and perfections few could understand, so that the community bothered with little of it.

    Another factor may have been the difficult modules many had to deal with outside their own code: multimedia players that hardly worked; web browsers ditto, and so many thread-based activities that nearly no-one understood or had not been designed accurately in the first place, so that they failed in real use in extravagant ways.

    So much wheel-spinning because coders at most levels didn't do quality or depth knowledge, or forethought either.

    I know they often wished to understand better, but experience says not so many of them did.

    Now we reap the consequences, when there is a profit, and it may be also a politics, for some in taking advantage.

    Not fun. But on the other hand, maybe we are finally learning something about making software adapt. Another subject....

    Regards
    Narr vi
  • Featuritis, software bloat and lack of knowledge

    These are, I think, the main reasons why software is insecure. There is too much thought put on extra features without going through a security audit. There is very little attention paid to the number of lines of code, and there is an amazing lack of knowledge among the users. For computers,instant gratification rules, and, with parallels to real life, these have their inevitable side effects.
    nilotpal_c
    • fun, you know, in doing it right

      It seems something one should say, that it is actually fun to encapsulate and make intelligent parts that interestingly couple and work together.

      When you start calling it 'security audit', then the fun stops.

      I suspect there is a great deal in this, the grey maneuver, that has stopped good thinking in its tracks.

      For it is imagination that is taking advantage of these flaws and their openings; and seems very likely that encouraging imaginations is what will get the foresight in motion to avoid having them available.

      Doing better...welcome tendency to have come to mind on a Friday...
      Narr vi
  • Desensitized

    Pick a program. Active-X, QuickTime, Real (the particular application doesn't matter, they are all/have been security jokes). The consumer public has been desensitized, or actually convinced that security is NOT actually important in any given product.

    That's why it is SOP to have Anti-Virus, Anti-Malware, add on firewall, Anti-Spam, ISPs touting security tools, XYZ-Removal programs, professional re-installs. All of this is SOP. Now that we are in an era where consumers think getting botted is NOT the OSes fault (not phishing), or their OWN fault (didn't have the most up to date XYZ version running on my computer), vendors have zero incentive to code securely.

    I have read a thousand posts on ZDNet where users get blamed for getting infected, or apologizing for whomever (no, not including phishing attacks, just the automatic exploits), and it astounds me.

    It is a sad state of affairs to be sure, and I don't see it changing any time soon (eventually it will, Linux folks look at what is SOP for windows users as an example and scratch their heads).

    The above translates into make it work, just work so we can sell it. Security is not our problem (ok, we'll patch after the fact when ZDNet finds an exploit, or secunia makes a stink, but hey, we'll turn that into PR Spin showing how great we are)

    TripleII
    TripleII-21189418044173169409978279405827
    • ActiveX is not an application

      it is a specification. And it is possible to write safe, secure software using ActiveX. Just look at the banking systems in South Korea. They used ActiveX extensively, and put out services better and faster for it.

      One problem with ActiveX is the same problem with any specification or language: people are willing to write crappy software regardless. Just because Facebook didn't write a safe plugin isn't ActiveX's fault. It can be done, they didn't take the time to do it.
      mdemuth
      • ActiveX is a DLL--that's an application from where I come from

        nt
        D T Schmitz
        • Then they should learn to read

          wherever it is you come from

          http://en.wikipedia.org/wiki/ActiveX

          It would be like blaming C++ for buffer overruns.
          It is the programmer misusing it that is the problem
          mdemuth
          • Buffer overruns...

            ...don't matter if your app's memory space is in a 'sandbox', right?
            See my threads below (It doesn't matter).
            I don't think we need to revisit an old story do we? :)
            D T Schmitz
      • Holy irrelevant tangent BatMan!

        Let's replace ActiveX with IE 6.0, original. Then you get my point, it has become SOP that security is NOT a particular vendors primary concern (look at IE7, it didn't come about because of security concerns, it came about because of FireFox), it is up to third party applications and is the customers fault, and the customer has come to believe it is true.

        TripleII
        TripleII-21189418044173169409978279405827
  • Security afterthought creates jobs in the IT....

    industry so it can grow and employ more people. How else would our society survive without the economics of it? If you sit back and think of the billions that go into and from products and the fact we have no manufacturing of practically anything it makes total sense!
    fredfarkwater
  • Without speghetti code and releasing beta-quality programs

    IS/IT, as an industry, wouldn't grow nearly as fast.
    nix_hed
  • It doesn't matter!...

    ...if your internet session is running in a 'sandbox'.

    Windows Users:

    Install
    1) [url=http://vmware.com/download/server/]VMware Server[/url] (FREE as in Beer!)
    2) Install from VMware openSUSE 10.3 image (FREE as in Beer!)
    3) Enable AppArmor FireFox sandbox scripts (FREE, I also have them [url=https://dietrich.mymobilesite.net/pub/]here[/url]
    4) Make your VMware image 'read-only' by activating snapshot from VMware console menu (VM>Snapshot>Take Snapshot)

    You now have a read-only 'sandboxed' Firefox browser running in openSUSE 10.3 Linux.

    No worries. Bullet-proof.
    Safe Surfing Folks.
    D T Schmitz
    • P.S. openSUSE 10.3 KDE VMware image here

      [url=http://vmware.com/appliances/directory/1083]Here[/url]
      D T Schmitz
    • VM Article

      Folks, [url=http://www.techthrob.com/tech/linux_virtualization.php]here[/url] is a current article on the various VM offerings at your disposal.

      Master the possibilities!
      Be Safe.
      D T Schmitz
    • Wrong answer

      You are depending on the security of VMWare, which has been shown as flawed. There's still communication to the host, and that is a vector for overflow.

      http://secunia.com/advisories/18162/
      http://secunia.com/advisories/26890/
      rpmyers1
      • N/A; It still doesn't matter

        I can [url=http://en.wikipedia.org/wiki/Fuzz_testing]fuzz[/url] test applications for hours on end in a lab environment and eventually I might find improper handling of stack/heap, function parameter passing of null-terminated strings.

        But that doesn't necessarily mean an end-user will experience an exploit because of its discovery.

        Your first reference is for an advisory from 2005 which doesn't reference VMware Server.

        Your second reference is for VMware Server 1.x and specifies:

        /****
        1) An unspecified error can be exploited by a user with administrative privileges in the guest system to cause a memory corruption on a certain host process.
        ****/

        A highly improbable scenario, unlikely to occur in 'real-world' circumstances.

        Besides, running Firefox profiled with [url=http://en.wikipedia.org/wiki/AppArmor]AppArmor[/url] in a Linux virtual machine 'sandbox' makes these advisories essentially meaningless.

        Even if there was a buffer overflow in FF in this context, as a general user (vs root) it would not propogate past AppArmor out of the Firefox memory space and as such the process would be 'killed' at the point of the privilege escalation attempt by AppArmor.

        So, again, I maintain that it doesn't matter. Thanks.
        D T Schmitz
  • Poor Foundations

    I think a great deal of this is tied to weak foundations.

    Windoze is laden with security holes. By running our code under Windoze, we automagically "inherit" problems.

    Then we use languages like C to write our code in. C is deceptive: it looks like a high-level language, but in reality was specifically designed to be a front-end to assembly language. C compilers behave differently from each other, and generally provide very little to prevent the programmer from doing stupid things. It was never meant as an application language... yet the majority of programming langauges since then have proudly denounced themselves as being "C-like"!

    How pathetic.

    Significantly more secure OSes have been around longer than Windoze. Significantly better programming languages have been around longer than C. It is this push by so-called "modern" users to use the latest, most pathetic technologies that causes so many of our problems.

    We do it to ourselves.
    fde101
  • RE: Why is security usually an afterthought?

    Spoken like a true non-programmer.

    1. It is bloody hard to avoid security holes when developing in current languages.
    2. If programmers refuse to develop in current languages they won't find employment.
    3. It is hard to quantify the probability of security holes being present in software. It is even harder to quantify the exploitability of those holes.
    4. How do you quote a figure for developing '100% secure software?'
    5. Project management allocate resources for security testing eg: 'fuzz testing' before deployment, not programmers.
    6. Fuzz testing is random testing -
    7. Who audits the code of libraries and third-party software incorporated in a product? - e.g. apache for exmple.

    I think the solution is to equip progammers with more security aware development languages and tools. Budgeting for a security audit of code, and the overall environment. This will often require a security expert on the development team, and will increase development cost.

    Simply telling developers to put security first is a fantasy. There are too many other pressures, and just giving a damn is not enough.
    Rhend