Fred Avolio's Musings

iChat Status

musings on security and other topics topics archives
August
Sun Mon Tue Wed Thu Fri Sat
   
31    
most recent headlines other links, other blogs  

Thu, 31 Aug 2006
Disposal of Data Disks

Recently, I've used Active@KillDisk to remove data from some old hard drives from obsolete computers before taking them to the dump. You know … making sure there is no personal data of any kind left on the old disks.

Today, I read PDAs sold on eBay 'loaded with sensitive data'. The video this points to is interesting. Granted, this was motivated by marketing: the company who bought these phones on ebay and performed the tests sells software to secure these hand-held systems. Nevertheless, the results seem to be real.

Does your company have a policy for computer dispostal? Does your company have a policy for disposing mobile phones and PDAs? Does someone in your company know how to do a "zero-out reset" on these devices?

Comment on this.
[/security/] permanent link

Top Ten Security Threats

Background: This is from a 3 or more year old course I gave in support of what I say in The same old stuff further in support of Top Five Reasons Why I Hate Network- and Computer-Security. In short, this is old and, yet, is still relevant. (Kinda like me.)

When we consider Internet system security, these are what I consider to be the top ten security threats.

Default Install
All types of systems are vulnerable to this: desktops, servers, appliances, routers … anything that can be configured. Personal computers and servers often have unneeded services running. And although No security updates VATs can help So can proper policies with proper implementation

Passwords
There are multiple problems here, The first are demo or guest accounts. (This also can be considered part of the Default Installation problem, as many default installations come with preset passwords.) Easily guessed passwords are almost as bad. Guessed passwords do not necessarily provide complete control, but they do provide a foothold. And a foothold is an attackers "Step 1."

There are, of course, solutions to this. An enterprise can set password policy, but then has to back up policy with policing, using many of the password checking and scanning programs available. Even better, is to replace user-id/password with 2- or 3-factor authentication, including security tokens and biometrics. Recently, when I have taught a course, I ask who has 2-factor authentication. I am pleased to see that the percentage of raised hands is on the rise. Still, most hands remain down.And still, like most things "security," strong user authentication is an "add-on."

Bad Backup Policy
Most enterprises do a decent job here, but many do not consider backing up teleworkers' computers. And many do not routinely verify backups.

Open Ports
This is still a problem on many gateways. (" Default deny" still has not caught on, even though done correctly it is nearly invisible and protects better than " default allow.") On our servers, desktops, and gateways we have opened unused network ports and used ports that are not required. Think of a house with 65,537 open doors.

Lax filtering
IP Spoofing is still used. Do not allow your gateways to pass any source-routed packets

Bad logging practice
Unread logs are not very useful. Logs that are incomplete are worse.

CGI Scripts
Common Gateway Interface scripts are necessary for all but the most basic web pages. The risk is to the web server. Web servers come with example code. Some of that example code has, in the past and today, contained exploitable bugs. (See CGI Script Source Code Disclosure Vulnerability in Apache for Windows.) The solution? Write your own code, if you are able, and test, test, test.

Remote Procedure Calls and Remote access
RPCs allow one computer to run a program on another computer. Buffer overflows and other security weaknesses can and have led to an attacker running a program on the local computer. Unix, Windows, and Mac OS X systems run RPC servers. Global file sharing is a potential point of vulnerability. Do you know what the default settings are on your computers? Firewalls can stop connections. Do yours? What about your teleworkers?

