DB2: Internal Subsystem Security vs. External Security Manager (ESM)?

With the ever increasing requirement for regulatory compliance and the clear and present danger associated with cybersecurity attacks, isn’t now the best time to safeguard your organizations most important asset, namely business data?  Various industry analyst quotes state that ~80%+ of Mainframe data resides in databases and associated data sources and ~80%+ of global corporate data originates or resides on IBM Mainframes.  Depending on your viewpoint, rightly or wrongly DB2 is the most pervasive of database subsystems, offering two mechanisms for security, either internal subsystem or External Security Manager (ESM) based via ACF2, RACF or Top Secret.  When DB2 was first released in 1983, Mainframe security was in its infancy and perhaps even an afterthought, and so implementing internal DB2 security might have been the typical approach for many years.  Some several decades later, asking that age old rhetorical question; what is the best security solution for my mission critical and priceless data?  I’m not sure it is a rhetorical question, the answer is patently obvious, external security!

RACF and DB2 security integration was introduced in 1997 with OS/390 2.4 and DB2 Version 6 and so a ~14 year period where DB2 internal security was the only option!  Personally, ~20 years ago I was involved with an internal DB2 to RACF security migration project, part of a larger Operating System, DB2 and indeed CICS upgrade.  Basically the DB2 DBA team stated “we would have never implemented internal DB2 security if the RACF option was available; can you migrate to RACF for us”?  The simple reality being that Security Management is not a core DBA skill and such a process is ideally delivered by a Subject Matter Expert (SME).  Of course, DB2 was somewhat straightforward ~20 years ago, as were its security features, but in the last ~20 years, DB2 has become more complex and enterprise wide, while I’m often surprised by the number of organizations I encounter, both small and large, still deploying internal DB2 security…

Recognizing a ~20 year longevity period of RACF security support for DB2, maybe even the most conservative of organizations might concede that the technology is proven and works?  From a business viewpoint, such a migration from DB2 internal to an External Security Manager (ESM) is the proverbial “no brainer”, because:

  • Subject Matter Expert (SME): Clearly all IBM Mainframe organizations now have dedicated security professionals who are ideally placed to implement enterprise wide security policies. A DB2 DBA is a highly skilled SME in their own discipline, most likely welcoming the migration of security from DB2 to ACF2, RACF or Top Secret.
  • Compliance: A plethora of industry regulations, including but not limited to GLB, SOX, PCI-DSS, et al, dictate that a hybrid of technical skills and business policy knowledge is required. This has generated a requirement for the executive level CISO role and associated security certifications (E.g. CISA, CISM, CISSP) for SME resources.
  • Auditability: From a board level CxO viewpoint, which technical resource would you want responsible for your security policy, the CISO/CIO and their security engineers or a DB2 DBA?
  • Hacking-Penetration Testing: Rightly or wrongly, rightly in my opinion, Penetration (Pen) Testing is a methodology to try and hack a system in order to highlight security vulnerabilities, supplementing the traditional periodic audit processes. Once again, high levels of security expertise are required for such activities.

From a technical viewpoint, what is the complexity of performing a DB2 internal to RACF external security migration?

From a DB2 viewpoint, internal security rules are stored in DB2 catalog tables with the SYSIBM.SYSxxxAUTH naming convention.  Therefore these data repositories can be processed with a simplistic DB2 to RACF security migration tool (RACFDB2).  As per any migration activity, Garbage In, Garbage Out (GIGO) applies, and this golden rule dictates the requirement for a collaborative team effort to execute a DB2 to RACF security migration process.  Of course, the most important resources will be the DB2 DBA(s) responsible for maintaining DB2 security and a RACF SME.  Between them, these 2 resources have all of the skills required to perform this migration process, if not the experience.

From a documentation viewpoint, there are several resources that can be referenced to simplify this process:

The purpose of this blog post is a “call to action”, for those sites still deploying DB2 internal security, to migrate to their External Security Manager (ESM), whether ACF2, RACF or Top Secret.  There are also options for the migration of internal DB2 security to CA ACF2 and Top Secret respectively.

As previously stated, the DB2 DBA will be ideally placed to review the existing internal DB2 security environment, performing any clean-up and rationalization before the actual migration process.  The initial pass of the migration process will inevitably produce a one:one (1:1) mapping of rules, generating numerous security definitions extraneous to requirements.  This is where the ACF2, RACF or Top Secret SME can collaborate with their DB2 DBA, applying grouping, masking and generic filters to vastly reduce and simplify the number of security definitions required.  As with any migration, perform on the lowest level non-Production environment first, apply the lessons learned, and use common sense, issuing warning messages for inadvertent security policy errors, as opposed to denying security access for Production migrations!  Therefore allowing for the smooth transition from DB2 internal to ESM based security.

