Each year, your risk for a hack attack grows. In 1999, 9,859 security incidents were reported to Carnegie Mellon University's CERT Coordination Center, a premier computer emergency response team. By June 2000, the number had already reached 8,836. Better awareness accounts for some of the increase, but not all: People submitted information on 417 software vulnerabilities to CERT in 1999. By mid-year 2000, that number had already reached 442.
Best-kept secret No. 1: Most security holes hired experts find are well-known vulnerabilities with easily accessible patches.
Most Internet-related hacks are traceable to a dozen security holes. These tend to be months -- even years -- old and easy to discover, says Phil Cox, a consultant for security firm SystemExperts in Sudbury, Mass., and former member of the Department of Energy's Computer Incident Advisory Capability team. The Systems Administration, Networking and Security (SANS) Institute keeps a list of the top 10 Internet security threats at www.sans.org/topten.htm. These are all preventable -- "all of them are [due to] a simple lack of configuration management," he says.
For example, the SANS Institute found that, in mid-1999, as many as 50% of Domain Name System servers were running vulnerable copies of the popular Berkeley Internet Name Domain program. Yet this same warning appears on the list today. Much the same can be said of others: An FTP vulnerability, called FTP Bounce, was reported in 1997. A malicious Visual Basic Script, known as network.vbs, was discovered in March. A vulnerability in the rpc.statd command found in several Linux variants was discovered in August. If you run any of this software, you have no excuse for not patching these holes.
You also have no justification for not configuring firewalls to block Internet Control Message Protocol (ICMP) pings originating externally, Cox says. It's well known that numerous attacks tunnel through in that protocol's echo reply. You should also block outgoing ICMP pings, lest your network be an accessory in a distributed denial-of-service attack.
While security consultants will happily take your money to find such obvious flaws, why not better apply your cash and their talents?
Best-kept secret No. 2: Contrary to common practice, scanning for vulnerabilities and patching holes does not constitute good Internet security.
Even if you check for vulnerabilities and are vigilant about security software upgrades, don't assume you're doing Internet security right, says Ian Poynter, founder of Jerboa, a security consulting firm in Cambridge, Mass. He believes this "find-and-fix" method serves the security industry's need for profit more than it serves a company's need for protection. With find and fix, vulnerabilities are identified via an attack or by antivirus, intrusion-detection and other so-called preventative software tools. The result is a never-ending spiral -- hackers keep inventing new ways to attack, and you're constantly investing in updated security tools.
Poynter contends it is better to apply the concepts of hardware reliability engineering to Internet-related network security. A hardware vendor can calculate the probable mean time between failures for each system component and thus the device itself. Using those calculations, corporate network managers schedule upgrades or architect redundancies, preventing failures.
Apply those methods to network security and you get true prevention rather than reaction, Poynter says. "We're trying to come up with a scientific approach to Internet security."
With this form of systems engineering, a security manager creates actuarial tables that list probabilities of an Internet attack for any given device or network segment. These tables guide the security manager in how, when, where and what type of security to apply to the network. It's like an insurance company that calculates risk factors to determine a customer's cost.
Systems-engineered security is designed in, rather than added on. Like the self-healing network IBM is building system-engineered security disallows unsanctioned software or network device outputs.
You can systems-engineer existing networks and applications, not just new ones.
To do that, you would profile the targeted network by creating a detailed schematic of external connections and the percentage of traffic every device receives from untrusted sources. Next, you would run several algorithms to ascertain statistical risk. For instance, Poynter uses a formula that produces a vulnerability measurement by multiplying a system's exposure by the value of the information at risk.
With systems engineering, you get more predictable security. Like weather science, systems engineering doesn't guarantee a sunny day, but it's better than planning a picnic for Tuesday by checking the sky on Monday, backers say.
Best-kept secret No. 3: You can't find security breaches by looking for anomalies.
Some security consultants and intrusion-detection vendors promote anomaly detection. The idea is if you take a baseline of your network's topology and performance, you can detect security breaches in progress by finding unusual activities. While this sounds logical, it has been proven mathematically infeasible.
"As long as I do the same thing day to day, the mathematical model of what I do will be accurate. But if I do a range of activities, an anomaly system doesn't work," says Marcus Ranum, inventor of the proxy firewall and chief technology officer of intrusion-detection vendor Network Flight Recorder, in Rockville, Md. Anomaly detection doesn't work for three reasons. One, humans aren't that predictable. Two, there's no guarantee that you're not already under attack, which invalidates the profile by normalizing hacker activities. Three, large networks contain so much variety, there's no such thing as a statistical anomaly.
"You'd need a neural network and massive resources to find an actual anomaly," says Rich Hogragia, vice president of architecture for Golden America Life, an insurance company in Westchester, Pa. Moreover, when the system starts crying wolf, "your people will start to ignore the alerts," he adds.
Instead, you must search for activities that are hallmarks of attacks. For instance, the above-mentioned malicious VBScript begins by opening network.log on the local machine and then generates a random 24-network address block, often the first octet of which will be between 199 and 214 for the first 50 addresses.
Like antivirus software, intrusion-detection products should seek attack signatures. For example, they should make sure ICMP echo replies conform to expected parameters and aren't hiding distributed denial-of-service attacks.
Of course, always watch for evidence of port scanning in your logs. Once found, "contact the originating ISP and ask it to investigate. Most ISP agreements don't allow port scanning," Hogragia says.
More obvious signs of intrusion on a Unix system include hidden files or directories, and setuid and setgid files, among others, CERT says.
Best-kept secret No. 4: Hacker tools are essential for your arsenal.
If you want to know what hackers see when probing your network, use hacker tools, SystemExperts' Cox says. The benefits of mastering hacker-built tools such as Strobe, Mscan/Sscan and SATAN/SAINT/SARA are numerous, agrees Cindy Ballard, network manager for Internet auction site Bid4vacations.com in Westminster, Colo. Because analyzing data produced by hacker tools requires more skill than analyzing data from commercial tools, using hacker tools helps you understand the hacker mind better.
However, such software carries unique risks. Disguised as a port scanner, a hacker tool could be hiding malicious code or a backdoor for whoever runs the FTP site from which you downloaded it. If an attack occurs, the IT staff could be blamed because it possesses hacker tools. You must ensure management knows that your staff will be using these tools as well as commercial scanners. Ballard recommends downloading and testing hacker tools on a stand-alone machine and removing them before too long.
Still, if you don't want to use hacker tools, then hire a security consultant who will, Hogragia says.
Best-kept secret No. 5: Key length is a near-meaningless measure of public-key infrastructures (PKI).
Now that most products support key lengths of at least 128-bit symmetric and 1,024-bit RSA/Diffie-Hellman, the lines of defense have moved, says Paul Kocher, founder of Cryptography Research in San Francisco. Key validation is more important, he says. That is, lessen your concern over hackers decrypting your data, and concentrate on preventing them from snatching active keys.
Many products issue certificates and encrypt data "yet ignore the question of how to make sure keys aren't misused. It's a tricky problem because validation servers have to work seamlessly across many certificate authorities and product vendors," Kocher says. "In many PKIs and networks, the compromise of a single key could be catastrophic."
This doesn't mean cryptography is a nonissue. A poorly designed key, no matter its length, isn't secure, nor is a well-designed key in otherwise faulty software.
Kocher recommends analyzing bug reports of the current and earlier versions of PKI products you're considering. Look for support of standards and products that have published cryptography designs. Published designs do not weaken the security as long as the actual keys are kept secret, he says.
"Cipher and protocol design are incredibly tricky. . . . Published designs benefit from academic and third-party reviews," Kocher says.
You should further beware of bulky code. The more complex a product, the greater the chance it contains vulnerabilities. Long lists of features are red flags because most bugs hide in seldom-used features.
You can also short-list a PKI product by evaluating a vendor's honesty. Does it offer you third-party reviews? Are its claims realistic and well-documented? "Good products won't be touted as completely unbreakable," Kocher says, "and good companies will discuss their security risks and past failings."
This story, "The best-kept security secrets" was originally published by Network World.