On Friday, 09/12/2008 at 09:20 EDT, Scott Rohling <[EMAIL PROTECTED]> wrote: > We are trying to eliminate all the z/OS DASD we are seeing on our z/VM > system...
While you can reduce the liklihood of them being accidentally used, I suggest you remove them from the I/O configuration. A secure I/O configuration is the second step in securing a multipartition system. If your auditors knew about the shared I/O, I imagine that they would object. The reason is that owning system's audit trail will not show that another partition accessed its data. If asked, "Who had access to the <sensititve> data on the date in question?" the answer from the scapegoat-seeking PHB will not be the hoped-for "I do not recollect at this time, Senator." Instead, the system programmers of each partition with shared I/O access will be on the short list. For those who are interested, the first step is to secure the HMC, and the third step is to create a separate partition for managing dynamic I/O. Do not allow a production system to do this - if it is, in some unforseeable way, hacked, it then has the keys to the data kingdom. In larger shops, separate the duties of "system programmming" from "hardware configuration management." Then it requires collusion between two people to get unaudited access to data (a conspiracy). Protect your company's data and yourself in one go. Plausible deniability, man; it's vastly underrated these days. Alan Altmark z/VM Development IBM Endicott