In my opinion, each and every IBM Mainframe organization has the ability to initiate this DB2 internal to external ACF2, RACF or Top Secret migration project.  Leveraging from 3rd party organizations also makes sense and in no particular order, other than alphabetical, I would suggest IBM Global Services, millennia, RSM Partners or Vanguard.

In conclusion, the IBM System z External Security Manager (ESM), whether ACF2, RACF or Top Secret is an ever-evolving solution with highly advanced security functionality and the de facto central repository for IBM Mainframe security policy management.  From a Security Information & Event Management (SIEM) integration viewpoint, any IBM Mainframe security policy violations will be reported upon in near real-time, while being managed by IBM Mainframe security experts.  Without doubt, if DB2 was implemented before 1997, internal security would have applied, but there has been a ~20 year period where migration to the ACF2, RACF or Top Secret ESM could have happened.  If such a migration activity applies to your organization, I would hope it’s a high priority item, given the potential security risk and priceless value of your business data!

What is my RACF technical policy? Could it be NIST DISA STIG based?

In the late 1980’s I was lucky enough to work at a Mainframe site that was performing early testing for MVS/ESA and DFP Version 3, namely DFSMS. So what you say! The main ethos of DFSMS was in fact System Managed Storage and the ability to define policies to manage data, and the system (DFSMS) would implement these policies. Up until this point, there was no easy way of controlling data set allocation and managing storage space.

Conversely, the three mainstream Mainframe security subsystems, in no particular and so alphabetical order, ACF2, RACF (Security Server) and Top Secret have always had the ability to define a security policy and for said policy to be processed as and when the associated resource was accessed. So why is it that so many security risk registers are full of “things to do” from a security viewpoint? Where did it all go wrong?

In the late 1980’s, Guide and SHARE, in Europe anyway, were separate entities, and these organizations had some influence with IBM regarding direction for various IBM Mainframe technologies. Not much has changed as of today, but the organizations have merged and for Europe, now we have GSE. From a DFSMS viewpoint, there was a significant amount of user input regarding how DFSMS might be shaped, and the “System Managed Storage” ethos. I wonder whether such user input, or indeed focussed collaboration from Mainframe security gurus might help with the RACF or Mainframe security technical policy challenge?

Having worked with multiple IT security focussed organizations (E.g. NIST, DoD) over the last few decades, Vanguard Integrity Professionals has been actively involved in creating and evolving NIST DISA STIG Checklists. These checklists (currently 300+ checks and growing steadily) provide a comprehensive grounding for z/OS RACF policy checking, and seemingly are gaining momentum in being accepted as a good starting point to assist organizations define and monitor their z/OS RACF (ACF2 & Top Secret in the near future) policy.

These DISA STIG checklists contain step-by-step instructions for customer usage to ensure secure, efficient, and cost-effective information security that is fully-compliant with recognized security and therefore Mainframe security standards. Being fully compliant with DoD DISA STIG for IBM z/OS Mainframes, these checklists provide organizations with the necessary procedures for conducting a Security Readiness Review (SRR) prior to, or as part of, a formal security audit.

To increase automation and thus reduce cost, Vanguard has optimized the DISA STIG checking process with their Configuration Manager solution. Configuration Manager can perform Intrusion Detection DISA STIG checks and report findings in just a few hours instead of the hundreds or thousands of hours it may take using standard methods. Potentially, Configuration Manager enables organizations to easily evolve from continuous monitoring to periodic compliance reporting.

Maintaining tight control over the security audit and compliance process is a critical imperative for today’s enterprises. To comply, enterprises must show that they have implemented procedures to prevent unauthorized users from accessing corporate and personal data. Even if enterprises have the means to efficiently conduct audits, they often lack the tools necessary to prevent policy and compliance violations from reoccurring. As a result, security vulnerabilities remain a constant threat, exposing companies to potential sanctions and erode the confidence of investors and customers.

As a result, the process of meeting compliance standards such as those found in the Combined Code issued by the London Stock Exchange (LSE) and the Turnbull Guidance (the Sarbanes-Oxley equivalent for publicly traded companies in the UK), the Data Protection Act 1998 (and, for the public sector, the Freedom of Information Act 2000), the regulations promulgated by the Financial Services Authority (FSA) (the FSA has oversight over the various entities that make up the financial services industry), standards set by Basel II, the Privacy and Electronic Communications Regulations of 2003, the HMG (UK Government) Security Policy Framework, the Payment Card Industry Data Security Standard (PCI DSS) and various UK criminal and civil laws, represents one of IT’s most critical investments.

As a consequence, managing security in the Mainframe environment is becoming an increasingly difficult task as the list of challenges grows longer every day. Even the most experienced Security Administrators can labour under the workload as security systems increase in size and networks grow in density.

So where does the Mainframe Security Administrator start to make sense of how to achieve security compliance for their particular business?

