The Security Skeptic

An on-demand version of my presentation on business-grade anti-spyware is available from TecWeb. During this webcast, I offer my list of top ten requirements for businesses seeking to deploy antispyware measures at the desktop. Find the registration page at TechWeb Today.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID423 by Dave Piscitello  

My colleague and ICANN co-worker, Steve Conte, recently called my attention to the fact that I'd neglected to add my mobile phones to the national Do Not Call Registry. Steve pointed out that telemarketing calls to mobile phones is increasing, in all likelihood because many folks overlook this number when registering at https://www.DoNotCall.gov. Steve also points out that telemarketing calls to mobile phones aren't just annoying, but potentially costly. Depending on your service plans, you may be charged for the call. This can be especially expensive if you are roaming internationally.

I imagine the next numbers I'll be registering at DoNoCall.gov are SIP numbers.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID422 by Dave Piscitello  

Steve Fallin wrote an interesting piece at WatchGuard Wire on Skype. In the piece, Steve explains how skype adapts to and evades firewall egress filtering policies. Skype is exactly the kind of application I write about in my blog #418.

Steve's reaction to Skype and P2P's that behave like Skype is one of fear and awe. Steve and I share a fear of applications like Skype because they defeat perimeter security policies. Blocking them involves touching desktops (yuck), adding more NIDS, reactionary policies, and an unproductive rejection of innovation. Steve suggests that Skype may be the wave of the future, and maybe we should look at P2P as a paradigm for network security.

I agree with Steve that P2Ps present a paradigm shift in application behavior that "perimeter mentality" security measures can't block or defeat. I find Steve's speculation both intriguing and consistent with recursively layered architectures. HTTP is in one sense becoming the link level protocol (PPP) of distributed applications. You could think of all the diversity above HTTP as a multiprotocol application network. If history repeats, we'll reject multiprotocol networks, weather a mulitprotocol war and one protocol and application architecture will emerge as the victor.

Before this comes to pass, however, I believe admission control technology will evolve to allow IT to "examine the DNA" of an endpoint before it is admitted. Today, network admission control is still in its infancy. It focuses on whether an endpoint is infected with malicious code, which is nice, but not nearly enough. I see admission control evolving to a point where an organization can check that authorized software, appropriate licenses, and local system security configuration all satisfy policy before a device is admitted to a network.

I can also imagine a time when sensitivity labels might be associated with files. An endpoint might be barred from connecting to networks where its presence on the network would expose that information to unauthorized access and misuse, and (importantly) make the network operator accountable and liable for accepting it as well as how it is used once accepted. Today, organizations worry about information leaks; for example, if you operate under HIPAA regs, you worry that a patient's medical information will be disclosed to unauthorized parties. But organizations should also worry about situations where illegal files are introduced into their network. Is it easier for you to block endpoints that have images of child pornography, or provide evidence in a court of law that you did not knowingly possesses these files after they'd been uploaded to your server?

If you have an opinion about Scott's commentary, visit WatchGuard Wire. If you have an opinion about mine, contact me.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID421 by Dave Piscitello  

AskSam.com has posted a free browse-and-search version of the U.S. Health Insurance Portability and Accountability Act of 1996 (HIPAA). Downloadable versions available as well, in viewer and database formats. If you are involved in any HIPAA-related projects, http://www.asksam.com/ebooks/HIPAA/ is a handy link to add to your favorites.

Several other federal regs are available as well:

• Sarbanes-Oxley
• Patriot Act
• Intelligence Reform and Terrorism Prevention Act

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID420 by Dave Piscitello  

Reviewing logs when you introduce a new application to your internal networks is always a good idea, especially when that application involves client-server or peer-to-peer communications with external hosts. By reviewing logs, you learn that some applications are well-documented and well-behaved, and use a well-known port as the gods intended. Increasingly, however, application developers are bending the rules, all in the name of ease of deployment and plug-and-play.

The symptoms of the rule-benders have become all to familiar. The client application tries to connect to peers or servers over its well-known port(s). Failing to reach the mother ship using these ports, the client may try NETBIOS ports, and failing these, http/80. Why? HTTP/80 is almost assuredly open outbound on Internet firewalls today. The objective of the application developer is to make certain the client connects without requiring (firewall) administrative intervention. So what better port to choose as the default than http/80?

I've tested and use several collaboration clients, remote desktop clients, and multi-player online games that are written to behave in this manner. I often run a LAN analyzer or block http/80 outbound initially to see what the clients will try. One capture session for any of these applications quickly reveals they aren't trying to be stealthy (most are quite the opposite). They aren't maliciously seeking to evade detection. They just want the application to work the way users have come to expect applications to work - plug and play.

I no longer complain to vendors that this is architecturally distasteful. I will, however, open the well-known port these applications (hopefully) seek first. This allows me to monitor and control this application separately from web traffic in general. I can review logs and quickly see connections and traffic associated with individual applications. I can schedule times when this application is to be used; and allocate bandwidth based on relative application priority. With user authentication, I can even control who uses the application. None of these granular controls are available if I simply say "allow whatever over http/80". (I also eliminate all the silly port-seeking traffic).

In larger shops, this method might help administrators identify slackers and excessive users. I don't think you really need firewall logs to identify these folks, but that's fodder for another blog entry.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID419 by Dave Piscitello  

Channel Viewpoint has posted a re-hash of an article I wrote earlier this year for Watchguard Technologies. Profiting from IE's 'problems' is written to help organizations where business practices impede a switch from Microsoft's built-in browser to an alternative. The article explains how organizations can reduce the spyware threat through central IE policy definition and distribution via Active Directory, and more.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID418 by Dave Piscitello  

I'm on the review list for the "...for Dummies" series. Don't ask., I can't tell you why (I honestly don't know).

Techies may think "...for Dummies" confines itself to PCs, networking, and security. How wrong you are.

To give you a sense of just how wide a range of topics 'dummies books cover, here's a list of titles I've received recently:

• Writing Children's Books for Dummies

• Parrots for Dummies

• Chemotherapy and Radiation for Dummies

• Tour de France for Dummies

