locks keep lawful people out...    

The Security Skeptic

Dave Piscitello's Security Weblog

Skeptic (sceptic): a person inclined to question or doubt accepted opinions.

Web www.corecom.com The Security Skeptic
Thu, 27 Sep 2007 00:00:00 00, 650
ICANN hits YouTube

I don't often visit YouTube. Much of what I find there has very little meaning or value to me, and it's way too hard to find the very little that I'd find meaningful and valuable at such an overwhelming site.

I am very pleased to see that ICANN's added value to YouTube by publishing a short video on Internationalized Domain Names. ICANN colleague Tina Dam does a "damn fine job" of explaining a very complicated subject in plain speak, in just over 4 minutes.

Watch the video. Encourage your company to make short, educational videos and put them on YouTube.

If enough companies follow ICANN's fine lead, the next thing you may hear from your teenager while she's trawling YouTube is, "ZOMG - YouTube is soooooooo ed you kay shun all!"

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID650 by Dave Piscitello  


Thu, 20 Sep 2007 00:00:00 00, 649
When SMBs meet AUPs

An editor of an online publication contacted me by email today, asking if I would talk about network usage policies. The editor asked, "How can companies handle employee's usage of IM, email, social networking sites, YouTube etc. Should the company block access to certain sites? How does the company deal with network overload? Should the company prohibit personal email and IM use? How should these rules be enforced?" My response, amplified a bit, follows...

You are covering a huge swath of territory by including applications like email that are 20 years mature and IM that is less mature than email but becoming essential in mobile technology alongside social networking and entertainment sites that have unclear, even questionable business value and possibly add risk as well as impact productivity.

The hard question for organizations to answer isn't how to control traffic but rather, what applications fall within the realm of appropriate use? What applications enhance productivity? What apps are justified because they are good for morale? What applications expose the organization to unnecessary risk? Should all apps have unlimited bandwidth? Can compromises be made so that critical applications receive preferential and ample bandwidth and less critical applications receive a sufficient "trickle" to accommodate those who benefit from them?

How a company defines an AUP is very dependent on the type of business it operates. A company with hourly employees who must meet production benchmarks might require a very restrictive policy whereas an advertising company might want a very liberal policy. All the applications you mention may not be very useful to employees who use networked computers to perform work in a manufacturing company. An ad company may find YouTube invaluable because it wants to keep pace with youthful expression, teen obsessions, etc. OTOH, YouTube could pose a risk to a company that projects a traditional "corporate white collar" image but runs afoul of an employee who records and posts "insider activities" from his office PC that reveal the Emperor's true clothing.

Finally, there's a tendency to view AUPs as monolithic. With today's firewalls, application proxies and UTM appliances, even a small business can create group based AUPs in a company, so that the "creative" people in the company have access to what they need, the "mobile" people are hyper-connected, and the "production" people have a distraction-free computing environment.

Network usage and acceptable use policies are not one size fits all. This is one of many areas of network and security design where each company has to invest time and be thoughtful before it invests in technology.

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID649 by Dave Piscitello  


Thu, 13 Sep 2007 00:00:00 00, 648
Tokens are a big deal... but not a complete solution in themselves

Colleague, friend, and fellow consultant Rik Farrow had this important insight to add to my comments regarding the adoption of two factor authentication by PayPal/eBay and eTrade:

Hi Dave:

I read a couple of your blog entries, and had a couple of comments for you (and hi!). My attention was caught by

http://www.securityskeptic.com/arc20070801.htm#BlogID640

The proliferation of tokens certainly is a big deal. But tokens are not a complete solution in themselves.

Take e*trade, as an example. They posted about a 12% loss last year to trades made via stolen authentication credentials, surely enough to give everyone who is willing tokens. But just using hard tokens doesn't necessarily fix the problem. Bruce Schneier suggested, first during an RSA luncheon, and later in his blog, that tokens are not a complete solution, as authenticated connections can still be hijacked via malware that operates within the browser, or at the OS level (a rootkit).

Most of e*trades problem is pumping-and-dumping of penny stocks. The people running these scams use compromised e*trade accounts to buy the penny stocks, pumping up the prices and encouraging others to buy in, before selling off. I've heard that it is possible to make 5% profit IN ONE DAY using these schemes...

Rik's of course entirely correct: two-factor authentication still requires that the user/client communicate both elements of the challenge to the server, and if the sending application (browser) or the channel is compromised, you are screwed. For Joe Average User, the lesson to learn is to use token authentication *and* the best possible defenses against malware (or buy a Mac).

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID648 by Dave Piscitello  


Tue, 11 Sep 2007 00:00:00 00, 645
If you knew where you wanted to go today, could you get there using IPv6?

My SSAC committee is studying a number of IP version 6 (IPv6) issues. This is IMO entirely appropriate since changing the network protocol of the Internet architecture has decided security and stability implications. I've been engaged in discussions about accelerated depletion of IPV4 address space, IPv6 address allocation strategies, availability of security products for IPv6, 11th hour measures to forego IPv6 in favor of a network protocol that doesn't simply replace IPv4 and accommodate larger addresses and have discussed an even longer list of "what if?" scenarios.

