If you are a publicly traded company and z/VM is running production without an ESM or its equivalent, then you have a "material control weakness in your segregation of duties (SOD)" which can lead to more than a 10% error in your financial statements and by Act of Congress, Sarbanes Oxley, aka SOX, requires such GAPs, ie material control weaknesses, to be reported to the Board of Directors and for them to report it to the SEC, made public, which often as an adverse effect on the price of stock.
If the IT Audit has failed to identify such a weakness, then it needs to be redone. If you want to bring this to the attention of your management in a timely manner so you can obtain funding for your ESM, just call or email the Audit Committee which is, by law, a subset of the Board of Directors and I am sure the funds will be readily available. You may want to update your resume first. Tom Huegel <tehue...@gmail.com> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 12/08/2010 03:10 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Vswitch Grant as a CMD in User's Directory? It is a hard sell to management to buy an ESM if there is no audit requirement. On Wed, Dec 8, 2010 at 11:34 AM, David Boyes <dbo...@sinenomine.net> wrote: On 12/8/10 4:15 PM, "Quay, Jonathan (IHG)" <jonathan.q...@ihg.com> wrote: >I don't. I don't have any human beings on my systems except for system >programmers that have full authority anyway. Having to GRANT linux >servers is an extra thing that has to be managed. I would like to >define a vswitch as unrestricted. > >Is there anyone out there that actually gains security from CP users not >being granted onto their vSwitches? How many people would like to be >able to >define a vSwitch as "open to the public" or not requiring a grant to be >accessed? I'll make a counter argument: there is a significant difference between being allowed to create a piece of infrastructure, and being allowed to use it. Granting permission to use something after it's created is that second item, and I would say that there is a very good reason to have the two steps separate so that they can be separately controlled and audited. So, I think I'm going to side with Alan. If you want an unrestricted VSWITCH, you need to kick your ESM vendor to allow you to control them and declare a rule that anyone can attach to said VSWITCH. OTOH, I think this also argues for a bigger step: for IBM to supply a default ESM and quit having to do it two different ways. We can always replace the default one with something better, but there's a lot of wheel-spinning being done in IBM development to support the two different models. Personally, I dislike RACF with a passion, but I'd rather have RACF be present by default and have one single way to do security management (via the ESM) than have to have a completely separate command authorization matrix to worry about via CP privilege classes, etc, etc, etc. It may have worked in the past, but it's time HAS past. There's too many regulations and too many hostile bozos out there to not have a comprehensive security management tool as part of the VM hypervisor suite. If that means we all have to suffer under RACF for long enough to turn it off, then so be it. >