Although there are many security and compliance regulatory requirements with supporting policy frameworks, none of these high-level mandates actually drill-down to the technical level and thus provide RACF or equivalent Mainframe (ACF2, Top Secret) policy guidelines!

There are synergies between various global organizations that define security standards. This is certainly true for NIST and ISO/IEC. Page viii of the NIST SP-800-53 policy states:

NIST is also working with public and private sector entities to establish specific mappings and relationships between the security standards and guidelines developed by NIST and the International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 27001, Information Security Management System (ISMS).

Furthermore, the seemingly ubiquitous Annex A of ISO 27001 is also cross-referenced by this NIST SP-800-53 policy, and the various controls and monitoring points are cross-referenced, where largely, the requirements of the NIST standard are mapped in the ISO/SEC standard, and vice versa. Please refer to Appendix H of the NIST SP-800-53 policy, which cross-references NIST SP-800-53 with ISO/IEC 27001 (Annex A) controls.

Put simply, one must draw one’s own conclusions as to the robustness of NIST SP-800-53 vs. ISO/IEC 27001, but both security standards seem to have commonality as robust and acceptable security standards. So maybe Mainframe users all over the world can define and deploy a generic and robust baseline Mainframe technical security policy, vis-à-vis, the NIST DISA STIG checklists…

We must also recognize the IBM Health Checker for z/OS, which also has the ability to perform automated RACF policy checks. This facility includes some ready-to-go checks for standard system services, in conjunction with a facility that allows the user to define their own policy checking rules. Without doubt, the IBM Health Checker for z/OS is a worthy resource that should be leveraged from, but for RACF, if each Mainframe user defines their own policy checking rules, maybe there is the possibility for a significant duplication of effort. For the avoidance of doubt, although RACF resource naming standards might be unique to each and every Mainframe user, there is a commonality of ISV (E.g. ASG, BMC, CA, Compuware, IBM, SAS, et al) software subsystems and products they deploy. If only we could all benefit from previous lessons learned by “standing on the shoulders of giants”!

Perhaps the realm of opportunity exists. There are many prominent Mainframe security giants actively involved today, including the authors of ACF2, Vanguard Software, Consul (Tivoli zSecure), naming but a few. Is it possible that there could be one common standard that might be used as a technical policy template, based upon the ubiquitous 80/20 rule? So deploying this baseline would deliver 80% of the work required for 20% of the effort, where the unique Mainframe customer just customizes this policy as per the resource naming standards in their Mainframe Data Centre? Equally the user has the ability to contribute to this template, perhaps using a niche software product not commonly used that requires security policy checks, where said software product is deployed in maybe tens of Mainframe customers globally.

Vanguard clearly has put a lot of effort into evolving the DISA STIG resource for Mainframe, IBM also has their RACF Health Checker, but what about one overseeing independent organization, which could benefit from the experience of Mainframe security specialists, and moreover, real-life field experience from Mainframe users globally, implementing and refining these standards. Wasn’t that the essence and spirit of Guide and SHARE several decades ago, listening to Mainframe users and evolving Mainframe technology accordingly? Of course SHARE in The USA and Guide Share in Europe, IUGC and APUGC in the APAC region still perform this function admirably, but seemingly with the NIST DISA STIG resource, we already have a great baseline to leverage from.

What is the size and shape of this potential task, ideally to identify each z/OS software product that has specific interaction with the security subsystem (I.E. ACF2, RACF, Top Secret), typically via resource profiles? For a software z/OS product to be developed, the ISV will have interacted with IBM, initially via their PartnerWorld resource for product development, and eventually via the IBM Global Solutions Directory from a Marketing viewpoint. As of Q4 2012, the IBM Global Solutions Directory contains ~1,800 ISV’s with z/OS based software products.

However, recognizing there are already good security resource checklist templates in existence, vis-à-vis the solid foundation primarily provided by Vanguard via the DISA STIG checklists, the best organization to add to these DISA STIG checklists are the ISV’s themselves. The ISV has most knowledge about their product, having written the code and supporting documentation for security related control; so a modicum of effort from the ISV that has product specific security resource checking seems the best way forward.

In 2003 IBM launched a Mainframe Charter initiative, demonstrating their commitment to the Mainframe platform, where they adopted nine principles organized under the pillars of innovation, value, and community. Although this was an IBM initiative, wouldn’t it be great for the Mainframe ISV to proactively be part of this global Mainframe community, and assist their Mainframe customers simplify the activity of implementing and monitoring their Mainframe security technical policy? Not every ISV will have software products with specific security resource interaction, and therefore not every product in the ISV software portfolio will require a security checklist. The amount of work per software product to create a template might only be several hours, and so could the ISV produce these checklists as part of their day-to-day customer support activities?

Is it possible that globally, we can all participate and collaborate in a focussed and Mainframe security centric group, to define a technical policy template that will assist all Mainframe customers satisfy regulatory compliance mandates? No one of us is as good as all of us…