Securing your network used to be a simple concept: get antivirus software. Well, that's what the antivirus vendors said, anyway. Then came the realisation that antiÃƒ,Ã‚Âvirus software was not enough to guard against all threats, although it remained a vital part of any network security plan. So then the concept changed. Get antivirus software and a firewall and you're in tip-top shape. Well, that's what the firewall and antivirus vendors said, anyway. Then came the realisation that firewalls weren't enough to guard against all threats either.
This scenario repeated itself a few times, with intrusion detection systems, vulnerability scanners, penetration testing, SSL and so on, until it dawned on the more progressive IT managers out there that securing a network wasn't about any one product, or even a set of products. There's no checklist, and there never will be; the tools are always changing.
So what's out there for the IT managers of 2004? Here's a shopping list of the range of security technologies currently being recommended by vendors.
Vulnerability scanners have been in common use for considerable time. Companies such as eEye Digital Security and Internet Security Systems offer commercial variants, but there are many open source tools available that do a similar job.
The idea is, you set one loose on your LAN or your servers; the scanner probes them for common vulnerabilities and provides a report at the end of its run. It can tell you which systems in your network are vulnerable to which types of attack.
While they are continuously evolving, vulnerability scanners are mostly useful for telling you which patches haven't been run on a machine yet. If you have your patch management under control, they are of limited use.
Famed white-hat hacker Rain Forest Puppy wrote an early vulnerability scanner, Whisker, although it's no longer maintained. Nessus, from nessus.org, is a popular choice, and there are other niche scanners such as Nikto, which will scan a Web server for vulnerable or undesirable Common Gateway Interface (CGI) scripts.
If you're running custom applications, especially those that are accessible from the Internet, like .NET, J2EE, or PHP scripted applications, then these scanners will not audit your code for you to find design flaws. Simple design flaws have been found in some of the most popular Web sites out there, and can be as simple for an attacker as entering a dodgy URL into their browser.
Penetration testing and code auditing
While penetration testing has fallen out of favour with many organisations -- due to less-than-skilled "pen-testers" scanning for basic vulnerabilities that can be eradicated through proper patch management -- penetration tests are still useful in many situations, particularly for businesses where their Web site is a large component of their business model.
A good penetration tester, a rare breed, can prod and poke at your company's defences to find a way in. If they way in is through a known vulnerability affecting one of your company's machines, then it's of limited use.
But if the way in is through some old machine connected to the network that everyone has forgotten about, or through a design flaw in one of your company's custom applications, then the information could be worth its weight in gold.
The problem with penetration testing is finding a person or company good enough to tackle the work. It's an expert field, and let's face it, any manager skilled enough to know if a penetration tester is doing a good job could probably do it themselves. If you want to hire someone, ask around. Big consultancies charge mega-bucks for these types of services, but there are smaller players and freelance contractors that can do this work.
Chris Wysopal (also known as Weld Pond), the current chief technology officer of US-based security consultancy @Stake, had this advice for Technology & Business readers who want to survive a good penetration test.
"Not many places with data worth protecting have zero in-house-built code. Once you write a line of code you probably just wrote a vulnerability," he says. "[Write] secure code."
"Turn on that [Windows] XP firewall... this is one of the best defence-in-depth techniques I know," he adds.
"For the paranoid, run alternative architectures. Sure you are running Linux or OpenBSD but if you are running them on an Alpha processor there is little chance Johnny's [security exploit] will work."
Authentication and Single Sign-On
Case study: When security software goes wrong
Authenticating your users is no longer a simple task, especially if you have lots of them. As networks have grown in size and complexity over the years, so has managing the way users gain access to networks and resources.
The applications and data used by someone in the HR team are most likely not the sort of stuff you want your latest temp to be able to access.
So then you set about creating an access policy that deals with who gets access to what. It sounds simple enough, but when you have 10,000 employees in 50 different groups doing 200 different jobs, things can get a little tricky.
Single sign-on (SSO) systems have proved useful in tidying things up. They're basically a master console used for assigning access to employees in complex environments. They tidy up "ghost" -- or disused -- accounts and passwords that haven't been used in a while, and streamline the process of creating and administering accounts across hundreds of different resources.
It's quite rare that something as useful as SSO actually comes out of vendor land. It's even rarer for security software to present such a clear economic argument for its use. In most large organisations it will result in a boost to the bottom line, simply because the number of calls to the help desk requesting a password is slashed dramatically.
Instead of authenticating to a dozen different servers with a dozen different passwords, users just have to remember their master password. The SSO machine then logs them in to all of their accounts automagically. Neat.
Vendors like to call these technologies "identity management solutions", probably because it makes it sound cooler and more important. In truth, it's administration software as described above, with some good policy and management tools built in.
The truth about firewalls is they are among the least sophisticated computing devices ever invented, but they're also one of the most vital. They exist to inspect Internet Protocol (IP) header information, such as origin IP address and port, and destination IP address and port, and protocol type -- such as ICMP, UDP, TCP, etc -- and determine whether the data should be allowed through.
The main function of a firewall is to block certain types of incoming traffic. If you are running a Web server, you need to let traffic destined for TCP port 80 through, otherwise no one will be able to access it. As for your LAN, no connections from the outside world should be allowed in.
Often, the basic "nothing comes in" technique can be accomplished by using network address translation (NAT), which is essentially a basic form of firewall. These days most routers and broadband modems have an in-built firewall or NAT function, although NAT won't restrict outbound traffic, which is often desirable.
If your company doesn't have one, then you should consider resigning, moving to Brazil and hiring a plastic surgeon so you never have to show your face and be recognised in public again.
Virtual Private Networks
Virtual private networks (VPNs) can be used to allow remote users to access their networks as if they were in the building, and can also be used to provide a secure connection between two office sites. While standard PPTP (Point to Point Tunnelling Protocol) VPNs, as used by many operating systems, are easy to set up, they only rely on a password to stop outsiders getting in. A more sophisticated VPN protocol called IPSec can be configured to allow connections to users who have an encryption key generated by the VPN device. That means potential intruders can't simply throw a dictionary or random password generator at your network in order to gain access.
VPNs can also be configured to only allow certain types of traffic across their links. This is particularly important when dealing with large, site-to-site VPNs, but a good VPN policy is a must. If, for example, you only need to transfer files across links using Microsoft's file-sharing protocol, then why allow anything else? It was poor VPN policies that allowed the SQL slammer worm to propagate through secure global networks, even though the worm targeted a vulnerability that attacked a process on a port that is very seldom used. Ask yourself what you need and enable it. Deny everything else.
Network-based Intrusion Detection Systems
Network-based intrusion detection systems (NIDS) have been around for donkeys' years. They are usually deployed as standalone network "sniffers" that analyse traffic as it passes the machine, which acts as a sensor. A NIDS compares traffic that passes it to known attacks and alerts the administrator to any suspicious activities.
The problem with NIDS, according to Robert Ferrell, a systems security specialist with the US Department of the Interior, is managing the technology.
"NIDS, or any IDS, for that matter, is probably the most misunderstood and blatantly abused tool available to the security practitioner," he says "Without intelligent and strategically sound placement of the probes, without a thorough understanding of the algorithms and the network topology in place, without human interpretation of the results, an IDS is just an expensive piece of junk using up valuable bandwidth and CPU cycles and spewing out tons of useless data."
When Gartner, which had been hyping IDS, effectively ditched its support for the tool, many vendors re-branded them as "intrusion prevention systems," or IPS. They're basically the same device with some real-time heuristics -- a method of detecting attacks that may be new or unknown -- thrown in for measure. The IPS can then strip the malicious content out of the nasty data packet or simply block it. These types of techniques were used in NIDS systems, but marketing managers everywhere agree "prevention" is better than "detection", so voila! IPS it is.
Another limitation of NIDS is they can't inspect encrypted data. This means they are utterly useless in detecting attacks against SSL enabled Web servers. Some vendors offer NIDS products that can decrypt SSL traffic, but the administrator has to load the device with the server's private encryption key, which makes some security consultants hesitant. It's an introduction of another weak point: the NIDS itself (see sidebar on page 88).
A better alternative may be to use an SSL accelerator. This is a machine that sits in front of the Web server to handle all the encryption. Data is passed between the accelerator and the Web server in clear text, which can be analysed by the NIDS.
Host-based Intrusion Detection Systems
Unlike NIDS, host-based intrusion detection systems (HIDS) are designed to detect actual intrusions, and not attempted ones. They are installed on the host being protected.
If some evil hacker type hacks into your system and replaces one of your system files with an alternative loaded with malicious code, a HIDS can detect the activity. The HIDS can act like a booby-trap, watching for strange activity in the system memory.
Authentication and Single Sign-On
Case study: When security software goes wrong
Keeping up to date with your security patches has got so out of control that vendors actually make patch management software. The more sophisticated solutions keep an inventory of devices on the network and their patch levels. If you have enough time you could probably do that job with a pen and paper and a copy of Microsoft's Windows Update Services (WUS) to handle patching the zillions of desktops you no doubt maintain, assuming of course that you run Windows on the desktop.
Patch management it vital. Whether you use a vendor solution or not, you should have a good patching process in place. It will protect you against the vast majority of attacks you're likely to encounter.
Yes, you still need it. Preferably on your servers, your desktops, and your mail server to inspect incoming e-mail. Even the humble handheld is no longer safe (see sidebar on page 86). As with a firewall, there's really no excuse for not using antivirus software.
This is a really neat idea that's finally getting some traction. Instead of letting your users execute any e-mail attachment that hits their inbox, this software lets you restrict what can and can't be run on a given system.
Most, if not all, viruses and worms will load their own process into memory in order to infect the host system and propagate further. If you remove the user's ability to be tricked into executing an attachment, you're covering a remarkable number of threats. Let's face it, even if you have a "do not open executable attachments" policy and tell your users, at the end of the day they'll still open anything that promises a movie of dancing dogs or the latest picture of Paris Hilton with her kit off.
And, if you're a fascist network maintainer from hell you can have oodles of fun disabling the telemarketers' ability to run Solitaire. Hell, you could even set up a side business accepting bribes for games execution rights. Could be a nice little earner.
Honeypots and Honeynets
Honeypots, are one technology for which the future doesn't look that bright. Many in the industry expect the systems to find themselves on death row some time before 2006.
Described by Greg Shipley, chief technology officer at security consultancy Neohapsis as the "security guy's pet rock", the general consensus is that honeypots and honeynets are useless.
As the name suggests, a honeypot is a vulnerable system that sort of waves about to the world at large saying "Hack me! Hack me!" Their use is two-fold: research and diversion.
The Honeynet Project (project.honeynet.org) is headed by security architect and former US Army tank commander Lance Spitzner. Along with his cohorts, Spitzner places vulnerable computers all over the Internet and allows malicious hackers to break in. By doing this, the Honeynet Project was able to study new types of attacks, and capture hacker toolkits for analysis.
The problem is, the bad guys out there hold on to their best tools like grim death. They are hardly likely to waste them on an anonymous, insecure system located nowhere interesting in particular. There was talk among vendors of using honeypots to act as a diversion to attackers. Once you've detected suspicious activity, divert them to an environment that looks like your production environment, but is in fact a virtualised duplicate. How cunning.
Unix security guru Rik Farrow doesn't place much stock in honeypots. They're "luxuries for the under-utilised security administrator," he says. "If you have budget for honeypots, and haven't done everything else, something is seriously wrong with your organisation's priorities," he adds.
Biometrics, tokens and smartcards
With passwords often dismissed as poor protection by security analyst houses, many companies are moving to extra layers of authentication. Biometrics, such as fingerprint scanners, smart-cards encoded with an encryption keys, one-time authentication codes, and authentication tokens are all show-ing promise.
One-time authentication codes can be generated at the authentication server and sent via SMS to the user, for example. This is already being used by banks in New Zealand to authenticate customers. Smart cards require the user to insert the card into a reader when they authenticate to the network -- if someone wants to access the network they need the card, not just information.
Security tokens rate pretty highly on the cool-o-meter. Usually carried as a keyring, the token's LCD readout changes regularly, providing the user with a pseudo-random code to be used in conjunction with their password.
Gluing it all together
Some vendors offer a wide range of security technologies that will seamlessly integrate. The problem is, it's unlikely the company's solutions will be best-of-breed in every single area.
Integration can also pose a risk. The guy who brags about having one console to control all of his security also brags about every hacker's prime target. It's a case-by-case basis; caution is urged.
Authentication and Single Sign-On
Case study: When security software goes wrong
Like all software, security solutions need to be maintained. You'd feel like a certified doofus if the software you bought to defend your network wound up letting an attacker in, right?
Well you can imagine how some ISS customers felt when the Witty worm came along. It used a vulnerability in the company's software to infect hosts. Unlike more benign threats out there, Witty caused considerable damage to the infected hosts.
Vulnerabilities in security products are the Holy Grail for crackers. Why would you want to find a vulnerability in notepad when you can find a gaping flaw in the very software that's used to protect data from misappropriation?
Many network intrusion detection products have turned out to contain vulnerabilities, across a large stable of vendors. Some of those flaws allow an attacker to take control of the NIDS machine simply by sending a packet across the network to nowhere in particular.
One flaw found in an "intelligent" firewall was a classic example of security technology getting too fancy to be effective. The firewall in question inspects Web requests as they pass through the device, checking them for suspiciously long or malformed strings.
Due to some downright awful coding, attackers could send a string to the Web server being protected by the device that would give them access to the firewall itself.
So if you don't want to be wiping egg off your face any time soon, keep an eye out for security patches for your security software.