Overcoming Software Volatilities

>> Installing the latest software on your network? Take it from the pros: No new program is entirely risk-free.

Last year, security consultancy @stake Inc. in Cambridge, Mass., was hired to validate the findings of a well-known security assessment tool at a government agency. Turns out, the scanning software itself was so insecure that it risked the integrity of the entire network, according to @stake's vice president of research and development, who goes by the hacker handle "Mudge."

Nothing unusual there - similarly harrowing tales of software-induced vulnerabilities abound in the information technology industry.

Not only are common operating system browsers, mail servers and other popular software tools full of bugs and vulnerabilities, but the very software designed to protect the network can also be tricked, hacked or forced to render gaping security holes into the networks they're supposed to protect. For example, some well-known firewalls, including Cisco Systems Inc.'s Pix and Check Point Software Technologies Ltd.'s FireWall-1, have been fooled by denial-of-service and IP fragmentation attacks (packets sent with improper sequences or sizes).

"All software from all vendors starts out insecure," says John Pescatore, research director of security products at Gartner Group Inc. in Stamford, Conn. "A brand-new code base from a big vendor is likely to be as insecure as a brand-new code base from a start-up vendor." That begs the question: If seasoned vendors create code with such vulnerabilities, what about software developed by emerging software companies?

Rushed Software

While many in the IT community say they feel the new vendors have more at stake if their products create security problems, users of new vendor products say start-ups pose more of a security risk because they hastily develop code in a rush to market.

"As a rule of thumb, when you put new software on a system, you are introducing new vulnerabilities. Commercially developed software from start-ups is particularly notorious for these problems," says Scott Blake, security program manager at BindView Corp., a security tools vendor in Houston.

Citing BindView statistics, Blake says poorly written new software is responsible for a 90%-per-year rise in security vulnerabilities. The best way to avoid software security problems is to never run Version 1.0 on a production system, advises Pescatore. "Vendors have caught on to this and seem to be starting their version numbering with 3.0," he says.

Rafael Arroyo, network analyst at United National Bank in Bridgewater, N.J., says he agrees that start-ups should, in theory, produce clean code the first time out if they want to capture market share. But in reality, he says, start-ups commonly use him and other IT managers as unwitting beta testers.

"The new vendors have this business plan of 'Get the product out there quickly,' " he says. "When we call those vendors and tell them there's a security problem, they'll say they've got a patch and they'll send it quickly. But we all know that if the patch was ready, it would have already been in or with the product."

For this reason, Arroyo buys from new vendors only if they offer a money-back guarantee. "I purchase it, test it hard-core for 30 days, and if I don't like it, I send it right back," he says.

The ideal is finding a vendor whose product has undergone third-party independent security testing and can provide the testing documentation, which few, if any, do, according to Pescatore. Barring that, Pescatore recommends researching the background of the new vendor's chief technology officer or vice president of product development. Finding out if these key people came from a game company or a security company would be useful, he says.

Evaluating Problems

Mark Decker, team leader at BF Goodrich Aerostructures, AAG Corp., which has U.S. headquarters in Raleigh, S.C., starts his product evaluations by reading white papers and media evaluations. He also asks for and checks user references.

Even before selecting a new software tool, determine exactly what you need your new product to do. In May, Arroyo was looking for a product to monitor which programs employees access. He says he chose EventAdmin from Powell, Ohio-based Aelita Software Inc. (one of Computerworld's Emerging Companies), mostly because he felt the company would, at the very least, be responsive.

When the product arrived, Arroyo took advantage of the 30-day evaluation to conduct testing in a mock network environment. "In this case, the software is internal to the network, and it doesn't run with admin privileges," he says. "So even if someone hacked it, EventAdmin can't do anything malicious because it only has access to a log file."

Weak points

Decker followed this strategic process when considering another Aelita program called ERDisk to automate the task of building daily backup repair disks for his network servers. When evaluating the test copy of the software, he determined the program's strategically weak point was that it needed Windows NT administrative privileges to run. If an application with administrative privileges or, in the case of Unix, root privileges gets cracked, it then gives the attacker complete control over the machine and all other programs running on it.

"Anytime you have a program that requires administrative-level privileges to run or interact, you need to be aware of what it's doing," Decker says.

In a controlled environment, Decker's testing team monitored ERDisk as it traveled throughout the test network to see what data it collected and from where until the team was satisfied the program stayed contained to just those processes it needed to function. He also hit it with a barrage of hacker tools to see if an attacker could exploit the application to gain administrative privileges.

Arroyo is just as concerned with applications that require him to open extra ports to travel to and from the network. "I had a problem in some automatic stocks-and-bonds updating software I was trying to test. It locked up even though the user account was set up with password, port number and proxy server," he explains. "The update program was problematic with five different types of firewalls, because the user account would only work if we punched a hole through our firewall. Eventually, I chose another product."

Once the application is on the network, Arroyo and Decker make sure the application is retested during a follow-up or scheduled network security assessment. This overlapping testing process is the ideal, according to Mudge, who adds that you can't test a new application too much, especially if that application faces the big, bad Internet.

"The Internet is a hostile environment. You don't know what sort of data will be thrown at an application," he says. "Don't be afraid to kick the tires and see how an application comes out under stress. You want to make sure that if it fails, it fails in a safe manner, which means it fails closed, without giving up services or information to an attacker."

Copyright © 2000 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon