What is the definition of a severe security code vulnerability?
A severe security code vulnerability is a weakness in the z/OS operating system caused by coding techniques that do not follow the IBM Statement of Integrity. The vulnerability could be located in IBM Software Products supplied programs, in Independent Software Vendor (ISV) supplied programs, or installation-added programs or exits. A severe security code vulnerability occurs when one of the authorized programs on your z/OS system violates the IBM statement of integrity. IBM’s statement of integrity says “IBM’s commitment includes design and development practices intended to prevent unauthorized application programs, subsystems, and users from bypassing z/OS security – that is, to prevent them from gaining access, circumventing, disabling, altering, or obtaining control of key z/OS system processes and resources unless allowed by the installation.”
Why should I care about system integrity?
IBM’s commitment to system integrity is one of the major reasons that z/OS is such a secure platform. z/OS, as well as the big three external security manager (ESM) products (CA-ACF2, CA-TSS, and IBM-RACF), all rely on system integrity in order to function properly. An appropriate analogy for not having system integrity is like locking the front door to your house but leaving your windows open. Without operating system integrity there cannot be any security on your z/OS system.
What responsibilities do I have for my z/OS system with regards to integrity?
According to IBM’s z/OS Authorized Assembler Services Guide you are responsible for the following for each z/OS system you have: To ensure that system integrity is effective and to avoid compromising any of the integrity controls provided in the system, the installation must assume responsibility for the following: Physical environment of the computing system. Adoption of certain procedures (for example, the password protection of appropriate system data sets) that are a necessary complement to the integrity support within the operating system itself. That its own modifications and additions (3rd Party Software) to the system do not introduce any integrity exposures. That is, all installation-supplied authorized code (for example, an installation SVC) must perform the same or an equivalent type of validity checking and control that the system uses to maintain its integrity. It should be noted that the IBM z/OS statement of integrity only applies to the IBM code. It does not apply to any ISV code or installation written code. You, the z/OS system owner, are responsible for verifying the integrity of any code you add to z/OS.
What is a severe security code based exploit?
A severe security code based exploit is a set of instructions that will enable an unauthorized z/OS user to bypass your installation’s ESM controls. This exploit is usually based upon one or more severe security code vulnerabilities.
How bad can these severe security code vulnerabilities be?
A: The z/Assure™ Vulnerability Analysis Program (VAP) has categorized severe security code vulnerabilities as ALTER level and READ level. An ALTER level severe security code vulnerability is defined as a vulnerability that when exploited will completely compromise all data on your z/OS system, as well as the system itself. Why? Because the exploiter can change their authority to allow them to alter any security parameter and gain access to all data on the system. Severe security code based ALTER level vulnerabilities will typically score at least 8.4 or higher using the CVSS V2 calculator. A READ level severe security code vulnerability is defined as a vulnerability that when exploited, will completely comprise some or all memory on your system. It is common practice to place sensitive data into fetch protected memory. Data placed into fetch protected memory includes clear text passwords, encryption keys, and other similar sensitive data. This sensitive data could also include installation defined sensitive data. Severe security code based READ level vulnerabilities will typically score at least 5.0 or higher using the CVSS V2 calculator.
Can any z/OS user utilize one of these exploits to bypass my security policy or are there restrictions?
Every severe security code based exploit will have certain requirements in order to be exploitable. You would review these requirements to determine which of your users would have the ability to implement the exploit. Here are some sample requirements for a typical ALTER level severe security code base exploit discovered by z/Assure VAP . The hacker might require:
- Ability to create a new data set or update an existing one
- Ability to execute a REXX exec
- Ability to submit a batch job
- Ability to logon to TSO
- Ability to use an assembler and/or linkage editor
- Ability to use TSO TEST command
- You will note that NO extra-ordinary security authorities would be required. The exploiter typically only requires authorities granted to the lowest authority users on your z/OS system.
What causes these severe security code vulnerabilities?
Severe security code vulnerabilities primarily exist in interfaces between unauthorized and authorized code. When this interface software is not designed and/or coded correctly then severe security code vulnerabilities are created.
Where does this authorized code come from?
Authorized code comes from:
- IBM software products
- Independent Software Vendors (ISV’s)
- Installation-written code
- Open source code and shareware
- System exits
How do I know if I have any of these severe security code vulnerabilities?
Based upon the z/Assure VAP products’ current knowledge of known severe security code vulnerabilities and exploits, it is highly likely your z/OS system contains one or more of these today. Typically, the bigger your mainframe environment is the higher the likelihood. This is because the bigger shops use more ISV and installation written code. As the number of ISV products goes up it is more likely that one of them will have poorly written code which leads to severe security code vulnerabilities. But even those z/OS systems that only have IBM programs running on them will contain vulnerabilities. It only takes one authorized program with single severe security code vulnerability from a single vendor to compromise your entire z/OS system.
Are you saying that my External Security Manager (CA ACF2, IBM RACF, CA Top Secret) is broken?
No. Ensuring system integrity is outside the scope of the current external security managers. None of the big three security packages are capable of enforcing the defined security policy when severe security code vulnerabilities allow your users to gain unauthorized access thru an exploit to circumvent z/OS system integrity.
What can I do about these severe security code vulnerabilities and exploits?
- Require stringent testing by your vendor (they won’t find all of them)
- Require an integrity statement from the vendor (not all have this)
- You can perform your own integrity scans as called for by all of the major compliance standards.
Does it matter what external security manager I have? Will z/Assure VAP work with CA ACF2, IBM RACF, CA Top Secret?
z/Assure VAP is independent of the installed external security manager. The exploits that can be created based on the identified severe security code vulnerabilities will work regardless of the external security manager you have installed.
If I use z/Assure VAP to locate and find these severe security code vulnerabilities would I only do this once?
No. Any Compliance Audit or Vulnerability Assessment you perform is only valid for a specific point in time. Once the system is modified (ex – maintenance applied or systems options changed) you would have to reassess the system using the z/Assure VAP license.