In-Depth
The Mainframe Security Paradox
Mainframe operators know which controls to implement, but auditors -- who frequently come from the distributed side of the divide -- don’t.
You don’t typically think of the mainframe as an insecure -- or comparatively less secure -- platform. According to several security and compliance experts, that in itself is a problem.
They concede that Big Iron systems are typically more secure than are other platforms. There are a number of reasons for this: a tried-and-true Big Iron permissions model (namely: whatever isn’t expressly permitted is denied); the traditional isolation of mainframe systems (though this is becoming less of an issue and, for that reason, more of a risk); and the comparative unfamiliarity of mainframe concepts and operations.
Simply put, the relative esoteric nature of the mainframe makes it a smaller, more rarefied target, though this, too, is becoming less of an issue thanks to the efforts of IBM Corp., CA Inc., and others to promote Big Iron education and training.
The mainframe’s unfamiliarity can work against it, particularly in the area of compliance. Mainframe programmers and operators might know precisely which controls to identify, but compliance personnel don’t, and that’s the issue, experts argue.
“Generally speaking, if you talk with mainframe accounts, often time they’re not failing their internal audits or even their external audits, but they’re still at risk. The reason for that is … that the auditors frequently come from … a different generation. I’m generalizing, obviously, but their background tends to be from the distributed area,” comments David Hodgson, a senior vice-president in CA’s mainframe business unit, “and most of the auditing work that’s been done has been done in the distributed area.
"When [these auditors] turn their attention to the mainframe, they have a couple of suppositions. First, that it’s a very mature area, it’s a very reliable area; there aren’t a lot of changes there. Second, they don’t actually know the environment -- they don’t know the probing questions to ask. We’ve had some very frank conversions with some IT departments about how effective the audits they’re doing on the mainframe are.”
Hodgson cites this as one of the impetuses behind CA’s new Compliance Manager for z/OS offering, a GUI-based tool that enables mainframe and non-mainframe personnel to manage security and compliance events on System z. (The new Compliance Manager for z/OS is designed to work with CA’s existing green-screen tools -- such as ACF2 and Top Secret -- as well as IBM’s RACF.)
In this respect, Hodgson maintains, CA’s new offering automates what -- for the most part -- has been a largely manual process. “[Tools such as] RACF, ACF2, Top Secret -- they’re all very secure [tools]. [With them] the platform can be secured much better than [is the case with] many of the distributed systems. From the compliance point of view, however, you still have questions about how do you know we’re always doing this?
"The problem is that [even with these tools] there really isn’t the labor available to make sure that all of this is being done correctly,” Hodgson argues. “For example, Compliance Manager in real time would pick up on any changes … to the way the security subsystem is configured. It can log that, and if you want to alert people to that change, it can send an e-mail, open a service desk ticket -- it’s intelligent enough to be integrated with change management software. Out of the box, it integrates with [CA] Endevor, and you can also integrate it with other change management systems,” he continues.
The problem isn’t necessarily identifying infractions, Hodgson says; it’s more an issue of isolating the rules or permissions that enable an unauthorized user to perform an action.
“We can tell you the specific security rule or permission that had granted that person permission to that data set. What we’ve done there in real time -- and probably we’re describing five or ten minutes [worth of configuration] work now -- we’re enabling someone to detect the event and research it and then remediate it,” Hodgson says.
“This is when it becomes very labor intensive for either IT security people or for auditors on the site to gather the right information and look at the logs. Maybe they’re looking at SMS information or other logs … to know the extent of what they did, and then, of course, the last bit in terms of totally remediating the situation. Assuming that you can find out what they’ve done, then you have to find out how to reverse it. What we’ve done is automate and reduce what is a long process really to a very short period of time.”
Compliance Manager is still a work in progress. At this point, for example, it only offers out-of-the-box integration with CA’s own change-management or help-desk software. At this point, adopters can hand-code interoperability with third-party tools, although Hodgson says CA plans to focus on third-party interoperability in forthcoming revisions.
“We hope to ship exits [i.e., interoperability connectivity] for other products at the end of this year. At the moment, we have integration with our service desk product. Most others allow you to automatically open [a] help desk [ticket] … with an e-mail interface. If a product will do that, obviously, you can send an e-mail today,” he explains.