In-Depth
IT Security: Lessons of a Thirty-Year Career
IT security has changed in the last 30 years; we look back and explore what IT must do now to get a better grip on the environment.
As any security professional will tell you, the landscape has decidedly changed: from the distributed computing concerns to the nature of hackers, security administrators have a much more difficult job these days. We recently spoke with Barry Schrager, chief security architect at Las Vegas -based Vanguard Integrity Professionals, about the changes he’s seen in his more than 30-year career working with mainframe security.
"Thirty years ago we had only mainframes," Schrager notes. "Like today, the applications grew up independently—batch, TSO, IMS, CICS—all were independent entities and if they had security, they had their own user IDs and passwords. There was no coordinated approach which is sort of like today. Back then we had the idea of ‘one person, one ID’ and the need to control that person’s identity. We needed to journal exceptions. Today we have the same situation, with the need for authentication, authorization, and journaling.
"There should be a centralized bank of user definitions and a centralized bank of resource definitions, and another of which include information on which users have access to which resources." Therein lies a problem, Schrager says. "Suppose originally you were using CICS to do transactions by service representatives. Now if you reconfigure the application to use SOA and take information from the mainframe to the Web, your Web server is now doing the authorization and is now generating the CICS transactions on behalf of the service representatives. However, CICS is saying, ‘Hey, server, you’re authorized to do this and I’m assuming that you have verified that the user has validated this.’ The transaction could also be part of a bigger, complex action. There is no validation of the real user and no centralized journaling." That’s dangerous, he observes.
"The trouble is that such applications have their own authorization system, typically based on groups or roles. If they want a transaction only to be authorized by senior representatives, they have to change that authorization in two, three, or more places. That’s a big change from 30 years ago."
That’s just one of the problems that arises when authorization is decentralized. We wanted to know what IT is doing to combat the problem. "In most cases the industry has focused on authorization for a single application, but we should be looking at the bigger picture. These silos really don’t allow an outside party to do an authorization. We need a common, conceptual place where it can be done. That’s why IBM introduced a System Authorization Facility for the mainframe which is the common place where it’s done; the caller (IMS or CICS) doesn’t know what goes on, they just get back a ‘yes’ or a ‘no.’ That approach needs to be applied to the distributed enterprise."
At the very least, Schrager thinks that application vendors should allow for a security plug-in to make their authentication and authorization decisions available outside the application. "This approach allowed the zSeries Security Server (RACF), ACF2, and Top Secret security servers to compete in the market and all three products became much better because of it, and the IT industry greatly benefited from the competition."
In fact, that universal approach is critical to third-party developers of front ends, such as Vanguard’s own ez/Signon product, a cross-platform universal password and intrusion detection solution that treats the entire enterprise as a single secure domain. The software redirects authentication to RACF or to a Windows system with Active Directory, collects user information (for administrators), so end users can use the same password to safely sign onto multiple systems, including Windows, Novell, Sun Solaris, HP-UX, Red Hat Linux, and AIX.
Schrager uses the word "conceptually" often and deliberately. RACF on the mainframe, he points out, has RRSF which can mirror portions of RACF databases in different physical locations, but the RACF databases are administered as though they’re one. That’s the high-level approach he’s talking about.
If it’s so important, why hasn’t such a centralized approach caught on? Schrager maintains it’s because there is no common thrust to push the vendors into doing this. "Back 30 years ago, IBM and other vendors bought into a common security approach; that hasn’t happened in the enterprise today."
That’s not all that’s needed, however. Systems need to know an attack is in progress, which is much harder, and maybe even impossible, when security mechanisms are distributed.
Currently Vanguard’s ez product line is dependent on RACF and the mainframe, but they are working on pushing this to LDAP on Windows servers, with the potential to expand to other platforms.
Security Administration on the Move
Years ago, because environments and systems were so much smaller, Schrager points out, "administrators could look at logs and knew who the user was by looking at the user ID, knew what information the file contained by looking at the data set name, and he or she just ‘knew’ the business purpose of that access." That’s a far cry from today’s environment, in which a security administrator has to deal with hundreds of thousands of users, supervises a dozen or more subordinates, and has systems with literally millions of datasets.
"The admin doesn’t know the users personally any more, has far too many files to track, and doesn’t have the same grasp on the environment as his or her counterpart three decades ago." Schrager says that doesn’t mean the administrator is any less smart today—only that the environment has so radically changed that it’s impossible for that person to know all the details.
The problem is multiplied: you have large, complex environments—imagine configuring a server, a mainframe, and an application with so many users. The complexity can easily make the environment seem like it’s growing out of hand, and it’s tough to keep up.
Schrager says IT is looking for better, not more, security software. "If you have a payroll application to configure, you now have to worry about what role to use on one system and know if there’s a different role to be authorized for a different platform. Without centralization, this can be extremely difficult."
He admits that security administrators want a single interface to work with multiple interfaces, but suggests we imagine how, with security plug-ins, multiple applications, systems and devices could use a centralized facility to figure out what is permitted. "Administrators could truly work with one system, as if it were a single secure domain, and not just a front-end to multiple authorization systems."
Vendors also need to pay closer attention to the user interface of their products, making products simpler for clerks, not highly-skilled administrators, to manage. "It used to be that administrators came out of application or operations, but today that knowledge isn’t as pervasive, and you have to have a simplified, user-friendly, mistake-proof interface." Furthermore, security administration may just be one of several duties that an IT professional has to juggle in some shops—all the more reason for simplification.
People Still Do Dumb Things
People are still a problem. That hasn’t changed in 30 years—security administrators constantly must guard against good people doing bad things. In fact, 30 years ago it was harder for people to do dumb things, Schrager recalls. "You couldn’t take 40,000 records to a USB drive and drop it, or download the records to a laptop that’s stolen." It’s the sophistication of the computer environment that lets people do more dumb things.
"Hackers are also more sophisticated. Students used to break into systems but show us they’d done it without actually causing any harm to the system. They did it for fun; they didn’t do it harm people, only to prove that they could do it. Today people are doing it for their own personal gain, or as part of a crime syndicate. Nowit’s about stealing Social Security numbers and bank account information for profit." There’s also the threat that terrorists can destroy records in databases, including those of a government agency.
In 1977, the Foreign Corrupt Practices Act caused businesses to begin the process of putting security controls into place, but that’s very different from the compliance regulations that now hang over the heads of security administrators. In fact, compliance has gotten more invasive. "Before, you only had to record when someone made changes to something like medical or credit data, but today you also have to track when someone even accesses this type of information."
To combat that, Schrager returns to his call for centralization. "In a mainframe-only world, centralized security was accepted as the correct approach. What I’ve learned over the years is that, regardless of whether you are running a mainframe-only or distributed heterogeneous environment, a centralized approach, at least at a conceptual level, is the only way to go to provide true enterprise-wide security."