By Brian Cummings, ESM Security Consultant
In the 1990s, it was deemed that the mainframe was going away; as a result, focus on the platform and its security suffered. Back then, if you put mainframe security implementations on a quality bell curve, you would have the good, the bad and the ugly. There were only a few excellent implementations of mainframe security. As regulatory requirements for SOX and privacy raised the bar, mainframe security suffered ever more. Today, we see the mainframe continuing to manage the core information assets of most large companies. So how are those companies addressing the concerns caused by the lapse in mainframe security development?
Recently, the industry has seen worst-case scenario implementations in which good security practice has been trampled by an emphasis on availability over confidentiality and integrity. For example, one major, global financial institution has taken mainframe ESM default security and flipped it over to a completely promiscuous configuration; everything is accessible except those resources specifically protected. The result: There was no assurance of compliance and privacy or even confidence that the resources thought to be protected actually retained any security control.
We hear installation professionals say, “We have always passed our audits” and “We have never suffered a mainframe security breach.” To which we reply that audits are changing, and we are seeing an increase in audit findings. Financial auditors consider these significant deficiencies a serious financial audit bell-ringer. Regarding a security breach, most installations don’t effectively monitor their mainframe security events and would not know they were breached unless, for some reason, the breach became visible.
Another objection we hear is that the mainframe cannot be hacked. Even IBM has changed its mainframe pitch from “the most secure platform” to “the most securable platform,” recognizing that implementations can override the inherent mainframe security capabilities. Even as recent as a few years ago, Philip “Soldier of Fortran” Young published in great detail how to find and hack mainframe computers through the Internet. His hack exploited FTP daemons in Unix System Services, which typically have SuperUser privileges. More disturbingly, Young characterized FTP daemon privileges as a common problem (read: a hacker opportunity) across all platforms. The step-by-step instructions and illustrations are very good and can easily be performed by other hackers, real or would-be.
If you suffer from any of the following, you are likely vulnerable and at risk to a mainframe security breach, external or internal:
- Security bypass privileges are applied to Started Procedures.
- Security bypass privileges are granted to individual “People” user IDs.
- Batch jobs all execute under a single user ID or inherit the Scheduler system ID.
- SVCs have not been reviewed and their bonafides defined; and the code of installation SVCs and ESM exits have not been independently reviewed for vulnerabilities (e.g., embedded passwords, ESM event logging suppression, etc.).
- System programmers set up and configure security for technical environments such as VM and Unix System Services.
- Privileged accounts are not actively monitored for anomalous activity.
- Access to all resources is managed based on the principle of “Least Privilege, Need to Know,” regardless of their classification.
- Security administration productivity is measured by throughput, not by controls enforced.
- A security violation event is viewed as a problem to be corrected, not a win to be applauded.
- There is no documented standard to govern mainframe security implementation and administration, and security has devolved to access being granted if managers approve the request.
- You have implemented role-based access control but continue to manage access requests on a user-by-user basis, greatly diminishing the benefit of role-based access management.
- Mainframe security events are captured and archived for potential forensic use but are inspected infrequently, if at all, for anomalous activities.
If any of the above scenarios can be applied to your mainframe security, then you may want to reconsider your security strategy. Start by focusing on those above conditions and work towards managing your mainframe security, not just administering it.
Brian Cummings is one of the last active consultants with hands-on experience with all three major ESM products: CA-ACF2, CA-Top Secret and RACF. He served as the SHARE security and audit project manager from 2010 to 2014 and has been a frequent conference presenter. He has been in a consulting role since 1988 and continues to assess and guide mainframe security implementations, most recently including a mainframe security architecture project for a point-of-sale authorization implementation. Cummings is a vocal advocate for classification-based access management as an alternative to across the board “least privilege” management, and he promotes privileged account control along with “knowing and monitoring your environment”" as a key means to timely detection and prevention of unauthorized intrusions.