How To Protect Your Web Site

Companies are showing a remarkable light-footedness in moving their business applications to the Web, but, in the process, they are sometimes overriding the security measures that used to safeguard them.

Analysts say the recent string of high-profile intrusions is a direct result of the pressure being put on Web applications developers to get e-commerce and other Internet sites up quickly and make those systems widely accessible to the masses - not lock people out.

One such intrusion occurred Sept. 13, 1998, when The New York Times' site was hacked and peppered with sexually explicit messages that could not be removed. Times site managers took it down at 10:20 a.m. for nine hours on a high-traffic day, Sunday. The attack could have been prevented through well-documented precautions, security experts say.

"The mechanisms for passing requests for information back to the core systems are not designed with security in mind," says Jay Bolton, a partner at consulting firm PricewaterhouseCoopers.

But according to security experts, there are several products and techniques that can be used to shore up both the front and back ends of commercial Web sites.

Frequently, with many of today's Web sites, the data needed to tell customers the status of their orders or the functionality needed to capture their transactions is found in legacy applications, such as SAP's R/3 enterprise resource planning suite or an Oracle database application, located on a mainframe or other host. Access to that application used to be limited to an individual log-in procedure. But it would never do today to require every Web site user to remember a separate name and password for each application.

In the past, the mainframe's mere inaccessibility guaranteed there would be few security breaches. Knowledge of mainframe access was limited to those deeply schooled in its ways and in intricate mainframe security systems, such as Computer Associates International's RACF and ACF2. The mainframe security packages kept a close eye on what users were trying to do vs. what they were allowed to do.

In addition, many of today's Web servers run older versions of the Unix operating system and are not "hardened" or bolted down against intruders. The holes in older Unix versions, such as SunOS or Unix System V, are well-documented on the Web. "If someone can get into your Web server, they're pretty much in," says Alex Noordergraaf, senior security architect at Sun Microsystems Professional Services. Once on the Web server, the intruder can assume system administrator privileges, and then the links to legacy applications become "a neat channel to your back-end systems," Noordergraaf says.

With time to market at a critical juncture, Web application developers consider getting users to the application a more pressing goal than protecting the application from the rare miscreant. Web application developers "tend to strip as many rules as they can out of the firewall. Anybody on the planet can talk to your Web front end," Noordergraaf says, and a skilled hacker can determine if it's run by a version of Unix or Windows NT with holes in it.

Web development teams start out with some security measures in place, then find they are facing increasing delays and penalties as they try to add multiple applications to their project. The response is to impose the minimal level of security, such as a simple user log-in at the Web server, and override other protective measures, Bolton says.

In many cases, he says, one group of information technology specialists is developing the Web application while another runs and maintains the mainframe. "These are two separate groups doing different things, and often they are not coordinating their efforts. I've seen mainframe managers turn ashen as they're told what's being accomplished with a Web application," Bolton says.

One way to maintain security across applications - legacy applications connected to a new Web application - is to centralize the security function in front of the set of applications to be accessed. One system can then check user identities and level of privileges, and authorize them to access the applications they are entitled to, says Eric Olden, chief technology officer at Securant Technologies, an Internet security management software supplier. Securant's SecureControl 3.5, priced at $20 per user, provides such a function.

Active Software's Information Broker, middleware that uses store-and-forward messaging to connect one application with another, also performs such a function, using a certificate-checking mechanism to make sure the requesting application is who it says it is, says Rafael Bracho, chief technology officer at Active Software, an enterprise application integration firm.

Such an approach lets a third-party vendor create and maintain the security system, but it's an answer with a price. A typical Active Software project starts at roughly $75,000, with some projects crossing the $1 million mark, Bracho says.

Short of that approach, these experts offer some steps that can be taken to achieve an 80 percent to 90 percent secure Internet application. More stringent steps will get the organization's security around 95 percent secure. Achieving 99 percent security is cost-prohibitive for most shops, they say, and achieving 100 percent security is almost impossible at any price.

Harden the operating system on the Web server. This is a common point of failure. The operating system should be the latest release, with all vendor-provided patches installed. "Run the Web server operating system in a sand box," according to Sun's Noordergraaf.

That means the operating system is controlled by a hidden set of files with a nontypical directory name. Only system administrators within the organization are allowed to access it, he says.

If you don't harden the Web server, an intruder can gain administrative privileges on it, making him invisible to the intruder detection system, which is trained to look for the behavior pattern of an unauthorized user, not an administrator, Noordergraaf says.

Keep the rules of the firewall as stringent as possible. Test them because they are easily reversed from the safeguards intended, Noordergraaf says.

If you install a front-end security management system, tie it into the existing mainframe security protections and let their well-established policy rules govern who accesses mainframe applications, Securant's Olden says.

"Most sites stop when they think they've put security on the Web server and the application server," he says.

After installing security measures at the Web server, application server and other points, give security administrators one view into each system's server logs so they can follow one user account from point to point to see what is going on. "Aggregate the security logs into a common reporting system," Olden says.

Some sites are aggregating data in a front-end data warehouse, PricewaterhouseCoopers' Bolton says, and only allowing Web users to reach the warehouse, rather than the applications generating the data on the back end.

Know your own systems' strengths and weaknesses and spell out to the intruder detection system what it's looking for. "You don't want a bunch of false alarms that nobody pays attention to. You have to have a clear image of the intruder you're watching for," Noordergraaf says.

Most of all, Active Software's Bracho says, think security at the start of the application design. "Bolting it on afterward will leave your legacy applications open to breaches. The Web system has to take responsibility for security," he says.