Aug 19 ’10

Mainframe Security: Organizational Questions Affecting Mainframe Security

by Editor in z/Journal

Here, we address two organizational questions affecting mainframe security: “Whose job is it?” and “Where are decisions made?”

Auditors occasionally identify some issue that’s important for effective security but hasn’t been addressed because no one has been assigned responsibility for it. This can include issues such as how mainframe TCP/IP is secured, which disk data sets are to be encrypted, how we protect sensitive residual data, how system data sets are protected, which powerful programs are secured, whether opening VTAM Application Control Blocks (and the risk of applid spoofing) is to be controlled, how SNA network-to-network connections are secured, etc. (Auditors could help more by identifying the organizational issue behind the security issue.)

If it isn’t someone’s job, it won’t get done. Auditors will occasionally criticize the security administrator for various security settings when the administrator doesn’t have the authority, much less the technical knowledge, to make the decision. Managers can address this by ensuring that standards and policy identify who is responsible for these three functions:  

In the February/March “Mainframe Security” column titled “Laying the Security Groundwork,” I examined six categories of questions: access to the system, access to data sets and resources, access to the network (both TCP/IP and SNA), operating system protection, organizational issues, and dealing with auditors. Note where each function falls in the organization. The Execute function often falls to the security administrator.

Consider his approach to protecting, for example, the payroll application: Everyone knows the Decide function should be performed by someone, such as the head of the payroll department, who understands the associated business risks. (The degree to which this is performed by someone who best understands the related risks is an important component of the quality of information security.)

The security administrator may consider whether to use encryption to protect the data (on tape, disk, or in the network), but may not have the means to make this happen. He may also be considering whether to use features (such as Erase-On-Scratch in RACF or AUTO-ERASE in ACF2 or Top Secret) to protect sensitive payroll data. But this is only possible if he knows which, if any, payroll data sets are considered sensitive, and that may depend on which laws and regulations apply. Who knows the laws and regulations? The legal and regulatory compliance departments elsewhere in the organization.

Managers can improve information security by ensuring each application has a formal risk assessment, specifying which data sets are considered sensitive or confidential, which laws and regulations apply, and what security measures the administrator should be taking to appropriately protect the data sets. (This would be a good place to document records retention requirements, too, since legal and regulatory compliance have the knowledge to specify these.)

So, to ensure your organization provides effective support for information security, ask yourself how true each of the following is, and make improvements as you see fit: