Letters to the editor: “U3 promises to break the apps chain”

Also: truth about teleworkers; anomaly detection; broadband policy; AT&T-BellSouth customer concerns; Novell mind share; and taxing teleworkers

Bad choices

Regarding Mark Gibbs’ Gearhead column, “U3 promises to break the apps chain”: The complexities of today’s applications are the result of choices made by Microsoft and application developers – and generally better choices exist than the typical environment most use.

I am chief engineer on a Windows project to develop a fully functional pharmacy prescription-filling system. It is nearly complete at over 350,000 lines of code. It does everything the pharmacist needs on a daily basis for prescription filling, including on-line SSL-encrypted insurance transmission. The core that accounts for 95% of the functionality will compile and compress into under 250K bytes and only requires two support DLLs. It does no registry entries, and to install the program you copy a few EXEs and DLLs to a directory along with the empty database and you are done. The whole thing can be distributed in less space than a 3-1/2 floppy.

Windows DLL hell and registry nightmares are not required – they are a choice, and a bad one at that.

Mark Strickland

Chief engineer

SimplyBASICsecurity

Atlanta

Trivel pursuit

Regarding “The dirty, naked truth about teleworkers”: You’ve just helped me create a new word – “trivel” – which is what you get when you combine “trivial” and “drivel.”

It’s a shame that while many are hard at work at home, someone pays for salaries and office space for people to call up and interrupt them in order to elicit useless information like this, and then you waste your time printing it and my time reading it in the vain hope that there was useful information in it. Trivel.

Karl Hermansen

Herndon, Va.

Dispelling myths

Regarding Gil Arbel’s Face-off column arguing that anomaly detection is not the best way to prevent virus and worm attacks: Arbel’s comments reflect a larger problem within this community: a general technical misunderstanding of how Network Behavior Analysis (NBA) technologies work and what benefits they provide.

Myth 1. “It is too slow to detect fast-spreading virus and worm attacks.” Arbel states that “anomaly detection relies on network flow data, which is often reported at intervals of 15 to 45 minutes.” This is patently false. All flow-based collection strategies offered by Cisco, Juniper, Foundry and other network infrastructure providers allow for flow exports intervals down to 1 second. Arbel seems confused by the meaning of NetFlow’s “Active Timeout” vs an “Inactive Timeout.” For worms and other fast spreading malware, the “Inactive Timeout” is what matters. For example, consider an infected laptop that connects to the network and begins sending TCP SYNs on port 445 to hosts within an organization’s internal network. As the first TCP SYN transits a NetFlow-enabled router or switch, a flow timer is started. Assuming an Inactive Timeout of 5 seconds, if a second packet is not received from the attacker within 5 seconds, then the NetFlow record is exported to the Anomaly Detection collector. As flows are received by the collector, they’re processed in a very similar fashion as a classic packet Sniffer or IDS would process a packet. Even in the worst case, given a host scanning various subnets on TCP 445, an NBA technology like Lancope’s StealthWatch would be sent flows resulting from the scanning activity within 5 to 15 seconds — a far cry from Arbel’s misstated “15 to 45 minutes.”

Myth 2. “It produces an enormous number of false positives.” This is a common non sequitur argument posed by many people throughout the security industry about various security products, not just anomaly detection technologies. One must ask the arguer to “prove it.”

Modern anomaly detection technologies such as those provided by Lancope and Arbor Networks utilize a mixture of detection methodologies that include both pure anomaly detection (deviations from an established norm) as well as algorithmic pattern matching (known patterns of bad behavior). Rather than looking for packet payload patterns (“cmd.exe” in HTTP GET), anomaly detection technologies look for patterns in network connections (the use of the same source port in many TCP/80 connections).

Further, given the algorithmic approach utilized by anomaly detection systems, a wide range of tunable behavioral thresholds are provided, allowing operators to increase or decrease the sensitivity of the system based on the type of host or the location where the host sits in the network.

Will an anomaly detection system require some level of tuning in a 20,000+ node network? Yes. Have over 400+ companies across the world already successfully deployed and tuned an anomaly detection system? Yes.

Myth 3. “It provides marginally effective mitigation techniques, if it provides any.”

Again, this comment reflects a general lack of technical understanding – especially as it relates to modern NBA technologies and mitigation approaches. Lancope’s StealthWatch and Arbor Networks’ NBA technologies both provide a myriad of mechanisms for blocking and quarantining attacks. For instance, StealthWatch uses a “Closest Interface Selection” algorithm when processing NetFlow or sFlow that tells the mitigation subsystem exactly which router and port a host is connected to. This allows the mitigation subsystem to operate in a surgical fashion against the most optimal location for quarantine.

The StealthWatch mitigation subsystem is based on an extensible TCL Expect scripting language that allows connection to almost any network infrastructure device for automating mitigation actions. This includes NetScreen OS policy manipulation, Checkpoint OPSEC actions, Nortel 8600 switch reconfiguration, Cisco IOS ACL manipulation, Null0 black-hole route injection, Foundry switch port disablement, etc. StealthWatch is successful in this arena given its infrastructure awareness through the use of NetFlow and sFlow information.

