Last Updated: 01 February 2024


z/VM Security and Integrity Resources

Best Practices


Defining best practices for security for any information system is nebulous at the best of times. Security is not, after all, one big dial one turns from "clear" to "secure." Security and privacy are lifestyle choices, whether one is speaking of a mobile device, a laptop, or a virtualized environment running under IBM Z.

Documents do exist to explain the "how" of security on z/VM -- some of them are linked in the Publications section of this very webpage. Very few of them delve into the "why" of security, though. Absent a full-blown checklist (which, as DISA Secure Technical Implementation Guides (STIGs) and similar grow in popularity, is forthcoming), this page will delve into the mindset one should take when locking a z/VM system.

  1. Know your rules. There are a lot of rules for information systems, and ignorance of the law is not an excuse for failure to comply. (Ask anyone who's failed to notice the speed limit sign on the highway.) Just because your company's Security Team hasn't noticed you doesn't mean that you're off the hook to implement security in your environment. Get to know your security people. Buy them coffee. (Trust me, they need it.)
  2. Consider what sort of data will live here. The rules change based upon data classification--health care, banking and financial, PII, company trade secrets all may require extra controls or different levels of protection.
  3. For z/VM: change your defaults. The Ethical Hacker community calls it a "shrink-wrap" attack: exploiting default behavior that's less secure than what experts would suggest is a reasonable "initial secure state." Consider:
    • Default privilege classes... for administrators and for hosted workloads. (More on this in a moment.)
    • Default passwords (userid or minidisk) in the z/VM User Directory
    • TDISK clearing (enabled by default in z/VM 7.2; not so earlier)
    • Virtual machine access (if you're not using it, mark it NOLOG)
  4. Adopt a posture of Least Privilege. An administrator and a Linux guest should each have Just Enough Authority to do their jobs. No more; no less. Consider if Class G is "enough" or "too much" for a standard Linux guest; create a new privilege class if not. Consider also if your z/VM administrators are overpowered, or if you need to distinguish between "hypervisor admin" and "storage admin" in your environment. Those accessing the system will have different needs.
  5. Enable TLS for z/VM. Speaking of system access, securing data-in-flight doesn't cease to be a requirement over virtual or software-defined networks. Your hypervisor layer must be protected, whether it's TLS-Secured Negotiated Telnet or FTPS or some other channel. z/VM is FIPS-compliant and can meet the latest standards for secure connectivity.
  6. Only humans need passwords. A service virtual machine (that is to say, an automated process) can't be fired in the case of a data breach. Make use of LBYONLY or SURROGAT to restrict password-checking to humans.
  7. Deploy Multi-factor Authentication. On a related note, don't limit your systems to one authentication factor. The IBM Z Multi-factor Authentication V2.3 product supports z/VM. Enable this to allow for LOGONBY using digital certificates, or RSA SecurID, or ldap-bind, or some combination thereof.
  8. Treat your virtual networks with care. You should be using the z/VM Virtual Switch for Layer 2 routing between guests, and you should define LAN segments with a sensitivity toward where data flows. This includes HiperSockets--they're a neat technology to use, but they circumvent LPAR EAL 5+ workload isolation. Protect them. Guard them. Install firewalls in such a way that security decisions can be made.
  9. Encrypt sensitive data. You probably have it (see #1 and #2). Make use of guest technologies like dm-crypt to encrypt Linux filesystems, such that data is only in the clear in memory. Make use of z/VM Encrypted Paging, such that any data swapped out of active memory is enciphered. Take advantage of DS8880 encrypted storage, tape encryption... if you're not sure where it's going and who can see it? Encrypt it.
  10. Install an External Security Manager on z/VM. This means the RACF for z/VM Security Server feature or a comparable product. Your passwords are not encrypted without it. You do not have Discretionary or Mandatory Access Controls for your hypervisor without it. You are not doing sufficient security-relevant auditing without it.
  11. Train your people. The hardest part of security is the humans. It's easy to push it off as Someone Else's Problem... but that's not how information technology works. Humans are as interconnected as the servers they manage--and potentially susceptible to compromise. Educating those who access your z/VM environment lessens the risk that simple error might lead to problems later on.
  12. Gather Proof. If you're not auditing an event, did it really happen? How do you measure a z/VM system's relative compliance? Use a utility like the z/VM Compliance Utility to gather data from across your z/VM system, and leverage audit logs from your ESM to assure that no one's gone rogue. If pertinent, stream your RACF audit logs through zSecure to a Security Information and Event Manager (SIEM) platform, so you can receive a consolidated view of security in your enterprise.
  13. Set a timer, and then start over. Security is a moving target. z/VM will continue to provide the strongest possible controls to make your virtualized environment (be it a server farm, a containerized DevOps space, or a cloud) as airtight as possible. But security is never "finished" and must be re-evaluated periodically. Watch for news on new issues, vulnerabilities, and fixes. (Register for the IBM Z Security Portal for this sort of information.) Be ready to challenge your own assumptions about the security of your environment.

It's not everything, but it's a start. Checklists, guidance, and tricks and tips will be added to this page as they become available. In the meantime, take a look at your z/VM system--really take a look at it. Examine virtual machine stanzas and extra options. See if anything can be NOLOGged. See if human users need to be purged as part of identity management, or ACLs need to be scrubbed.

And if there's anything that the user community thinks would assist z/VM Development in securing workloads, the z/VM New Function Webpage is a great place to get involved.

For more information on any topic, please reach out to Brian Hugenbruch (z/VM Security Development Champion) at bwhugen@us.ibm.com.