Zero Days: How to protect yourself

Zero Days: How to protect yourself

Summary: The SANS Institute released its top 20 security risks for 2007, which documents the security arms race between cyber criminals and the folks playing defense. But let's focus on the big scourge--zero day attacks.

SHARE:
TOPICS: Security
33

The SANS Institute released its top 20 security risks for 2007, which documents the security arms race between cyber criminals and the folks playing defense. But let's focus on the big scourge--zero day attacks.

The report released Wednesday (press release) gives a nice overview of zero day attacks, recaps the year and provides some tips on how to protect yourself. The last part is particularly handy given that zero days aren't going extinct--Word, Office, Acrobat and RealPlayer were targets in 2007--any time soon. On the bright side, SANS says:

Several zero day attacks were recorded in 2007 although that number has dropped from the previous year.

However, a lot more can be done. Here's a look at SANS advice on thwarting the dreaded zero day.

  • Adopt a deny-all stance on firewalls and perimeter devices that protect internal networks. My take: Shouldn't this be a no brainer for most companies?
  • Separate public-facing servers from internal systems. My take: Hopefully a few retailers will read this.
  • Turn off unneeded services and remove user applications that do not support operational needs. My take: Prune those apps. It saves money too.
  • Follow the Principle of Least Privilege in setting user access controls, permissions, and rights. My take: Beware the insider.
  • Restrict or limit the use of active code such as JavaScript or ActiveX in browsers. My take: How will users enjoy the Web during work?
  • Educate users about opening unsolicited file attachments. My take: I can't believe fools still open stray attachments.
  • Disable the ability to follow links in email. My take: Users will revolt.
  • Disable the ability to automatically download images from the web in email. My take: So long HTML newsletters.
  • Maintain an aggressive in-house security alerting and warning service (or outsource the capability) to become aware of zero-day exploits as they become public. My take: This is doable and handy.
  • Use end-point management solutions to rapidly issue patches or workarounds as they become available. My take: Do we have a VP of patches yet?
  • If you use Microsoft's Active Directory, take maximum advantage of Group Policy Objects to control user access. My take: Access is everything.
  • Do not rely on anti-virus protection alone since zero-day attacks are often not detectable until new signatures are released. My take: Another blow to the AV market.
  • Use third-party buffer overflow protection where possible on all systems. My take: A no brainer.
  • Follow vendor recommendations on workarounds and mitigations until a patch is available. My take: This advice depends on quick vendor response.

Topic: Security

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

Talkback

