RACF Audit Minimizes Risks for Mainframe Customers

RACF Audit Minimizes Risks for Mainframe CustomersMore than 80 percent of all global z/OS installations employ RACF (Resource Access Control Facility), the IBM tool for identifying and verifying users, managing access rights and logging access to protected resources. Based on the probable assumption that IBM mainframe systems are likely used by very large companies, it can be said with great confidence that RACF protects the security of the world’s most complex IT landscapes.

IBM started shipping the security tool in 1976 and has been upgrading it on an ongoing basis. Yet, trying to keep IT systems safe is a constant, frustrating battle since threats such as increasing cyber attacks, organizational flaws, technological accidents or force majeure appear to always be a step ahead of corporate IT security measures. And as IT risks and weaknesses change, so do regulatory requirements.

This situation calls for subjecting RACF to a permanent screening process to uncover weak spots. Is the system still able to detect IT risks in due time? If it is not, the reason for this might be general flaws in design and implementation. During ongoing operation, human error tends to be another factor, which has become worse over time. After all, RACF experts are getting rare these days; young people staffing the IT departments are of a different generation that grew up with Macs and Windows. And these are precisely the users that Beta Systems developed Beta 88 Discovery for. Its modern user interface makes it much easier to administrate RACF as compared with the built-in interfaces.

The RACF Tool Does Not Play a Major Role During Audits

It is a common misconception among CIOs that installing an accessory such as this software will purge the weaknesses of RACF ‘just like that’. The truth is, however, that checking a running RACF system is mostly (60 to 70 percent) a consulting job that requires actual people to determine the neuralgic weak spots of the software. The technology used to capture and assess information is of secondary importance; you can use Beta 88, Excel or paper lists. But a suitable technology such as Beta 88 will no doubt result in much faster and more efficient audits. The RACF Audit developed by Beta Systems naturally also incorporates this balance between consulting and technology.

Why It Makes Sense to Perform an RACF Audit

Many RACF customers commission Beta Systems with auditing their RACF system. This allows them to identify and remove weaknesses in their infrastructure before an actual audit takes place. In highly regulated areas, including the financial services sector, external audits are mandatory. For example, banks are required to have their IT systems checked for security flaws by an external BAFIN auditor twice a year, each time with a different focus such as the operating system, the network or RACF.

Security violations are not always driven by criminal or fraudulent intent.

For instance, a security system is critically flawed if an application that should be protected can be edited by defining false authorizations of individuals or groups that are not supposed to have access. Or if the command for shutting down RACF is not protected, enabling anyone to easily disable the security system. More often than not such weak spots are not the result of criminal intent. Instead, it’s the hundreds of configuration parameters associated with RACF commands that can cause problems. It takes years of experience and deep specialist know-how to master them.

What Does the Beta Systems RACF Audit Comprise?

The RACF IT security audit is a consulting project that analyzes risks and weak spots under consideration of all conceivable error causes.

  • Over the past 15 years, Beta Systems developed a standard procedure based on proven RACF audit guidelines.
  • These guidelines account for the BSI list of basic security measures and the recommendations of the ISO 27000 security standard.
  • The first part of the RACF audit addresses static configuration issues by analyzing the global RACF security settings. The auditor checks 131 test items that cover all functions for analyzing, documenting and assessing data.
  • The second part of Beta Systems’ best practice approach focuses on event auditing based on twelve test items. This includes checking past events such as, e.g., failed attempts to log on to the mainframe, thus allowing the auditor to trace possible attacks.

Rapid Analysis of Weak Spots Based on the RACF Audit 

The RACF audit is based on a set procedure. After the initial meeting, the auditor performs a needs analysis and determines which test items of the audit guideline should be emphasized. This is followed by installing the technology, in this case Beta 88 Discovery. There are batch jobs associated with the individual test items. These jobs are installed and executed in the customer’s RACF environment to collect data. Each job generates a result file that indicates what data should be collected for each test item. The auditor then determines the system’s weak points by evaluating these files one item at a time. In this context, Beta 88 serves as a fast and cost-efficient data gathering tool. After data evaluation, evidence must be collected. The reason for this is the legal obligation to document and provide dedicated proof of any test item that failed to pass.

There Are Two Types of Reports Besides the Proof Document

RACF-Audit_Management-Report-2RACF-Audit_Management-Report-1

  • The Management Summary Report provides at-a-glance information on test items via a traffic light indicator system, and
  • the Detail Report lists specific measures for each test item. During the second meeting on site, the auditor coordinates the order in which weak spots are to be removed together with the customer.

RACF audits are of critical importance to mainframe and RACF users with a particularly high need for protection and/or those who already experienced an attack.

System security always goes hand in hand with proper organizational structures. This means that one key task during the security audit is to verify the organizational processes in the company. This will determine if the organizational structure is adequate. Most of the time, the findings of an RACF audit trigger measures taken to improve the organizational design. These, in turn, cause long-term changes to corporate processes.

Reduce Audit Costs by up to 50%

Audits of this kind are generally performed by auditing firms or IT companies. The former rely on audits as their core business model. Audit firms apply best practice procedures and cover a wide range of audits.

However, they perform these tasks manually, and the auditor goes through each department to hold interviews and tick off checklists. As a result, audits tend to take a very long time. IT providers have software tools that help them accomplish the task much faster, also resulting in lower costs (up to 50 percent). They do not have the broad expertise of an auditing firm, but tend to have more in-depth technical know-how.

Expect Increased Audits in the Future

The need for regular security checkups of (but not limited to) the RACF system is certain to rise further. One reason is that corporate mergers result in bigger and increasingly intransparent IT installations, making them more susceptible to cyber attacks. At the same time, the number of legal requirements is rising steadily in an effort to ensure a constant level of protection. This means that IT security audits are not a momentary trend. They have been relevant for many years and will become even more important in the future.

Tags: |
Bernhard Prüger
I was born in Vienna, living and working with my family for many years in the German capital Berlin. As business data processing specialist I am attracted by the fascination of IT. As a Product Marketing Specialist at Beta Systems I'm responsible for the data center product portfolio. So far, I helped companies in the start up of inbound marketing and the implementation of Go-to-market strategies.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

← zurück