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:
- Decide (how each security option should be set)
- Execute (implement these decisions)
- Review (ensure each decision is carried out effectively).
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:
- Is someone clearly responsible for the Decide, Execute, and Review functions for each of these areas: granting and revoking a userid, resetting a password, securing each path into the system, securing each TCP/IP port and IP address, granting access to data sets (on tape, disk, and the print queue, as well as on other platforms), protecting residual data on tape and disk, evaluating whether and how to use each resource class in RACF and Top Secret/type in ACF2, protecting USS files, and securing each TCP/IP daemon? Often, the security administrator shouldn’t be the one to decide.
- As a test of the previous bullet, is there clear documentation available of the decisions whether and how to use these resource classes: JESSPOOL, OPERCMDS, VTAMAPPL, SERVAUTH? Is there someone clearly responsible for these decisions?
- Does your security administrator believe after reading this column he has all the information and authority he needs?
- Is Kerberos installed on the Windows networks used to log onto the mainframe (to prevent sniffer programs from learning everyone’s mainframe userid and password)?
- Does each application have a formal risk assessment reviewed and updated at least every other year by the business owner and by legal and regulatory compliance?
- Does the Decide function result in a written approval that an auditor could use as a standard to evaluate the security software rules? (This is the Review function. If auditors don’t have a written approval or other standard to compare the rules to, they’re likely to use their checklists or personal opinion, resulting in subjective audit findings.)