Yup, at a particular client site we were able to get around any requirement for US to do anything with idle VM users by virtue of the fact that all Windows PC's are forced to have a screen saver timeout with password (and end users can't disable it). In Govt auditing terms, we "inherited the control", and the control was satisfied.
When undergoing a security audit, always try to use inherited controls wherever possible - it shifts the responsibility for YOU satisfying the control to some other organization. :) -Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Les Koehler Sent: Thursday, September 24, 2009 5:07 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Where is the VM/CMS timeout value set An idle user isn't necessarily a security exposure. The security audit question to be asked is: Does the company have a policy for securing terminals when the user isn't there and how do they enforce it? It's very simple to write a little exec that makes a user look non-idle. Les Martin, Terry R. (CMS/CTR) (CTR) wrote: > Thanks Mike. I have Velocity so I will look into using that. I just > have not taken the time to write anything yet because it never came up > until now with the security audit. > > Thank You, > > Terry Martin > Lockheed Martin - Information Technology > z/OS & z/VM Systems - Performance and Tuning > Cell - 443 632-4191 > Work - 410 786-0386 > terry.mar...@cms.hhs.gov > > WFH Tuesdays and Fridays > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] > On Behalf Of Mike Walter > Sent: Thursday, September 24, 2009 12:39 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Where is the VM/CMS timeout value set > > To be a little more specific, z/VM does not provide such a service. > But at least one performance monitor provides exits to do what you > wish. > > We use Velocity Software's ESAMON product to do exactly this, the > TUNEFRC EXEC provides the proper call. We've modified that a lot to > manage forcing users idle for 3+ hours between the time of 9PM and 5AM > in their > > own timezone - but that is a very site-dependent requirement. > > I'm not sure if other performance management products provide the same > sort of capability, but it would seem likely. Any z/VM site serious > about > using z/VM needs a supported performance management product. > > Mike Walter > Hewitt Associates > The opinions expressed herein are mine alone, not my employer's. > > > > > > "Martin, Terry R. (CMS/CTR) (CTR)" <terry.mar...@cms.hhs.gov> > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > 09/24/2009 08:16 AM Please respond to > "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > > To > IBMVM@LISTSERV.UARK.EDU > cc > > Subject > Where is the VM/CMS timeout value set > > > > > > > Hi > > Where do you set the timeout value for an idle VM/CMS user for > automatic > > logoff? > > Thank You, > > Terry Martin > Lockheed Martin - Information Technology > z/OS & z/VM Systems - Performance and Tuning > Cell - 443 632-4191 > Work - 410 786-0386 > terry.mar...@cms.hhs.gov > > WFH on Tuesdays and Fridays > > > > > > The information contained in this e-mail and any accompanying > documents may contain information that is confidential or otherwise > protected from disclosure. If you are not the intended recipient of > this message, or if this message has been addressed to you in error, > please immediately alert the sender by reply e-mail and then delete > this message, including any attachments. Any dissemination, > distribution or other use of the contents of this message by anyone > other than the intended recipient is strictly prohibited. All messages > sent to and from this e-mail address may be monitored as permitted by > applicable law and regulations to ensure compliance with our internal > policies and to protect our business. E-mails are not secure and > cannot be guaranteed to be error free as they can be intercepted, > amended, lost or destroyed, or contain viruses. You are deemed to have > accepted these risks if you communicate with us by e-mail. > >