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 and then open it up without a security plan in place, you've opened all that data up to the Internet," says Chuck Townsend, president of LegacyJ Corp., a Cobol conversion software and services vendor in Pleasanton, Calif.
The problem is twofold, says Edmund C. Arranga, editor of weekly online 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 explains. "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."
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 now introducing additional accidental complexity," Arranga says, 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."
Different Strokes
That's why no two legacy-to-Web applications look the same. Nor should they. According to Arranga and other analysts, businesses with compelling reasons to open their legacy systems to the Web should build their infrastructure with minimum access in mind.
Some organizations, such as Minneapolis-based Lutheran Brotherhood, an insurance and investment association for Lutherans, won't open their legacy applications to customers. The company has Web-enabled many of its applications so that its district insurance officers can look up customer information and access forms online. Others, such as San Francisco-based Charles Schwab & Co.'s eSchwab Web site, must meet customer expectations for live trades through real-time access to their legacy systems if they don't want to lose business to competitors.
And then there are those that fall somewhere in between, such as Erie, Pa.-based food distributor C. A. Curtze and Co., which refreshes legacy data on the middleware server hourly instead of allowing direct Web access into its legacy system.
ESchwab Giving It All Up
With the advent of online trading firms such as ETrade Group Inc. in Palo Alto, Calif., pushing into its territory, Schwab 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," says 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.
It was in this middleware layer that Schwab had the most work to do. At the time, the middleware worked only with SNA, an IBM mainframe architecture. The Web uses Internet Protocol.
"You have to take a Web request coming in IP and translate it into an SNA request, then take the SNA response and turn it into IP to drive the browser," Richards explains.
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 says. 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.
To enforce these access functions, eSchwab relies on a second firewall inside the server cluster that authenticates a user's privileges and puts a security-object cookie on the user's browser to flow along with his actions and grant or deny access based on the privileges in that object.
"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 says.
Because traditional mainframe security can't scale to millions of users coming from the Web, Richards says he feels this is currently the best large-scale addition for the tried-and-tested IBM mainframe access controls and privilege lists.
Balancing Act
But traditional IBM mainframe RACF controls still rule at Blue Cross/Blue Shield of Chattanooga. In the insurer's Cobol-to-Web extranet application, medical providers access claims, eligibility and client coverage with their browsers.
Because of the sensitive nature of this material, providers that use this application must pass two authentications, first by providing a digital certificate to the Web server and then at the mainframe itself, which grants or denies access based on predefined criteria in RACF.
"It's a bit cumbersome," says Wayne Wilson, senior manager of e-commerce and government systems at Blue Cross/Blue Shield of Chattanooga. "We've been trying to limit the number of customer sign-ons, but we need both levels of security here."
RACF also still rules at Lutheran Brotherhood. Ron Starzinski, lead information security analyst at Lutheran Brotherhood, says he's well aware of the security problems when converting Cobol into or wrapping it around C++ or other more complicated languages. Thus, along with careful planning and testing of middleware code, he also adds an extra ounce of prevention - RACF access controls.
"It's an unusual architecture. The way our middleware is constructed, we actually utilized (Secure Sockets Layer) browser encryption to our mainframe access-control mechanism," Starzinski says. "We then use our allow/disallow functionality to prohibit or allow access to application resources on the mainframe."
Because this dual-authentication architecture doesn't work on a larger scale, Lutheran Brotherhood's legacy-to-Web applications are limited to corporate intranet users such as district insurance managers. And, as at Blue Cross/Blue Shield, opening up Cobol applications to the public won't happen anytime soon, Starzinski says. "We want to make sure that people who are accessing legacy applications off the Web don't at the same time have access to other application resources, such as our restricted internal applications," Starzinski explains. "We've just addressed this in a test with server-side certificates."
But the client side presents the dilemma. Not only will RACF prove problematic in terms of scaling, but so too will certificates.
"If we wanted to expand our network, we would have to issue 20,000 certificates to authenticate our insured," he says. "It will likely take two to five years to accommodate low-level certificates like this."
Issues such as these are also holding up similar Web-based customer service deployments for the $140 million C. A. Curtze.
Scaling Problems
Tony Darden, a Curtze programmer, began dabbling with Cobol-to-Web conversion tools two years ago. He decided to start his own Cobol-to-Web conversion consulting business, SalesPro Technologies Inc., also in Erie. 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 says. 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 says. "You can incorporate your HTML 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," says Darden. "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."
Darden, like other IT managers working on Cobol-to-Web conversions, has reason to be paranoid, what with 273 organizations citing nearly $266 million in financial losses as a result of computer crime last year, according to a March report by the FBI and the Computer Security Institute in San Francisco.
Thus, 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 build-out itself, explains Pamela Coker, CEO of Acucorp.
"People think, All of a sudden, we should be secure in an environment that's inherently unsecured," she says 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."
Radcliff is a Computerworld contributor in Northern California. Contact her at DeRad@aol.com.