The slides from February's meeting of GSE are now online here. If you've ever implemented Role-Based Access Control (RBAC) on a mainframe, then you might find the model user discussion interesting. Comments welcome below.
Matching: rbac X
Meeting old friends and new, IBMers and customers at last week's GSE UK Enterprise Security Working Group (ESWG) has inspired me to start blogging again. Let's see how long this lasts ;)
The meeting was well attended, especially considering we were outside the M25 (London's outer ring road)! Our hosts, RSM Partners, looked after us very well and the day was well-paced, packed with informative sessions and full of lively debate. I was "dragged up" to continue the JOBROLE debate during the Hints and Tips session - more on that later - but the highlights were Mark Wilson's "z/OS Pen Testing Live" where we saw Mark "break in" to a z/OS machine before our very eyes (well, it was actually his own, so no crime was committed), and I was impressed by the presentation from Dave Constable of Barclays Bank's Global z/OS Security Engineering team on the IBM System z Security Portal and CVSS.
While we await the minutes and presentations to be uploaded to the website, why not check out said IBM Portal, and read about the "Common Vulnerability Scoring System" (CVSS) and how it can help you manage your z/OS maintenance schedule. Maybe this is what you need to justify to the budget holder that maintenance spend you know is necessary? Maybe CVSS will help us mainframers to discuss security matters with our distributed platform peers in the same language?
Now back to JOBROLE. A quick straw poll of the attendees revealed that a majority had already implemented Role Based Access Control (RBAC), were planning to, or had a desire to do so. Encouragingly, most could see the value in our proposal for either TEMPLATE user or the new JOBROLE construct. Read the background here, and have your say below. We will probably draft a proposal for GSE UK to present to IBM this year.
As promised, here is the discussion about RACF MODEL users that has been going on at UK GSE Security meetings this year. The more observant of you will have noticed that the title of this post is somewhat more dramatic, however. This is because the discussion moved on from one about MODEL or TEMPLATE users to the discussion of a new entity, the RACF ROLE object.
FIrst, let me recap. In February, IBMer and z Security expert Lennie Dymoke-Bradshaw proposed a new keyword on the RACF User profile, which he called MODEL. This keyword or attribute would mark the profile as a MODEL user, used only as a model from which to copy other users. Marking as MODEL would make the user ineligible for logon, thus an improvement on current techniques (which include using REVOKE, RESTRICTED and PROTECTED for purposes they were not intended).
We discussed this back then and came to no consensus. However, I liked the idea and posted it up on LinkedIn here, where there was much useful discussion of using model or template users, and managing RBAC in RACF. When GSE reconvened in June there was not only greater support but the discussion moved on rapidly. What if we took it one step further? What if we created a whole new RACF class, like USER, to define a role, but allow USERs to be connected to it thus inheriting their RACF permissions, group connections, attributes and class authorities? Like connecting to a group but more powerful? Then we would no longer have to change hundreds of users when a role changes (e.g. a new team adopts User Admin responsibilities and needs CLAUTH(USER)) but you would change one ROLE definition, from which hundreds of IDs inherit their rights.
I think I'll leave Lennie to discuss this now, in the attached slide deck. Lennie and I will continue to drive this in the UK but we would be interested in your feedback. Comments welcome below. Thanks