LongEx Mainframe Quarterly - May 2018
As a young systems programmer, I was always in awe of the mainframe and its security. "The most secure system on the planet." I've used that phrase many times when talking to people of the mainframe, and why it's still relevant today. In those days, I believed that statement. If you had z/OS, then your system was more secure than anything else in the machine room. But that's not necessarily true. Not Following RulesAs a consultant, I get to see many different z/OS systems for different clients. Most of my work deals with cost (CPU) savings, performance tuning, and fixing problems. As part of that, I often come across security issues: from small things that should be tightened up to bigger problems. Doesn't sound like the most secure system on the planet does it? And I'm not alone. In July last year, ZDNet released an article explaining how a security auditor, Ayoub Elaassal, quickly achieved full privileged access on a z/OS system. In this case, Ayoub found an APF authorized dataset he could write to: he could create an APF authorized program. And as we know, this is the line with z/OS: if you can create an APF authorized program, you can do anything. Security auditors spend a lot of time looking at access to APF authorized libraries, and other ways a user can create a privileged program. Systems programmers reading this will probably be listing these in their head, and there are a lot. But this is far from the only problem. In 2015, John Hilman from Vanguard Professional Services gave a presentation listing the ten most common z/OS vulnerabilities found by Vanguard. In 73% of cases they found user IDs with no password interval. This isn't great, but as long as these weren't high powered IDs, most managers wouldn't lose much sleep. However, John went on to say that 40% of sites had a RACF database that was not sufficiently protected. If you can read the RACF database (or backups) directly, then there's real scope for evil. What's more, 39% allowed excessive access to APF authorized datasets. Some valid reasons for insomnia. So, we can summarize these issues as sites not following the rules. The problem is that there are a lot of rules; constantly changing with new features, products and environments. There are some resources to help, including the ISACA Security/Audit Assurance Program, and the US Defense Information Systems Agency (DISA) Security Technical Implementation Guidelines (STIGs). But these can't, and don't, list all the security rules for every possible z/OS configuration. Even if you follow them to the letter, there will be other security holes. This is where you need systems expertise to track them down. Software IssuesIn our partner article, we look at the Common Criteria certification, and how it is used to validate z/OS security. The problem with such tests is that they look at a specific configuration. So, the certification for z/OS didn't cover CICS, IMS or DB2. It didn't include ISV products and didn't take into account user written routines or exits. Such certifications are no guarantee that your configuration is up to scratch: always the chance of a bug in any software you have. The good news is that all software vendors fix security problems or bugs as soon as they're reported. IBM also offers an RSS feed and other options to notify subscribers of any new security issues. The reality is that such issues are regularly found, and fortunately fixed. But these fixes need to be installed. Many sites still run unsupported software, which won't get any new security fixes. For example, the Arcati 2018 mainframe survey found 8% of sites still using the unsupported z/OS 1.13. Even if the software is supported, many sites don't have enough staff to frequently install maintenance. Few will do this more than once a year, so fixes have to wait. Sometimes these fixes identify a workaround that can be used. But again, you need staff to monitor alerts, and quickly implement workarounds through test environments to production. When reviewing security, consultants hone in on locally-written exits, programs or routines that can potentially run as privileged. These are often written in assembler using systems APIs, and I must admit I love doing this. But many sites I see don't have staff with the skills to check these routines – assuming they still have the source. ConclusionThe fact is that z/OS can be the most secure system you have in your machine room. But it isn't necessarily so. As far back as 2010, Gartner released a report saying that z/OS security was at risk, and a major reason was a lack of skilled professionals. In my experience, this is very much the case today. But an equal issue is that those with the skills rarely have sufficient time, or management support, to use them to make their mainframe watertight. |
