On 20/12/2017 9:35 AM, Jesse 1 Robinson wrote:
The exposure that my ancient Audit department focused on was devious code that
could be slipped into production in some random library being STEPLIBed to in
an individual job. Code like the legendary (fairytale?) case of diverting
fractions of a cent from accounts payable into a private fund. Someone would
have to vet the source code, of course, but at least there was an audit trail
from source to production.
I'm not sure I buy that. It seems like linklist would greatly increase
the number of people who could slip in a substitute module. I imagine it
would be easier and less obvious to add a module into a usermod or 3rd
party product installation than to change a STEPLIB in production JCL.
The problem that I am aware of is almost the opposite - where users with
less authorization can add modules that will be executed by uses with
more authorization. E.g. an application person adds a module that just
happens to match a likely misspelling of a RACF command. If called, it
checks authority, performs some nefarious action if allowed, then either
calls the real module or issues the expected error message according to
preference.
In theory code should be vetted, but I suspect the number of cases where
this is possible on z/OS means there would be a lot of stuff that goes
unvetted. On z/OS, you would have to include update access to any clist,
panel etc. libraries in any logon proc as well as any libraries which
are dynamically allocated.
--
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