Throughout these discussions, folks tell me that people are using IPv6 today.

I got curious. What are they using it for? What web sites they are visiting?

I ran a very informal test - a reality check might better describe my time invested.

First, I visited Netcraft and obtained a list of the 100 most visited web sites (all countries). How many of these are reachable using an IPv6 address?

Using dig aaaa +noall +answer [domain name], I quickly checked which sites returned a AAAA resource record:

www.google.com NO

*.yahoo.com NO

www.google.de NO^

mail.google.com NO

www.google.co.uk NO^

www.google.fr NO^

news.bbc.co.uk NO^

www.bbc.co.uk NO^

www.google.it NO^

www.google.es NO^

www.google.nl NO^

*.microsoft.com NO

*.ebay.com NO

www.foxnews.com NO

en.wikipedia.org NO

*.foxsports.com NO

*.hotmail.com NO

www.symantec.com NO

www.paypal.com NO

www.myspace.com NO

www.bestbuy.com NO

*.aol.com NO

www.mapquest.com NO

www.drudgereport.com NO

www.circuitcity.com NO

tgp.pornaccess.com --

www.clubic.com --

b.casalmedia.com --

*.msn.com NO

www.01net.com NO

www.ebay.fr NO^

www.ebay.it NO^

www.yahoo.co.jp NO^

www.amazon.com NO

* denotes WILDCARD

^ denotes CCTLD

Hm.... I must be doing something wrong with my dig...

I tried host -tAAAA [domain name] with similar results.

If my hastily constructed checks are correct, none of the most visited 100 sites (on this given date) support IPv6.

As I sniff around the 'net, I find other forums where folks are talking about the futility of end user adoption of IPv6, see (18 Jul 2007) and (29 Mar 2005).

This wild speculation on my part, but shouldn't we give users destinations before we ask them to use a new method of transport?

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID645 by Dave Piscitello  


Wed, 05 Sep 2007 00:00:00 00, 647
Is FRED a good security system?

I read James Gaskin's column, The Fred Security System: Improve security for zero dollars with some interest and of course skepticism:-) Jim proposes that every company have a "Fred", a reasonably smart and suitably trained individual to whom email attachments can be forwarded for inspection. Fred uses his antivirus, anti-phishing and anti-spyware savvy and his amply fortified workstation to ferret out malicious email payloads and attachments that possibly adds a level of malware protection without increasing your budget.

My experience with Freds is that they don't always pan out the way Jim suggests. I've met lots of Freds. I call them Bob. But for now, let's stick with Fred.

I'm OK with educating users on the dangers of malware. I'm OK with giving users who show some savvy a reasonable set of malware detection tools. And I think that in very small businesses, having a Fred is a reasonable idea as long as the small business can escalate the problem beyond Fred to a competent, affordable, and trustworthy 3rd party. I have several reservations, based on experiences with Freds in businesses small, medium, and large.

Fred is not 24x7 available. Fred's inspection capabilities and breadth of knowledge regarding malware are more limited than any automated system such as an email security proxy or Unified Threat Management appliance. Most importantly, Fred can't keep current with the insane pace and variation of malware attacks. Unless Fred is seriously over-qualified for his role, I speculate that Fred entirely ill-prepared to deal with never-before-seen or 0-day attacks (I hate this term, BTW).

My experience is that Fred is not zero-cost. Fred is being paid, ostensibly to satisfy a role other than malware ferret. Hours Fred devotes to ferreting out malware don't appear in the security budget but affect productivity elsewhere. This is security through budget obscurity. It's also my experience that Fred doesn't scale. One Fred can perhaps deal with malware in an office of 10-25, but how many Freds will you need for an office of 50, 100, 1000?

I suspect that if you study costs carefully, you'll find that even a single Fred costs more than the gateway antispam inspection software that even SMB/SOHO firewalls and unified threat management (UTM) appliances cost today. I'll venture that you could buy a Watchguard, SonicWall or Netscreen UTM with annual subscription for virus/spam/IPS definitions probably for than the cost of buying Fred lunch for 6-8 months (possibly depends on how much Fred eats).

Will a malware gateway/UTM improve security without increasing your budget? Of course not, nor will it break your budget.

One last life-lesson regarding Freds. All my SMB consulting is pro bono or deeply discounted as favors to friends, schools, and parishes. In all these networks, I find Freds. The difficulties I've experienced when dealing with nearly all Freds (or cleaning up after them) is that they cannot resist opportunities to play sys admin. They read about a registry setting and can't wait to change it on everyone's system. They read about secure browser settings, run to every novice's desktop and rejoice in having made the network a safer place. They wreck havoc on innocents who find that they can't use their browser as they've been taught, who encounter errors they don't understand, who learn to lock their offices to keep Fred at bay, and who roll their eyes when the consultant comes in to remedy wounds Fred has inflicted.

User Freds as you would a topical cream for a rash or insect bite: apply in small doses, monitor carefully, and never conclude it is an effective substitute for a physician's knowledge and expertise. If you want a Fred rather than a UTM appliance, however, you may as well train Fred to be a sys admin because that's what he'll very likely try to be.

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID647 by Dave Piscitello