If Arbel wasn’t CEO of CounterStorm, which incidentally targets the exact markets as that of Lancope and Arbor Networks, then would he still offer similar comments on the success or failure of network behavior analysis technologies? Highly unlikely.

Adam Powers

Director of technology

Lancope

Atlanta

Service vs. content

Regarding Mark Gibbs’ BackSpin column, “We need a broadband policy”: I have long thought that our problem is allowing distribution service providers (i.e., those who own and operate the distribution system of cable, telephone and power lines) to be content providers also. If someone has a regulated, monopoly distribution system (and was prohibited from providing content), that entity would be much more interested in finding content providers who would appeal to its customers than if it also provides content in which case it becomes interested in discouraging competition for its content.

George Hadley

Normandy Park, Wash.

Customer disservice

Regarding “AT&T-BellSouth union stokes user concerns”: It would be helpful to spend more time addressing the readers who could further comment on the lack of customer service and customer service concerns in these large mergers. Many of us feel like these mergers only please a few, large shareholders, leaving the customer out to dry.

Additionally, as a customer of all of these different companies (and the companies they merge into) it seems that there is no one who is able to listen to, or address the questions and concerns that existing customers have. It really does seem that the biggest loser in these mergers are the customers, who supply the revenue in the first place.

As a telecommunication engineer with 20 years of experience, I interface with every local and long distance company in the nation to build large bandwidth connections, and enable the transport of broadcast video. The established business relationships that I value and maintain with the different representatives of these companies are an important element of establishing connections and success in business. These company mergers come along and we are blindly informed that there will be changes in processes, departments, and established contacts, in which “they” have determined would be better for business. No one ever knows who “they” that make these decisions are, and if “they” ever really studied the internal processes in the first place, before changing the existing workflow in favor of reorganization. Rarely, if ever, is there a resulting improvement to the process. Usually the customer is forced to work within unavailing, automated Web pages, voice mail trees, and naïve “customer service” representatives who hardly understand the technology, products or services they are attempting to represent or install. It truly seems that “they” who make these decisions and changes are basing their actions solely on the bottom line of an accounting spreadsheet, and truly have no understanding of the business processes within the telecommunications industry; what it takes to order, design, implement and maintain services.

Paul Atwell

Director of video networking

Paxson Corporate Engineering

St. Petersburg, Fla.

Novell mind share

“Does Novell still have mind share?” rounds up the usual suspects who seem unfamiliar with what Novell has been doing since 1994. I particularly liked the guy who “recently looked at Novell for directory services and Linux” and decided to write his own metadirectory to use with Red Hat Linux. Gee, I guess Novell wasted a lot of time and money creating a distributed and replicated directory service that runs on Linux, NetWare, Solaris and Windows when someone could just sit down and hack one out on their own.

Then there is always someone who complains about Novell’s marketing. This is supposed to prove Novell’s ineptness because the company apparently can’t figure out how to market some “quality products in directory services, systems management and collaboration.” I’ve noticed a steady stream of Novell’s print ads gracing the pages of industry publications for quite some time. I can’t vouch for their effectiveness, but Novell is putting out its message about how its products and services help organizations create an open enterprise.

And since everyone loves a horse race, there is now the mandatory comparison of Novell and Red Hat over who has the larger share of the Linux market. Never mind the interesting stuff like how well Red Hat is doing with the Netscape Directory Server vs. Novell’s multi-platform eDirectory. Or how Novell has implemented Virtual Iron’s extensions to the Linux kernel in SLES9 SP3 and SLES10 while RHEL4 doesn’t. Or how Novell will support NetWare 6.5 virtualization on SLES10 using the XENsource Hypervisor while Red Hat is slow to commit to XEN. Who is the leader and who is the follower here? Seems obvious to me that Novell is making solid technical improvements in SLES while Red Hat lags behind with RHEL.

Yes, it’s great fun to kick Novell around a couple of times a year. The problem is the routine is getting tired and not informative. How about delivering some intelligent commentary and analysis on the cutting-edge work Novell is doing with open source software? Novell is scoring big wins with many customers who are smart enough to know the value Novell brings to the table. You should be talking to them to find out why they chose Novell and stop printing vapid quotes from people who care nothing about what Novell is doing.

Tim Wessels

Rindge, N.H.

Taxing teleworkers

Regarding “Bird flu: IT pros planning for worst”: While telework will be an essential tool for helping businesses sustain operations in the event of a flu pandemic, the price tag states may slap on this emergency management strategy may be exorbitant. Some states (including New York and others) may require nonresidents who sometimes telecommute to their in-state employers to pay taxes, not only on the income they earn while physically in the employer’s state, but also on the income they earn at home. The double tax risk can make telework unaffordable for many Americans and may compel them to resist remote work. In addition, the rule may saddle employers with unduly burdensome withholding obligations. Proposed federal legislation called “The Telecommuter Tax Fairness Act” would eliminate the tax penalty for interstate telework, prohibiting states from taxing income nonresidents earn at home. If employees and employers are to prepare adequately for a pandemic, barriers to interstate telework must be removed — and fast. Congress must pass The Telecommuter Tax Fairness Act now.

Nicole Belson Goluboff

Scarsdale, N.Y.

(Goluboff is the author of “The Law of Telecommuting” and “Telecommuting for Lawyers” and an advisory board member of The Telework Coalition.)