Patrick O'Keefe writes: >If the shops I've seen are any example, there are many thousands >(millions?) of lines of online application code whose function depends >on knowing and understanding LU names. This is not for security, but >for setting the application environment: this user gets this print queue, >this mailing address, access to this database, etc. Whether that is a >reasonable design is irrelevant; it exists, and it is too deeply embedded >to change without major redesign.
Absolutely true. I generally advise at least reviewing these sorts of issues. There are many cases (e.g. print LUs) where it may be possible to change strategies and let a modern TN3270 gateway -- CS z/OS certainly qualifies -- handle some or all of the LU assignment logic previously hardcoded. "It depends." >Even so, that does not argue for offloaded Tn3270 servers. If anything, >it argues for the need to centralize maintenance of the various LU pools >so that changes or additions to LU names don't conflict with existing >names. Yes indeed -- very good point. >And THAT argues against the value of an outboard Tn3270 server as >protection against a Denial of Service attack. Unless the only IP >service you provide is Tn3270 you still to provide access to your host. >It protects you against a DoD attack directed to your Tn3270 port on >your Tn3270 server's IP address. It does nothing to protect you from a >DoS attack directed at any port on your hosts. It doesn't even mean one >less port on your host; you still may use port 23 (or whatever port you >choose) on your host for Telnet or Tn3270. Agreed, TN3270 is rarely the only IP service. Let's remember also you can have all sorts of attacks without IP. Install any offboard server, connect it to another (such as a mainframe), "trust" it for application interaction of any kind (e.g. traditional LU6.2), and you've now got a potential attack vector. Nothing new here. I would argue that complex (i.e. multi-tier) infrastructures are inherently more difficult to secure than simpler ones, and hopefully that isn't a controversial idea. Security-oriented people must also be very careful in understanding the human element. If you build a total moat around your mainframe and make it hard for even legitimate access to information, then workers are simply going to figure out a way to get their jobs done, and it probably won't be the way you intended. I saw one organization with an end user department that set up clusters of Windows machines which did nothing but 3270 screen scrape, using a single user ID, in order to replicate a database (effectively) so they could run a data cleansing program of their own design then upload the new contents. Of course that wasn't a technical problem -- mainframes can run such programs just fine, written in any particular language you like, developed using end-user friendly graphical tools, and SAF/RACF-protected so they only do what they're supposed to do -- but that's what happened when two groups failed to work together. And the resulting "solution" was anything but secure. (Imagine if one of those machines caught the wrong worm or virus. Game over.) Chris Mason writes: >Watching the responses to your post, if seems a popular "offload option" is >"to onload". I think that's right, although I want to be careful and say "never say never." There are a couple interesting corner solutions where it might be appropriate to run an offboard TN3270 gateway, but it requires some careful consideration. - - - - - 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
