ComputerWorld Canada
September 22, 2000

Cobol on the Web May Not Be as Safe
Middleware Can Translate It, But May Compromise Security
By Deborah Radcliff
IDG News Service

Cobol. A simple language that's so easy to read, it's impossible to hide malicious programs. A language for mainframe data locked securely behind tried-and-tested access controls like the Resource Access Control Facility (RACF), Top Secret and ACF2. But that's all changing, now that brick-and-mortar companies are linking online customers and suppliers to their own account information stored in the mainframe.

To do so, companies are writing elegant middleware code to make the language of the mainframe (Cobol) talk to the language of the Web (HTML). But in so doing, businesses are stripping away the decades-old security mechanisms inherent in Cobol and mainframe access controls.

They're taking Cobol, which is secure by virtue of its simplicity, and wrapping it around or translating it into C, C++, Perl and Java. Then they're pushing and pulling this data to a Common Gateway Interface translation server with less-secure operating systems.

If done incorrectly, these new legacy-to-Web system efforts could, by virtue of this added complexity, inadvertently allow unauthorized viewing of the converted data or glimpses into previously protected areas of the mainframe itself.

"If you take something that's historically in a glass house then open it up without a security plan in place, you've opened all that data up to the Internet," said Chuck Townsend, president of LegacyJ Corp., a Cobol conversion software vendor in Pleasanton, Calif.

The problem is twofold, said Edmund C. Arranga, editor of the weekly on-line newsletter CobolReport.com in Orinda, Calif. First, businesses are putting this data on a middleware server with less-secure operating systems and access controls.

"The overriding issues are often found at the operating system-level itself," Arranga said. "You have so many break-ins on the NT boxes, and companies don't have time to patch or are even unaware of the vulnerabilities. Unix is less of a security threat. But it really all depends on the underlying architecture designed to protect their assets."

Hiding Places
The other security issue resides in the middleware programming layer, he continues. Checking code for malicious programs is easy in Cobol. But Perl, C++ and even Java are great hiding places for malicious code because they're more complicated to read.

"You're introducing a lot more potential for problems and errors because you're introducing additional accidental complexity," Arranga said, paraphrasing Fred Brooks, the father of the IBM 360 mainframe operating system. "To make sure this new middleware program is tasked in a well-defined manner, the system manager must read very complex strings of symbols, numbers and characters. (The process is) very error-prone."

With the advent of on-line trading firms such as ETrade Group Inc. in Palo Alto, Calif., pushing into its territory, San Francisco-based Charles Schwab & Co. was compelled four years ago to build a real-time trading service for customers who were demanding Web trading. When Charles Schwab, the company's co-CEO and chairman, first saw a demonstration of customer transactions that let browser users call up legacy data, he issued an edict to build such a system in a scant three months.

"For a long time, our back-office systems ran on IBM MVS, with a security system equivalent to IBM's RACF. It was very robust in terms of access controls and privileges," said Adam Richards, vice-president of transactional architecture at Schwab. "When we planned to go on the Internet, we realized we couldn't do what a lot of companies do-put up a storefront without any real access to the business systems at our firm. Our customers needed direct access to their data to perform an action on their assets in real time." At the time, Schwab had already built new screens to represent mainframe data in a new client/server environment. So all the company needed to do was build Web graphical user interfaces, port those screens to the Web servers and "glue" the Web servers together with the legacy data through a cluster of high-speed middleware servers.

The first security policy was to keep the new applications as simple as possible.

"You can do a lot of things in C++ that look elegant but aren't good for security," Richards said. In the Schwab environment, Web-based customer applications are limited to functional requests, such as balance inquiries or transferring money between accounts. This limit both restricts the user to his own account field and prevents accidental or purposeful overflow into other areas of the legacy system.

"A customer could completely muck up the presentation of his own account information but couldn't gain access to some other account (that) he's not authorized to access," Richards said.

Because traditional mainframe security can't scale to millions of users coming from the Web, Richards said he feels this is currently the best large-scale addition for the tried-and-tested IBM mainframe access controls and privilege lists.

Tony Darden, a programmer with Erie, Penn.-based food distributor C.A. Curtze and Co., began dabbling with Cobol-to-Web conversion tools two years ago. He decided to start his own Cobol-to-Web conversion consulting business, SalesPros Technologies Inc., in Erie, Penn. Under that consulting name, Darden built a Web-based order network now used among Curtze's in-house and outside sales representatives.

"Now we have to make this Web-accessible to our customers," he said. Already, he has figured out that it's more secure to keep the customer data in Cobol, so Darden is experimenting with a Web browser plug-in offered by Acucorp, Inc. in San Diego.

"Once the plug-in is enabled, customers can visit the distributor's Web site, click the order-entry link, and up pops an actual Cobol object running inside the browser," he said. "You can incorporate your HTML elements, elements inside the object, but the logic that supports it all is Cobol. Without the plug-in, the object won't execute and the data won't make sense."

The other advantage of Curtze's system: The customer has no direct connection to the back-end legacy system because the Cobol object is transported from the middleware server (which is refreshed hourly) to the customer's browser. "That object is what the customer sees," Darden said. "There is no data they can get to on the legacy system, only data on the Web server based on permissions from the log-in screen."

No system that pulls legacy data to the Web should go live without having security built into the planning and development of the e-commerce building out itself, said Pamela Coker, CEO of Acucorp.

"People think, all of a sudden, we should be secure in an environment that's inherently unsecured," she said of the Internet. "Guess what, corporations: You've given up security if you put your secure applications on the Internet. If you put your secure applications on the Internet, you'd better put (them) back on lease lines, where you have some control."

Contact | Site Map | | Legal | Trademarks | Privacy | Print this page