On Fri, 6 Mar 2009 08:48:18 -0600, Hal Merritt <hmerr...@jackhenry.com> wrote:
>IMHO: exits as a subspecies are evil critters. They become an ongoing maintenance challenge and tend to attract unwelcome attention from auditors. Exits are hard to write, hard to stress test, and introduce a level of risk. You need extraordinary measures in place to protect the code. > >On the well proven fact that there is no software that is completely bug free, why would you want to introduce -more- bugs into your most sacred of processes: authentication? > >There is another pretty interesting argument that as the complexity of your solution package increases, so do the opportunities for holes. Perhaps put there intentionally (the largest risk is internal) or intentionally (bugs). > >I once worked in an exit happy shop. Getting the exits updated and tested tended to be the single biggest bottleneck in rolling out new operating system levels. > >Of course, if you have a compelling business/technical need, then lock and load. Those are some of the reasons that we provided the REXX part of the exit, too, with code that implements some commonly requested functions. Ideally all you have to do is set some switches to enable the functions we've already written. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
