Q&A: Best Practices for z/OS Security
Mainframes are typically more secure than most other platforms, but that doesn't mean IT can ignore them.
Although mainframes have traditionally been thought to be immune from most security threats, that doesn't mean that IT can ignore them. We explore z/OS security guidelines, the threat landscape, and how IT should attack the problem using built-in or third-party tools with Phil Smith, a mainframe architect at Voltage Security.
Enterprise Systems: What is the biggest z/OS security threat?
Phil Smith: Complacency. Forty-five years of mainframe theology has led to a belief that "The mainframe is secure," including claims such as "No mainframe has ever been hacked" that can't be proved.
Mainframes are, on average, likely more secure than most other platforms. This can be attributed to three things:
- Historical lack of Internet connectivity
- Rigid change-control and security methodologies, the latter including a "least-privilege"/"need-to-know" default in most sites
- Hardware and software architectures that provide better isolation than x86
However, these are all changing. More mainframes are connected to the big, bad Internet. Use of open source software, although beneficial, can lead to relaxed security requirements due to such packages' origins on less secure platforms: there is sometimes no reasonable way to "lock down" such environments because the open source product simply will not function. Finally, although the core operating system and hardware continue to be hardened, innovations such as zBX bring less-secure hardware and operating systems into the trusted core mainframe environment, with attendant risk.
How has IT been trying to prevent such threats? Why hasn't IT been totally successful using this approach?
IT has largely approached the Internet threat to the mainframe through its traditional approach of isolation. Mainframes are usually well behind the corporate firewall, and often use non-routable IP addresses. It is also common not to enable DNS, thus reducing risks from outbound connections.
Some sites have involved themselves with open source projects specifically to add enterprise-level security to those projects, but this is not that common in this era of reduced resources (other than IBM, which has contributed greatly to Linux and associated projects).
zBX is too new to provide any real data, but many System z customers seem leery of its adoption: some because they do not have a valid use case yet, others because they distrust such proximity between the mainframe and the zBX x86/Power blades.
Why is it difficult to achieve full compliance with z/OS-specific guidelines?
History, tradition, and lack of knowledge.
Historically, security guidelines written specifically for z/OS have been rare. IBM has published Redbooks, and DISA has a set of STIGS (Security Technical Implementation Guides -- see http://iase.disa.mil/stigs/os/mainframe/z_os.html). However, since most z/OS shops have been running for decades, many have their own security approaches, hammered out over time and woven tightly into the fabric of everyday business, making change extremely difficult.
Most more general security guidelines are not written with the mainframe in mind, and thus may both include inappropriate directives such as "No root access" (while users on the z/OS UNIX System Services "side" could have root access, most z/OS installations still barely use UNIX System Services, and thus do not even understand the requirement). Security guidelines reflect a lack of understanding of the degree of interprocess isolation provided on System z (e.g., concerns about data in the Hardware Storage Area, which is managed by the Hardware Management Console and is inaccessible to applications under any circumstances).
This lack of knowledge cuts both ways: far too many z/OS system programmers have only passing familiarity with the distributed world, and thus often find security guidelines difficult to understand due simply to terminology differences (such as "storage" vs. "DASD" vs. "memory").
How big is the threat of a breach to z/OS data?
The difference between a mainframe breach and a Windows breach can be like the difference between hacking a user's bank card and a corporate account: it's less likely, but if it occurs, a much larger number of customers may be exposed. Not that there haven't been large distributed breaches, but the vast majority are relatively small. A mainframe breach would typically include an entire customer database.
As the boundaries between mainframe and distributed applications continue to blur, the likelihood of such a breach increases. This is not just because distributed environments are (perhaps) more porous, but because often the two worlds collide with poor understanding and communication. This can lead to security holes as, for example, required JDBC connectivity to a previously secure mainframe database provides access to data via a Web application which itself falls victim to a zero-day exploit. Because such a breach would originate far from the mainframe system programmer's purview, it is extremely difficult to foresee and thus avoid.
How should IT be attacking the problem?
IT should largely be continuing to do what it's been doing, with two changes: (1) embracing the wider world of other platforms, networking and the Internet, and (2) adding encryption to protect critical data.
Learning about other technologies positions staff to better understand and protect against threats. It has the added benefit of possibly improving communications between the traditionally siloed mainframe group and the distributed and networking groups, which can help them work better together.
Adding encryption implies different solutions for different media: protecting backup tapes, network transmissions, and production data will take varied approaches. For backup tapes, whole-data encryption makes sense (and can be performed by outboard hardware, thus avoiding overhead on the mainframe); for network transmissions, mostly use SSL (or VPNs, for persistent connections). The most difficult -- and, frequently, the most vulnerable -- is production data.
What are the existing approaches to production data encryption in z/OS, and what are their strengths and weaknesses?
There are two basic approaches: whole-data encryption (encrypting everything) and column- or field-specific encryption. Either of these can be implemented natively, using System z CPU to perform the encryption operations, or by sending the data through a server on the network, typically accessed using Web services (SOA).
Whole-data encryption for production databases is appealing at first look because it can be made transparent: the database can decrypt the data whenever it is accessed, thus avoiding any requirement to change applications. However, this approach fails for several reasons:
- Performance: Decrypting and re-encrypting data for every fetch/update is expensive.
- DASD usage: Encrypted data is often larger than the original and does not compress well; depending on how well the encryption is integrated, this may mean that DASD usage increases significantly.
- Security: most regulatory requirements (PCI DSS, et al.) mandate separation of duties. This means that unencrypted data is available only to staff with the appropriate need-to-know. Transparent encryption solutions obviously do not provide this, because doing so removes the transparency.
Column-specific encryption requires some application changes but helps with all three problems: since less data is encrypted, performance is better; even if DASD usage increases, it does so to a lesser degree; and the application can be authenticated, enabling separation of duties.
In terms of implementation, most z/OS installations prefer local processing over SOA approaches. The idea of requiring a second machine for production data use -- especially a second machine that lives "out on the network" and is thus likely not fully under control of the z/OS team -- is unpalatable.
Native solutions vary in effectiveness and usability, but typically include some form of API, callable from some or all z/OS languages. This approach means that System z MIPS are used for the encryption.
What facilities does the modern z/OS environment provide for encryption? Are third-party tools needed to supplement these facilities?
IBM mainframes offer two forms of hardware encryption assist: CP Assist for Cryptographic Functions (CPACF) and Crypto Express (CEX).
CPACF is available on all machines but must be enabled via a no-charge feature (IBM Feature Code 3863) because encryption technologies are considered "munitions" by the U.S. government, and their distribution to certain companies is prohibited. Customers in those countries will be unable to order that feature, but there is no other reason that it should not be enabled on all machines (and, in fact, most machines are installed with it enabled). CPACF is a combination of silicon and millicode (firmware); it provides single-instruction access to various cryptographic functions, such as AES, DES, and SHA-2.
Crypto Express2 and the newer Crypto Express3 are Hardware Security Modules (HSMs) -- add-on cards that provide off-board cryptographic assists. It is important to understand that these HSMs exist to provide enhanced security, not performance. Customers frequently think that adding a CEX will make encryption faster, but that's almost always incorrect. The exceptions are (1) a CEX may be configured to provide SSL handshake acceleration (so systems that are doing lots of SSL may benefit from this) and (2) when very large blocks of data are being encrypted, AES or DES may be faster using CEX operations, especially if the central processor is heavily loaded.
IBM provides the Integrated Cryptographic Services Facility (ICSF) with z/OS. This is a software service that provides an API for a wide variety of cryptographic functions. When CPACF or a CEX are available, ICSF will use them as appropriate (and, indeed, will reject requests that require a CEX if one is not available). Some functions, such as AES, can be performed entirely in software; using CPACF; or using CEX, depending on options and availability.
The combination of ICSF, CPACF, and CEX provides a powerful set of encryption tools. However, more work is required to assemble production encryption solutions. IBM offers some limited solutions, including whole-database encryption and whole-file encryption, but has mostly focused on encryption hardware (tape drives and DASD -- the former securing backups, the latter ensuring security of DASD shared among outsourced installations, as well as removing concerns about latent data when DASD is decommissioned). A variety of vendor products has stepped into the breach, providing encryption solutions of varying sophistication and usability. Where appropriate, vendor products should exploit ICSF, CPACF, and CEX.
One important area for any encryption solution is key management. Surveys reinforce the mantra, "Encryption is easy, key management is hard." Enterprise encryption solutions must include robust key management, or management complexity will overwhelm any benefit.
IBM continues to develop new CPACF and CEX features. For example, the zEnterprise includes advanced CPACF functionality over the z10, and Protected Key operation was added for systems with CPACF and CEX in 2010. We can expect these innovations to continue.
What has made encryption traditionally so challenging in mainframe environments?
Resistance to application change. This goes back to 45 years of rigid change-control methodologies, as well as 45 years (in some cases) of running the same applications: mainframe shops are resistant to application change.
While the stereotype of Windows teams slamming changes into production at 2PM on a Friday is not entirely realistic, it's also not entirely unfair: such things have happened (recall Google Docs and Blackberry outages in October 2011). Not that such mistakes are impossible with mainframe applications -- there's no magic here -- but the average mainframe shop is much more cautious about risk than the average distributed shop.
Combine this cautiousness with code written by people no longer with the company (and thus perhaps poorly understood), and the result is a desire to avoid code changes wherever possible.
Where do you see mainframe data security five years from now?
Encryption will be far more widespread, and enterprise auditing tools will be even more common than they are now. This evolution will have improved security in that not only will data be better protected, but the exercise of having added encryption and performed auditing will mean that installations will have a better understanding of their own application flow. Mainframes will be better integrated into the company's network and thus its Internet connectivity, and with this, hopefully, will come a better recognition that the System z fortress is not impregnable and thus must be defended.
Tell us about the encryption features Voltage incorporates in its products.
Voltage SecureData for z/OS provides a full suite of encryption functionality, most notably including format-preserving encryption (FPE). A new mode of AES, FPE encrypts data while preserving the original data length and character set. An encrypted Social Security number, for example, looks like a Social Security number; an encrypted credit card number has the same number of digits as the original (optionally including a newly calculated Luhn check digit). Names encrypt to the same pattern of uppercase and lowercase letters; numbers in addresses encrypt to numbers. "John Smith, 123 Main Street", thus might encrypt to "Bxdd Jeqonm, 938 Lwod Fyupoi".
This means that database schema need not change; indeed, most applications need not change at all, or even know that the data is encrypted -- they simply use the encrypted value as-is. For example, a credit card number can be encrypted at point-of-capture, pass through all other processing in its encrypted form -- even if used as a primary key -- and decrypted only by the application that will transmit it to the bank for settlement.
Voltage SecureData for z/OS exploits both CPACF and CEX as appropriate, and includes both am API and bulk data encryption tools (for initial encryption of existing data, as well as for data masking for test). Voltage SecureData is available on many platforms as well as z/OS, and because the character set is maintained, data encrypted with it can be translated between ASCII and EBCDIC and still be decrypted. This data-centric encryption provides end-to-end protection, and means that even if a breach occurs, the data will be useless to the attacker -- unlike encryption at the container level (full-database encryption) or pipe (SSL), which leave data exposed in "air gaps" -- exactly what attackers are looking for to exploit.
What is Voltage SecureData and what features does it offer for z/OS security?
The Voltage SecureData key server is an appliance -- virtual or dedicated -- on the network, serving keys to all Voltage SecureData clients and APIs. It provides stateless key management: keys are derived from an identity provided by the requestor, using standard key derivation functions plus a Base Derivation Key stored in the key server. This means that Voltage key servers need be backed up only when their configuration is changed rather than every time a key is generated, as with most key servers. This also means that key servers can be readily replicated for hot sparing, at disaster recovery sites, or geographically to reduce latency.
The newest member of the Voltage SecureData family is Voltage SecureData z/Protect, a z/OS-based encryption server that adds an encryption API that uses a single line of code to encrypt or decrypt data by specifying a named object that is defined in the server and encapsulates all the encryption details.
Voltage SecureData z/Protect reduces the need for a complete understanding of data flow; the atomic, one-line z/Protect API allows adding encryption and decryption calls at the specific points of data capture/presentation, without any context or control blocks to manage. Plus, with its ability to use the native z/OS security system and/or external LDAP security such as Active Directory, Voltage SecureData z/Protect fits naturally into existing operational controls.