Security sensitivities, 10/26/98

Security sensitivities
Opening a host system to Web users means being ultraprepared and never letting down your guard.

By Steve Blass
Intranet, 10/26/98

When it comes to securing Web-to-legacy links, there's good and bad news. The good news is that you can get to the mainframe from an intranet or extranet. And the bad news? You can get to the mainframe from an intranet or extranet.

The sad fact that most network break-ins come from inside the organization gets more dreadful when you consider that more and more sensitive data is traversing company Webs. And when you start talking about integrating an intranet or extranet with a legacy system - a host typically loaded with highly confidential, proprietary company information - that fact gets downright frightening.

Peace of mind can be yours, though, if you follow these basic guidelines.

First, you've got to temper the euphoria of getting the Web-to-host gateway to work, with security concerns raised by the fact that the gateway does, in fact, work. The last thing you want to do is compromise the company's well-being because you've opened the host.

So before you even begin to think about opening a Web-to-host link, make sure you've appropriately secured the intranet or extranet. This means you've got to address the issues of authentication, authorization, accounting and availability - not only in terms of policy but also in practice. For example, require passwords for all network access. Make guest accounts a thing of the past. Assign each login ID to one person only. Make sure network activities logged by Web servers are attributable to specific individuals.

One way to meet accountability conditions is by establishing a smart card architecture that requires two-factor authentication. Before a Web user gains access to host data, make him prove that he's got a smart card and that he knows the personal ID number and password that goes with the card. This virtually guarantees that the person logging in is actually the person whose credentials are being presented.

Establishing a person's identity beyond a shadow of a doubt takes care of authentication concerns. The next step is deciding whether to allow the authenticated user access to particular resources. This is a matter of authorization.

By setting up a public key infrastructure (PKI), you can foster a "Web of trust," as well as establish whether Person A has authorization to access Resource B. With a PKI, X.509-based digital certificates can provide authentication verification. And when you use them with X.500 directory resources, digital certificates can help manage access privileges.

But implementing authorization and authentication technologies alone is not enough. In addition, you need comprehensive data access policy statements describing who has what access to which resources. These policy rules have to be made available electronically for intranet access decisions.

Content should be easily classified as permitted or forbidden for each person requesting information, and you need to make sure every transaction is logged. Set up Web servers to perform system level accounting, and process log files regularly.

Only when you've established sound intranet security should you advance to integrating that Web with your legacy data system. There are two prevailing models to consider in doing so. In the first model, a legacy-hosted data set is published to the intranet. The second model allows intranet users to query against information housed on legacy systems.

Securing access to a well-defined, published data set extracted from legacy systems reduces the problem of protecting other Web pages on the intranet. Control can be exercised through PKI certificate credentials, or even by server-based Web page logon access controls. Alternatively, you could send the published data via encrypted e-mail to users who are authorized to have it.

Securing access in the second model, in which intranet-based queries are presented through a dynamic gateway, is similar to the steps required to secure the back-end extraction process in the first model.

In both cases, take care to ensure that the request is coming from an authorized requestor and that the results are published to the appropriate outlet. Guaranteeing both conditions can be a trick given the weak security provided by the TCP/IP protocol suite underlying intranet implementations.

Taking advantage of the Secure Sockets Layer and HTTP-S //<< As an additional precaution, use a proxy server like you do to protect against ne'er-do-wells tapping in from the open Internet. Make sure to take advantage of policy-based routing schemes offered in some proxy servers, as well as in other equipment used to link the intranet to legacy systems.

Authorized users should present their requests for legacy system information through a proxy server that is identified as the only legitimate source for such queries. That proxy server, in turn, should essentially be a single-use machine that only accepts connections and requests from the select group of authenticated users that has been granted access privileges for the legacy data.

Further safeguards such as time-of-day and day-of-week restrictions on particular types of legacy queries can help prevent some attacks. They also can provide telltale alarm messages when authorized users are performing unusual queries during off-hours.

And, it's always a good idea, particularly when security really matters, to encrypt all Web-to-host requests and responses.

Beyond these basic guidelines, take steps to implement switched rather than shared network media. This will cut down on the exposure of sensitive network traffic to unauthorized sniffers and eavesdroppers. It is difficult to stage a man-in-the-middle eavesdropping or spoofing attack in a switched environment in which there are no workstations between the requestor and the server. On the other hand, it is easy to introduce a shared media hub and an eavesdropping workstation to the link if physical wiring closet security is not sufficient.

In the end, securing the connections between an intranet and a legacy system is the same problem as securing the legacy system or the intranet itself, or securing any other manifestation of an organization's intellectual property. It takes work to obtain a clear articulation of policy and to map policy to procedure and process. It takes diplomacy to obtain the political support required to do the right things. It takes finesse to foster compliance with security policy among the workforce. And, finally, it takes effort to implement the technical solutions that support a comprehensive enterprise security posture.