Even though I write regularly about security, I'm not qualified to comment on a book that professes to teach you to write Children's books (maybe I am but I'm being polite).

I will admit to finding birds in general and parrots in particular highly unappealing pets, so this one's available to whomever will pay S&H.

My wife is a licensed nurse practitioner, all too familiar with cancer and its treatment. Initially, she laughed when I received the book, but after thumbing through it she thought it covered most of the issues and questions people have when they or a family member is diagnosed with some form of cancer, but dutifully warned that it's for background information and support, and not a substitute for medical advise from a physician/oncologist.

I found the Tour de France for Dummies highly entertaining. I've followed le Tour for years, and have learned bits and pieces about its history. le Tour pour provides a fair bit of history; explains the rules; and provides the obligatory "Top Ten" lists of riders, legs, and unique statistics.

I spent an hour speed reading the entire book (hey, it's not Moby Dick). Two chapters I thoroughly enjoyed were "Spending a Day in the Life of a Rider" and "Understanding Race Strategies. Without question, the most amusing discussion was "Heeding Nature's Call While Riding", where authors Phil Liggett, James Raia, and Sammarye Lewis answer the question, "Hey, what do they do when they gotta go?"

Read the book to find out. I will tell you that riders in the peloton obey an unwritten and absolute rule to not attack while riders are watering the sunflowers" :-)

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID417 by Dave Piscitello  

Proofpoint and Forrester Research recently polled 300+ US-based enterprises of 1000 or more employees, to gauge the extent that outgoing email is viewed as a security risk by companies of this size. Some of the interesting statistics I gathered from this survey include:

• Over a third of the companies employ staff to analyze outbound email;

• On average, these companies estimate that one quarter of all outgoing email contains material that poses a legal, financial, or regulatory risk;

• Confidential business information surpasses offensive content as the most common form of inappropriately transmitted content;

• More than half of the companies surveyed disciplined employees for email abuse in the past 12 months, and one quarter of companies terminated an employee for email policy violations.

In addition to survey results, this report offers an interesting consideration of email security policies. If your organization doesn't have such policies, you can learn quite a bit about "The email Policy Environment in Today's Enterprise".

I'm usually unimpressed with vendor reports. This one is worth a look. It's available at http://www.proofpoint.com/outbound/

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID416 by Dave Piscitello  

Secunia recently reported that a long-known, exploitable feature... um, flaw... uh, flawed feature... was reintroduced into Firefox 1.0.4. The flawed feature allows a web page to load content into the frame of another page. An attacker could use this to substitute a bogus authentication prompt and capture passwords from an Extranet, online banking portal, etc. Secunia has published an online demonstration of this exploit.

Try the demo, it's very interesting.

Some time ago, I wrote that the "which is better, Open or Proprietary?" is silly. Quality of design, quality of developers, and quality assurance aren't guaranteed from either community, and will differ over time and project (application). You'll find good and shoddy software wherever you shop. Shop wisely.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID415 by Dave Piscitello  

The IM world learned *nothing* from the multi-protocol networking wars of the 1980s. Every provider has to run its own messaging protocol. Everyone provides a distinctly clever client. Everyone is protectionist to keep multi-lingual IMs in constant state of flux.

I was perfectly happy with Trillian. It satisfied my very modest IM needs. One client for MSN, Yahoo! and AIM.

Jabber is very popular among the folks I collaborate with when I am doing ICANN-related work. Unfortunately, the Jabber plug-in for Trillian was less than cooperative. But one positive aspect about freeware is that you don't have to feel bad if you choose to discard it in favor of something else.

On a colleague's recommendation, I installed GAIM. I like it. Very uncomplicated configuration, clean look and feel (yes, I chose the "no skins" look), and I had my IMs reconfigured in less than a minute.

Of course, the day I choose to create a Jabber account, wouldn't you know that Jabber.org's server decided to act out? From the Jabber.org web page...

2005-03-04: Attempts to register new jabber.org accounts using recent versions of Gaim are failing because of a protocol misunderstanding between Gaim and the jabber.org server...

Did I mention that the IM world learned nothing from the multi-protocol networking wars of the 1980s?

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID414 by Dave Piscitello  

Recipients of my monthly digest have complained that the digests don't provide a direct link to the blog entry. I have corrected this and in future digests, you'll see something like this:

Digest of Dave Piscitello's WebLog (http://www.securityskeptic.com/weblogindex.htm)

Mon, 23 May 2005 00:00:00 00, http://www.securityskeptic.com/arc20050601.htm#blogID410

Subject:Security's 4-legged Stool needs reinforcement

During a recent thread on the Firewall Wizards email list, one participant called...

I have overlooked this too long. Sorry for the inconvenience. I now understand why the page search is so frequently used!

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID413 by Dave Piscitello  

I gave two presentations at Interop on behalf of TechTarget.com. Both are list of ten security related matters. TechTarget has converted the presentations into pdf files and made them available online.

The first is Commonly overlooked security hazards, a list of ten practical guidelines you can put into place today to protect your network and critical data in the future.

The second is Foolproof initiatives to boost your network security, a list of ten most commonly overlooked security hazards and easy ways to prevent them from placing your network at risk (for some value of easy).

My "top tens" may not match yours. If you disagree, drop me an email.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID412 by Dave Piscitello  

I have accepted a fellow position at ICANN, the Internet Corporation for Assigned Names and Numbers, on the Security and Stability Advisory Committee, (SSAC). The official staff appointment is here.

SSAC charter is quite expansive, and includes such activities as "developing a security framework for internet naming and address allocation services" and "engaging in ongoing threat assessment and risk analysis of the internet naming and address allocation services to assess where the principal threats to stability and security lie, and to advise the ICANN community accordingly".

I have the privilege of reporting directly to Dr. Stephen Crocker, whom I greatly respect (Steve, along with Vint Cerf and Jon Postel, were part of the original IMP deployment team at UCLA). I am also excited by the prospect of working with an impressive group of experts from the domain name and internet address allocation services community.

I will still be active in Internet Security, and will still post here. As opportunities appear, I hope to write more about DNS and Internet naming security, along with the customary fodder you've encountered when you visit.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID411 by Dave Piscitello