Iron Giant: Q&A with the Father of Mainframe Security

The whole idea that data needs to be protected, and that users need to convince a computer that they’re worthy of seeing the data on that computer—in other words, the entire information security industry—exists because of some punk undergraduates at the University of Illinois.

It was the early 1970s and, as Barry Schrager remembers it, the undergrads were accessing the mainframe in order to trash graduate students’ research data. But why? “Just for fun,” says Schrager, who at the time was assistant director at Illinois’ computer center. Schrager realized that the mainframe, the data on it, needed protection from a perpetual threat that one should never underestimate: typical undergraduate behavior.

By 1972, IBM had learned of Schrager’s security efforts and asked him to create a security project for its flagship mainframes. The foundation of this work with IBM, called the Share project, was based on the concept of system integrity, meaning a normal user must be incapable of bypassing the formal interfaces of an operating system to gain access. It seems obvious now, but back then, with a bunch of researchers sharing a few big computers in a collegial atmosphere, it was a fresh, even daring idea. To look at data, you had to have permission. Later in the ’70s, Schrager would develop ACF2, a mainframe authentication mechanism that succeeded IBM’s own software, RACF. ACF2 and its descendants are still used today.

Fast-forward three-plus decades and Schrager, like everyone, sees an entirely different computing landscape. Yet when he thinks about how to secure it, he keeps coming back to the original tenets that came out of 1972. He keeps returning to centralized authentication, to simplification, to shared services, to default protection. He keeps coming back to mainframes. CSO Executive Editor Scott Berinato spoke with Schrager, who now works with software and services provider Vanguard Integrity Professionals, still preaching the mainframe-centric security gospel. Schrager spoke about his faith in the mainframe security model, the challenges he sees in securing today’s enterprise and how information security problems that we think are new are nothing of the sort.

CSO: What was the primary concept behind the Share project that you still find so appealing?

Schrager: The concept here was that the application and delivery system shouldn’t do their own security. They should be calling a central service. The idea was to specifically take security out of the application. Then, if you have two different ways you’re updating payroll, the security will be consistent. If security is not centralized, each payroll is doing its own, you have inconsistency. The idea was to share security. And, beyond the technical, the Share project was the ability for people to get together and work together. Still, it took five or 10 years for applications or vendors to follow suit and externalize security.

CSO: Five or 10 years?

Schrager: Yes. In the early ’70s, the computing industry was a bunch of odd ducks. It was anyone with a computer center that wasn’t closed. It was universities, service bureaus and the Department of Defense. I didn’t get input from private industry or from financial institutions at all, even though they used mainframes. Then in ’77, the Foreign Corrupt Practices Act dictated that companies had to prove they were securing international transactions. Suddenly, everyone got on board.

CSO: Radically insecure private sector, followed by legislation that forces companies to adopt more secure practices. That sounds awfully familiar.

Schrager: Yes. What you’re seeing now with Sarbox, HIPAA and other things. I’ve seen this before.

CSO: We tend to characterize the current security landscape as new and uncharted territory. You’re saying it’s not?

Schrager: Not at all. Take identification. How many do you have? Too many, right? One of the biggest concerns as mainframes took off was identities. All these mainframe guys were complaining they had too many and it was hard to manage them all. That was a huge problem on the mainframes! We talked authorization, about logical security and journaling capabilities. Now they call it authentication, authorization and accounting, AAA, but it’s the same concepts that we were talking about in 1974.

CSO: Of the security concepts from the mainframe that you believe can help improve enterprise security today—including making data protection default on, simplifying enterprise architecture, to centralization of security—which is most important?

Schrager: The most important lesson we should have is to have a conceptually centralized security approach. Nowadays we have SAP, Oracle and everyone else having their own security. What we really need to create is a framework for a single security approach. We also really need a centralized place that recognizes an attack in progress on a computer. If you have to look at billions of log entries stored all over the place to find unusual events in your enterprise, it’s too late.

CSO: It sounds like you’re saying we need more architects and fewer engineers.

Schrager: Yes. We need a lot more architects. And a lot more cooperation between the people designing products. Cooperation with other people designing products around their products. How do I provide better enterprisewide security? I get Oracle and SAP to provide a common interface that allows me to manage and use one security product regardless of the applications I’m using.

CSO: And to do this you say we should rely on mainframes for security.

Schrager: It’s a great option. For some reason people keep thinking that the mainframe is dying. It’s actually enjoying growth. But there are ways to adapt the ideas to nonmainframe environments.

CSO: Which era appreciates security more, the current one or the 1970s mainframe era?

Schrager: Right now, it’s the same as the early 1980s. People found out you could do these things with security we developed in the 1970s and they jumped on the bandwagon. People are jumping on the bandwagon again, but it’s so complex now. And the thing to do is to try and simplify the enterprise.

CSO: But often people will say that to achieve simplicity you must give up flexibility or functionality.

Schrager: If you look at the mainframe, from an application point of view, it’s pretty simple but highly functional. Yes, there’s complexity behind it. But the point is just because there’s a lot going on underneath doesn’t mean it has to be complex for the administrator.

CSO: In other words, the current generation hasn’t done a good job keeping the complexity under the hood?

Schrager: Right. Take SOA, for example. You have one delivery system passing data through 12 layers of transformation.

CSO: But enterprise computing is so complex now, it seems a little quixotic to think you can simplify.

Schrager: That’s why the role-based stuff is coming. I put a person in a role, then create groups of people in similar roles, and I reduce complexity. I categorize the data. Once you start talking about that, you have a better chance. The only way you can deal with it is at the architectural level.

CSO: So the barrier to your vision of simplicity is the up-front cost of transforming the enterprise. Of creating roles and groups and categorizing data and so forth.

Schrager: Yes. You read the discussion lists, and that’s a huge problem when you’re trying to move over to the simpler approach. One company, it took them a year. It’s hard.

CSO: Hard, but you still believe inevitable.

Schrager: It is. Otherwise you are exposed to the atrophy effect. You won’t be able to keep up. Systems fail over time, and the more places you have the data, the more rules you have in more places, the worse the problem. Eventually it’s not even that you can’t keep up, it’s that you can’t grasp what’s going on in the enterprise from a security perspective. Total atrophy.