A policy of "we don't enable TCP/IP on our mainframe for security reasons" inevitably results in...less security. :-(
Yes, if you put all your corporate information in a vault and send it to the deepest trench in the bottom of a major ocean, your information will be "secure." It will also be inaccessible. Duly authorized and authenticated individuals still need access to (and even must update) corporate information. So how are they going to do that if you insist on disabling TCP/IP on your mainframe? Through gateway servers, of course. And how are the security mechanisms set up in such cases? Most often, inevitably, with super-permissive whole-server IDs and passwords. And you've now taken the world's most sophisticated and robust security system, the z/OS Security Server, and effectively disabled it, pushing authentication and even authorization to, say, Microsoft Windows?!?!?!?! Not to mention all this corporate information flowing in the clear, through PC memory and internal (sometimes external) networks.... Check this narrative in comparison with your own organization's current installation. About a month ago I visited a bank, and this is exactly the pattern that developed in their current architecture. The bad architecture also happened to be far more expensive to implement and to operate. The solution is pretty simple in concept at least. First, get rid of the blanket policy, now. If there's an end user or application that has a TCP/IP link to somewhere and ultimately accesses mainframe-hosted transactions or data, then it's hard to imagine why you wouldn't have TCP/IP enabled on your mainframe. In 2007 this probably describes everybody. (Or do you have hardwired real terminal tubes? Or encrypted SNA-type connections to terminal emulators that human beings use directly? If you've got only those access paths, you might be a special exception.) Second, as with any other TCP/IP connection, secure it using encryption and the other security facilities available, depending on your requirements. (You can use unique client certificates, for example. And virtual firewalls. And choose non Internet-routable addresses if appropriate.) Third, take a good, hard look at authorization and authentication and where it's happening. In many cases you'll be horrified at what's actually going on, whereupon you can take remediation steps. Again, the mainframe has all the "cool, hip" stuff -- like an in-built LDAP server in z/OS, to pick an example -- so you've got lots of security implementation choices. Fourth, establish good security review procedures, audit procedures, and monitoring mechanisms. This is a lot easier and more potent when you can focus on centralized computing infrastructure. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
