A common perception of the mainframe is that it’s unhackable. RACF, ACF2, or Top Secret will keep the bad guys out, Authorized Program Facility (APF) authorization is gained only by trustworthy programs, and viruses are strictly a Windows issue. So, is the mainframe safe?
Stan H. King, president of Information Technology Co., LLC, for his December 2009/January 2010 z/Journal article “Mainframe Hacking: Fact or Fiction?” (www.mainframezone.com/it-management/mainframe-hacking-fact-or-fiction), scoured the news archives for stories of data loss and theft, and found no mention of a mainframe in more than 850 reports. King is confident that “Programmers who properly use tools such as RACF can enshroud applications in effective security and stop an unauthorized application from accessing prohibited resources.”
Later, in the same article, however, we read a telling insight from noted RACF expert Bob Hansel of RSH Consulting: “I’m not personally aware of any instance where a mainframe has been hacked. However, I think the scarcity of such incidents is due more to a lack of technical expertise by would-be perpetrators than to the sound implementation of controls.”
King’s article was posted to business social networking site LinkedIn by ACF2 co-author and Vanguard chief architect Barry Schrager in June, and quickly became one of the busiest discussions this year in the MainframeZone group (http://linkd.in/b18fei). Two main themes emerged from that discussion, which pulled in some big names in mainframe security and was a great example of pre-Internet experience meeting Web 2.0 services—with positive results for all.
Software Integrity Issues
The discussion dealt with integrity issues created by software vendors shipping code that doesn’t comply with APF standards. Schrager pointed out that a poorly coded, APF-authorized Independent Software Vendor (ISV) program might allow itself to be tricked into giving an unauthorized caller control in an authorized state. The program would have to be written in violation of the guidelines in the MVS Authorized Assembler Services Guide, but you shouldn’t doubt that such programs exist and are widely installed today.
Do you make your vendors certify their code is compliant? Even better, do they supply the source code so you can vet it yourself for integrity exposures? For more on this topic, see Ray Overby’s article “Is Your z/OS System Secure?” in the August/September 2010 issue of z/Journal. (www.mainframezone.com/it-management/is-your-z-os-system-secure).
A second theme emerged regarding configuration weaknesses. Rather than exploiting poor code, can an attacker find a way through or around your security defenses due to poor configuration, weak access controls, or lax monitoring? From collective experience, this would certainly seem to be possible. Here’s just one example, for discussion purposes, of the many serious configuration weaknesses commonly found in RACF-protected production systems: The allocation at logon time by the security administrator’s Time Sharing Option (TSO) account of other departments’ CLIST or REXX libraries is common, often to make available shared utilities such as storage management routines. With this configuration, anyone with update authority to these libraries could plant RACF commands to be executed by (and with the authority of) a RACF SPECIAL user. Such an attack would almost certainly go undetected, as it would have the appearance of normal administration activity.
Now a reasonable objection to this situation being described as a weakness is that it requires a reasonably high privilege assignment in the first place (namely UPDATE access to specific libraries). That’s true, but the nature of the “privileged insider” is changing. In many organizations, this might even include offshore third parties. Did you know you had granted these users indirect RACF SPECIAL privileges?