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.
with Tags: racf 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
Last week I attended the summer meeting of the Guide Share Europe UK Region's Enterprise Security Working Group (hereafter referred to as GSEUK and ESWG!).
It was a lively meeting, for which I must admit I was largely responsible. I can get quite excited when talking about Information Security and my favourite platform, System z. :)
As well as some excellent presentations, which you can find attached to the minutes page of the GSEUK ESWG website here, two lively debates were enjoyed, one about RACF MODEL users (which developed into a discussion about implementing Role-Based Access Control or RBAC in RACF) and another about Password Entropy. If you've never heard the term, then I can recommend this primer, and suggest you have a think about your current RACF password rules.
The RACF MODEL discussion was very exciting, and deserves a blog post of its own, which will appear here in a few days. Until then, you can engage in the debate going on over at the Mainframe Security Gurus LinkedIn group here.
Finally, GSE UK has its own LinkedIn group, and it is here. We are likely to see more use of this group to provide a means of extending the excellent debate enjoyed at the meetings, into the online world such that it continues after we've gone back to work.
RACF Model users and RBAC post soon.
The big break in my blogging habit was because - as those who know me IRL (in real life) will understand - I've changed jobs and there was a heck of a lot to do when I arrived in my new post! The good news is that I am working almost exclusively on RACF and zSecure and will be able to share experiences with zSecure 1.12 and beyond, including zSecure Visual and Access Monitor, two features I've not previously played with.
Meantime, I'll be catching up by blogging some bits and pieces relating to IBM Security zSecure and RACF in the coming days.
Firstly, here is the zSecure Newsletter - Issue 1, 2011. Out in April, this includes the following topics:
To get on the mailing list for this Newsletter, please send an e-mail to
I've uploaded my white paper on "Achieving PCI-DSS with zSecure" here for ease of reference. If you're considering a mainframe PCI compliance project then you may find this helpful.
For a more detailed exploration of PCI DSS and the mainframe you can read this document from independent consultants Atsec.
For a general discussion of mainframe security in 2011 and the security journey don't forget my z/Journal article here.
Last month's GSE security conference at IBM Warwick was excellent. After listening to several enlightening talks I gave a talk on the zSecurity conference last year in Montpellier, which you can see here.
Here are the highlights of the Hints and Tips session:
TEMPDSN – Make it possible for the RACF TEMPDSN class to be simply and safely enabled in a sysplex without needing a sysplex-wide IPL, nor suffering any availability issues. (Lennie)The group agreed that the TEMPDSN enhancement would be of benefit and fully supported this through signing a recommendation form.Model user ID – Provide a facility to create and manipulate USER profiles which are marked as MODELs and which cannot be used for any authentication, but are used instead as security role definitions. (Lennie)We agreed this requires more debate, which will be continued at the next ESWG meeting.Default Password could be set differently e.g. randomly when issuing the ADDUSER command without specifying the PASSWORD operand. (Jamie).Again it provoked much discussion and requires more debate at the next ESWG meeting.
Here it is, my z/Journal article on the web.
I will be manning the Pirean stand next week at the GSE UK Conference 2010, where I will be demonstrating Pirean's Extended System z Adapter for ITIM (PEZA). Come and see how it helps achieve mainframe compliance. More importantly, come and win an iPhone at our stand! See you there.
In Montpellier last month there was much talk of Security enhancements in z/OS 1.12, on which I had intended to blog earlier. Now, thanks to the excellent zSecure newsletter (subscriptions available from the z Security team at IBM, message me for contact details) I have been prompted to write this. Key enhancements are:-
• A discrete general resource profile with generic characters (*,%,&) in its name, defined in a class not enabled for generics (GENCMD or GENERIC), is often called a "ghost" profile. Such profiles are not referenced by RACF for authorisation checking. However, when defined, they can confuse and annoy RACF administrators and system programmers. RACF now provides a new NOGENERIC keyword for the RDELETE command to enable you to delete these profiles along with a GENERIC=N option for R_admin DELETE.
• RACF now issues a warning message when creating a profile which contains generic characters (*,% or &) in a non-generic class
• Prior to z/OS V1.12, RACF caches up to 4 sets of generic profile names per address space to speed up authorisation checks for resources which are covered by generic profiles. If an address space uses more than 4 sets of profiles, RACF discards the least recently used list of generic profiles. If a deleted HLQ or class is referenced, the list is built again, which can result in thrashing. With V1.12, you can configure the number of sets of profiles, up to a maximum of 99.
• The SAFTRACE facility allows an in-depth analysis of the calls made from resource managers to RACF. With V1.12, you can control SAFTRACE records for RACROUTE and database (ICHEINTY) access by class and user ID.
There are a number of improvements for ICSF, including:-
◦ New ICSF segment on CSFKEYS, GCSFKEYS, XCSFKEY, and GXCSFKEY profiles allows the specification of controls on high performance secure keys
◦ ICSF segment fields may be extracted using RACROUTE REQUEST=EXTRACT,BRANCH=YES
◦ Mapping of in-storage ICSF segment information is in ICHPISP SAF mapping macro
◦ ICSF segment is unloaded by IRRDBU00 as record type 05G0
◦ RACF panels are populated with initial values for the ICSF segment
• RACDCERT and PKI Services enhancements include:
◦ Support for elliptic curve cryptography (ECC) when creating certificates and when processing certificates created using ECC
◦ Support for RSA keys up to 4096 bits
◦ Support for DSA key types
◦ Support for long issuer distinguished names
◦ Extend certificate validity date beyond its current limit (PKI:2038, RACF:2041) to the year 9999
◦ Support for certificate management protocol (CMP)
◦ Support for custom X.509 certificate extensions
◦ Support for the posting of certificates and certificate revocation lists (CRLs) to LDAP at any time
◦ Configurable maintenance task execution time
The full z/OS 1.12 announcement letter can be found here
Just time before Montpellier to tell you there is some new System z related content at http://www.pirean.com/Systemz.htm including now four PDFs for download. These are
As promised, here is my analysis of how IBM Tivoli zSecure can help you achieve compliance with the Payment Card Industry Data Security Standard (PCI DSS). PCI DSS is a set of twelve requirements designed to secure and protect customer payment data. As of September 2010 the revised standard is mandatory for members of the Visa and MasterCard schemes, with fines for violations running into hundreds of thousands of pounds.
If you have zSecure then this document might help you on your way. If not, read this to see how it can help you achieve PCI compliance, implement your security policy goals and reduce the overall cost of security administration and compliance activity.
This is a short extract from the first draft of an article I'm writing for z/Journal about maturing the mainframe security function. This section deals with a necessary cultural shift in the control of mainframe data.
"Organisations carry lots of sensitive data, typically the mainframe will host thousands of customer account records, and in some cases this will include financial data such as credit card details and even PINs. All of this is valuable information for which criminal gangs will pay, even as much as $15 for a single set of “identity data” including address, DOB and social security number. The infamous “lost disks” containing the UK government’s 25 million child benefit claimants were estimated to be worth £1.5bn on the black market (http://bbc.in/cqAgvP, 2007)
"This means we must lock down our sensitive production data, even from browsing. Access must only be allowed via the applications that use the data, via legitimate transactions. However many RACF administrators have been brought up to prevent data modification, and might view READ access as fairly benign. Some shops allow READ access to production data fairly widely to facilitate production support. It takes a major cultural change to wean your IT staff off wide-ranging READ access, and further effort still to achieve the desired state of least-privilege access."
The full article should be in the December issue, but why not subscribe now and read some excellent stuff in the current issue by Ray Overby, Alan Radding and others, including a closer look at the zEnterprise.
I'm attending this next month:-
System z Security Event for Today and Tomorrow...
Note the dates have changed but the website still shows the old dates (in a GIF which is messy to edit, there's a lesson there for all webmasters!)
New dates are Tue 28th Sep to Fri 1st Oct 2010.
If you use LinkedIN then I've added the event here - please update if you're attending and maybe we can meet up.
Topics for the 4-day conference are
I continue to be amazed at the worrying stories of PCIDSS non-compliance in UK organisations, many of which are certain to have System z at the heart of their payment operations.
To that end I am writing a paper on how zSecure can help you achieve compliance with the PCIDSS (Payment Card Industry Data Security Standard) - which becomes mandatory for Level 1 merchants in the Visa and Mastercard schemes from next month. That will be available on Pirean.com soon but here are some highlights. The numbered list is the "Digital Dozen" - the twelve basic requirements of the PCIDSS, and the bullets describe briefly how zSecure can help you deliver against that requirement cost effectively.
1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
3. Protect stored cardholder data.
5. Use and regularly update anti-virus software.
6. Develop and maintain secure systems and applications.
7. Restrict access to cardholder data by business need-to-know.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.
12. Maintain a policy that addresses information security.
I'll let you know when the full doc is available, meantime check out my thoughts on compliance for System z in my earlier white paper here.