Jun 21 ’10

Mainframe Security:  Operating System Protection

by Editor in z/Journal

Like all servers, a mainframe has many doors that can be “knocked on” to gain entry. Whether or not you can open the door and gain entry depends on the implementation of security in the chosen External Security Manager (ESM)—RACF, ACF2 or Top Secret—as well as the operating system configuration and a vast array of resource managers such as TSO, CICS, IMS, WebSphere, etc.

We often hear that the mainframe is secure and IBM has an integrity statement, so we’re fine! However, what does “system integrity” really mean? Well, according to IBM: “System integrity is defined as the inability of any program not authorized by a mechanism under the installation’s control to circumvent or disable store or fetch protection, access a resource protected by an ESM (note it actually states RACF in the official IBM document), or obtain control in an authorized state; that is, in supervisor state, with a protection key of less than eight (8), or Authorized Program Facility (APF) authorized.” In other words, it works, is secure, and will maintain integrity if configured correctly!

Anyone familiar with mainframe security will be aware of such things as APF, Linklist, LPA, PPT, Started Tasks, etc., often called “sensitive resources,” and over time, we’ve come to understand how important it is to secure these with our chosen ESM.

Who should have access to an APF authorized library? What level of access should they have? These are examples of the many questions we should know the answer to these days. How often do we review the access to these sensitive resources and realize we have an issue? I sometimes hear the question, “How has that happened again?” In the majority of cases, it happens because the process in place to manage these resources is flawed.

One thing that helps with managing these challenges is a robust change management procedure. This will vary widely within each organization, as it isn’t a “one size fits all” solution.

Another stumbling block to implementing our chosen change management solution is determining what level of access the systems programmer should have to manage system resources. In some organizations, the systems programmer is allowed to update these resources and in others he or she isn’t. However, when sensitive resources are updated, we must be logging access, so we can answer the question, “How has that happened again?”

How many organizations spend countless hours reviewing audit reports, looking at individual security violation messages? What about the access granted by the ESM? Is this access appropriate? If we get a security violation, is our chosen ESM in fact doing its job and preventing unauthorized access?

Today, we should be looking for trends in the violations and not at individual messages. We should also be spending more time and effort recertifying access to resources. For example, periodically reviewing the actual data set profiles that protect all APF data sets with the resource owner and confirming that the access granted is appropriate will ensure access is correctly authorized.

IBM and CA Technologies continue to invest in facilities to help us protect our corporate assets, sensitive resources, and operating systems. IBM recently announced support to allow us to digitally sign programs. Should we be using this facility and, if so, how?

We need to provide the technical teams, security teams, and auditors with the processes and procedures they need to effectively perform their jobs. There are tools that allow for real-time alerting to enable an enterprise to proactively monitor changes to the system—not only at the operating system level, but also changes in the ESM configuration right down to individual resources protecting the sensitive resources. These tools immediately alert technicians and management via email, SMS, SNMP, and various other means when a change that’s considered sensitive is made.

So, in summary, we need to: