Endevor

To comply with NIST 500-83 AC-6 Least Privilege, I arranged (using our official change process) to remove the assembler and compiler libraries from the LINKLIST on the z\OS production partitions (we have separate development and test partitions). But I am now being told (after the fact) that "support [for] anything that makes our install process more complicated" will not be granted. How do you handle access to the assembler and compiler on production partitions? Can those libraries be in the LINKLIST and execution authorization be restricted to only COTS software installation staff using RACF?  Can we assume that the vendors SMPE definitions will support a STEPLIB to the assembler and compiler load libraries?

I think we can initially assemble and compile into development or test libraries and then copy the load modules to the production libraries. Or is it asking too much to arrange for the assembler and compiler load libraries to be removed from the production partition LINKLIST

I'm unclear if you are referring to application load libraries or system ones, but I'm going to assume you mean applications being generated by Endevor.

The easiest thing I can think of is to just remove the GENERATE processor from your production stage and make sure your MOVE does a MOVE, not a GENERATE. Assuming you're running production out of Endevor controlled datasets, you have assurance that the last compile/assemble was done pre-production. 

(Not exactly sure if I answered the question or not, though....)

This an about removing access to the software development tools from the production partitions to protect our software change management controls from being bypassed. One way is to remove the assembler and compiler load libraries from the production partitions LINKLIST and restrict access to those libraries from the production partitions. Another way is the restrict use of the assembler and compiler load modules on the production partitions (for example, using a RACF general resource program class). A third possibility is to remove the assembler and compiler load modules from the load libraries on the production partitions and publish a procedure to populate them temporarily on an as needed basis. This also applies to the UNIX compilers that could be executed on the production partitions. Ideally we would remove them entirely from the production partitions, but some people would be inconvenienced if we did that and as a result management will not agree to removing them. but we should be able to at least restrict their use. At least some people acknowledge that generally accessible development tools on the production partitions pose a security risk.

I guess my opinion is just make it so production only runs out of datasets that are controlled by Endevor. Then you don't have to mess with the assembler and compiler load modules on the partitions... if Endevor writes to HLQ "XXXXXXXX.whatever.LOAD" and Endevor is the ONLY one that CAN write to "XXXXXXXX.whatever.LOAD" and packages are needed to MOVE objects to XXXXXXX and you remove the ability to GENERATE to XXXXXXX.whatever.LOAD", you have (in essence) accomplished your goal. 

I am required to formally confirm that I have read, and am acting to comply with, a security and privacy control standards document that included an instruction to restrict access on the production computing environments to compilers and similar programs that convert source code to executables.  I am disinclined to cite SCM tool populated production library security as justification for rejecting that recommendation in part because I think properly securing production entails multiple levels of different, sometimes overlapping, defensive steps, and in part because I defer to others who have more expertise in their technical area of focus than I do.