I would regard an appropriate response to such an obviously-uninformed
request to be to send them links to the extensive IBM documentation
covering these automated controls on z/OS -- e.g.
z/Architecture Principles of Operation
various RACF manuals
manuals on authorized system macros,
and various other generic IBM manuals on security concepts in z/OS
Your installation should have some internal documentation on local
installation conventions for administration of RACF and approval of RACF
change requests and policies on protection of updates to PARMLIB members
which relate to security and authorized libraries, and this is the only
locally produced documentation that makes sense on z/OS, as all the
automated security support is integrated into z/OS and thoroughly
documented by IBM. If they were competent auditors they would know this.
We were fortunate in that our corporation had its own audit department
that interfaced with the annual external auditors and our auditors were
fairly well versed in z/OS security concepts from interfacing with
Technical Services over several decades. If the external auditors were
ever totally clueless, we could reasonably expect our own auditors to
recognize requests that didn't make sense in the context of the
mainframe and side with us on suggesting sensible alternatives.
J C Ewing
On 09/05/2012 08:29 AM, Blaicher, Christopher Y. wrote:
You have to show the whole picture of security involved in z/OS.
1) The instruction set is broken into general, semi-privileged and privileged.
2) The operating system has RACF, or equivalent, to control who can put what in
what libraries and data sets.
3) Data set (read as libraries) control the level of instructions and functions
that can execute.
4) If a user can put an 'unapproved' program in a library, but can't use it, is
it a risk?
The trick is to show that there are required procedures that must be followed
to get programs into a situation that could be 'dangerous' to the system.
Of course, you could write a program that scans every PDS/PDSE and verifies
that every program is on an approved list, but then how do you verify that
someone didn't put a 'bad' program with a 'good' name in a library. Of course
your checker program could use a CRC check and verify what is there is what you
think it should be, but what do you do when maintenance is applied?
Send the question back to them. What product or system is available for you to
use to do what they want?
Chris Blaicher
Senior Software Engineer, Software Services
Syncsort Incorporated
50 Tice Boulevard, Woodcliff Lake, NJ 07677
P: 201-930-8260 | M: 512-627-3803
E: cblaic...@syncsort.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Greg Dorner
Sent: Wednesday, September 05, 2012 7:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Preventing the installation of "unapproved" software
Man, the auditors came up with a new one!
"Gap noted. Automated controls to prevent the installation of unapproved software
were not documented."
So I have been assigned the task of researching how to provide "Automated controls
to prevent the installation of unapproved software".
I'm hoping someone on the list has a clue to what could possibly do this. My
brain already hurts thinking about it. Just thinking logically with my limited
intellect tells me doing this is somewhat close to impossible.
Any thoughts? I also accept rants and expletives.
...
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