Browsers
There are "necessary," but remember: all popular browsers—IE, Opera, Mozilla, Firefox, Camino, Safari, Netscape, Konqueror, Avant Browser and Maxthon—have had reported vulnerabilities. All are subject to spoofing vulnerabilities. (Check your browser out at http://secunia.com/multiple_browsers_dialog_box_spoofing_test/.) Also, browsers (and so, client systems) may be vulnerabile to Java and Javascript vulnerabilities. Errors in the Java or Javascript system could allow a web page to trigger a local user action (anything the user could do locally). Any active code on a web page follows this same basic idea: the web page based program is downloaded and executed, and the browser makes sure the operation stays contained. This is apparently very hard to get right. See Cross platform javascript vulnerability leaves IE, Firefox open.

Enterprises should strip Java or Javascript from HTTP traffic at the firewall. Users will be up in arms over it. It doesn't help with HTML e-mail messages. E-mail Acceptable Use Policy: Disable all HTML, Java, JavaScript, VB, and any other interpreting in e-mail reader

Outlook
Okay, really any fancy e-mail client that:

  • Automatically renders Java, JavaScript or ActiveX.
  • Automatically launches dangerous applications, remembering that any "helper" program may be dangerous (browsers. Picture viewers, Word, PDF viewer).

    If you are stuck with Outlook, turn off some features:

    • Any that users do not really, really, really need. (Disable them and wait for complaints. Then selectively add.)
    • Do not allow Outlook to auto-display HTML
    • Disable Java, JavaScript, ActiveX and VBS controls (under Internet options)
    See The Things I Hate About Outlook and Outlook—Just say "no".

    Further, be very selective in what attachments your organization will admit through an e-mail gateway or firewall. Does your enterprise require .scr, .bat, .com, .exe, .dll files? Start with what it needs. Disallow all except the ones you absolutely need. (See Buried in Swen! from 2003.)

    This was my top ten security threats list. These are not the top ten security threats that keep me up at night. All of these have some kind of reasonable mitigation, none of which are useful unless they are implemented.

    Comment on this.
    [/security/] permanent link

  • The same old stuff

    This is the second of the Top Five Reasons Why I Hate Network- and Computer-Security. And I will give some examples.

    Example #1: My friend Dave Piscitello points to a NetworkWorld article he wrote, Neglecting identity management. It is part of a series, and he mentions the others in his Blog #550. In it he lists the other "Six Worst Security Mistakes." And his blog proves my point, as every one of them, including his, could have been a magazine article 5 or 10 years ago.

    Now, hear me clearly: Dave's article is, of course, excellent. My point is not that his or the others are somehow not relevant. My point is that they should be old news, at least when it comes to proving the point. Mechanisms and methods change. The fact that identify mangement is not to be neglected, or that training is important, or that product "bells and whistles" should not be a security selection criteria (in the early 1990s the flashiest not the most secure-able firewall "won"), or that one needs a security architecture (and most companies would benefit from a policy for a plan), does not change my point. We are talking about these things—and writing multi-page magazine articles—like it is all new stuff. We didn't get it 5 or 10 years ago. We'll get it now?

    I will give another two examples. I pulled some examples out of my presentation folder from two courses I used to give for the Computer Security Institute. I will blog on each and I think you will agree that they are still accurate. They are from 2003 and 2004. The examples were old and relevant then.

    Example #2, Top Ten Security Admin Errors.

    Example #3, Top Ten Security Threats.

    By the way, I talk about the same old stuff in a blog entry from 2004 in Security Redux. It, too, proves my point.

    Comment on this.
    [/security/] permanent link

    Top Ten Security Admin Errors

    Background: This is from a 3 or more year old course I gave in support of what I say in The same old stuff further in support of Top Five Reasons Why I Hate Network- and Computer-Security. In short, this is old and, yet, is still relevant. (Kinda like me.)

    #10: No or Outdated Security Policy
    The reasons for this are many, including:

    • We dont know how to start.
    • We want to get it righ, so we delay.
    • We dont have the resources (staff, money, time) to get to it.
    • Things are moving too fast.

    Examples are also manifold, including:

    • Mainframe policy in an internetworked world. Or similar (more up-to-date-now), the policy was created 5 years ago when we were a 30 person company and before all of those mergers.
    • Doesn't take into account remote or teleworkers.
    • Doesn't cover all user types. That is to say it treats all users (Sales, Sales reps (not employees), Contract workers, Business partners) the same.

    #9. Lack of Senior Management Understanding/Buy-in
    They don't understand the expense, the costs, the liabilities, or the risks. They equate security with the last large expense the company made, the "Security=Firewall" phenomenon.

    This is from a posting on the firewall-wizards mailing list:

    Is there anybody out there that can help me get some configurations right on our new Gauntlet firewall? I have never configured a firewall before and have not had training and this is very important to our company so I am feeling the pressure here. Any help would be apprecaited.

    To which I replied:

    "Can anyone out there help me learn to drive an 18 wheeler? I was hired to do this and I have a truck supplied by my company. I have a driver's license for an automobile, but I've never driven a big rig before, nor have I had any training in one. It is very important to my company that I get this right and I have to start a cross-country run on Wednesday. Any help you other drivers can offer in your spare time as you pass through will be greatly appreciated>

    #8 and #7 No Audit Logs or Unread Audit Logs
    This is neglected because enterprises don't know what to do with them or how to handle them. (Okay, maybe this has gotten better. You think?)

    #6. Leaving the Door Propped Open
    Enterprises are still creating one-time changes to their security posture that end up being permanent, because they are forgotten. "I just need to do this one thing." "Open this up now, and I will call you when I am done." "We have this customer demo."

    #5. Exceptions
    They might be needed, but are they? The more exceptions, the lower the security posture of the enterprise. And this is linked to #6.

    #4. The Big Boss Problem
    Every organization has someone high enough in the organization to be able to make a decision that put the enterprize at risk, but lacking the knowledge or information to make it an educated decision.

    #3. Network Service Requests Before Establishing Business Requirements
    I mean think about these services that are allowed with no real business need:

    • Streaming media from the Internet
    • Instant Messenger
    • SkypeTM
    • Access to my Hotmail, et al. accounts

    #2. Allowing Network Services Without Assessing Security
    This is almost meaningless nowadays as nearly everything works through today's porous "firewalls." Do we allow SSL through our firewalls? SSH? Can our people use NetMeeting? Of course. Have we weighed the risk? Often, of course not.

    #1. User Wants Disguised as Requirements
    And solutions disguised as requirements.

    • I need NetMeeting. Translation: I need (maybe) inexpensive teleconferencing.
    • I need port 2592 open on the firewall. Translation: I want to play Netrek.
    • I need access to my hotmail account when at work. Translation: I am running a business on the side.

    Comment on this.
    [/security/] permanent link