Legacy Integration and Protecting the Mainframe
Our readers comment on the December 2001 issue.
I couldn't help but comment on Joseph McKendrick's Web-to-host article ("Shipshape E-Business," October 2001).
The need to integrate legacy information with new Web sites is a common problem that our customers face every day. Caching and refreshing the cache works for some implementations, but is limited to implementations that refresh relatively small amounts of data. Many of our clients are replacing this type of implementation because they've hit a throughput wall.
An alternative approach is to utilize the information directly from the legacy databases and files in which it resides, which is what the eXadas family of products provides.
eXadas dynamically integrates mainframe-based data with new Web applications using SQL (even for legacy databases that don't support SQL). eXadas JDBC and ODBC Connectors empower virtually any tool or application with direct access to legacy databases and files with no mainframe programming. And eXadas can scale to thousands of users while delivering sub-second response times.
Santa Clara, Ca.
I read Joseph McKendrick's article, "The Next Big Thing," (August 2001) and I agree with his assessment of the three areas of evolution in Web to host.
I invite your readers to take a look at Sybase's entry in the Web-to-host space, XJS/390 Enterprise Integrator. (I'm one of the developers of the product.) XJS/390 is the mainframe access piece of Sybase EP (Enterprise Portal).
XJS/390 is also a very powerful tool for any company looking to do EAI. XJS/390 provides Web-based access to existing CICS and IMS/DC apps, and gives customers the ability to quickly and easily create new Web-accessed host applications.
For more information, go to: www.sybase.com/products/eaimiddleware and www.sybase.com/products/eaimiddleware/xjs390enterpriseintegrator.
Security for Mainframes
I read Robert Bragg's article, "Don't Ask, Don't Tell" (August 2001) with great interest.
I'm a security consultant specializing in network authentication. My company, based in Montreal, has some customers using IBM mainframes—and they're opening up access through Web-to-host products, or by making the mainframe available through the IP network using the TN3270 protocol, for example.
Given that, I'm wondering about security around IBM mainframes, AS/400s and TN protocols, and what protection we can set up against those threats.
Montreal, Quebec, Canada
Sounds like you have a big challenge, Jeff—and you've brought up some topics that I'll address in upcoming columns.
In short, I'll be providing some broad-based security best practices for mitigating the risks associated with the growing exposure of mainframe data to the Internet. I'll concentrate on what you point out—the new challenges to mainframe security as companies like your customers move toward exposing data more readily on the Internet, on partner extranets and on corporate intranets.
Some thoughts: Certainly there will be new vulnerabilities—in fact, all those problems that are so visible today on Windows and Unix systems are beginning to plague mainframes. If your mainframe talks IP, is its stack vulnerable to the same typical IP attacks we have elsewhere? If applications are being used to legitimately obtain data from mainframes, is the only thing protecting the data a user ID and password? Are all users aware of the issues of complex password creation and password protection? Do these apps reside on the mainframe or on a Unix or Windows box? If they reside on the mainframe, do the applications themselves have vulnerabilities?
Some current midrange and Unix Web server apps also exist for the mainframe. What are their vulnerabilities? If they reside external to the mainframe, you'll have to consider the security vulnerabilities of the other hosts as well. Will a compromise of these external hosts make a hacker's job easier? The same hardware (routers, switches, etc.) lie between the mainframe and the Internet—compromising these access points will have the same effect on the mainframe as on any other source of data.
The first steps in any security plan should be the obvious ones: Password complexity and account policy; correct resource access authorization; appropriate and correct usage of native or resident security mechanisms; possible use of encryption to protect sensitive data; appropriate auditing and monitoring steps; researching known vulnerabilities for all the attached network systems.
I hope this short list and upcoming columns will prove helpful.