8/31/06

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?

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

The same old stuff

This is the second of the Top Six 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 management 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.

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 Six 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 don't know how to start.
  • We want to get it right, so we delay.
  • We don't 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 enterprise 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.

8/30/06

More on Stolen Notebook* PCs

Just a short one on this, as this problem has become commonplace. The solution is trivially easy. We just don't do it. The VA has finally got what they should've known before losing personal records. See VA buys encryption tools

Earlier I talked about this in January 2005 and April 2005. In this USA TODAY article, Jon Swartz writes, "Encryption can be pricey. Gartner estimates a company with 100,000 customer accounts can spend $30 to $40 per laptop on data encryption. Yet, the cost of a data breach is even higher." So, when will we start thinking "security" along with the initial purchase? Pracically speaking, AV software is free (at least for the first year). Both XP Pro and Mac OS X come with "free" disk encryption, don't they? (See Laptops and PII Losses.) We've been talking about this for years and have known the answers.

I am on a PGP mailing list and received an invitation to a jointly-sponsored webinar with Vontu on September 13, 2006: Stolen Laptops: How to Recover and Reduce Risk. I've previously told you how to do this, but if you want to hear from a vendor's perspective (I respect both PGP and Vontu), register and tell them I sent you. (I don't think I'll get anything for it, but you never know.)

*Notebooks, not laptops!.

Notebooks not Laptops

We don't call them "laptops" since they overheat and explode. Check these out, and don't tell me that some of these sources are dubious! The photos are great. :-) "Exploding" Dell Laptop Destroys Truck, Imperils Outsdoorsmen; Dell laptop explodes at Japanese conference; Another PowerBook violently explodes. As far as we know, a commercial jetliner has never been brought down by a notebok PC, but one can never be too careful.

8/21/06

Yet another reason I am still glad I switched to Mac

Dear Sir Bill Gates: invoice enclosed

E-Cards

You've gotten them, right? Electronic birthday cards, greeting cards, etc.? You ever get one from someone you didn't know? Every one wants a secret admirer, no?

I received two within a week, so it reminded me to remind friends and family members that you should treat electronic cards as you do any e-mail with an actual attachment. That is to say, "with caution." ("With extreme caution, if you don't know the sender.) Here's why.

Message #1 was this:
From: "Found D. Tyree"
Dear recipient.
Sender at Michelle sent you an "e-card" "Here's the Rub" from 'greeting-cards'. To see your card, click here

This "ecard" will be stored for one week, so print or save the card as soon as possible.
Hope you enjoy our "e-cards". Spread the love and send one of our "e-cards".

Brought to you by 'greeting cards' - a better way to greet.
Seems benign. Anyone else bothered by the strange mismatch between the full name and the mail address? "Click here was linked to a web site. I won't give you the URL (because you night click on it). What happens when you do? I don't know. All I know is this. 1) I don't know a Michelle who' send me a card. 2) the "top level" of the URL pointed to a web site that was under construction. The top level had text that read, "Welcome to the home of [the top level domain name]. To change this page, upload your website into the public_html directory. Date Created: Sat Aug 5 12:36:14 2006."

That was 4 days before I got the e-mail. Badguy sets up a web page. Badguy puts a trojan attack on a web page targeted at a particular operating system. Badguy uses spammer techniques to seed the world and waits.

Message #2 was this:
From: greeting@all-yours.net
Subject: You just recieved a E-Greeting.

Hello ,

A Greeting Card is waiting for you at our virtual post office! You can pick up your postcard at the following web address:

http://www.all-yours.net/u/view.php?id=a0190313376667

visit E-Greetings at http://www.all-yours.net/ and enter your pickup code, which is: a0190313376667

(Your postcard will be available for 60 days.)
This is how I received it, misspelled words and funny punctuation (space before the comma after "Hello," and all). That URL actually pointed to a different URL at a different host and the URL ended in ".jpg.exe". Not good. Not good at all.

There was no indication as to who it was really from. And I check URLs. Do you? It's a good habit to get into.

Look three times before you "click".
  1. Does the letter look like it was created by an automated process on a real, in-the-business, e-greeting card company, or does it look like it was quickly generated by someone who has English as a second language?
  2. Do you know the sender? Really?
  3. Do the collars and cuffs match? I mean, does the URL link name and the actual link match?