The problem with getting security folk skilled up on mainframe tech is the lack of availability (i.e. lack of access to a sandbox area where a newbie to the field can explore, learn and test things out).

I certainly agree with your assessment of the problem. One banking client that I did work for had a big DB2 installation on their mainframe. Until this particular project, all access to the DB2 instance was from within the mainframe itself, using supposedly trusted code, and supposedly trusted users (i.e. only folks with TopSecret (=~ RACF/ACF2) logins). The problem was that now they wanted to allow an external app to use the mainframe’s DB2 as a backend, via a JDBC connection.

When I checked the table permissions, I found that there were approximately 20000+ tables with PUBLIC SELECT access defined on them, and several thousand with PUBLIC INSERT, UPDATE and DELETE access allowed. And they had no idea why, or which applications were using those tables, as which user. Which meant they could not fix the permissions. Even adding auditing to the tables to identify users would have impacted performance too much, and was dismissed as an option. So it was left as is, but now with external access allowed, so that people could start digging around. Nice, eh?

Another audit I did at a government organisation was equally inspiring. All users are given a menu which comes up after they login, and they are only able to run programs that appear on the menu. Supposedly. Oh, yes, except for the “escape code” that you can type in which would give unrestricted command line access. Which the sysadmin knew about, but didn’t think any of their users would know anything about. Nobody thinks about organised crime deliberately planting someone in a low paying job in order to get access to terminals and access credentials.

The trend at the moment seems to be inbetween - use mainframes to massively parallel VM’s running ‘modern’ operating systems.

But yes, there is a belief that the mainframe is immune to almost anything….