33 comments
Log in or register to join the discussion
  • My take...

    if it's so dangerous and all... then stop using the internet all together. Come on let's be real here. I mean as much as I dislike Microsoft even I will admit that the last couple years have been pretty quiet on the scale of infections.

    Sure they still happen, but no where near the volume they used to AND the severity hasn't been all that bad either.

    In a nut shell things have been relatively quiet out there. Linux, Mac and Windows now seem to all share similar playing fields in the security arena. Then again... who knows, maybe there is some massive attack about to happen.

    Anyhow, the bottom line while I can agree with some of their recommendations some of them are pure fear tactics. ]:)
    Linux User 147560
    • No, it's a shift to stealth

      The number of attacks is growing, the sophistication of malware attacks is growing, and the "cracker" community theft rings are a HUGE growth industry. What we are seeing is the move from flash to low key. They concentrate on small scale under the radar attacks to silently extract/extort and steal their money. They are in it to make money, and by going the subtle route, they indeed are much more profitable. I would suggest that it is even more dangerous out there now that they are working diligently and very successfully to stealth their activities.

      They make more re-routing a few thousand DNS settings in some brand of router than bringing the net to it's knees with slapper.

      TripleII
      TripleII-21189418044173169409978279405827
    • Not fear tactics

      There's been shift from hackers showing what they can do to the world to hackers making boat loads of cash of data that can be used to drain bank accounts, blackmail corporations, sell to spammers or just sell to AV companies.

      What you aren't see is the worms that used be in the past. Now they don't spread as quickly to avoid detection. Also you have morphing malware that changes its signature every time it copies its self (good luck detecting that with AV software).

      People are just getting complacent because they are seeing hacker stupidity like the "I Love You" virus which really didn't do anything except spread.

      So if I were a hacker I'd put my skill to work being stealthy so I can build a bot network to deliver spam on mass and rake in a boat load of cash for it. If I do it right you'd never know it's happening. If I were more criminal I'd use my skills to gather personal info to sell to organized crime so they can steal identities.
      voska
      • Yup

        [i]If I do it right you'd never know it's happening.[/i]

        And that is why ebola, as a virus, isn't a particularly successful one. Simply put, it kills its host too quickly.

        [url=http://en.wikipedia.org/wiki/Ebola] Ebola [/url]
        [i]Its effectiveness as a biological-warfare agent is compromised by its extreme deadliness and its quickness: a typical outbreak spreads through a small village or hospital, affects the entire population, and then runs out of potential hosts, burning out before it reaches a larger community.[/i]
        NonZealot
        • Hey! NZ finally said something noteworthy!

          But unfortunately, most malware tools are acting like the flu, not
          ebola. It spreads more slowly, gestates for a period of time while
          it's spreading, then seems to explode all at once into an epidemic.
          This plants the germ into a new group of hosts and starts the cycle
          all over again.
          Vulpinemac
    • I Agree

      It seems most people would disagree with you and me but I agree that for the most part, the frequency and severity seems to have diminished over the years assuming one takes reasonable and prudent measures.

      Let's face it folks, if most home users would stop surfing porn, stop opening emails from unknown people, stop installing anything and everything they can download on-line, run AV software along with some anti-spyware/adware software and patch regularly, 99% of the problems go away.

      Much of the security industry uses FUD to create fear to sell their products.

      Now, grant it, the corporate world is a whole other issue. It is difficult (but not impossible) to secure a corporate network.
      rkuhn040172@...
  • One more to add to your list

    Ordinary worker bees should not have anything higher than user privileges - they don't need to install software or make system changes. Why this one simple step is taken so seldom is beyond me. This would prevent all of the drive by installs and the other invisible threats that use the admin privileges to install and run without the user's intervention.

    Score - a real no-brainer.
    Confused by religion
    • One thing

      [i]"This would prevent all of the drive by installs and the other invisible threats that use the admin privileges to install and run without the user's intervention."[/i]

      This is generally not true, unless several more restrictions are put into place. On every mainstream OS today (Windows/Linux/OSX/BSD/etc) admin/root rights are not required to introduce new executables into the system, and admin/root rights are not require to get infected and have your data stolen.

      The purpose of privilege separation is to protect the system from the user and to protect users from other users. It cannot protect the user from themselves.

      More advanced security mechanisms like SELinux, App Armour, Windows policies are something that can begin to address this issue.
      toadlife
      • 100% right

        [i]On every mainstream OS today (Windows/Linux/OSX/BSD/etc) admin/root rights are not required to introduce new executables into the system, and admin/root rights are not require to get infected and have your data stolen.[/i]

        I shouldn't be amazed by how many people believe that the only way of introducing code onto a machine is by installing it via a setup program/package manage. [i]You can't install programs in OS X without the admin password so drive by infection is [b]impossible[/b].[/i] Considering how powerful *nix shell scripting is, you don't even need to introduce an executable, a shell script is just fine.

        [i]The purpose of privilege separation is to protect the system from the user and to protect users from other users. [b]It cannot protect the user from themselves.[/b][/i]

        Nicely phrased.

        [i]More advanced security mechanisms like SELinux, App Armour, Windows policies are something that can begin to address this issue.[/i]

        Add IE7 Protected Mode to that list. IMO, when you look at the amount of damage caused by each attack vector, IE7's Protected Mode is going to make more of a difference than UAC.
        NonZealot
        • Even scripts

          which are essentially executables on *nix, they don't get downloaded with execute permission. So any .bin, .sh, etc, it just isn't possible to automatically infect even the user's space without a manual step (or tandeming the malware with an as yet unknown flaw in the browser).

          TripleII
          TripleII-21189418044173169409978279405827
          • Missed the point

            [i]So any .bin, .sh, etc, it just isn't possible to automatically infect even the user's space without a manual step[/i]

            We are talking about whether [b]root[/b] permissions are needed in order to introduce executables into the system and the answer is no. Since the current user is able to chmod their own files, so is any code that gets executed as part of a buffer overflow or URI handling flaw, etc. The defense is that drive bys are impossible because [b]root[/b] permissions are required to introduce executable code into a Linux/OS X system and that is simply not true.
            NonZealot
          • I agree, but you are off topic

            Originator of thread
            [B]his would prevent all of the drive by installs[/B]

            Anyway, I agreed that some programs, depending on packaging can be installed in the userspace, but they are NOT the norm. In the user space, yes, at a system level, no.

            I'll defer until the first ever drive by install on any *nix happens.

            TripleII
            TripleII-21189418044173169409978279405827
      • Not Drive By though.

        Drive by installs are not possible (the norm, exploit exceptions probably exist). Not a single Browser (not sure about IE under wine) native to Linux will download an executable and give it execute permission. The first step is always a manual (or through a file manager), chmod +x. Drive by installs are simply not possible.

        I agree, if a user does download, give execute permission, etc, you can't protect against that.

        [B]On every mainstream OS today (Windows/Linux/OSX/BSD/etc) admin/root rights are not required to introduce new executables into the system,[/B]

        That needs to be clarified, root is absolutely needed to write to any system directory. Some linux programs can be installed local the user's directory (firefox, netbeans, etc), however, infecting system files without root is not possible (except for an escalation exploit). You simply have to love ext3 or Resier or whatever, built right into the filesystem, the control you need. That makes it harder because the malware has to not only find a way to run but to install in non standard directories cause it will die writing to /usr/bin.

        Note: just clarifying, you are right, nothing anyone can do (except admin with apparmor) to protect a user determined to install that must have malware infected screensaver.

        TripleII

        P.S. That's why I am not particularly enamored with FF plugin installer, there is little control to many untrusted plugins and malware in that way could gain access to a running program (firefox) which can spawn others in the user space.
        TripleII-21189418044173169409978279405827
        • Not correct

          [i]Not a single Browser (not sure about IE under wine) native to Linux will download an executable and give it execute permission.[/i]

          Not a single browser native to Windows will download an executable and run it without user interaction (the norm, exploit exceptions probably exist). In fact, XP SP2 introduced something that OS X users are just getting now in that executables and certain data files (like XML) are tagged as "untrusted" when downloaded to disk and you must explicitly remove that flag in order to run/open the file. It isn't called an execute bit but it performs the exact same function.

          [i]The first step is always a manual (or through a file manager), chmod +x.[/i]

          This also is patently false. Files are untarred with whatever permissions they were tarred with so no, chmod is not required to give remote programs the execute permission. Also, I don't believe shell scripts need the execute permission if you invoke them with 'sh somescript.sh' although I would have to double check that.

          If your point is that downloading and executing code is harder to do in Linux because of the execute bit, I'll politely disagree since Windows also forces you through manual steps to execute code you download. However, the execute bit is off topic since this is about being able to introduce foreign code without root permission and even you admit that this is possible in Linux.

          [i]You simply have to love ext3 or Resier or whatever, built right into the filesystem, the control you need. That makes it harder because the malware has to not only find a way to run but to install in non standard directories cause it will die writing to /usr/bin.[/i]

          Um, NTFS has had this since 1993. I don't say that to suggest Windows has had this longer, only that this has been a part of Windows for a very, very long time. In fact, ACL extensions have recently been added to the above mentioned file systems because in some cases, ACLs are more flexible than what is possible with the traditional ugo system. I've been immune to 99% of Windows malware since 2000 since I never ran with admin permissions and nearly all Windows malware would fail trying to write to the Windows\System32 directory.

          Note I'm not suggesting Linux is worse, only that you have used examples trying to show that Linux is better when it turns out that those examples also have Windows equivalents. They may not be called the same thing (ACL vs ugo, execute permission vs untrusted source) but they perform the same function. Also, in the case of the execute bit, it seems that you place an unjustifiable amount of faith in its ability to prevent foreign code from executing (and note, again, I'm not saying Windows' untrusted source is any better). Neither prevents foreign code from executing and to say that exploit exceptions exist is like saying we don't need to breathe although exceptions to that rule occur every couple seconds.
          NonZealot
          • A tar is not an executable

            [B]Not a single browser native to Windows will download an executable and run it without user interaction[/B]

            XP SP2 on, I would generally agree, however, drive by installs by the billions happened before ActiveX was reigned in.

            [B]Files are untarred with whatever permissions they were tarred with so no, chmod is not required to give remote programs the execute permission.[/B]

            OK, this drive by install is impressive! :D

            It silently downloads a tar file, extracts it using ? did the user install gunzip, zip, tar, etc? Anyway, after that, it executes the extracted executable, mind you, correctly now detecting that it is not root and then discovers how to install itself in the userspace, replacing the file FireFox with it's version. And what is accomplished?

            1) It can't start itself on next boot, meaning it has to somehow convince the user to start it every time?
            2) The system is configured to run firefox from /usr/bin and so even after spoofing itself, it can't change the link or the path to allow for it's version to be executed next time.

            It is just way too much. Now, I agree, nothing will prevent or help a user from themselves if they really want that malware infected widget, but drive by installs, even in the userspace, I simply have to wait for any example to ever happen.

            TripleII

            P.S. I think we are both arguing two ways to say the same thing. It is technically, not physically impossible for all the above to come together to cause a drive by install, but, like I said, that's a heck of a drive by. LOL
            TripleII-21189418044173169409978279405827
    • Already in the list

      "Follow the Principle of Least Privilege in setting user access controls, permissions, and rights. My take: Beware the insider."

      The principle of least privilege covers only giving users what they need to get the job done. User don't need admin privs to get the job done.
      voska
  • turn on Data Execution Protection

    It's free, and you probably already have it!

    This should be another nobrainer, but raising awareness seems nearly impossible. Data Execution Protection will stop virtually all buffer overrun attacks. Most processors built in the last 4 years or so supports it. It's built-in to Windows XP and Vista, but only enabled for Windows core function. Just turn it on for everything!
    diane wilson
  • RE: Zero Days: How to protect yourself

    Education is the key here. Its amazing that so many users have no idea of the threats out there. Do they even care?
    Hard to tell.
    spywarebiz@...
    • Zero Days

      I really do not know who you are indicating as far as "Users have no idea of the threats out there. Do they even care"? I do and I know a a lot more that do care we do not just sit hear on this thing a write. I work and ck Zdnet ever chance I get. So Please do not think we are all idots.

      sk04x5_1
      sk04x5_1@...
  • RE: Zero Days: How to protect yourself

    Separate public-facing servers from internal systems. My
    take: Hopefully a few retailers will read this. No brainer.
    ol_pip