SG245677 IBM Server OS/390

User Manual: IBM Server OS/390

Open the PDF directly: View PDF PDF.
Page Count: 142 [warning: Documents this large are best viewed by clicking the View PDF Link!]

ibm.com/redbooks
CA-TopSecret to
OS/390 Security Server
Migration Guide
Paul de Graaff
Ted Anderson
Julie Bergh
Peter Desforge
Lynn Kearney
Lori Halberts Kikuchi
Tony Nix
Mark Shell
Product design similarities and
differences
Planning the migration
Conversion methodologies
International Technical Support Organization SG24-5677-00
CA-Top Secret to OS/390 Security Server
Migration Guide
October 2000
© Copyright International Business Machines Corporation 2000. All rights reserved.
Note to U.S Government Users - Documentation related to restricted rights - Use, duplication or disclosure is subject to restrictions
set forth in GSA ADP Schedule Contract with IBM Corp.
First Edition (October 2000)
This edition applies to SecureWay Security Server Version 2, Release Number 10, Program Number 5645-001 for
use with the OS/390 Operating System
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
Before using this information and the product it supports, be sure to read the general information in Appendix D,
“Special notices” on page 109.
Take Note!
© Copyright IBM Corp. 2000 iii
Contents
Figures ......................................................vii
Tables .......................................................ix
Preface ......................................................xi
The team that wrote this redbook .......................................xi
Commentswelcome................................................xiii
Chapter 1. The value of SecureWay Security Server for OS/390 .........1
1.1 OverviewoftheSecurityServer.................................1
1.1.1 Business benefits of the Security Server .......................1
1.1.2 Financial benefits of the Security Server .......................3
1.2 RACFadministrativehighlights..................................3
1.2.1 RACF administrative enhancements . . . .......................3
1.2.2 RACF/DB2securityadministrationoverview....................5
1.3 RACF market penetration ......................................8
Chapter 2. SecureWay Security Server for OS/390 ...................11
2.1 SecureWay branding. . .......................................11
2.2 Introduction to the SecureWay Security Server for OS/390 . ...........11
2.2.1 Resource Access Control Facility (RACF) .....................11
2.2.2 TheDCESecurityServer .................................13
2.2.3 OS/390 firewall technologies. . . ............................14
2.2.4 TheLDAPServer.......................................15
2.2.5 Network Authentication and Privacy Service (Kerberos) ..........16
2.2.6 OS/390 Open Cryptographic Services Facility (OCSF) ...........17
Chapter 3. RACF overview ......................................19
3.1 Informationflow ............................................20
3.1.1 Authorizationflow.......................................22
3.2 Vocabulary ................................................23
3.2.1 RACFuser ............................................23
3.2.2 RACFgroup ...........................................24
3.2.3 Owner................................................25
3.2.4 RACFprotectedresources ................................25
3.2.5 RACFsystem-wideoptions................................27
3.2.6 The RACF database .....................................27
3.2.7 RACF commands .......................................28
3.3 Interfaces.................................................30
3.3.1 Product interfaces .......................................30
3.3.2 TheSAFinterface.......................................31
3.3.3 RACFexits............................................31
Chapter 4. CA-Top Secret overview ...............................33
4.1 The CA-Top Secret security philosophy ..........................33
4.2 TheCA-TopSecretenvironment................................36
4.2.1 TheALLrecord.........................................36
4.2.2 Personnel . ............................................36
4.2.3 Resourcerules .........................................37
4.2.4 CA-Top Secret database files . . ............................38
4.3 CA-TopSecretsubsysteminterfaces ............................38
4.3.1 TSO .................................................38
iv CA-Top Secret to OS/390 Security Server Migration Guide
4.3.2 CICS................................................ 38
4.3.3 IMS.................................................38
4.3.4 DB2................................................. 38
Chapter 5. RACF migration project overview....................... 39
5.1 Preparing for the migration project plan . ......................... 39
5.1.1 ReviewthecurrentCA-TopSecretenvironment................ 40
5.1.2 Personnel . . . .........................................42
5.1.3 Education ............................................43
5.2 Buildingthemigrationprojectplan..............................44
5.2.1 Significantprojecttasks.................................. 45
5.3 Resource scheduling ........................................ 49
5.4 Summary................................................. 49
Chapter 6. Database migration .................................. 51
6.1 Conversion methodology . .................................... 51
6.1.1 Migrationconsiderations .................................51
6.2 ConvertingACIDs .......................................... 52
6.2.1 CA-TopSecretuser/groupmigrationissues................... 53
6.2.2 ListingtheCA-TopSecretACIDs........................... 54
6.2.3 ReviewinganddefiningACIDstoRACF .....................54
6.2.4 Converting zone, division and department ACIDs .............. 54
6.2.5 ConvertingprofileACIDs................................. 55
6.2.6 ConvertinguserACIDs .................................. 57
6.2.7 ConvertingsecurityadministratorACIDs.....................58
6.2.8 Password............................................. 60
6.2.9 OtherCA-TopSecretuserACIDparameters.................. 62
6.3 Convertingdatasets........................................ 62
6.3.1 User-basedversusresource-basedprotection................. 63
6.3.2 Datasetconversionoverview ............................. 64
6.3.3 DefiningdatasetprotectioninRACF........................ 65
6.3.4 Data control groups and the RACF high-level qualifier. . . ........ 65
6.3.5 Datasetaccess........................................ 66
6.3.6 Undercutting considerations. .............................. 67
6.3.7 OtherCA-TopSecrettoRACFdatasetmigrationissues......... 69
6.3.8 Moredatasetconsiderations..............................71
6.4 Convertingresources ....................................... 72
6.4.1 FACILITIES........................................... 72
6.4.2 VOLUME............................................. 73
6.4.3 OTRAN .............................................. 74
6.4.4 LCFAUTH/EXMP ......................................75
6.4.5 DB2................................................. 75
6.4.6 TERMINAL ........................................... 76
6.4.7 PROGRAM ........................................... 76
6.4.8 XAACID ............................................. 77
6.4.9 User-definedresources.................................. 77
6.5 Otherconsiderations........................................ 78
6.5.1 OS/390UNIXconsiderations..............................78
6.5.2 STCs................................................ 78
6.6 Convertingsystem-wideoptions ............................... 80
6.6.1 Commonsystem-widesecurityoptions ...................... 80
6.6.2 CPF................................................. 80
6.6.3 Protection modes. . . .................................... 80
v
6.6.4 Passwords ............................................81
6.6.5 RACFoptions..........................................81
Chapter 7. Administration and maintenance........................83
7.1 Theadministrativeinterface ...................................83
7.2 Commands ................................................84
7.3 RACFutilities ..............................................86
7.4 Security reports. ............................................86
7.5 Availabilityconsiderations.....................................89
7.5.1 RACFactivebackupoption................................89
7.5.2 Reorganizing the RACF database ...........................90
7.6 RACFperformanceconsiderations..............................90
7.6.1 Performance of shared databases...........................92
7.6.2 Migrationissues ........................................92
7.6.3 Summary..............................................93
Appendix A. IBM migration services................................95
A.1 Mainframesystemsoftware ......................................95
A.2 Migrationservices..............................................95
A.3 Conversionvs.migration.........................................95
A.4 Migrations-notwoarealike......................................95
A.5 Migrationserviceofferings .......................................96
A.5.1 Migrationassessmentservice.................................96
A.5.2 Database conversion service .................................96
A.5.3 Migrationconsultingservices.................................96
A.5.4 Migrationperformservices...................................96
A.5.5 LearningServices..........................................97
A.6 Productmigrations .............................................97
A.7 Gettingstarted.................................................98
Appendix B. Security policy considerations .........................99
B.1 Useridentification..............................................99
B.1.1 Batch....................................................99
B.1.2 TSO.....................................................99
B.1.3 Started procedures (STC). . ..................................99
B.2 Resourceprotection ...........................................100
B.2.1 Datasets................................................100
B.2.2 Transactionsandotherresources.............................100
B.3 Authentication . . . .............................................101
B.3.1 Passwords...............................................101
B.3.2 Passtickets..............................................101
B.4 Namingconventions...........................................101
B.4.1 Datasets................................................101
B.4.2 Otherresources ..........................................102
B.4.3 Users and groups . . .......................................102
B.5 Ownership...................................................102
B.6 Securityadministration.........................................102
B.6.1 Structure................................................102
B.6.2 Effectiveness.............................................102
B.6.3 Efficiency................................................103
B.7 Auditconsiderations...........................................103
B.7.1 Logging.................................................103
B.7.2 Eventmonitoring..........................................103
B.7.3 Statusreview.............................................104
vi CA-Top Secret to OS/390 Security Server Migration Guide
B.8 Resourceutilization............................................104
B.8.1 Performanceoptions.......................................104
B.8.2 Potentialperformanceimpact ................................104
Appendix C. Frequently asked questions ...........................105
Appendix D. Special notices ......................................109
Appendix E. Related publications .................................111
E.1 IBMRedbookscollections.......................................111
E.2 Otherresources...............................................111
How to get IBM Redbooks ..................................... 113
IBM Redbooks fax order form . . . .....................................114
Abbreviations and acronyms ................................... 115
Index ...................................................... 117
IBM Redbooks review......................................... 121
© Copyright IBM Corp. 2000 vii
Figures
1. RRSFoverview .................................................4
2. DB2externalsecurity(RACF)overview...............................6
3. RACFoverview ................................................12
4. SeamlessaccesstoOS/390resourcesusingdigitalcertificates...........12
5. Overviewoftheself-registrationprocess.............................13
6. DCE-RACF interoperation ........................................14
7. Usage of VPN technology ........................................15
8. Overview of the OS/390 LDAP Server and supported back-end systems . . . . 16
9. KerberosimplementationonOS/390................................17
10. OCSF-OCEPinfrastructureoverview...............................18
11. InformationflowforRACF........................................21
12. AuthorizationflowforRACF.......................................23
13. Database structure for RACF......................................28
14. CommandsforRACF............................................30
15. RACFexits....................................................31
16. CA-Top Secret access checking sequences ..........................34
17. Sample migration project organization...............................42
18. Project planning phase items ......................................45
19. SampleRACFgroupstructure.....................................47
20. Security Database Conversion Process. . . ...........................53
21. RACFprimaryandbackupdatasets................................89
viii CA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 ix
Tables
1. Schedulinggraph...............................................49
2. ACIDsConversionTable.........................................52
3. USERACIDparameterconversion.................................58
4. User administration responsibilities .................................60
5. Accesslevelconversion..........................................66
6. ResourcerulesandRACFequivalents ..............................72
7. System-wideoptionscommontoCA-TopSecretandRACF..............80
8. RACFcommandstoadd,modify,deleteandlistresources ..............84
xCA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 xi
Preface
CA-Top Secret and the OS/390 Security Server are both sophisticated products.
In some areas their designs are similar, and in other areas the designs are very
different. Planning a migration from CA-Top Secret to the RACF element of the
OS/390 Security Server, without unduly disrupting an OS/390 production
environment, requires considerable planning and understanding. With proper
planning, and perhaps with specially skilled people to assist in certain areas, the
migration can usually be accomplished in an orderly way.
Understanding the higher-level issues and differences between the two products
is an important starting point. This redbook is intended to assist in this area.
The team that wrote this redbook
This redbook was produced by a team of specialists from around the world
working at the International Technical Support Organization Poughkeepsie
Center.
Paul de Graaff, the project leader, is a Certified IT Specialist at the International
Technical Support Organization, Poughkeepsie Center. He writes extensively and
teaches IBM classes worldwide on all areas of S/390 Security. Before joining the
ITSO, Paul worked in IBM Global Services in the Netherlands as a Senior IT
Specialist.
Ted Anderson is a Senior IT Specialist with IBM's Software Migration Project Office
(SMPO). He is a previous redbook author with 19 years of large systems experience.
His areas of expertise include, but are not limited to, OS/390 systems programming,
RACF and RACF migrations, and numerous other OS/390 system software products.
He holds a BA degree in biology from Bethel College.
Julie Bergh is an IT Specialist currently with IBM's Software Migration Project Office
(SMPO) in North America. She has over 20 years of IT experience in MVS and
related areas. Her areas of expertise include, but are not limited to, OS/390 systems
programming, RACF and RACF migrations from competitive security software,
OS/390 system software products, business continuity planning, security
administration, applications programming, auditing, project management, and quality
assurance. Julie holds an external certification as a Certified Business Continuation
Professional (CBCP). She holds a bachelor of science degree in Management
Information Systems from the University of Wisconsin, Superior, and a masters
degree in Computer Resource Management from Webster University in St. Louis,
Missouri.
Peter Desforge is a Certified Senior IT Specialist currently working with the IBM
Software Migration Project Office - Security Team. He has over 18 years of IT
experience in a variety of areas, including system and application programming,
managing user support and security administration, project management, user
training and consulting. Since joining the SMPO in 1994, he has been involved in well
over 100 migrations to RACF from both CA-ACF2 and CA-Top Secret. He is also a
senior member of the team that is responsible for the design and development of the
IBM tools that convert CA-ACF2 and CA-Top Secret to RACF.
xii CA-Top Secret to OS/390 Security Server Migration Guide
Lynn Kearney is a Certified Senior IT Specialist currently working with the Software
Migration Project Office in Dallas, Tx. She has over 30 years of IT experience in a
variety of areas. She worked for 15 years in Poughkeepsie, NY in MVS development
doing testing, design, development, and running Early Support Programs. She
moved to Texas in 1982 where she supported an 11-state area with MVS and
security hotline calls and did ASKQ responses. While in the Area Systems Center,
she was a systems programmer, security administrator, security analyst, and
systems availability consultant. She did security audits for internal IBM sites and for
customers. Since joining the SMPO in 1993, she has been involved in over 100
migrations to RACF from both CA-ACF2 and CA-Top Secret.
Lori Halberts Kikuchi has worked for IBM for 17 years. Since the mid 1980s Lori
has specialized in the area of security. Currently, Lori is a Certified Sales Specialist in
IBM System 390 Software Sales in the Americas. Her main goal is to sell the IBM
SecureWay Security Server OS/390's RACF Element and RACF migration services
to competitively installed clients. Lori's other positions in IBM were retail banking
specialist, storage specialist, RACF Brand Manager, and manager of the SMPO
security team.
Tony Nix is a Certified Senior IT Specialist currently working with the Software
Migration Project Office in Costa Mesa, CA. He has 17 years of IT experience in a
variety of areas, including computer operations, systems and applications
programming, project management, line management, security administration,
training and consulting. As a member of the SMPO for nearly four years, Tony has
been involved in many diverse migrations. He holds an external CISSP certification
(Certified Information Systems Security Professional).
Mark Shell is an Advisory IT Specialist currently working with the Software
Migration Project Office from Dallas, TX. Mark was in the military for 9 years
before he began his computer industry career. He has 13 years of IT experience
in a variety of areas. Mark worked with the SMPO for four years as an external
customer converting multiple security databases before joining the SMPO team
over two years ago.
Thanks to the following people for their invaluable contributions to this project:
Kurt Meiser
ITSS International, Inc.
Kleber Candido de Melo
IBM Brazil
George Dawson
ISSC Australia
Bill Ogden
ITSS International, Inc.
Cees Kingma
IBM International Technical Support Organization
Gunnar Myhre
ITSS International, Inc.
xiii
Walt Farrell
IBM RACF Development
Rich Miles
IBM Software Migration Project Office
Terry Barthel, Alison Chandler, and Al Schwab
International Technical Support Organization, Poughkeepsie Center
A special thank you to Marilyn Thornton, manager of the RACF Software
Migration Project Office, without whose leadership and dedication this book
would not have been written. Marilyn's perspective on IBM's security has led to a
better environment for all RACF users.
Comments welcome
Your comments are important to us!
We want our Redbooks to be as helpful as possible. Please send us your
comments about this or other Redbooks in one of the following ways:
Fax the evaluation form found in “IBM Redbooks review” on page 121 to the
fax number shown on the form.
Use the online evaluation form found at ibm.com/redbooks
Send your comments in an Internet note to redbook@us.ibm.com
xiv CA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 1
Chapter 1. The value of SecureWay Security Server for OS/390
This chapter describes the advantages of using the OS/390 Security Server
versus competitive security software from Computer Associates. The value is
presented both from a functional point of view, component by component, to the
monetary savings of the OS/390 Security Server.
1.1 Overview of the Security Server
In 1996 the IBM corporation offered a newly packaged operating system for
mainframes, named OS/390. The base of OS/390 is the MVS operating system.
OS/390 integrates MVS in addition to about 30 other products, which are
pretested, integrated, and packaged together under the new name OS/390. This
integration, performed by IBM, is very beneficial to the users of OS/390 because
now only one product needs to be ordered: There is no need to test 30 separate
products each time an operating system upgrade is performed, and it even costs
less. Most of the products packaged in OS/390, like JES2 and VTAM, became
standard features of OS/390. Other products, like SecureWay Security Server for
OS/390 and DFSMS, became optional features of OS/390. Both standard and
optional features are packaged, tested and delivered with every license of
OS/390, but to use the optional features you must order the feature codes from
IBM and enable the features on your system.
When IBM moved from MVS to OS/390 there was a perception in the
marketplace that the name of RACF had been changed to SecureWay Security
Server for OS/390. Actually, SecureWay Security Server for OS/390 is more than
just a new name for IBM's RACF for MVS. IBM created a “security umbrella” as a
delivery vehicle for IBM OS/390 security-oriented software. RACF is but one of
the elements in the Security Server. In SecureWay Security Server for OS/390
2.10, there are six elements:
1. IBM RACF
2. OS/390 DCE Security Server
3. OS/390 Firewall Technologies
4. OS/390 LDAP Server
5. Network Authentication and Privacy Service (Kerberos)
6. Open Cryptographic Enhanced Plug-ins (OCEP)
IBM has positioned the SecureWay Security Server for OS/390 as the security
product that will deliver the support and exploitation of new technology inside the
glass house and in the e-business arena.
1.1.1 Business benefits of the Security Server
The job of your security product is to protect your information while allowing your
business to move ahead with new ventures and technologies. RACF is the leader
in this area. RACF integrates seamlessly upon availability of new versions and
releases of IBM subsystems (e.g., CICS, DB2) and technologies (e.g., Sysplex
Coupling Facility). This allows your business to move ahead with its objectives
and applications as quickly as you choose. Many non-RACF customers have
been held back for months by their current mainframe security product.
2CA-Top Secret to OS/390 Security Server Migration Guide
With the LDAP V3 Protocol Server, IBM continues this tradition outside of the
glass house. The SecureWay Security Server for OS/390 delivered the LDAP
Server as one of its elements before many companies even knew about the new
Lightweight Directory Access Protocol. Now those same companies are ready to
roll out applications and directories that will make use of the LDAP Server on
OS/390, and they can do that with the confidence of knowing that the server was
delivered as part of the SecureWay Security Server for OS/390 -- and it is ready
and waiting for them.
Now any authorized LDAP client throughout the enterprise can search, extract,
add and delete information from any OS/390 LDAP server (from the IBM brochure
Secureway Security Server for OS/390
, G221-4102-04). As of OS/390 2.7 it
became possible to extract information from the RACF database into an LDAP
directory. In OS/390 2.8 this support was enhanced to allow an authorized LDAP
client user in your enterprise to access the RACF database and use the functions
to add, delete and retrieve RACF user and group profile information. This ability
opens the door to many enterprise-wide uses based on RACF information.
The Firewall Technology element of the Security Server delivers a set of features
that can be used alone or with the Firewall Technologies that already ship in the
OS/390 Communications Server, a standard part of the OS/390 Operating
System. When used together, you have a full function OS/390 Firewall ready to
use. The Virtual Private Network (IPsec) support of the OS/390 Firewall is one of
the areas where it excels.
The RACF element of SecureWay Security Server for OS/390 2.4 first introduced
support for Digital Certificates and Public Key Infrastructure (PKI). In September
of 1999, SecureWay Security Server for OS/390 2.8 greatly enhanced that
support. Again, RACF has new technology ready and waiting for you to move into
the world of e-business. The following is a high-level list of the supported
technology features:
Digital Certificate Authentication providing integration between PKI technology
and traditional RACF Authentication
Certificate mapped to RACF userid, to provide seamless access to OS/390
resources
User self-registration of digital certificates
Processing of Certificate Revocation Lists by the IBM HTTP Server for OS/390
RACF can generate digital certificates
Chapter 1. The value of SecureWay Security Server for OS/390 3
1.1.2 Financial benefits of the Security Server
This section details the monetary savings of using the OS/390 Security Server.
1.1.2.1 Identifying monetary savings based on product price
The five elements are delivered for virtually the same price as RACF alone. This
is great news for RACF users!Non-RACF users who want to use any of these
exclusive features will have to license the Security Server to use any of the
elements other than the LDAP Server. Then, non-RACF businesses will be
paying for both Security Server and their non-RACF security package. New
releases become available every six months in conjunction with the OS/390
operating system.
If you are a Novell Directory Services (NDS) user, there is another benefit to
having the SecureWay Security Server for OS/390: Novell Network Services for
OS/390 incorporates Novell NDS Version 4 and comes free of charge when
customers license SecureWay Security Server for OS/390.
There are many scenarios where the value of the SecureWay Security Server for
OS/390 is evident, not the least of which is the scenario of upgrading CPUs.
IBM's pricing policies are flexible yet predictable. There are no surprises
regarding huge software upgrade bills.
1.1.2.2 Identifying productivity savings
The SecureWay Security Server for OS/390 is an optional feature of the OS/390
operating system. The benefit of being a feature of OS/390 is that the Security
Server is integrated and pretested with the OS/390 operating system. This
reduces the amount of testing that your systems staff devotes to your security
package. Most of our customers see a 40- to 120-hour time savings each time a
new release of the operating system or non-RACF mainframe security product is
installed. The savings to your systems programming organization will reflect
these savings (40-150 hours) multiple times per year.
1.2 RACF administrative highlights
This section highlights the administration of the RACF element of the OS/390
Security Server and some of the recent administration enhancements made to
RACF.
1.2.1 RACF administrative enhancements
It is beyond the scope of this document to try and communicate all of the product
benefits that the SecureWay Security Server for the OS/390 RACF element
(RACF) provides, so we limit this list to the new administrative features, the
exciting features that support the UNIX System Services “side” of OS/390, and
open computing.
Historically, RACF has brought out day-one support and exploitation of new
software and hardware technologies. This is beneficial to corporations who like to
be on the leading edge with new technology. For example, many customers with
RACF have enjoyed the benefits of having RACF make use of the Coupling
Facility since day one.
4CA-Top Secret to OS/390 Security Server Migration Guide
The RACF product performs extremely well. For detailed technical information
you can review the RACF Performance White Paper written by Mark Nelson of
RACF development and design (see
http://www.s390.ibm.com/products/racf/racfperf.html).
RACF's Remote Sharing Facility (RRSF) is an integrated feature of the RACF
element (RACF), which allows you to administer and synchronize multiple RACF
databases. RRSF is extremely granular which allows you to make the choices
that fit your business. For example, some or all commands and/or passwords can
be synchronized automatically or they can be specifically targeted to one or more
of the databases being managed. IBM has delivered this integrated feature with
the utmost of integrity by encrypting the transmission of data and by providing
automatic recovery if the transmission is interrupted.
Figure 1. RRSF overview
RACF provides four reporting options. The traditional RACF reporting features
are the Data Security Monitor (DSMON) and the RACF Report Writer. DSMON
delivers “canned” RACF database and OS/390 auditing reports. The RACF
Report Writer allows for ad hoc violation reporting. The Report Writer has been
stabilized, which means it will not report on some of the new functions that RACF
provides. This feature was not removed from RACF.
Both the Report Writer and DSMON are still supported and shipped with
SecureWay Security Server for OS/390's RACF element. A few years ago IBM
met customer requirements by adding two additional reporting options:
1. The RACF Database Unload feature
2. The SMF Unload feature
These features allow you to unload the RACF database and the violation records
from SMF into flat files. IBM ships a comprehensive set of DB2 based reporting
queries to meet your needs. In addition, you can use any SQL- based language
Node A
RACF
database
Session Node B
RACF
database
Password
changes
ADDGROUP
ADDSD
ADDUSER
ALTDSD
etc.
RACROUTE
RACDEF
RACXTRT
ICHEINTY
add
alter
delete
rename
Password
changes
ADDGROUP
ADDSD
ADDUSER
ALTDSD
etc.
Chapter 1. The value of SecureWay Security Server for OS/390 5
or product to create reports from the flat files. This method of reporting allows you
to combine data stores to create more informative trend analysis reports on a
user, system, or across platforms.
The RACF element delivered with version 2.8 includes an administrative
enhancement for reporting called RACFICE, which was formerly only available
via the Web. This feature includes over 30 sample reports, and it uses the
DFDSS ICETOOL report generator. This is very beneficial to organizations that
do not have DB2, and they can now easily make use of the database and SMF
Unload utilities without having to write their own queries. Additional reporting
options can be found in the IBM product Performance Reporter for OS/390.
Performance Reporter includes 11 canned reports for RACF in its extensive list of
performance-related reports.
The RACF Remove ID utility is a helpful new feature of RACF that greatly
enhances the productivity of security administrators. This utility allows the
administrator to search for an occurrence of a user ID or group. The results of the
returned search are a set of RACF commands to delete the user ID or group and
its related access permissions. The administrator can then mark the ones to
delete, as it may not be appropriate to delete all occurrences. The administrator
can then submit the results and the deletions will take place.
1.2.2 RACF/DB2 security administration overview
SecureWay Security Server for OS/390 2.4 introduced the RACF/DB2
administration feature with DB2 Version 5. This feature allows security
administrators to manage DB2 security administration via RACF. The RACF/DB2
external security module is shipped with the Security Server.
RACF and CA-Top Secret have Identification, Authentication and the use of
Secondary Authorization IDs in their base support -- this is not the issue. We are
comparing the RACF/DB2 external security module to the CA-Top Secret DB2
add-on product. Using either the CA add-on products or the RACF/DB2 feature
you can realize the benefits of moving your DB2 security administration function
out of DB2 and into your OS/390 security product. DB2 is an outstanding
database product, but its internal security structure does not provide the robust
level of security administration that most organizations desire. Figure 2 on page 6
shows an overview of DB2 external (RACF) security.
6CA-Top Secret to OS/390 Security Server Migration Guide
Figure 2. DB2 external security (RACF) overview
1.2.2.1 Benefits of using RACF to administer your DB2 security
The following benefits are gained when you use RACF for DB2 security:
Separation of duties
Single point of control for administration and auditing
Ability to define security rules before a DB2 object is created
Ability to allow security rules to persist when a DB2 object is dropped
Ability to protect multiple DB2 objects with one security rule
Eliminate the need to create multiple, and sometimes duplicate, security rules
Ability to use RACF generic profiles and/or Member/Grouping profiles
Eliminate DB2 cascading revoke
Flexibility for multiple DB2 subsystems:
– One set of RACF classes for multiple DB2 subsystems, or
One set of RACF classes for each DB2 subsystem
1.2.2.2 Migration issues: protection of DB2 resources via RACF
For organizations currently using the CA-Top Secret/DB2 product, the IBM SMPO
Security Team’s migration tools have built-in functions that can convert your DB2
add-on product data into the appropriate RACF commands to provide you with
equivalent function via the RACF/DB2 external security model.
For organizations currently using internal DB2 security administration, RACF will
allow you to phase in the RACF/DB2 function while you move from internal to
external DB2 security administration. Once you have begun protecting DB2
resources via the RACF external security module, the RACF/DB2 external
security module will look at the RACF profiles first. If there is not a RACF profile
to protect the DB2 object, then the RACF/DB2 external security module passes
RACF DatabaseDB2 Catalogs
DSNX@XAC
SecurityDB2 In-Storage
Profiles in
dataspaces
RACF
SYSIBM.SYSTABLES
SYSIBM.SYSDATABASE etc.
e.g. DSNADM, MDSNTB, etc
e.g. DSNADM1, MDSNTB1, etc
19 New Classes
FASTAUTH
DSNDXAPL
Chapter 1. The value of SecureWay Security Server for OS/390 7
control to DB2’s internal security authorization catalogs. This allows you to move
over to external security in a manner best suited for your organization.
1.2.2.3 Product benefits
Since the administrative function is included in RACF, there is no additional
maintenance that needs to be done. The CA solution is delivered in a separate
product, so there is an additional product to maintain, upgrade and test.
The external security module is shipped in the SAMPLIB member IRR@XACS. It
is coded and fully supported by the IBM RACF development team. This means
that you can call the IBM support center if you have any problems with this code,
and they will support you and accept APARs if it is determined that a problem
does exist.
The external security module is installed in DB2 at the Access Control
Authorization Exit point. This allows RACF and DB2 to make use of the standard
SAF interface, which eliminates the need install or modify any DB2 product code.
IBM’s implementation of the external security module provides any vendor the
ability to perform DB2 security administration within its product without the
requirement of modifying or overlaying DB2 code by simply using the industry
standard SAF interface.
The IBM RACF development team works in concert with the DB2 development
team to make sure that this module works and that it continues to work as each
product comes out with new releases and versions. As a user of this function, you
can feel confident that you will have day-one support of new releases and
versions.
1.2.2.4 Financial benefits
The RACF/DB2 external security module code is shipped with RACF for use with
DB2 V5 and higher at no additional cost. The competitive product, CA-Top
Secret/DB2, is sold as a separate product.
Identifying monetary savings based on product price
If you have already purchased this add-on product from CA then you will see an
annual savings equal to your current maintenance charges. Most contracts that
organizations have negotiated with CA do not have “out” clauses. Therefore, you
will probably not realize these savings until the end of the contract period.
If you are trying to cost justify the migration to RACF and currently have funds for
the CA DB2 add-on product allocated in your budget, then you can free up all
OTC funds and the annual maintenance fee. In most cases, the amount of money
that is saved can be used to cover the migration charges for the SMPOs Security
Migration Team to advise and assist you with your migration.
Don’t forget that these CA products will most likely be subject to upgrade charges
when your CPU is upgraded or a new CPU is purchased.
CA has purchased Platinum, the company that came out with the RC Secure
product. If you are currently using RC Secure, then you may also be able to
discontinue that product when you implement the RACF/DB2 function. Once your
contract has ended for RC Secure, you will also realize those savings.
8CA-Top Secret to OS/390 Security Server Migration Guide
Identifying productivity savings
The maintenance effort for RACF is easy to identify and quantify. It should take
your systems programmer less than an hour to initially get the RACF/DB2
external security module installed. Annually, this should require minimal
maintenance, if any at all. As of January 2000, our staff has spent less than 10
minutes over the past two years maintaining this module on our OS/390 system.
If you are currently using the CA DB2 add-on product, then you can easily
quantify the benefits of migrating to RACF. You will need to quantify the number
of hours the systems programming staff expends installing and maintaining this
product on an annual basis. Subtract one hour per year from that number and you
will arrive at the annual savings in hours that your organization should realize
after migrating to RACF.
1.3 RACF market penetration
RACF has been securing data in the MVS environment for 24 years. Most
companies chose their security products in the early eighties. The main choices
then, as now, are RACF from IBM and CA-ACF2 and CA-Top Secret. At that time
CA did not own the products. Most organizations chose CA-ACF2 or CA-Top
Secret over RACF, because at that time RACF was not an extremely robust
product.
Since the early to mid nineties organizations began taking a second look at
RACF. Often the initial reason to consider migrating was, and still is, a
dissatisfaction with their current vendor. Once these organizations began to
research the implications of migrating to RACF, they also saw that RACF had
become a robust product. It became very clear that IBM had committed itself to
making RACF the best security product on the MVS operating system.
In 1986 RACF had roughly a 28%market share in the United States. This is
based on the number of RACF licenses billing in MVS environments. RACF was
the number three product behind CA-ACF2 and CA-Top Secret.
In 1993 the penetration had grown to approximately 38%, and by 1998 the
penetration was 70%. The rise in market share in the United States had finally
caught up with the rest of the world, and as of 1998 the penetration rates are
based on the world-wide penetration of RACF on MVS and OS/390 systems.
As of the end of 1999, the RACF penetration rate has exceeded 70%.Some
machines have more than one security product running in separate LPARs.
Therefore, the marketplace actually exceeds 100%. We estimate that there is
probably a 110%penetrated market, meaning that RACF is licensed on over 70%
of MVS and OS/390 licenses. The remaining 40%or so of the market is shared
between CA-Top Secret and CA-ACF2.
Since so many migrations have taken place in just the past five years, CA may
still be receiving a revenue stream on unused licenses due to their practice of
long-term contracts. This could mean that internally they show a higher
penetration.
Many organizations are confused when we tell them that RACF has such a high
penetration rate, and that it is the top security product in the MVS and OS/390
arena. The reason for this confusion lies with understanding the basis for the
Chapter 1. The value of SecureWay Security Server for OS/390 9
penetration rates that are quoted by various vendors. Be sure to ask other
vendors how many operating systems and how many products are included in
their penetration number. Remember, IBM’s penetration rate only includes actual
revenue producing licenses only on the MVS and OS/390 operating systems.
10 CA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 11
Chapter 2. SecureWay Security Server for OS/390
This chapter gives a high-level overview of the SecureWay Security Server for
OS/390 and the security enhancements of the SecureWay Communication
Server for OS/390.
2.1 SecureWay branding
IBM SecureWay software provides integrated directory, connectivity, and security
between users and applications for e-business in a networked world. Every
e-business application requires the ability to: locate resources, such as people,
information and applications in the network;connect customers, partners, and
employees to those resources across multiple systems;address the concern
about how to secure communications, data, and transactions. SecureWay
integrates these infrastructure requirements to provide the secure network
platform needed for e-business. IBM SecureWay software is supported on
multiple platforms, including OS/390.
With Release 8, the eNetwork Communications Server for OS/390 has been
renamed SecureWay Communications Server for OS/390, and the OS/390
Security Server is renamed SecureWay Security Server for OS/390.
2.2 Introduction to the SecureWay Security Server for OS/390
Advances in the use of, and general familiarity with, small computers and data
processing have increased the need for data security. OS/390 incorporates the
SecureWay Security Server for OS/390, which provides a platform that gives you
solid security for your entire enterprise, including support for the latest
technologies. As a feature of OS/390, the SecureWay Security Server for OS/390
comes with the major components described in the following sections.
2.2.1 Resource Access Control Facility (RACF)
The primary component of the SecureWay Security Server for OS/390 is the
Resource Access Control Facility (RACF). RACF works closely with OS/390 to
protect its vital resources. Building from a strong security base provided by the
RACF component, the Security Server is able to incorporate additional
components that aid in securing your system as you make your business data
and applications accessible by your intranet, extranets, or the Internet.
Using an entity known as the RACF user ID, RACF can identify users requesting
access to the system. The RACF user password (or valid substitute, such as
RACF PassTicket or digital certificate) authenticates the RACF user ID. RACF
supports the user of PassTickets as other products use this to present a single
sign-on environment to end users at their workstations. Once a user is
authenticated, RACF and the resource managers control the interaction between
that user and the objects it tries to gain access to. Figure 3 on page 12 shows an
overview of RACF and its functions.
12 CA-Top Secret to OS/390 Security Server Migration Guide
Figure 3. RACF overview
Digital Certificates can be mapped to the RACF user ID to provide seamless
access to OS/390 resources, as shown in Figure 4.
Figure 4. Seamless access to OS/390 resources using digital certificates
Users can be enabled to self-register their digital certificates, as shown in Figure
5 on page 13, to ease the administration of digital certificates.
Audit reports
integrity reports
RACF
Security administration
(local or remote)
User identification,
and authentication
Security console
Violation reporting
Resource authorization
checking and system
access control
RACF database
Primary and backup
Local and remote sharing
RACF
Web
Browser
Business dat
IBM
HTTP Server
for OS/390
OS/390Firewall
OS/390
Security
Server
Web Pages
Certificate
Chapter 2. SecureWay Security Server for OS/390 13
Figure 5. Overview of the self-registration process
Certificate name filtering support was added to associate many certificates to a
single, shared RACF user ID without having to install each certificate into the
RACF database. Certificate filters substantially decrease the amount of database
storage and the system administration requirements associated with processing
large number of certificates.
With network authentication and privacy services support, it allows privacy
services principal and realm information to be stored and administered in a RACF
database.
RACF program control enhancement were created to provide better security and
integrity of OS/390 UNIX server and daemon programs. This is accomplished by
providing more control over the execution environment and preventing
uncontrolled programs from entering into a controlled environment. Environment
control is accomplished through a new services, IRRENS00, which marks an
environment as either controlled (clean) or uncontrolled (dirty).
Application identity mapping provides an improved method for associating
identities defined by OS/390 UNIX and Lotus Notes for OS/390.
2.2.2 The DCE Security Server
The DCE Security Server provides user and server authentication for applications
using the client-server communications technology contained in the Distributed
Computing Environment for OS/390. The DCE Security Server can also
interoperate with users and servers that make use of the Kerberos V5 technology
developed at the Massachusetts Institute of Technology and can provide
authentication based on Kerberos tickets.
Through integration with RACF, OS/390 DCE support allows RACF-authenticated
OS/390 users to access DCE-based resources and application servers without
RACF
Database
OS/390 WEBSERVER
RACF
USERID/PASSWORD
SSL V3
Webpage calls
the initACEE
callable service to
register certificate
14 CA-Top Secret to OS/390 Security Server Migration Guide
having to further authenticate themselves to DCE. In addition, DCE application
servers can, if needed, convert a DCE-authenticated user identity into a RACF
identity and then access OS/390 resources on behalf of that user, with full RACF
access control. Figure 6 shows an overview of the DCE and RACF interoperation.
Figure 6. DCE-RACF interoperation
2.2.3 OS/390 firewall technologies
Implemented partly in the Security Server and partly in the SecureWay
Communications Server for OS/390, OS/390 firewall technologies provide basic
firewall capabilities on the OS/390 platform to reduce or eliminate the need for
non-OS/390 platform firewalls in many customer installations.
The Communications Server provides the firewall functions of IP packet filtering,
IP security (VPN or tunnels), and Network Address Translation (NAT).
The Security Server provides the firewall functions of FTP proxy support, SOCKS
daemon support, logging, configuration, and administration.
OS/390 Firewall Technologies has support for On-Demand Dynamic Virtual
Private Networks (VPNs). On-Demand VPNs allow an outbound Security
Association (SA) to be set up automatically when the designated network traffic
requires that it be transmitted securely through a VPN. Figure 7 on page 15
shows the potential usage of VPN technology.
Registry server
Kerberos AS
Kerberos TGS
DCE PS
RPC
Registry
Database
Ticket Cache
RPC RPC
Logon Appl
DCE
end user
DCE security server
RACF
Database
MVS
subsystems
RACF
user ID
cross-linking
End user using
CICS, IMS, TSO....
OS/390 environment
Chapter 2. SecureWay Security Server for OS/390 15
Figure 7. Usage of VPN technology
2.2.4 The LDAP Server
The LDAP Server provides secure access from applications and systems on the
network to directory information held on OS/390 using the Lightweight Directory
Access Protocol (LDAP). A directory is typically employed to store information
used to locate computing resources, information about people in an enterprise, or
configuration information for systems and services.
RACF data presents a large set of user, group, and profile information that is
useful to applications in other environments or on other systems. This item makes
RACF information that is accessible through SAF interfaces available via an
OS/390 LDAP server to programs on and off the OS/390 platform. Figure 8 on
page 16 shows an overview of the OS/390 LDAP server and the back-end
systems it supports.
User ID and password authentication of LDAP client access to OS/390 LDAP
Directory Server can be optionally handled by Security Server RACF rather than
by accessing user IDs and passwords stored within the LDAP Server Directory.
Corporate
Intranet
Business
Partner/
Supplier
Intranet
Branch
Office
Intranet
Internet
Remote
Access
16 CA-Top Secret to OS/390 Security Server Migration Guide
Figure 8. Overview of the OS/390 LDAP Server and supported back-end systems
2.2.5 Network Authentication and Privacy Service (Kerberos)
This is a new component of the SecureWay Security Server for OS/390. It is an
implementation of MIT's Kerberos Version 5. It provides authentication,
delegation, and data confidentiality services which are interoperable with other
industry implementations based on the MIT Kerberos Version 5 reference
implementation.
The Network Authentication Server provides the basis of consistent user
identification and authentication in a heterogeneous networked environment
when combined with Kerberos-aware applications that can span OS/390 and
other platforms which support the MIT Version 5 Kerberos reference
implementation.
The security client locates the security server through one of three methods:
1. Using LDAP, when the LDAP server is specified in the Kerberos configuration
files.
2. Using the Domain Name Service (DNS), when DNS lookup is specified in the
Kerberos configuration files.
3. Using static information contained in the Kerberos configuration files, when
the LDAP or DNS server is not available or the target realm is not defined in
the directory.
Note 1: This is new function delivered as part of the Security Server, but is
shipped
always-enabled
, like the LDAP Server. This means that it does not
require a Security Server license in order to use it, but it does require that
some new functions and fields be implemented in RACF.
Note 2: Network Authentication and Privacy Service is a new implementation
of Kerberos and does not require DCE.
DB2 Database
OS/390
Image
slapd.conf schema
RACF Database
Unix Callable
Service
LDAP Protocol Handler
(Server)
Chapter 2. SecureWay Security Server for OS/390 17
Figure 9. Kerberos implementation on OS/390
Figure 9 shows an overview of the various Kerberos pieces:
1. Kerberos registry integrated into RACF registry
2. Kerberos KDC executes within OS/390 address space
3. OS/390 KDC behaves like any other Kerberos “realm”
4. Kerberos realm-to-reaIm function supported
2.2.6 OS/390 Open Cryptographic Services Facility (OCSF)
Cryptography comprehensively helps meet multiple security needs, such as
confidentiality, authentication and non-repudiation. Open Cryptographic Service
Facility (OCSF) for OS/390 addresses these requirements in the emerging
Internet, intranet, and extranet application domains. The primary application
interface to this function is provided by Open Cryptographic Enhanced Plug-ins
(OCEP), a component of Security Server.
OCEP functions are to be used by applications complying with Common Data
Security Architecture (CDSA) standard interfaces. This makes it easier for
application developers and independent software vendors (ISVs) to develop and
port applications to the S/390 platform. It also helps customers apply consistent
security rules to e-business applications that use digital certificates. Figure 10 on
page 18 shows an overview of the OCSF and OCEP.
Key
Distribution
Center
RACF
S/390 with OS/390
Ticket Granting
Server
Authentication
Server
Address Space
(AS)
Authenticates Users
Grants TGTs
(TGS)
Generates Session Keys
Grants service tickets based
on TGT
RFC 1510 => Kerberos V5
RFC 1964 => GSS-API
Standards
(new component, intergrated with RACF via SAF)
Kerberos
Registry
18 CA-Top Secret to OS/390 Security Server Migration Guide
Figure 10. OCSF -OCEP infrastructure overview
The optional PCI Cryptographic Coprocessor (PCICC) brings additional
cryptographic processing capacity and function to S/390 Parallel Enterprise G5
and G6 Servers. The PCICC feature is
integrated
into S/390 and OS/390. (Some
people mistakenly think it is an external box.)
PCICC works in conjunction with the CMOS Cryptographic Coprocessor that is
standard on those servers. PCICC is not a substitute for CMOS crypto
coprocessors and in fact
requires
that the CMOS crypto coprocessors be
enabled. Transparently to applications, OS/390 will route requests to the
appropriate crypto engines for processing. OS/390 V2 R9 is the minimum release
level required for PCICC support.
The SecureWay Security Server for OS/390 provides “one-stop shopping” for
security on OS/390. With its integration of RACF and DCE security, its
contribution to the OS/390 Firewall Technologies, the LDAP server, and RACF
support for client authentication via digital certificates, the Security Server
provides complete security both for traditional host-based data processing and
for safely expanding your enterprise onto the Internet.
OCEP Data
Library
Application Domains
Security Middleware
OCSF Framework
Service Providers
Applications
SSL Firewall
OCSF Security API
CSP
Manager
TP
Manager
CL
Manager
DL
Manager
SPI TPI CLI DLI
CSP
Providers
TP
Providers
CL
Providers
DL
Providers
RACF
OCEP Trust
Policy
OCEP Trust
Policy OCEP
Data Library
Chapter 3. RACF overview 19
Chapter 3. RACF overview
The Secureway Security Server for OS/390, also known as Resource Access
Control Facility (RACF), is an IBM program product designed to provide OS/390
and VM users with an effective tool for managing access control, an increasingly
important user responsibility and concern.
The objective of RACF access control is to protect data sets and other data
processing resources from unauthorized destruction, modification, or disclosure,
whether by accident or design. To be effective, security procedures should be
easy to use and place no additional burden upon data processing management.
RACF controls users and protects resources.
Users are identified by a
user ID
and authenticated by a
password
. A RACF user
is identified by an alphanumeric user ID. However, a RACF user does not have to
be an individual. For instance, a user ID can be associated with a started task
address space or a batch job.
Resources can be divided into two categories, data sets and general resources.
General resources include:
CICS/VS resources
DASD volumes
•DB2
IMS/VS resources
JES resources
•NODES
• Programs
Tape volumes
• Terminals
•VM
There are many other resources that can be protected. For a full list of resource
types (or resource classes), see
OS/390 Security Server (RACF) System
Programmer's Guide.
Before describing RACF resource definitions and resource access authorizations,
we will explain how RACF is started and its main components. It may prove very
useful when we discuss conversion problems from another security product.
RACF is started during system IPL. There is no specific command to start RACF.
So, there is no specific command to stop it.
At startup time, RACF requires the name of the data sets containing user and
resource definitions. Names can be provided either by a table (ICHRDSNT), or by
a DD statement in MSTRJCL. If MSTRJCL does not contain a proper DD
statement, and the name table is empty or contains invalid names, the operator is
prompted for the name of the RACF database.
20 CA-Top Secret to OS/390 Security Server Migration Guide
Some advantages and disadvantages of each of the three methods are:
• MSTRJCL
You can define only one RACF database (the primary database). No
secondary RACF database definition is allowed.
Operator reply
Very suitable for early tests, a conversion is an iterative process. Replying the
RACF database name at IPL time may provide flexibility to back out to a
previous iteration stage if errors are encountered and the current IPL is in
error.
ICHRDSNT (database name table)
Recommended for standard implementation. No reply is needed at IPL time.
Primary and secondary database names are allowed. The number of resident
data and index blocks in storage is also specified.
3.1 Information flow
For all resources, security is processed through the system as summarized in
Figure 11 on page 21. In this process, the components involved are listed in the
leftmost part of the figure. They are (top to bottom):
A subsystem (such as JES) or an application
The System Authorization Facility (SAF), which is part of OS/390
•RACF
The RACF database
The role of each component in the security process is discussed in later topics.
The information that is passed is discussed in the following sections.
Chapter 3. RACF overview 21
Figure 11. Information flow for RACF
The application directs a request to RACF. Depending on the type of request,
information is passed along with the request;for example:
Example 1
Request to RACF : Verify user identity
Information passed : USERID and PASSWORD
Example 2
Request to RACF : Check user access to a resource
Information passed : USERID
Resource name and type
User intent
The security interface formats the information gathered by the application to be
used by the security monitor (here RACF) and passes it to the System
Authorization Facility (SAF).
SAF determines what actions are required to process the request and may
forward the request to RACF if needed. If requested, RACF then performs the
check by verification against data retrieved from the RACF database. Although
Figure 1 may indicate an input operation is performed, RACF data is often
retrieved from areas in storage and no input operation takes place.
RACF always returns a return code as a response to a request. A reason code
may also be returned. For list-type requests, RACF also returns the requested
data.
F
I
L
E
S
R
A
C
F
OS/390
S
U
B
S
Y
S
T
E
M
A
P
P
L
I
C
A
T
I
O
N
Resource Manager
Security Interface
SAF
RACF
RACF DATABASE
o
r
22 CA-Top Secret to OS/390 Security Server Migration Guide
A return code of zero (0) indicates a valid request. A non-zero return code
indicates a request failure. This return code is passed to the resource manager
that issued the request. It is up to the resource manager to take appropriate
action.
The logical functions of each component are as follows:
Interface role
Receive and format information from the application.
Route information to the SAF facility.
Receive a return code from RACF and return it to the caller.
•SAFrole
Route the request to the security monitor.
Route the response to the proper requestor.
•RACFrole
Send back a return code and reason code as a response to a security
request.
Add, modify, or delete profiles in the database as required by RACF
commands executed by an authorized user.
Set global option values as directed by authorized users.
Return requested information from the database in response to a list-type
command.
3.1.1 Authorization flow
For all resources, security authorization is processed through the system as
summarized in Figure 2. For more information on authorization flow, see
OS/390
Security Server
(
RACF) Security Administrators Guide
.
Chapter 3. RACF overview 23
Figure 12. Authorization flow for RACF
3.2 Vocabulary
This section defines terms used in RACF.
3.2.1 RACF user
A RACF user is always defined as a member of a RACF group. This group is
called its
default group
. An entry in the RACF database describing a user is called
a
user profile
.
A user profile describes the user by name (user ID), password, default group, the
times that user can use the computing system, and statistics on a prior logon by
the user. It also describes other groups the user may belong to. A user must be a
member of at least one group (the default group), and potentially of other groups
(connect groups).
User profiles may also contain
user attributes
. These attributes describe the
privileges and restrictions that the user has when using the system. Attributes are
classified as either user-level or group-level attributes. When attributes are
assigned at the user level, the scope of the attributes are at the system level and
No
No entry or insufficient access
Match
No
No
No
Insufficient Access
STC?
GAC?
Sec Class?
Userid =
HLQ?
Userid in
Acc List?
Group in
Acc List?
UACC?
Privileged or Trusted?
Sufficient Access
Yes Grant
Access
No Match
Deny
Access
Insufficient Access
Insufficient Access
Insufficient Access
Out of OPERATIONS scope
No OPERATIONS attribute
OPERATIONS not allowed
Yes
Sufficient Access
Sufficient Access
Sufficient Access
ID(*)?
OPERATIONS?
No
Sufficient Access
Insufficient Access
Insufficient Access
I>A I<=A
24 CA-Top Secret to OS/390 Security Server Migration Guide
privileges granted are across the entire system. When attributes are assigned at
the group level, the corresponding privileges are restricted to a group or the
scope of the group in which attributes are assigned. Related product data may
also be recorded in user profiles. The set of data for a specific product is called a
segment
. At the user level, there may be segments for:
•CICS
• DCE
•DFP
•LANGUAGE
•LNOTES
• NDS
• NETVIEW
•OMVS
OPERPARMS (for MCS extended console sessions)
•OVM
•TSO
WORKATTR (for APPC/MVS processing)
For more information on each segment's content, see the corresponding topic in
this book, or in
OS/390 Security Server (RACF) Command Language Reference
.
The ability to define attributes at the system or group level is used to build the
correct administrative structure for RACF. The SPECIAL and AUDITOR attributes,
defined at the appropriate level, are used to achieve centralized or decentralized
security administration.
For conversion purposes, users are often classified as:
TSO users
STC (or started task users)
• Others
In the RACF database, there is no special definition for a TSO user, an STC user,
or other users. All are RACF users. The default group, attributes, and other values
in the profiles make the difference. It should be noted that a RACF user ID can
range from one to eight characters in length, but a RACF user ID used for TSO
LOGON must not be longer than seven characters.
3.2.2 RACF group
A RACF group consists of all the users that have similar requirements for access
to the system's resources. Each group, with the exception of the highest group
(SYS1), has a superior group. A RACF group is identified by its name. The name
of a group is one to eight alphameric characters, the first being alphabetic or
special characters.
An entry in the RACF database describing a group is called a
group profile
.A
group profile contains the group name, the superior group, the owner name (if not
Chapter 3. RACF overview 25
the superior group), a list of all RACF groups that have the described group as its
superior group, and a list of user IDs that are members of the group.
The
scope
of a group is confined to all resources and users within that group and
those of all groups that are subordinate to that group.
Related product data may also be recorded in group profiles. The set of data for a
specific product is called a
segment
. At the group level, there may be segments
for:
•DFP
•OMVS
•OVM
•TME
3.2.3 Owner
Each entry (or profile) in the RACF database has an
owner
. The owner must be a
RACF-defined USER or GROUP. For ease of administration, group ownership is
preferred. The RACF owner of a profile has full administrative authority over the
profile. If the profile is a user or a group profile that is in turn designated as the
owner of other profiles, the RACF owner of the top profile has full administrative
authority over the other profiles.
3.2.4 RACF protected resources
RACF resources are all the components of a computing complex required by a
job or a task. RACF resources include input/output devices, processing units,
data sets, job output, nodes, programs, and other items that must be kept secure
for normal business operations.
RACF protected resources can be divided into two categories:
Data sets
General resources
Both are described by
resource profiles
. RACF subdivides resource profiles into
two types: discrete profiles and generic profiles.
A
discrete profile
protects a single resource that has unique requirements. This
profile contains a description of the resource, including the authorized users, the
access authority of each user, and in the case of data sets, the volume of the data
set.
A
generic profile
protects several resources that have a similar naming structure
and security requirements. This profile contains a description of the resources,
including the authorized users and the access authority of each user. For more
information on discrete and generic profiles, see
OS/390 Security Server (RACF)
Security Administrator's Guide
.
26 CA-Top Secret to OS/390 Security Server Migration Guide
3.2.4.1 Data sets
Data-set resources include both DASD and tape data sets, and are described in
the RACF database using
data set profiles
. A data set profile contains information
about the data set profile owner, universal access, and other optional information,
such as the device volume serial number and data set security classification.
Before a data set profile can be created in the RACF database, a group profile or
user profile having the data set high-level qualifier (HLQ) as the group or user
name must be defined. This group or user is used in the RACF database as an
anchor point for all profiles having the same HLQ.
Therefore, protection for a data set always includes at least two entries (but
optionally more) in the RACF database:
A group profile or user profile (with same name as data set HLQ)
One or more data set profiles (either discrete or generic)
When a data set can be protected by several different profiles, RACF searches for
the best-fitting profile. The search is made from the most specific profile to the
least specific. Access is then granted or denied according to the security
classification associated with the data set and the user requesting access, the
access lists contained in the selected resource profile, and user attributes.
3.2.4.2 General resources
A
general resource
is any resource other than a data set. For example,
transactions, TSO logon procedures and job SYSOUT are general resources.
RACF defines the set of general resources in a Class Descriptor Table (CDT),
which identifies a RACF class of entities by the resource class name. This table
includes the resource class name, all syntax rules, and auditing and statistical
control.
A standard IBM-supplied CDT is installed with RACF at initialization time. You
can append your unique class names to the standard CDT to represent your
installation's requirements outside of those identified by RACF. For more
information on the Class Descriptor Table and on how to add new resource
classes, see
OS/390 Security Server (RACF) System Programming Library:
A conversion to RACF may require you to add installation-defined classes to the
standard CDT.
Protection of a general resource can be achieve through use of one or several
profiles, either specific or generic. Note that:
No anchor point is needed for general resource profiles (unlike data-set
profiles).
Authorization is the same as for data sets.
For most of the general resource classes, a relationship exists between a class
called a
member
class and another class called a
grouping
class.
The class TCICSTRN, for example, is a standard RACF resource class in which
one can create profiles to protect one or several similarly named CICS
transactions.
Chapter 3. RACF overview 27
For example:
A transaction named TRN1 can have a profile in the TCICTRN class with a
resource name of TRN1.
All transactions whose names begin with TRN can have a profile in the
TCICSTRN class with a resource name of TRN*.
But we may wish to define transactions TRN5, TRTA, and XYZas having the
same protection and authorization requirements.
We can then use the CICS grouping resource class name of GCICSTRN. Our
grouping transaction profile can then be defined in the GCICSTRN class with a
name of MYOWNAME and members TRN5, TRTA, and XYZ. This profile will then
control access to all the member transactions. MYOWNAME is an arbitrary
unique name within the GCICSTRN class. This name is assigned by the
installation to be a meaningful mnemonic. Grouping classes should be
considered when converting protection rules from another security system.
3.2.5 RACF system-wide options
RACF system-wide options are used to customize RACF for installation-specific
security. Mainly, these options deal with:
• Auditing
•Statistics
Activation of classes
Use of generics
In-storage profiles
JES job verification
Default JES user IDs
Data set protection and access
Password rules
• SECLABELS
Default language
Setting appropriate values for all general options in order to provide equivalent
RACF functions when converting from another security product is part of the
conversion project. When needed, changes to these values are mentioned in the
appropriate chapters. For a complete description of RACF options, see
OS/390
Security Server (RACF) Command Language Reference
and OS/390 Security
Server (
RACF) Security Administrator's Guide
.
3.2.6 The RACF database
There is only one RACF database, which holds the following:
System options
User profiles
Group profiles
Data set profiles
General resource profiles
28 CA-Top Secret to OS/390 Security Server Migration Guide
For performance purposes, this database can be broken into several files spread
across system DASD volumes.
For recovery purposes, this base can be
mirrored
onto another database. The
main database is referred to as the
primary database
. The mirror database is
referred to as the
secondary database
.
Modifications to the primary database are reflected in the secondary base at the
time they occur. RACF database definitions allow flexibility in the information to
be mirrored, providing the secondary database is online and active.
Figure 13. Database structure for RACF
3.2.7 RACF commands
RACF commands are TSO/E commands that may be executed either online from
a TSO terminal or as a part of a batch TMP job. RACF panels and REXX
procedures are both available in addition to the online commands.
In following chapters we will see that one of the main tasks in a conversion
process is the generation of many RACF commands. These typically will be used
as input to several batch TMP jobs to load the RACF database with security
information. Creation, review, edit, and execution of such files is an iterative
process during the conversion. Following is a brief review of the main commands:
Commands directed to user profiles:
ADDUSER (AU) Add User Profile
ALTUSER (ALU) AlterUserProfile
DELUSER (DU) Delete User Profile
LISTUSER (LU) List User Profile
PASSWORD (PW) Specify User Password
CONNECT (CO) Connect User to Group
Groups Users
Dataset
Resources General
Resources
RACF Database
Profile Nam e Owner Access List UACC
User and Group Entries
Chapter 3. RACF overview 29
REMOVE (RE) Remove User from Group
SEARCH (SR) Search for User Profiles
Commands directed to group profiles:
ADDGROUP (AG) Add Group Profile
ALTGROUP (ALG) Alter Group Profile
DELGROUP (DG) Delete Group Profile
LISTGRP (LG) List Group Profile
SEARCH (SR) Search for Group Profiles
Commands directed to data-set profiles:
ADDSD (AD) Add Data Set Profile
ALTDSD (ALD) Alter Data Set Profile
DELDSD (DD) Delete Data Set Profile
LISTDSD (LD) List Data Set Profile
PERMIT (PE) Maintain Data Set Access List
SEARCH (SR) Search for Data Set Profiles
Commands directed to general-resource profiles:
RDEFINE (RDEF) Define General Resource Profile
RALTER (RALT) Alter General Resource Profile
RDELETE (RDEL) Delete General Resource Profile
RLIST (RL) List General Resource Profile
PERMIT (PE) Maintain General Resource Access List
SEARCH (SR) Search for General Resource Profiles
Others (RRSF, System, etc..):
DISPLAY Display Sign-On-From List
HELP (H) Obtain RACF Help
RACDCERT RACF Digital Certificate
RACLINK Administer User ID Associations
RESTART Restart RRSF Functions
RVARY Change Status of RACF Database
SET Set RRSF Operational Characteristics
SETROPTS (SETR) Set RACF Options
SIGNOFF Sign Off Session
STOP Shutdown RRSF
TARGET Define RRSF Nodes
Figure 14 on page 30 shows an overview of all RACF commands.
30 CA-Top Secret to OS/390 Security Server Migration Guide
Figure 14. Commands for RACF
Complete details about each command can be found in
SecureWay Security
Server RACF Command Language Reference,
SC28-1919.
3.3 Interfaces
This section describes the interfaces to RACF.
3.3.1 Product interfaces
Products may or may not have security interfaces to RACF. RACF product or
application interfaces fall into three categories:
• Implicit
A product interface to RACF is
implicit
when no parameter value settings are
needed in the product to enable it to use RACF for security controls. For
example, products such as JES2 or TSO/E have implicit interfaces.
• Explicit
A product interface to RACF is
explicit
when parameter value settings are
needed in the product to enable it to use RACF for security controls. For
example, products such as CICS and IMS have explicit interfaces.
•ExitDriven
If neither an implicit nor an explicit interface to RACF exists for a product, the
installation can create the interface by using standard API. The security
requests are called from standard product exits. This approach can also be
used to create interfaces to RACF from within applications.
User:
ADDUSER
ALTUSER
DELUSER
PASSWORD
Group:
ADDGROUP
ALTGROUP
DELGROUP
Datasets:
ADDSD
ALTDSD
DELDSD
RACF
Database
General
Resources:
RDEFINE
RALTER
RDELETE
System:
DISPLAY
HELP
RVARY
SETROPTS
SIGNOFF
Lists:
LISTDSD
LISTGRP
LISTUSER
RLIST
RRSF:
RACLINK
RESTART
SET
STOP
TARGET
Permissions:
CONNECT
PERMIT
REMOVE
Digital Certificates:
RACDCERT
GENCERT
Chapter 3. RACF overview 31
One of the major problems in converting from another security system to a RACF
security system is the inventory of all interfaces used by the non-RACF security
product. We may discover that an exit interface has been used by the non-RACF
security product in order to bypass a standard implicit interface to RACF, or
parameter values to activate RACF from an explicit interface have not been set.
Re-establishing use of standard interfaces is one part of the conversion task.
3.3.2 The SAF interface
The System Authorization Facility (SAF) is a part of OS/390 and is always active.
Any security product can use the SAF interface. The main purpose of SAF is to
route requests from applications or subsystems to the proper security component
for processing. This routing uses the SAF Router Table. Depending on the type of
request SAF may, or may not, invoke RACF services.
For a description of SAF and how to add entries in the SAF Router Table, see
SecureWay Security Server RACF System Programmers Guide,
SC28-1913.
3.3.3 RACF exits
RACF provides exit points that can be used for additional levels of protection.
Figure 15 shows all the exits that RACF currently supports. Most installations will
not need to code these exits. Where possible, standard RACF functions should
be used.
The following section gives a brief description of some of the more common exits
and their possible uses. You can verify which exits are active by reviewing the
RACF DSMON report. Some exits can do both pre- and post-processing. Normal
RACF usage does not require the use of any exits. The exits provide interfaces
for changing normal RACF processing.
Figure 15. RACF exits
RACROUTE RACF
ICHRIX02
ICHRCX01
ICHRCX02
ICHRDX01
ICHRDX02
ICHRLX02
IC H RFX01
ICHRFX02
ICHCNX00
ICHCCX00
IC H PW X01
IC H DE X0 1
ICHRIX01
IC H RLX01
DATA CMDs
DG, DU, REM
PASSWORD
RACF
Manager
FRACHECK
RACLIST
RACDEF
RACHECK
RACINIT
VERIFY(X)
AUTH
DEFINE
LIST
FASTAUTH
VERIFY(X)
AUTH
DEFINE
LIST
FASTAUTH
DATA CMDs
DATA CMDs
DG, DU, REM
PASSWORD
RACINIT
RACHECK
RACDEF
RACLIST
FRACHECK
RACF
Manager
32 CA-Top Secret to OS/390 Security Server Migration Guide
3.3.3.1 Command exits - ICHCNX00/ICHCCX00
These exit routines allow the installation to associate additional security
checking, or processing, with certain RACF commands, or to bypass checking
altogether.
3.3.3.2 Authorization exits - ICHRCX01/ICHRCX02
The RACROUTE REQUEST=AUTH exits can alter the decision-making process that
determines if a user should have access to a resource.
3.3.3.3 Define exits - ICHRDX01/ICHRDX02
The RACROUTE REQUEST=DEFINE exits can alter the creation (or deletion) of profiles.
These might be used to enforce local standards.
3.3.3.4 Verify exits - ICHRIX01/ICHRIX02
The RACROUTE REQUEST=VERIFY(X) exits can alter the authentication processing for a
user.
3.3.3.5 Password encryption - ICHDEX01
This exit can be used to alter the form in which passwords are stored.
3.3.3.6 Password checking exit - ICHPWX01
This exit can be used to check for trivial passwords and enforce local password
rules in addition to normal RACF password rules.
3.3.3.7 Data set naming convention table - ICHNCV00
This table allows the installation to set up and enforce data set naming
conventions that are different from standard RACF naming conventions. For
example, you may need to perform RACF checking on the second-level qualifier
of a data set and not the first, which is the way RACF normally works.
© Copyright IBM Corp. 2000 33
Chapter 4. CA-Top Secret overview
This chapter briefly describes the Computer Associates CA-Top Secret security
product.
4.1 The CA-Top Secret security philosophy
The way CA-Top Secret protects data sets (and all other resources) is sometimes
referred to as “protection based on the user”. This means that, when deciding
whether a user can access a certain data set, CA-Top Secret starts with the user
ACessor ID (ACID is the ID assigned to users), and then checks for the
appropriate XA DATASET rules that are assigned specifically to that user.
By default, all resources (any component of the operating system required by a
task) are
not
protected on a system with CA-Top Secret installed and active. You
must set system-wide or resource-specific options to enable access to resources.
The four modes of operation in CA-Top Secret are:
DORMANT - CA-Top Secret is installed and is
not
actively validating
resources.
WARN - CA-Top Secret is active, and validating resources, but instead of
failing requests, it generates warning messages.
IMPL - CA-Top Secret is active, validating resources, and failing unauthorized
access requests. Undefined users can operate normally, but are restricted
from defined resources.
FAIL - CA-Top Secret is in full control of resources.
For example, for data sets, RACF has the PROTECTALL option with values of
FAILURES and WARNING. These values help map the CA-Top Secret MODE parameter
values (FAIL and WARN).
In CA-Top Secret, the data sets a user can access are determined by checking
the XA DATASET rules related to that user. These rules are found in both the
individual user ACID and any profile ACIDs the user belongs to.
There are three checking sequences, depending on which CA-Top Secret startup
option is used. If AUTH(OVERRIDE,ALLOVER) is used (the more common one), then
the checking sequence is:
1. Rules in the user ACID are checked. If a rule meets the criteria, no further
checking is performed.
2. Rules in any profiles assigned to the user are checked, and each profile is
checked in the order that it is listed in the user ACID. If a rule meets the
criteria, no further checking is performed. If multiple accesses for a resource
are located, access is granted/denied based on the access rule containing the
most specific match.
3. Rules in the ALL record are checked.
Another checking sequence used by CA-Top Secret is AUTH(OVERRIDE,MERGE).It
merges all the rules in the user profile and all profiles connected to the user, and
then chooses the most appropriate one. An access decision is not made until the
entire merged record is searched. If no match is found, the ALL record is
34 CA-Top Secret to OS/390 Security Server Migration Guide
searched. If a rule meets the criteria, no further checking is performed. If multiple
accesses for a resource are located, access is granted/denied based on the
access rule containing the most specific match.
Figure 16 shows these sequences.
Figure 16. CA-Top Secret access checking sequences
The following example shows a user's access to a resource in each of the AUTH
options:
•UserAcid
=
USER01
•Profiles=PROF01 and PROF02, and they are assigned to USER01 in that
order
USER01 contains the following resource definitions:
•XA DATASET - TECH.TEST.APPS01 - ACCESS = READ
•XA DATASET - TECH.*.APPS01.LOADLIB - ACCESS = UPDATE
PROF01
contains the following resource definition:
•XA DATASET - TECH.TEST - ACCESS = UPDATE
PROF02
contains the following resource definition:
•XA DATASET - TECH.*.APPS01.LOADLIB - ACCESS = NONE
The ALL Record contains the following resource definition:
•XA DATASET - TECH.TEST.APPS01.LOADLIB - ACCESS = EXECUTE
USER01 access level to dataset TECH.TEST.APPS01.LOADLIB in each of the three
different AUTH options would be determined from the following XA Dataset rules:
• Override/Allover:
•XA DATASET- TECH.*.APPS01.LOADLIB - ACCESS = UPDATE
Override/Allover M erge/Allover Merge/Allmerge
User Acid User Acid User Acid
Profile(s) Profile(s)
Profile(s) All Record
All Record
All Record
Chapter 4. CA-Top Secret overview 35
Reason - it was in the user's profile and had the most number of
characters.
• Merge/Allover:
•XA DATASET - TECH.*.APPS01.LOADLIB - ACCESS = NONE
Reason - it was one of the two rules that had the most number of
characters and it had an access level of NONE.
• Merge/Allmerge:
•XA DATASET - TECH.TEST.APPS01.LOADLIB - ACCESS = EXECUTE
Reason - the ALL Record is included in the merge and it had the most
number of characters.
The RACF security philosophy
The way RACF protects data sets (and all other resources) is sometimes referred
to as “protection based on the resource”. This means that, when deciding
whether a user can access a certain data set, RACF starts with the data set
profile, and then checks the access list of that profile for an appropriate
user
or
group
.
ACIDs fall into one of two categories:
1. Functional ACIDs used to perform specific tasks
User - This is the lowest level of ACID security in CA-Top Secret and is
used to define a person who can logon on to a system. User ACIDs are
converted to RACF users.
Profile - This is an ACID containing a collection of access characteristics.
This ACID cannot sign on. Profile ACIDs are converted to a RACF group
that is owned by the equivalent of a CA-Top Secret division or department.
Group - This ACID contains a collection of users who can share access
authorities for protected resources.
Control - This ACID is used to define security administrators.
2. Organizational ACIDs used to construct the security database hierarchy
Department - This is an ACID definition in CA-Top Secret describing where
a user usually works. Each User ACID needs to be associated with a
department. Department ACIDs are converted to a RACF group that is
owned by the equivalent of a CA-Top Secret division.
Division - This is an ACID used to define corporate hierarchy in a
companys corporate security structure. Division ACIDs are converted to a
RACF group.
Zone - This is an ACID used to group two or more divisions.
CA-Top Secret profiles become what the
SecureWay Security RACF Security
Administrator's Guide
refers to as “functional groups”. Both products use this
concept in the same way. Typically, all resources needed to perform a particular
function are permitted to the same CA-Top Secret profile (or RACF functional
group), rather than to each individual user performing that function. Each product
has a way of associating the right users with the right CA-Top Secret profiles or
RACF functional groups.
36 CA-Top Secret to OS/390 Security Server Migration Guide
In RACF, functional groups usually do not “own” any users;that is, no users have
these groups as their default group. Users instead are connected to these groups
in order to access the resources that these functional groups are permitted to
use.
The term
profile
has a different meaning in RACF than the CA-Top Secret
definition given above. Refer to the
SecureWay Security Server RACF Security
Administrator's Guide,
SC28-1915, for the precise definition of the term as used
by RACF.
CA-Top Secret is started as a task by a START command, and executes in its own
address space. CA-Top Secret execution is stopped by entering a STOP (P)
command (with the proper procedure name) on an OS/390 operator console.
All CA-Top Secret data is stored in the CA-Top Secret security file in an encrypted
format.
4.2 The CA-Top Secret environment
The following sections describe the CA-Top Secret environment and staffing.
4.2.1 The ALL record
There are times in CA-Top Secret when a user tries to access a data set, and
there is no appropriate XA DATASET rule in either the user ACID or any of the
profile ACIDs. For those situations, the ALL record is used by CA-Top Secret
(when the OVERRIDE,ALLOVER optioninCA-TopSecretisineffect).
This record is a list of resource rules (data set and others) similar to a profile,
except it is always the last place CA-Top Secret looks for a resource rule to check
against. If an appropriate rule cannot be found in the ALL record, then access to
the resource depends on the overall security mode that CA-Top Secret is in (WARN,
IMPLEMENT, and so on).
The functions of the ALL record in CA-Top Secret are handled by the UACC
(universal access authority) in RACF. The UACCs are not stored in one central
RACF list, but are defined separately for each RACF profile.
4.2.2 Personnel
CA-Top Secret security administrators are needed to obtain information on how
CA-Top Secret is implemented in the installation. The following describes the
personnel involved in the security administration in CA-Top Secret.
The CA-Top Secret administrative hierarchy
The CA-Top Secret administrative hierarchy has the following levels:
Master Security Control ACID (MSCA) is converted to RACF System-Special.
Central Security Control ACID (SCA) is converted to RACF System-Special.
Limit Central Security Control ACID (LSCA) is converted to RACF
Group-Special.
Zone Control ACID (ZCA) is converted to RACF Group-Special.
Divisional Control ACID (VCA) is converted to RACF Group-Special.
Departmental Control ACID (DCA)- is converted to RACF Group-Special.
Chapter 4. CA-Top Secret overview 37
CA-Top Secret security officer
The security officer with the MSCA or SCA attribute will be able to give you most
of the information you need to convert the CA-Top Secret database into RACF
commands.
CA-Top Secret security auditor
The security auditor has the same duties in both the CA-Top Secret and RACF
environments. The CA-Top Secret security auditor can give you information on
CA-Top Secret database contents, and on the reporting and auditing level
needed.
OS/390 systems programmers
These programmers will be responsible for all OS/390/JES/TSO exits and user
modifications. They are needed for maintaining libraries, modules, procedures,
and parameters.
Product systems programmers
These programmers will be responsible for converting and updating all product
interfaces to RACF.
CA-Top Secret has control options to define the security environment. These
options are defined in the CA-Top Secret parameter file. Some examples include
password definition, mode, tape dataset security, facility, and violation logging.
4.2.3 Resource rules
Securing resources in CA-Top Secret is a two-step process.
1. Once the resource has been defined, it needs to be owned by an individual
user ACID or a department ACID.
2. Once the resource has been owned, it can then be permitted to additional
users if needed.
In CA-Top Secret, a resource protection definition is called a
resource rule
.Some
examples of resource rules are:
XA Dataset for dataset protection
XA Facility for application protection
XA terminal for terminal protection
XA otran for transaction protection
CA-Top Secret access authority is defined as follows:
ALL - converts to RACF equivalent of ALTER
SCRATCH converts to the RACF equivalent of ALTER.
CREATE converts to the RACF equivalent of ALTER.
CONTROL converts to the RACF equivalent of CONTROL.
WRITE converts to the RACF equivalent of UPDATE.
UPDATE converts to the RACF equivalent of UPDATE.
READ converts to the RACF equivalent of READ.
FETCH converts to the RACF equivalent of EXECUTE.
38 CA-Top Secret to OS/390 Security Server Migration Guide
Some XA DATASET rules also have a FACILITY subparameter. A FACILITY is a
way of grouping options and associating them with a particular service that users
sign on to. Some facilities supported are CICS, TSO, BATCH, and STC. In
CA-Top Secret, you can restrict access to a data set to certain applications by
using the FACILITY subparameter. Mapping which applications are defined to
each FACILITY is a user-controlled option.
4.2.4 CA-Top Secret database files
The files used by CA-Top Secret to secure an environment are:
Security File - an encrypted file that contains the security records of all user
and resource permissions and restrictions
Parameter File - a file that contains and defines CA-Top Secret control options
used at initialization and sets up the operating environment
Audit/Tracking File - a file that contains security-related events such as
violations, job and session initiation, and resources accesses
Backup File - a file that contains the automatic daily backup of the Security
File
Recovery File - a file that contains recent administrative commands and can
be used in conjunction with the Backup File to restore a damaged Security
File.
4.3 CA-Top Secret subsystem interfaces
The interfaces discussed in this section provide CA-Top Secret access to OS/390
subsystems.
4.3.1 TSO
CA-Top Secret provides the ability to control access to TSO, commands, and
ISPF/PDF panels.
4.3.2 CICS
CA-Top Secret provides the ability to control access to CICS. Security access can
be implemented at a transaction level or resource level.
CA-Top Secret implements a sign-on interface for CICS to further control the
environment of the CICS user. The interface may include a new sign-on
transaction name and a different sign-on panel.
4.3.3 IMS
CA-Top Secret provides the ability to control access to IMS. Security access can
be implemented at a transaction level or resource level.
4.3.4 DB2
CA-Top Secret provides the ability to control access to DB2. When CA-Top
Security for DB2 is installed, native DB2 security is disabled. DB2 also provides a
separate subsystem in the product for security.
© Copyright IBM Corp. 2000 39
Chapter 5. RACF migration project overview
This chapter is intended as a project management guide for a CA-Top Secret to
RACF conversion. It was written to give you a starting point from which to create
a security migration project plan that is appropriate for your environment.
The information presented here was gathered from several CA-Top Secret to
RACF conversions. The project examples represent a typical, generic migration
project converting only one CA-Top Secret database to RACF, with expected
completion within three to six months. The actual time it will take you to complete
your migration will probably differ, depending on the nature and complexity of
your project.
There is no guarantee that, for any particular conversion, the information
contained in this manual is either complete, accurate, or even appropriate. Any
individual security migration usually has tasks associated with it that are unique
and specific to that particular migration. However, there are also many tasks that
are common to all security migrations. The purpose of this document is to
describe those tasks, and let you decide whether the task is appropriate for your
particular migration.
Some of the tasks in a security migration project involve determining how other
products, such as CICS, IMS and DB2, interface with RACF or CA-Top Secret.
Whenever those tasks are discussed in this book, you are usually referred to the
documentation of the other product. It would be difficult, if not impossible, to
accurately maintain that kind of information in a manual of this type. Instead, this
book concentrates on providing information not readily found in other sources,
such as creating a security migration plan and giving you some practical
guidelines for converting your CA-Top Secret database to an equivalent RACF
database.
This chapter describes how to prepare for the migration project, build the project
plan, and schedule the necessary resources. The need for assessing the current
environment and suggested personnel skills are also discussed.
5.1 Preparing for the migration project plan
In order to build a good plan, you will have to review your CA-Top Secret
database and supporting system environment for any security-related impacts.
What you find will determine the number and types of people you need to find for
the migration team. In addition, you must consider what type of education is
needed, who would need it, and when it should be completed.
Your overall goal is to build as complete a migration plan as possible, using
information from this book or other sources. The plan should identify all required
tasks, who will do them, and when the tasks should be completed.
40 CA-Top Secret to OS/390 Security Server Migration Guide
5.1.1 Review the current CA-Top Secret environment
The first step is to look at what security functions are implemented using the
CA-Top Secret database. You will also need to decide how to convert the CA-Top
Secret database, determine any impacts on the supporting system environment,
and identify applications with security interfaces.
5.1.1.1 Assess the current CA-Top Secret database
Some features in CA-Top Secret do not convert easily or on a one-to-one
correspondence to RACF. This is due to the fact that CA-Top Secret and RACF
are two separate, individual products.
Typically, this means you have to examine each vendor product (for example,
OEM) implemented in your environment and determine what has to be done, if
anything, for each product to work with RACF. In most cases, each vendor’s
product documentation will have published RACF installation instructions and
these should be reviewed. Identify all vendor product features you are using that
RACF does not have an equivalent function for, then determine alternative ways
of providing the same protection using RACF functions. Also, you have to check
your OS/390 base product code for any security-related usermods, accounting
exits, JES2 exits, and so forth.
As you assess the CA-Top Secret database and uncover potential issues, ask
whether a current business need still exists which caused the original
implementation of the security feature. If a need still exists, a solution should be
found for converting the feature to the RACF environment. Many solutions can be
found using either procedural controls or automated solutions.
5.1.1.2 Decide on how to convert the security database
You will have to create a RACF database that matches, as much as possible,
your CA-Top Secret database. As part of this task, you have to write or obtain
automated programs that can assist in converting the rules and parameters
contained in the CA-Top Secret database to the appropriate RACF commands.
You have several choices here:
You can buy or lease an existing product to assist with the migration.
You can write your own conversion routines.
You can “start from scratch”, that is, instead of converting your current CA-Top
Secret database, you build the RACF database with new definitions.
If you choose to convert your CA-Top Secret database, most likely you will have
to write or obtain automated programs that can assist in database conversion.
Typically, these programs or “tools” use the information in the CA-Top Secret
database to create RACF commands. When these RACF commands execute,
they load the appropriate security information into an empty RACF database.
Because of differences between the way CA-Top Secret and RACF protect
resources, any database conversion will probably not be completely transparent.
Therefore, it is very important that you ensure the RACF commands will
implement the same, or better, access control integrity than the CA-Top Secret
environment.
Chapter 5. RACF migration project overview 41
If you choose to write your own conversion programs, be aware that the programs
may take several months to write. Keep in mind that they need to be ready before
the start of unit testing. In addition, you should do several RACF database loads
during the development phase in order to ensure an adequate amount of testing.
If you choose to obtain the conversion programs from other sources, ensure that
you will be able to customize these programs to fit your individual needs.
Note: It is very important that you understand the amount of work involved in
converting your CA-Top Secret database. Several chapters of this book are
devoted to this topic. You should review them thoroughly before making your
decision.
5.1.1.3 Analyze the current system environment
You will need to complete a comprehensive, detailed review of any products,
programs, or interfaces that perform security functions. Depending on what is
being done, you may have to modify program code or write program code or exits
which would perform the function on behalf of a user’s request.
To analyze your current system environment, start by listing all hardware and
software products you have installed. Identify which ones have security
interfaces, or may otherwise be affected by this conversion. (This research is
similar to what you might do in preparation for a systems software upgrade, such
as a ServerPac installation.)
For each product that has a security interface, determine how RACF can provide
the same protection. Also determine the amount of work required to have the
product work with RACF, instead of CA-Top Secret.
5.1.1.4 Preparing the RACF test system
A test system, similar in size and nature to one that might be used for an OS/390
software upgrade, has to be available for the migration project.
You need the RACF test system on a “dedicated” basis for about two to three
months to complete this project in a timely and efficient manner. By a “dedicated”
test system, we mean one that is available during the normal working day so that
the project team can work on the environment during their normal day-to-day
work schedule.
Typical test system requirements include:
A SYSRES volume to install RACF
DASD space for the RACF database
DASD space for the applications to be tested under RACF
In some cases, because of system constraints, the only test system you can
dedicate to the project may not be large enough to handle the testing of more
than one application at a time. While this will allow you to do much RACF testing,
you will eventually have to test RACF using a second, more comprehensive test
system. You will probably not be able to dedicate this second test system to the
project.
You have to install RACF typically on a test system that is separate from the
CA-Top Secret production system. You will most likely not have to upgrade or
42 CA-Top Secret to OS/390 Security Server Migration Guide
install any product for the sole purpose of using RACF. However, some of the
advanced functions of RACF may work only with the higher release levels of
some products.
5.1.2 Personnel
A typical security migration project involves people with the following generic job
descriptions. Most people working on migrations usually perform multiple duties
throughout the project. As you determine which tasks need to be done, also
determine how many people are needed to perform the tasks, in order to ensure
a successful migration.
Figure 17 describes the organization that should be implemented prior to the
beginning of a migration.
Figure 17. Sample migration project organization
5.1.2.1 The security administrator
The security administrator is usually the most important and busiest person in a
security migration. This person is the focal point for all questions related to what
protection is currently in effect and why it was originally implemented. The
administrator also determines the methodology and customization of the
conversion programs that convert the CA-Top Secret database to RACF.
Frequently the administrator is also responsible for coordinating all testing,
updating all security procedures, and educating end users in RACF. Because of
the many responsibilities the administrator has regarding technical issues, this
person is usually too busy to be the project manager.
A key factor to the success of any migration project is having a security
administrator on the team who knows why past decisions were made and can
provide guidance on whether current business needs exist for carrying functions
into the RACF environment.
Chapter 5. RACF migration project overview 43
5.1.2.2 The project manager
The project manager is primarily responsible for creating the migration plan, with
the assistance of the migration team, and for monitoring the progress of the
project. Since the migration team usually consists of people from several
departments, the project manager has to make sure everyone is committed to
performing and completing the tasks he or she is responsible for throughout the
project. This person is responsible for acquiring any additional personnel or
systems support necessary to keep the project on schedule. The project manager
may also assist the security administrator in his tasks.
5.1.2.3 The conversion programmer
The conversion programmer is responsible for configuring the options of the
conversion programs. This programmer coordinates resolution of database
conversion issues and configures the conversion programs to properly represent
the desired RACF result.
5.1.2.4 The OS/390 systems programmer
The main responsibilities of the OS/390 systems programmer are to install and
customize RACF, to create and maintain the test system to be used throughout
the conversion, and to assist in the testing of RACF.
In some cases, the OS/390 systems programmer also installs and customizes the
companys use of vendor (OEM) program products which use security interfaces.
Vendor product documentation usually contains specific instructions on how to
set up their product to use RACF.
5.1.2.5 The online systems programmers
Online systems programmers are responsible for performing whatever work is
necessary so that their subsystems work properly when RACF is installed. This
typically means analyzing their current subsystem for interfaces to CA-Top
Secret, preparing the appropriate code and JCL to accomplish the same
protection under RACF, and assisting in the RACF testing. Some examples of
subsystems are TSO, IMS, CICS, DB2 or VTAM.
5.1.2.6 The application project leaders
Application project leaders are responsible for verifying that they are the true
owners of any resources (usually data sets) as identified through the CA-Top
Secret database, and ensuring adequate testing of their applications. During the
testing phase, they are responsible for determining that the security protection for
their resources under RACF is acceptable, and that their applications function as
well or better than they did with CA-Top Secret.
5.1.3 Education
You need to determine who must receive RACF education before the project
starts, when the education should be completed, and which classes should be
attended. This education could include formal IBM-taught classes, self-study
courses, or classes you may develop in-house for help desk or end-user training.
You should schedule and attend RACF education for performing day-to-day
administration prior to starting the migration project.
44 CA-Top Secret to OS/390 Security Server Migration Guide
5.2 Building the migration project plan
This task simply means documenting all the tasks that have been identified, who
is to do them, and when they are to be done. Once you have decided you
want
to
convert to RACF, you then have to determine what methodologies to use in
converting to RACF. You need to develop a detailed migration plan which
identifies the tasks to be performed, who are the most qualified to complete the
task, and a projected time frame. Remember to include items that are not pure
tasks, such as educational needs and test system availability.
To create accurate estimates for the work involved in some of the migration tasks,
analyze what it will take to complete that particular task. Remember, there can be
multiple items to perform in order to finished the project tasks. Ask the same
questions for any other significant software installed on the CA-Top Secret
system. Following is an example of a potential project task.
You, as project manager, review the list of software installed on your system and
see that CICS is one of the products installed. You ask the CICS systems
programmer the following questions:
1. Are there any “non-standard” uses of security that would interfere with a
migration to RACF?
2. How much work would be involved in converting the security for the CICS
regions to RACF?
If the answer to the first question is yes, then that is identified as a potential
migration issue. Also, the amount of overall work involved in converting CICS
security to RACF, and who will do that work, is identified in the plan. You will not
begin that work until you have determined that the issue identified in the first
question will not cause a delay in the overall project.
In all cases, determine whether a current business need exists for the project
task. If something was done in CA-Top Secret which does not need to be carried
forward into the RACF environment, then this item does not need to be
addressed.
Figure 18 on page 45 shows a typical migration project plan by phase lasting over
14 weeks. There are seven major phases to the migration project: assessment,
education, project planning, development, unit testing, integration testing and
production cutover.
Chapter 5. RACF migration project overview 45
Figure 18. Project planning phase items
5.2.1 Significant project tasks
The following project tasks will be involved.
5.2.1.1 Analyze the current security environment
Examine the security database and system environment to identify which
technical issues need to be addressed. This includes database features which do
not have a direct RACF functional equivalent and any system exits or product
interfaces which perform security functions. Review all issues against whether a
current business need exists.
5.2.1.2 Project management
Throughout the project, you have to monitor and adjust the plan you created at
the beginning of the project.
5.2.1.3 Planning
In this phase, a detailed project plan is developed for the remainder of the project.
It lists who is to be involved, what other resources are needed, all the security
interfaces currently in effect, and any issues that have to be resolved before
proceeding to the next phase. Typical significant checkpoints would be the initial
load of the RACF database, testing and migration cutover.
5.2.1.4 Identify project team
Identify the people who will complete the migration tasks identified in the project
plan.
5.2.1.5 Identify major concerns or system changes
Review all conditions or situations that were identified as potential migration
issues. Determine whether any of them are serious enough to warrant delaying
the project until the condition or situation in question is resolved. Also, make sure
Assessment
Education
Project
Planning
Development
Unit Testing
Integration
Testing
Production
Cutover
WK1 WK2 WK4 WK5 WK6 WK7 WK8 WK10WK11WK12
WK3 WK9 WK13WK14
46 CA-Top Secret to OS/390 Security Server Migration Guide
you coordinate with other projects in the company, such as software upgrades or
hardware installations, that could interfere with the schedule for this project.
You have to identify anything that could be interpreted as a significant technical
project issue. You need to identify any issue which would adversely affect the
project timeframe. You want to avoid putting a lot of effort into the migration if a
condition exists that will cause you to delay the project anyway. For example, if
the necessary test system is not going to be available for several months, there is
no need to have the online systems programmers preparing their products for
RACF.
In many cases, you will need the support and approval of the end-user community
before beginning this project. Often, the information from this phase is used to
help obtain that support and approval.
5.2.1.6 Install and customize RACF
You have to install RACF, typically on a test system apart from the production
system that contains CA-Top Secret. You also have to review the customizing
options available, and determine what would be appropriate for your environment.
5.2.1.7 Prepare the RACF test environment
In this phase, you prepare a RACF test environment that emulates the CA-Top
Secret environment. All the security interfaces that exist in the current system are
identified. Any code that has to be prepared to accomplish the same protection
under RACF is prepared in this step.
5.2.1.8 Install Conversion Programs
In this phase, install the conversion programs to be used to convert the CA-Top
Secret to RACF. These programs should be customized based on your specific
requirements.
5.2.1.9 Review naming conventions
Naming conventions are important, because high-level qualifiers of data sets play
a more important role in RACF than they do in CA-Top Secret. RACF assigns
ownership of data sets according to a high-level qualifier. Only one RACF group
can “own” a high-level qualifier at any one time. For example, CA-Top Secret
allows the use of generic characters for masking of high-level qualifiers, while
RACF does not.
5.2.1.10 Review security procedures
Identify all procedures that will change due to the migration to RACF. Typical
procedures of this type include how help-desk personnel are to change
passwords, or how operators and software automation products interact with
RACF and OS/390 operations.
5.2.1.11 RACF group structure planning
This is a very important part of the database conversion. You want to build a
RACF group structure which is manageable, well-designed, and meets your
specific needs. For example, there are certain CA-Top Secret logonid fields which
provide security administrative functions and the migration team needs to decide
how to provide similar functionality to the RACF community through centralized or
distributed security administration procedures. Figure 19 on page 47 shows a
sample RACF group structure.
Chapter 5. RACF migration project overview 47
Figure 19. Sample RACF group structure
5.2.1.12 Convert the security database
In this phase, you run your conversion programs to convert the CA-Top Secret
database to RACF commands. Through repetitive executions of the tool against
the CA-Top Secret database, you should be able to build a functionally equivalent
RACF database. Final testing should verify the integrity of the user ID and
resource profile definitions.
5.2.1.13 Testing
A typical RACF testing sequence, or “cycle”, might be:
Create a RACF database to match the CA-Top Secret database.
• IPLthetestsystemwithRACF.
Execute the test plans.
Review the results.
Make any corrections to the conversion programs.
Retest the system.
Several testing cycles are usually needed before your RACF environment is ready
for testing against the full production system. This usually takes several weeks of
effort.
Unit testing
Unit testing tasks concentrate on verifying the initial RACF database, system
environment and selected important applications. You identify any differences
between the old and new security environments, make any necessary
corrections, and retest until you’re satisfied.
48 CA-Top Secret to OS/390 Security Server Migration Guide
Integration testing
In this phase, you test your RACF environment against the full production system.
You also target major applications within the company to verify their current
functionality has not been adversely impacted. This is usually done on weekend
“graveyard” shifts. If there are no major problems during this phase, you are
ready to convert to RACF.
5.2.1.14 Develop a backout plan
It would be prudent to develop a backout plan in case you need to back out RACF
and return to the CA-Top Secret environment. The backout plan typically
identifies all exits and interfaces that were replaced, how to reinstall them if
necessary, and relinking to the CA-Top Secret databases. Each project team
member responsible for implementing changes for the RACF migration needs to
provide input into the overall backout plan.
Another option is to publish a set of items, or expectations, which would
potentially trigger a backout. Some examples include inadequate testing of
security functions and applications not converted to use RACF. These
expectations should be communicated to all affected users prior to the cutover
date.
5.2.1.15 Preserve the CA-Top Secret databases
Prior to the cutover date, make copies of the CA-Top Secret security databases.
Problem resolution will be critical during the days immediately following the
cutover, and access to the previous security environment could help resolve user
and system issues.
Once the migration to RACF has been completed, you may need to check user
access problems against what the access was in CA-Top Secret. Since you may
not have the ability to log on to CA-Top Secret, you must have the LIST(ACID)
reports for all ACIDs available, or any other report used to diagnose and solve
user access problems. These files and/or reports can be written to DASD files as
part of the cutover process for easy accessibility.
You could also migrate CA-Top Secret to your test environment concurrent with
the RACF production environment cutover. Then you could log on to CA-Top
Secret to quickly resolve problems.
5.2.1.16 Production Cutover
Before migrating RACF to production, you probably want to test RACF with the
full production system, similar to the way you might test an OS/390 software
upgrade before putting it into production.
Successful migrations freeze all changes to CA-Top Secret shortly before the
cutover weekend. The conversion tool is run one last time and a final RACF
database is built. All modified exits and interfaces are installed and passwords
are synchronized.
5.3 Resource scheduling
You need to decide how and when to allocate your project team skills across the
entire migration project. Table 1 on page 49 is a representative sample of the
Chapter 5. RACF migration project overview 49
typical resources needed by project phase and the level of effort required. Each
of the six project skills has responsibilities in each project phase.
In this table, the Full-time or Part-time designation represents the allocation of
time on the migration project
in relation to their overall job responsibilities
.For
example, if the teammate can work 20 hours per week on the migration project,
then a Full designation would mean 20 hours of migration level-of-effort.
Table 1. Scheduling graph
5.4 Summary
In summary, the success of the migration project will depend on the quality of the
project plan and the deployment of the right migration project team members with
the right skill level at the right time. Here are some additional considerations.
Management Involvement
You need strong management commitment to undertake a major migration of any
kind. Owners or managers of production applications, in particular, must be
involved in testing phases. This is an additional task for these people, and there
must be sufficient management commitment to force testing compliance on a
reasonable schedule.
Test System
It is not practical to run both CA-Top Secret and RACF on the same OS/390
system. Likewise, it is not practical to undertake a migration to RACF without
having a RACF system available for testing. In this case “testing” means a large
range of testing, and this is not practical on any production system. Therefore,
you need a RACF OS/390 system to use solely for test purposes.
In practice the test system is most likely to be a Logical Partition (LPAR) on a
larger processor. With some care, the test OS/390 can share DASD with your
production data, making testing much easier. Whether you clone your production
OS/390 (removing CA-Top Secret and installing RACF), or install a new OS/390
(with RACF already integrated) is your choice. In either case, systems
programming time is needed to install, make ready, and maintain the test OS/390
system.
Resource type
Assessment
Education
Planning
Development
Unit Testing
Integration Testing
Production Cut-over
Project manager Full Full Full Part Part Full Full
Security administrator Full Full Full Part Part Full Full
OS/390 systems programmer Full Full Part Full Part Full Full
Conversion programmer Full Full Part Full Part Part Part
Online systems programmer Full Part Part Full Part Full Full
Application project leaders Full Part Part Part Part Full Full
50 CA-Top Secret to OS/390 Security Server Migration Guide
Education
You can obtain a reasonable overview and understanding of RACF by reading the
RACF manuals. This is sufficient for many purposes. However, if you are the
project manager, or intend to be the primary RACF specialist in the organization,
you should arrange for formal RACF education.
Application Involvement
A major goal of the migration project is to avoid disruption of production
applications, and this can be accomplished only with sufficient testing. Major
applications can be complex, with many jobs, files, procedures, and programs
involved. Specific job and application knowledge is usually required to test these
applications, and this means involvement by the application groups. They must
help you test their applications in the new RACF environment.
Manpower and timing considerations
For a security subsystem to be effective, it must be very tightly tied into the heart
of the operating system. Given this, it is quite difficult to make a major change in
the security subsystem without impacting system production. A large, production
OS/390 installation has many complex jobs. Some of these are rarely used, such
as year-end jobs or obscure recovery jobs.
The bulk migration of basic CA-Top Secret user records and resource rule
records can be automated. However, testing the results of this conversion, and
discovering/migrating all the special cases that exist,
without disrupting
production
, is another matter altogether. Nevertheless, this is the requirement for
almost all CA-Top Secret to RACF migrations. It is these practical considerations
that dictate the timeframe and manpower needed for migration.
No single plan can apply to all situations. However, a timeframe of three to six
months, with one full-time person and several part-time people working on the
project, is typical.
© Copyright IBM Corp. 2000 51
Chapter 6. Database migration
This chapter describes the process of the actual database migration of CA-Top
Secret to IBM’s RACF. It provides guidance on how to convert a certain CA-Top
Secret function to the equivalent function in IBM’s RACF.
6.1 Conversion methodology
This section discusses some of the issues and approaches that can be used
when converting your CA-Top Secret database to RACF. Like CA-Top Secret,
RACF offers a number of ways of implementing security policies and procedures.
Experience has shown that some approaches work better than others. This
section provides a number of recommendations for designing and implementing a
conversion methodology from CA-Top Secret to RACF.
6.1.1 Migration considerations
The migration from CA-Top Secret to RACF involves more than a conversion of
database records. We must first note that this is an excellent time (just before
your migration) to review, rethink, and polish your security policy. A clear vision of
what you want to produce will help the migration work, and provide better results.
Some of the key elements to a migration are discussed in Chapter 5, “RACF
migration project overview” on page 39. Before you begin the conversion, you
must have a plan that includes:
Management involvement, signoff, support
•Testsystem
• Education
Application involvement
Manpower and timing
One of the lasting aphorisms of the data processing business is “Garbage In
-Garbage Out,” commonly known as GIGO. While it is a complex, one-time
activity, migrating a security database from one product to another is a data
processing function, especially when an automated tool is used to help perform
part of the work. A fairly clean input database at the beginning of the migration
will help produce a higher quality result. There is no magic in the migration
process or tools that will automatically clean up substantial problems in the initial
database.
Unless meticulously maintained, a security database tends to accumulate a
certain amount of unwanted or erroneous entries over time. There are a number
of causes: changing security administrators, changing philosophy of security
management, former users who still own resources, and so forth. You have
several choices for handling these problems:
Make a reasonable effort to clean up your original database, before starting
the migration process.
Migrate whatever is in your original database, and clean up the resulting
RACF database.
Ignore the problems, and accept whatever appears in the final RACF
database.
52 CA-Top Secret to OS/390 Security Server Migration Guide
The first choice is usually the best one. You understand your current CA-Top
Secret database, and have the skill to review it. While reviewing and correcting a
large security database is not an enjoyable task, it will certainly reduce future
problems. Some migration tools may help you clean up your current database;
see Appendix A, “IBM migration services” on page 95 for an example.
Schedule pressures may push you toward the second choice. The problem with
this approach, cleanup after migration, is that the migration process may amplify
the problems in the original database. The conversion of a CA-Top Secret
database to a RACF database is not a simple, one-to-one process. Small
anomalies in the input, easily corrected if someone would take the time to do it,
might create large unwanted structures in the output.
A pre-conversion review process should consider (and correct) obvious errors in
the database. It should also consider design and philosophical changes that will
produce a better database after migration. Again, small changes here may make
the migration much easier and produce a better result. Examples of such
changes are the elimination of FACILITIES that are not really needed or that are
outdated.
In practice, of course, you are likely to use all three choices: some clean up of the
original database, some clean up of the RACF database, and then go into
production with the resulting database.
6.2 Converting ACIDs
ACIDs in CA-Top Secret become the User IDs and groups that make up the RACF
security environment. The following table shows examples of ACIDs in CA-Top
Secret and their RACF equivalents.
Table 2. ACIDs Conversion Table
CA-Top Secret Terms RACF Equivalent
Zones GROUPs
Divisions GROUPs owned by Zone
Departments GROUPs owned by Division
Profiles GROUPs owned by a Division or Department
Users USERs
SCAs USERs with SPECIAL privilege
LSCAs USERs with some special privileges
VCAs USERs with group special privleges
DCAs USERs with group special privleges
ZCAs USERs with group special privileges
The ALL record UACC (universal access authority) or ID(*) rules
Chapter 6. Database migration 53
6.2.1 CA-Top Secret user/group migration issues
Migrating the basic user from CA-Top Secret to RACF isn’t necessarily a complex
task. What may become more complicated is the migration of some user privilege
attributes. Some of these privileges can be carried across into RACF, while there
are a few that will require careful planning and possibly an exit. We have tried to
keep this section focused on some fairly common areas.
The conversion process is shown pictorially in Figure 20.
Figure 20. Security Database Conversion Process
An essential piece of the conversion process is the selection of a RACF
administrative group structure. The structure is usually based on the CA-Top
Secret structure as shown in Figure 19 on page 47. The RACF structure should
allow for user administration and user access authorization.
The flow of ACID conversion may be:
1. Design and define a set of new naming standards for the RACF database.
2. Design and define the RACF group structure (see Chapter 5).
3. Run LIST commands against the CA-Top Secret database which lists all
ACIDs into a data set.
4. Use the output from the report as an input to the conversion process.
5. Output from the conversion process is a set of RACF commands written to a
data set. These commands define group profiles and user profiles, as well as
user-to-group connections.
6. Use the commands to load the new RACF database.
C
O
N
V
E
R
S
I
O
N
ADDGROUP
ADDUSER
ALTUSER
R
A
C
F
C
A
T
o
p
Resource
Descriptor
Table
Translation
Tables Conversion
Process
(New)
Standards
RACF
Command
File
CA-Top
Secret
Database
TSSPARM
S
e
c
r
e
t
RACF
Database
54 CA-Top Secret to OS/390 Security Server Migration Guide
6.2.2 Listing the CA-Top Secret ACIDs
The following CA-Top Secret commands can be used to generate reports that list
all ACIDs, as well as the resources each ACID can access:
Profiles:
Zones - TSS LIST(ACIDS) DATA(ALL) TYPE(ZONE)
Divisions - TSS LIST(ACIDS) DATA(ALL) TYPE(DIV)
Departments - TSS LIST(ACIDS) DATA(ALL) TYPE(DEPT)
Profiles - TSS LIST(ACIDS) DATA(ALL) TYPE(PROF)
Users - TSS LIST(ACIDS) DATA(ALL) TYPE(USER)
Security Administrators:
System - TSS LIST(ACIDS) DATA(ALL) TYPE(SCA)
Limited Scope - TSS LIST(ACIDS) DATA(ALL) TYPE(LSCA)
Division - TSS LIST(ACIDS) DATA(ALL) TYPE(VCA)
Department - TSS LIST(ACIDS) DATA(ALL) TYPE(DCA
Zone - TSS LIST(ACIDS) DATA(ALL) TYPE(ZCA)
The All Record - TSS LIST(ALL)
Typically, you would write these reports to DASD files, then process the
information in them using a conversion tool providing automated processing via
application programs or REXX execs.
6.2.3 Reviewing and defining ACIDs to RACF
For each CA-Top Secret ACID, we must determine:
What the equivalent RACF definition is
What appropriate RACF command to use when converting
The following commands are used to define the ACIDs to RACF.
CA-Top Secret Term RACF Equivalent
Zones ADDGROUP
Divisions ADDGROUP
Departments ADDGROUP
Profiles ADDGROUP
Users ADDUSER
SCAs ADDUSER
VCAs ADDUSER
DCAs ADDUSER
ZCAs ADDUSER
6.2.4 Converting zone, division and department ACIDs
As in CA-Top Secret, every user must initially “belong” somewhere. In CA-Top
Secret, they are usually defined to a department. In RACF, the CA-Top Secret
departments become what RACF refers to as "administrative groups". These
groups become the default groups when users are defined to RACF. Zone and
division ACIDs become the Group Tree structure which allows administrative
controls.
6.2.4.1 Listing zone, division and department ACIDs
The following example shows how to list the zone, division and department
ACIDs, along with the output generated by each list command:
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(ZONE)
Chapter 6. Database migration 55
Output:
ACCESSORID = ZONE1 NAME = ZONE ONE
TYPE = ZONE FACILITY = *NONE*
CREATED = 04/20/98 LAST MOD = 04/20/98
ACIDS = DIV1(V)
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(DIV)
Output:
ACCESSORID = DIV1 NAME = DIVISION ONE
TYPE = DIVISION FACILITY = *NONE*
CREATED = 04/20/92 LAST MOD = 04/20/92
ACIDS = DEPT1(D)
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(DEPT)
Output:
ACCESSORID = DEPT1 NAME = DEPARTMENT ONE
TYPE = DEPT FACILITY = *NONE*
DIV ACID = DIV1 DIVISION = DIVISION ONE
CREATED = 04/20/92 LAST MOD = 04/20/92
ACIDS = PROF1(P)
6.2.4.2 Defining zones, divisions and departments to RACF
To convert these ACIDs, we define them to RACF as GROUPs, using the ADDGROUP
command. ZONE1 becomes a group owned by SYS1 if ZONEs exist. If not, this
level is skipped. DIV1 becomes a group owned by SYS1 if no ZONEs exist, or by
ZONE1 if there are zones. DEPT1 becomes a group owned by DIV1:
ADDGROUP (ZONE1) SUPGROUP(SYS1) OWNER(SYS1)
ADDGROUP (DIV1) SUPGROUP(SYS1) OWNER(SYS1)
or ADDGROUP (DIV1) SUPGROUP(ZONE1) OWNER(ZONE1)
ADDGROUP (DEPT1) SUPGROUP(DIV1) OWNER(DIV1)
Note: CA-Top Secret allows you to define ACIDs starting with numerics, such as
DIV=123DIV. In RACF, a group must start with an alphabetic character. If you
have used this feature, the ACID names will need to be changed.
6.2.5 Converting profile ACIDs
Conversion of CA-Top Secret profiles is a little more complex due to the
differences in philosophy of the two products.
CA-Top Secret profiles become what RACF refers to as "functional groups".Both
products use this concept in the same way. Typically, all resources needed to
perform a particular function are permitted to the same CA-Top Secret profile (or
RACF functional group), rather than to each individual user performing that
function. Each product has a way of associating the right users with the right
CA-Top Secret profiles or RACF functional groups.
In CA-Top Secret, the
profile
consists of the resources common to a group of
users and is permitted to each user needing the resources. In RACF, the
functional group
is a list of users who will access the same set of resources.
Converting the resources in a CA-Top Secret profile to the RACF resource will be
covered in 6.3, “Converting data sets” on page 62. This section is concerned with
56 CA-Top Secret to OS/390 Security Server Migration Guide
converting the profile to a RACF group and ensuring the users who had the
profile are connected to the functional group.
In RACF, functional groups usually do not "own"any users;that is, no users have
these groups as their default group. Users instead are connected to these groups
in order to access the resources that these functional groups are permitted to
use.
The term
profile
has a different meaning in RACF than the CA-Top Secret
definition. The profile in RACF is simply a record in the database. You can have
group profiles, user profiles, data set profiles, etc. Refer to the
SecureWay
Security Server RACF Security Administrator's Guide
, SC28-1915 for the precise
definition of the term as used by RACF.
6.2.5.1 Listing profile ACIDs
The following example shows how to list the CA-Top Secret profile ACIDs, along
with an example of the output:
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(PROF)
Output:
ACCESSORID = PROF1 NAME = PROFILE ONE
TYPE = PROFILE FACILITY = *NONE*
DEPT ACID = DEPT1 DEPARTMENT = DEPARTMENT ONE
DIV ACID = DIV1 DIVISION = DIVISION ONE
CREATED = 04/20/98 LAST MOD = 04/20/98
XA DATASET = SYS1. OWNER(SYS1)
ACCESS = UPDATE
ACIDS = USER1 SCA1 (S) VCA1 (V) DCA1 (D)
ACCESSORID = PROF2 NAME = PROFILE TWO
TYPE = PROFILE FACILITY = *NONE*
DIV ACID = DIV2 DIVISION = DIVISION TWO
CREATED = 05/21/98 LAST MOD = 04/20/98
XA DATASET = SYS2. OWNER(SYS1)
ACCESS = READ
ACIDS = USER3
Chapter 6. Database migration 57
6.2.5.2 Defining profile to RACF
To convert the profile ACIDs, we define them to RACF as
groups
using the
ADDGROUP command. In the previous examples, PROF1 becomes a group owned
by DEPT1 and PROF2 becomes a group owned by DIV2:
ADDGROUP (PROF1) SUPGROUP(DEPT1) OWNER(DEPT1)
ADDGROUP (PROF2) SUPGROUP(DIV2 ) OWNER(DIV2 )
In addition, all resources that these CA-Top Secret profiles could access are
defined to RACF and the function group (e.g., PROF1) is permitted to the
resource definition. All users who were associated with these CA-Top Secret
profiles are connected to the corresponding RACF functional groups with the
CONNECT command:
CONNECT USER1 GROUP(PROF1) OWNER(PROF1)
CONNECT SCA1 GROUP(PROF1) OWNER(PROF1)
CONNECT VCA1 GROUP(PROF1) OWNER(PROF1)
CONNECT DCA1 GROUP(PROF1) OWNER(PROF1)
CONNECT $USER3 GROUP(PROF3) OWNER(PROF3)
6.2.6 Converting user ACIDs
You normally convert each CA-Top Secret User ACID to a RACF User ID.
6.2.6.1 Listing user ACIDs
The following example shows how to list user ACIDs, along with an example of
the output:
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(USER)
Output:
ACCESSORID = $USER3 NAME = AARON AARDVARK
TYPE = USER SIZE = 768 BYTES
DEPT ACID = DEPT1 DEPARTMENT = DEPARTMENT ONE
DIV ACID = DIV1 DIVISION = DIVISION ONE
ZONE ACID = ZONE1 ZONE = ZONE ONE
CREATED = 11/11/99 LAST MOD = 24/03/00 12:34
PROFILES = PROF1 PROF7
GROUPS = OMVSGRP
LAST USED = 25/03/00 13:26 CPU(CPU1) FAC(TSO ) COUNT(00645)
DFLTGRP = OMVSGRP
MYDEFINE = MYDATA
----------- SEGMENT CICS
OPIDENT = ABC
----------- SEGMENT OMVS
HOME = /
OMVSPGM = /bin/sh
UID = 0000009303
----------- SEGMENT TSO
TSOCOMMAND = LOGOFF
TSOLACCT = ACCT123
TSOLPROC = PROCSP
TSOLSIZE = 0000000
TSOOPT = NOMAIL,NONOTICES,NOOIDCARD
XA DATASET = SYS1. OWNER(SYS1)
ACCESS = UPDATE
INSTDATA = THIS IS AN EXAMPLE OF INSTALLATION DATA
58 CA-Top Secret to OS/390 Security Server Migration Guide
6.2.6.2 Defining users to RACF
The User ACIDs are defined to RACF as USERs using the ADDUSER command. The
default group is the division or department the user belonged to in CA-Top Secret.
Also, as described in 6.2.5, “Converting profile ACIDs” on page 55, if there were
any CA-Top Secret profiles listed in the ACID, the user will be connected to the
equivalent functional group in RACF using the CONNECT command. The TSO, CICS
and OMVS segments will be added to the userid as they are in CA-Top Secret.
Therefore, to define the user listed above to RACF, we would enter the following
commands:
ADDUSER $USER3 DFLTGRP(DEPT1) OWNER(DEPT1) NAME(‘AARON AARDVARK’) -
DATA(‘THIS IS AN EXAMPLE OF INSTALLATION DATA’) -
TSO(PROC(PROCSP) ACCTNUM(‘ACCT123’)COMMAND(LOGOFF)) -
CICS(OPIDENT(ABC)) -
OMVS(HOME(/) PROGRAM(‘/bin/sh’) UID(0000009303))
CONNECT $USER3 GROUP(PROF1)
NOTE: There are special considerations for OMVS segments;they are covered in
6.5.1, “OS/390 UNIX considerations” on page 78.
The following table lists some of the CA-Top Secret ACID and resource rules that
are subparameters of the RACF ADDUSER command. The RACF default group can
be either the DEPT or DIV ACID:
Table 3. USER ACID parameter conversion
6.2.7 Converting security administrator ACIDs
RACF privileges are easy to identify, understand, and administer, but they are not
as granular as CA-Top Secret privileges. Conversely, the CA-Top Secret
privileges allow more granular control of authority, but have more complex
interactions and may require more administrative effort. This section discusses the
privileges we consider most important for user conversion.
Security administrators are defined as users in RACF. In addition, they are given
the SPECIAL attribute, which denotes them as having the special privileges and
authority typically associated with security administrators. The functions the
administrator is required to perform will determine any additional required
parameters (e.g., CLAUTH if the user will have authority over selected userids.)
CA-Top Secret parameter ADDUSER subparameter
ACCESSORID =USER1 ADDUSER USER1
NAME =ARRON NAME(‘ARRON’)
INSTDATA =xxx DATA(xxx)
ATTRIBUTES =SUSPEND REVOKE
DEPT ACID =YYY DFLTGRP(YYY)
DFLTGRP =OMVSGRP DFLTGRP(OMVSGRP)
Segment OMVS OMVS(parameters)
Segment CICS CICS(parameters)
Segment TSO TSO(parameters)
Chapter 6. Database migration 59
6.2.7.1 Listing security administrator ACIDs
The following example shows how to list system, zone, division, and department
security administrators, with examples of the output:
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(SCA)
Output:
ACCESSORID = SCA1 NAME = MASTER SECURITY
TYPE = CENTRAL FACILITY = BATCH,STC,TSO
CREATED = 04/20/92 LAST MOD = 04/20/92
PROFILES = PROF1
ATTRIBUTES = CONSOLE
BYPASSING = NODSNCHK,NOVOLCHK
XA DATASET = SYS1. OWNER(SYS1)
ACCESS = UPDATE
----------- ADMINISTRATIVE AUTHORITIES
RESOURCE = INFO
LIST DATA = *ALL*,PROFILES
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(VCA)
Output:
ACCESSORID = VCA1 NAME = DIV SEC ADMIN
TYPE = DIV C/A FACILITY = BATCH,STC,TSO
DIV ACID = DIV1 DIVISION = DIVISION ONE
CREATED = 04/20/92 LAST MOD = 04/20/92
PROFILES = PROF1
ATTRIBUTES = CONSOLE
XA DATASET = SYS1. OWNER(SYS1)
ACCESS = ALL
----------- ADMINISTRATIVE AUTHORITIES
FACILITIES = *ALL*
MISC1 = SUSPEND
Command:
TSS LIST(ACIDS) DATA(ALL) TYPE(DCA)
Output:
ACCESSORID = DCA1 NAME = DEPT SEC ADMIN
TYPE = CENTRAL FACILITY = BATCH
DEPT ACID = DEPT1 DIVISION = DEPARTMENT ONE
DIV ACID = DIV1 DIVISION = DIVISION ONE
CREATED = 04/20/92 LAST MOD = 04/20/92
PROFILES = PROF1
XA DATASET = SYS1. OWNER(SYS1)
ACCESS = ALL
----------- ADMINISTRATIVE AUTHORITIES
ACID = *ALL*
ACCESS = NONE
6.2.7.2 Defining security administrators to RACF
The above ACIDs are defined to RACF as USERs. The SPECIAL attribute is used in
RACF to distinguish users who will be performing security administrator
functions. The SCA is the easiest because they convert to system SPECIAL which
allows full administration of the RACF database. ZCA, LSCA, VCA and DCA users
have restricted privilege and will be given a Group-SPECIAL attribute in RACF.
Users who have the Group-SPECIAL attribute are restricted to only the RACF
profiles that are within the scope of their groups.
60 CA-Top Secret to OS/390 Security Server Migration Guide
There is a slight distinction between the way you add a user with the system
SPECIAL attribute, and the way you add a user with the Group-SPECIAL attribute. In
the following example, SCA1 is a user with system SPECIAL authority, and VCA1
and DCA1 are users with Group-SPECIAL authority:
ADDUSER SCA1 DFLTGRP(SYS1) SPECIAL
ADDUSER VCA1 DFLTGRP(DIV1) CLAUTH(USER)
CONNECT VCA1 GROUP(DIV1) SPECIAL
ADDUSER DCA1 DFLTGRP(DEPT1)
CONNECT DCA1 GROUP(DEPT1) SPECIAL
Security administrators perform the same basic functions in both products.
However, the way each product defines those functions, in terms of resource
rules and privileges, is completely different.
You should not attempt to map the attributes associated with the CA-Top Secret
security administrators on a 1-to-1 basis to RACF. Instead, you have to
understand what privileges you can assign to RACF security administrators, and
what RACF commands are available to do that. The information you need to do
this is in the
SecureWay Security Server RACF Security Administrators Guide,
SC28-1915. Table 4 lists some of the RACF translations for the CA-Top Secret
privileges that can be scoped.
Table 4. User administration responsibilities
6.2.8 Password
For conversion purposes, you must decide if you want to keep the same
password across the conversion or if you want to change passwords for all the
users. Usually, keeping the password as a non-expired password is the preferred
option.
CA-Top Secret user passwords are stored in the CA-Top Secret database.
Whether you can see the password or not is dependent on the setting in TSSPARM
of the PWVIEW option. To keep the passwords, set PWVIEW=YES at some time before
the conversion so the passwords will be available.
CA-Top Secret RACF
MSCA, SCA System SPECIAL
ZCA, VCA, DCA w/ full user responsibility Group-SPECIAL w/ CLAUTH(USER)
Password only across the system FACILITY IRR.PASSWORD.RESET access
Data set Rules responsibility Group-SPECIAL to data set groups
Segment responsibility FIELD level access to the required
segments
Chapter 6. Database migration 61
6.2.8.1 Listing passwords
The following example shows how to list the users’ passwords, with examples of
the output:
Command:
TSS LIST(ACIDS) DATA(PW) TYPE(USERS)
Output:
ACCESSORID = USER1 NAME = AARDVARK, AARON
PASSWORD = PASSW1 EXPIRES = 03/14/00 INTERVAL = 060
ACCESSORID = USER2 NAME = BOOP, BETTY
PASSWORD = PASSW2 EXPIRES = 04/28/00 INTERVAL = 060
ACCESSORID = USER3 NAME = CECIL,BEANY ANN
PASSWORD = PASSW3 EXPIRES = 03/20/00 INTERVAL = 030
ACCESSORID = USER4 NAME = SPECIAL ACID
PASSWORD = *NOPW*
ACCESSORID = USER5 NAME = NOINTERVAL ACID
PASSWORD = PASSW5
6.2.8.2 Defining passwords to RACF
Some of the users in CA-Top Secret may not have a password as shown in the
listing above by USER5. As of RACF 2.8, users with no password can be set as
protected user IDs by:
ADDUSER userid DFLTGRP(group) ... NOOIDCARD NOPASSWORD
If you are converting to an older level of RACF, you will need to define a
password for all users. By default, the password will be the same as the default
group name. If this is unacceptable, you must issue an ALTUSER PASSWORD
command similar to the one shown below to provide a password of your choice.
For each user with a password, you can issue the ALTUSER PASSWORD NOEXPIRE
command from a systems level SPECIAL userid to set the password and have it not
expire.
ALU USER1 PASSWORD(PASSW1) NOEXPIRE
6.2.8.3 Defining password interval
Some users are not required to change their password and some may be
required to change their password on a frequency different than the system
default. From the listing of the passwords shown above, you can determine the
password interval for each user. Use the PASSWORD INTERVAL command to set the
interval for each user. The samples below show how to set an interval of 60 days
for a specific user and how to set a user so that they are not required to change
their password. Password intervals must be set equal to or less than the system
default interval defined in the Systems Options (SETROPTS)
PASSWORD USER5 NOINTERVAL
PASSWORD USER3 INTERVAL(30)
62 CA-Top Secret to OS/390 Security Server Migration Guide
6.2.9 Other CA-Top Secret user ACID parameters
The previous conversion methodologies for fields within the CA-Top Secret user
ACID are some of the major methodologies one needs to consider for each of the
fields in use in the CA-Top Secret database. Additional information that is needed
from the User ACID records will need a conversion methodology designed to
convert those fields and user-defined fields to RACF when applicable.
6.2.9.1 Statistics and history
The statistics and history of a user’s access to the system will be recorded in the
RACF database as the user begins using the system. The statistical and history
information from the CA-Top Secret database is not usually carried into the new
database. If you want the information in the database, you will need to write code
to propagate it since there is no command to set statistics. Alternatively, you can
record the information in the copy of the database (or flatfile of the database) that
you keep to provide historical data.
6.2.9.2 User attributes
The user attributes are converted to similar attributes in RACF.
AUDIT - Both products have the ability to AUDIT users of the system and both are
called AUDIT. RACF also has options for levels of auditing in the systems
options, such as SAUDIT,OPERAUDIT, and LOGOPTIONS.
SUSPEND/ASUSPEND - Both the SUSPEND and ASUSPEND users can be converted as
REVOKED users in RACF. To continue ASUSPEND function, several design
considerations will be required.
BYPASSING - CA-Top Secret allows bypassing of security checking at granular
levels such as NOVOLCHK,NODSNCHK,NORESCHK and NOLCFCHK. OS/390 allows
bypassing by use of the Program Property Table (PPT) and RACF allows
bypassing for some users, such as Started Task Trusted function. Otherwise,
access will be checked for resources. You would approximate the CA-Top
Secret bypassing function by giving a user the OPERATIONS attribute when
the OPERATIONS attribute applies to a class and the user is not on the access
list.
6.3 Converting data sets
The way CA-Top Secret protects data sets (and all other resources) is sometimes
referred to as "protection based on the user". What this means is that, when
deciding whether a user can access a certain data set, CA-Top Secret starts with
the user ACID, and then checks for the appropriate XA DATASET rule.
The way RACF protects data sets (and all other resources) is sometimes referred
to as “protection based on the resource”. What this means is that, when deciding
whether a user can access a certain data set, RACF starts with the data set
profile, and then checks the access list of that profile for an appropriate user ID or
group.
This difference can create an issue when trying to convert CA-Top Secret data
set protection (and other resources) to RACF. The following discussion illustrates
the problem.
Chapter 6. Database migration 63
6.3.1 User-based versus resource-based protection
In CA-Top Secret, authorization to access data sets is given to each user by
checking through the XA DATASET rules that are assigned specifically to that
user (or in PROFILES defined given to the user). For simplicity, the following
discussion assumes data sets are given at the user level.
Consider three CA-Top Secret users who have the following XA DATASET rules
assigned to them, and what would happen if each of them tried to access
SYS1.LINKLIB:
USER1 - XA DATASET = SYS1.
ACCESS = UPDATE
USER2 - XA DATASET = SYS1.LINK
ACCESS = UPDATE
USER3 - XA DATASET = SYS1.LINKLIB
ACCESS = READ
In CA-Top Secret, all three users would have READ access to SYS1.LINKLIB.USER1
and USER2 would have UPDATE access to SYS1.LINKLIB. The fact that USER3 has
an XA DATASET rule that more closely matches the data set (SYS1.LINKLIB) being
accessed has no bearing on whether USER1 and USER2 can access
SYS1.LINKLIB. This is because when CA-Top Secret determines whether a user
should be given access to a particular data set, it looks only at the XA DATASET
rules associated with that particular user. Also, different XA DATASET rules can
be used to access the same data set.
To convert the above rules to RACF on a 1-to-1 basis, we would use the following
RACF commands:
ADDSD 'SYS1.**'
PERMIT 'SYS1.**' ID(USER1) ACCESS(UPDATE)
ADDSD 'SYS1.LINK*.**'
PERMIT 'SYS1.LINK*.**' ID(USER2) ACCESS(UPDATE)
ADDSD 'SYS1.LINKLIB*.**'
PERMIT 'SYS1.LINKLIB*.**' ID(USER3) ACCESS(READ)
However, this alone would not match the data set authority provided these three
users through their XA DATASET rules. The difference in RACF is that when a
user tries to access a data set, RACF checks only one data set profile. That
profile is the one that most closely matches the data set. The profile is chosen
from
all
profiles that exist, not just the ones associated with a particular user.
In other words, if the same three users were to try to access SYS1.LINKLIB, only
the access list of the profile SYS1.LINKLIB*.** would be checked, because that is
the profile that most closely matches SYS1.LINKLIB.
In our example above, only USER3 would be allowed access to SYS1.LINKLIB.USER1
would be allowed access to all data sets that start with SYS1., except those that
start with SYS1.LINK or SYS1.LINKLIB. Similarly, USER2 wouldbeabletoaccessonly
data sets that start with SYS1.LINK, except for SYS1.LINKLIB and any other data sets
covered by the profile SYS1.LINKLIB*.**.
64 CA-Top Secret to OS/390 Security Server Migration Guide
In order to match the CA-Top Secret protection, we have to put USER1 on the
access list of all other profiles that start with SYS1. Also, we have to put USER2 on
the access list of all other profiles that start with SYS1.LINK. To do that, we use
the following additional PERMIT commands:
PERMIT 'SYS1.LINK*.**' ID(USER1) ACCESS(UPDATE)
PERMIT 'SYS1.LINKLIB*.**' ID(USER1) ACCESS(UPDATE)
PERMIT 'SYS1.LINKLIB*.**' ID(USER2) ACCESS(UPDATE)
Now USER1 can access any data set starting with SYS1. because he is on the
access list of all the data set profiles that start with SYS1. Similarly, USER2 can now
access any data set starting with SYS1.LINK because he is on the access list of
both profiles that start with SYS1.LINK.
The process of allowing users access to the correct resources by putting all users
on the access list is called undercutting and is similar to the undercutting
philosophy used in CA-Top Secret.
6.3.2 Data set conversion overview
We start by showing you how to convert a simple CA-Top Secret resource rule to
the commands necessary to create the corresponding RACF protection.
6.3.2.1 XA DATASET rule
In CA-Top Secret, the data sets a user can access are determined by checking
the XA DATASET rules related to that user. These rules are found in the individual
user ACID, any profile ACIDs the user has access to, and the ALL record. In the
example below, USER1 has three XA DATASET rules in his user ACID:
ACCESSORID = USER1 NAME = AARON AARDVARK
TYPE = USER FACILITY = CICSPROD
PROFILES = CICSPRF1 TSOPRF1
.
.
.
XA DATASET = CICS.USER OWNER(CICSDIV )
ACCESS = UPDATE,CONTROL
XA DATASET = SYS1. OWNER(SYS1 )
ACCESS = READ
XA DATASET = SYS1.PROCLIB OWNER(SYS1 )
ACCESS = UPDATE
When USER1 attempts to access a data set, the DSNAME of that data set is compared
to XA DATASET rules in the user ACID. If all the characters in the XA DATASET
rule match the start of the DSNAME in the exact order, then that rule is used to
determine what access level USER1 has to the data set. If more than one XA
DATASET rule could apply to the same data set, then the rule with the largest
number of matching characters is the one chosen. If no rules apply in the user
ACID, then CA-Top Secret checks for XA DATASET rules in any profiles the user
is associated with, usually in the profile order listed in the user ACID. According to
the above rules, USER1 can access any of the following:
Any data set starting with CICS.USER, with either UPDATE or CONTROL authority
Any data set beginning with SYS1.,withREAD authority
Any data set beginning with SYS1.PROCLIB,withUPDATE authority
Chapter 6. Database migration 65
Note that in the above example, both the second and third rule could apply when
USER1 accesses SYS1.PROCLIB. The third rule is used because it has a larger
number of matching characters.
6.3.3 Defining data set protection in RACF
In RACF, to allow USER1 access to the same data sets as in the previous example,
you have to first define data set profiles to protect the data sets in question. The
ADDSD command is used to create these data set profiles. Typical ADDSD commands
look like this:
ADDSD 'CICS.USER*.**' OWNER(CICSDIV) UACC(NONE) GENERIC
ADDSD 'SYS1.**' OWNER(SYS1 ) UACC(NONE) GENERIC
ADDSD 'SYS1.PROCLIB*.**' OWNER(SYS1 ) UACC(NONE) GENERIC
Then you need PERMIT commands to add USER1 to the access list of the profiles
protecting those data sets. In addition, you have to specify the access authority
(READ, UPDATE) so that it matches what USER1 had in CA-Top Secret, as follows:
PERMIT 'CICS.USER*.**' ID(USER1) ACCESS(CONTROL)
PERMIT 'SYS1.**' ID(USER1) ACCESS(READ)
PERMIT 'SYS1.PROCLIB*.**' ID(USER1) ACCESS(UPDATE)
NOTE: The use of the generic characters .** or *.** at the end of each profile is
needed to make the data sets covered by the RACF data set profile consistent
with what the XA DATASET rule allowed access to. For consistency, we use these
same generic characters whenever we create a RACF profile in this book. For
further information on the use of generic characters, refer to the
SecureWay
Security Server RACF Security Administrator's Guide
, SC28-1915.
6.3.4 Data control groups and the RACF high-level qualifier
RACF expects the high-level qualifier of every data set to be defined as a user ID
or group before it allows any data set profiles to be created that use that
high-level qualifier. For data sets that do not belong to a defined user, a RACF
group must be defined before the data set can be protected. RACF refers to these
groups as "data control"groups. If, for example, the high-level qualifier of CICS
had not been defined as a group before executing the ADDSD 'CICS.USER*.**'
command shown previously, then that ADDSD command would fail. To correct the
problem, the following command would have to be executed first:
ADDGROUP (CICS) SUPGROUP(CICSDEPT) OWNER(CICSDEPT)
RACF also requires the high-level qualifier for every data set to be fully qualified.
Where you have defined CA-Top Secret data set rules with generic characters or
without a trailing period, you will need to convert the rule to fully qualified rules for
the actual data sets they are intended to cover. For example:
CA-Top Secret RACF Rules Needed
ABC+++. ABCAAA <==== generic characters if data sets exist
ABCBBB
ABCCCC
etc
XYZ111 XYZ111 <=== no period at the end
XYZ1112
XYZ11123
etc
66 CA-Top Secret to OS/390 Security Server Migration Guide
The exception to generics in the high-level qualifier is the CA-Top Secret rule in
the ACID to indicate the user has ALL access to his own data. This is the default
in RACF, so a rule is not needed.
XA DATASET = %.
ACCESS = ALL
If the access is not ALL, exits must be written to restrict user access to their own
data.
6.3.5 Data set access
CA-Top Secret allows access to resources in several ways:
Owning the data set
Giving explicit access by XA DATASET rules in USER or PROFILE ACIDs
Giving general access by XA DATASET in the ALL record
6.3.5.1 Standard access
What access level a user has to a data set in CA-Top Secret (such as READ or
UPDATE), is determined by checking the ACCESS subparameter that immediately
follows the XA DATASET rule. The RACF equivalent to this is the ACCESS
subparameter of the PERMIT command. A suggested mapping chart to use when
converting access authority in CA-Top Secret to RACF is shown in Table 5. The
list is arranged in order from highest to lowest access authority. Throughout this
book, the terms "access"and "access authority"often mean the same thing.
Table 5. Access level conversion
In CA-Top Secret, if more than one value is listed in the ACCESS subparameter,
then when converting to RACF, choose the value that is the highest among all the
values listed for that data set in CA-Top Secret. In the example in 6.3.2, “Data set
conversion overview” on page 64, USER1 had both UPDATE and CONTROL access
authority in CA-Top Secret. When converting to RACF, the CONTROL value was
chosen because it was the higher of the two values.
CA-Top Secret RACF
ALL ALTER
ALTER ALTER
SCRATCH ALTER
CREATE ALTER
CONTROL CONTROL
WRITE UPDATE
UPDATE UPDATE
READ READ
FETCH EXECUTE
NONE NONE
Chapter 6. Database migration 67
6.3.5.2 Ownership access
You will need to add the owner of the data set to the access list with ALTER access
if the data set is owned by an individual. In the following example, USER1 will need
to be on the access list for any data set beginning with the high-level qualifier of
DEPART1.
ACCESSORID = USER1 NAME = AARON AARDVARK
TYPE = DCA SIZE = 512 BYTES
CREATED = 03/25/98 LAST MOD = 07/01/99 16:42
LAST USED = 03/26/98 13:40 CPU(CPU1) FAC(TSO ) COUNT(00606)
DATASET = DEPART1.
XA DATASET = SYS3.LINK
ACCESS = READ
6.3.5.3 Universal access
The Universal Access (UACC) for a data set is equivalent to the resources in the
CA-Top Secret ALL record. Generally, the UACC should be NONE and the special
access of ID(*) added with the general access. For conversion, list the ALL record
and give the access in the record to each resource definition in RACF.
6.3.6 Undercutting considerations
The standard CA-Top Secret undercutting of the most specific rule applies in the
conversion. Depending on the TSSPARM authorization setting, the considerations
differ.
Since RACF will use only the most specific rule defined in the database for any
given data set, any user who would have been able to access the data set from
his user ACID or any permitted profile ACID will need to be on the RACF access
list. The following are examples of the undercutting issue in the authorization
scenarios.
6.3.6.1 AUTH(OVERRIDE,ALLOVER)
This is the most common setting and the default. Consider the following example.
PROF1 PROF2
XA DATASET = SYS1.LINK XA DATASET = SYS1.LINKLIB
ACCESS = READ ACCESS = UPDATE
USER1
PROFILES = PROF1 PROF2
USER2
PROFILES = PROF2 PROF1
In CA-Top Secret, USER1 would have READ access to SYS1.LINKLIB because PROF1 is
first in the list of profiles. USER2 would have UPDATE to SYS1.LINKLIB because PROF2 is
first in the list of profiles.
In RACF, when the resources from the profiles were converted, they would have
both USER1 and USER2 connected to group PROF1 and group PROF2. After the
correction for the undercutting process discussed above, the access lists would
be as follows:
SYS1.LINK*.** SYS1.LINKLIB.**
PROF1/READ PROF1/READ
PROF2/UPDATE
68 CA-Top Secret to OS/390 Security Server Migration Guide
USER 2 would have the same access in both CA-Top Secret and RACF. USER1
would be incorrect since he now has UPDATE and previously had READ access. The
authorization flow for RACF shown in Figure 12 on page 23 shows that any
user
on an access list is used before any functional groups (profiles). Therefore, to
resolve that access issue, USER1 would need to be put on the access list as an
individual user. Naturally, not only USER1 would be put on the access list
individually;all users with PROF1 in this order must be added.
To convert, any data sets with similar or partial names must be reviewed to
determine that they are not in PROFILE lists for users so that the above problem is
created. If such a situation exists, it should be corrected on the CA-Top Secret
database or each user affected must be put in the access list for all the affected
resources in the PROFILEs.
6.3.6.2 AUTH(MERGE,ALLOVER)
Using the example below, in CA-Top Secret both USER1 and USER2 would have
update access to SYS1.LINKLIB since it is the longest name which matches the
requested resource in any of the lists of PROFILES for the user.
PROF1 PROF2
XA DATASET = SYS1. XA DATASET = SYS1.LINKLIB
ACCESS = UPDATE ACCESS = READ
USER1
PROFILES = PROF1 PROF2
In CA-Top Secret, USER1 would have READ access to SYS1.LINKLIB because the
access would be found using the longest matching name in all the merged
PROFILEs.
In RACF, when the resources from the profiles were converted, they would have
USER1 connected to group PROF1 and group PROF2. After the correction for the
undercutting process discussed above, the acccess lists would be as follows:
SYS1.LINK*.** SYS1.LINKLIB.**
PROF1/UPDATE PROF1/UPDATE
PROF2/READ
USER1 would be incorrect since he now has UPDATE and previously had READ access.
The authorization flow for RACF shown in Figure 12 on page 23 shows that any
user
on an access list is used before any functional groups (profiles). Therefore,
to resolve that access issue, USER1 would need to be put on the access list as an
individual user. Naturally, not only USER1 would be put on the access list
individually;all users with PROF2 must be added.
To convert, any data sets with similar or partial names must be reviewed to
ensure that they are not in PROFILE lists that can cause the problem described
above. If such a situation exists, it should be corrected on the CA-Top Secret
database or each user affected must be put in the access list for all the affected
resources in the PROFILEs.
Chapter 6. Database migration 69
6.3.6.3 AUTH(MERGE,ALLMERGE)
This option is closest to the RACF philosophy. However, the situation with this
authorization is like the AUTH(MERGE,ALLOVER) except that the ALL record must be
considered in the merge process.
6.3.7 Other CA-Top Secret to RACF data set migration issues
This section details data set migration issues not covered previously.
6.3.7.1 ALL record
There are times in CA-Top Secret when a user tries to access a data set, and
there is no appropriate XA DATASET rule in either the user ACID or any of the
PROFILE ACIDs. The ALL record is used by CA-Top Secret for those situations.
This record is a list of resource rules (data set and others) similar to a profile,
except it is almost always the last place CA-Top Secret looks for a resource rule
to check against. If an appropriate rule cannot be found in the ALL record, then
access to the resource depends on the overall security mode that CA-Top Secret
is in (WARN,IMPLEMENT, and so on). The functions of the ALL record in CA-Top Secret
are handled by the UACC (universal access authority) in RACF. The UACCs are not
stored in one central RACF list, but are defined separately (default
access=NONE) for each RACF profile.
6.3.7.2 ACTION
In CA-Top Secret, the WARN mode is used to let a user access a data set at a
higher level than the XA DATASET rule would normally allow, but produce a
message, for audit purposes, each time this happens. For any one data set, you
can selectively allow some users to be in WARN mode and others in FAIL mode by
use of the ACTION subparameter. For example:
ACCESSORID = USER1
XA DATASET = SYS1.LINKLIB OWNER(TECHDIV )
ACCESS = READ
ACTION = WARN
In RACF, the ADDSD WARNING subparameter is used for the same purpose;namely
putting a data set in WARN mode;but it applies to all accesses to that data set by
everyone, and cannot be given selectively to only certain users. By default RACF
rules will be in FAIL or DENY equivalent mode.
6.3.7.3 FAC
Any XA DATASET rules with the FAC must be evaluated for the access you want
the user to have in all conditions. Access to data sets is provided to the list of
users regardless of the application they are using.
XA DATASET = SYS1.LINK
ACCESS = READ
FAC = TSO
XA DATASET = SYS1.LINK
ACCESS = UPDATE
FAC = BATCH
70 CA-Top Secret to OS/390 Security Server Migration Guide
6.3.7.4 PRIVPGM and LIBRARY
Both products can control access to data sets through program pathing (CA-Top
Secret) or Program Access to Data Sets - PADS (RACF). CA-Top Secret does it
through the data set rule by using the LIBRARY and/or PRIVPGM parameters.
RACF uses the PROGRAM class to define the controlled programs and libraries. On
the data set profile the additional statement WHEN(PROGRAM(xxx)) results in a
Conditional Access List which is used to restrict access only through this
program.
The following must be observed:
•The
PROGRAM must be protected. (PROGRAM protection is discussed in 6.4.7, “PROGRAM
on page 76.)
The conditional access list must be defined.
PADCHK or NOPADCHK must be specified.
An example of the CA-Top Secret access rule entry is:
ACCESSORID = PROF1
XA DATASET = SYS1.PAYROLL
ACCESS = UPDATE
LIBRARY = PROD.LOADLIB
PRIVPGM = PAYUPDT
The example above results in the following RACF commands:
1. Define the program PAYUPDT in library 'PROD.LOADLIB'tothePROGRAM class (the
library must be in the LNKLIST concatenation):
RDEFINE PROGRAM PAYUPDT -
ADDMEM('PROD.LOADLIB'//NOPADCHK) UACC(READ)
2. Permit group PROF1 (or USER1)toALTER access to data set 'SYS1.PAYROLL' when
executing program PAYUPDT from library 'PROD.LOADLIB':
PERMIT 'SYS1.PAYROLL' ID(PROF1) -
ACCESS(ALTER) WHEN(PROGRAM(PAYUPDT))
6.3.7.5 UNTIL
In CA-Top Secret, the UNTIL parameter lets you create an XA DATASET rule that
expires on a specified date. In the following example, USER1 has access to the
SYS1.LINKLIB data set with ALL authority until 12/04/01, at which time the access is
revoked:
ACCESSORID = USER1
XA DATASET = SYS1.LINKLIB UNTIL(12/04/01)
ACCESS = ALL
These parameters can be converted by implementing the RESUME and REVOKE
parameters of the RACF CONNECT command. By creating a holding group for the
resource being protected, connect the groups matching the UID string to this
holding group and specify the RESUME and REVOKE parameters to cover the period
indicated by the UNTIL parameters.
ADDGROUP (EXPIRE1)
ADDSD 'SYS1.LINKLIB*.**'
PERMIT 'SYS1.LINKLIB*.**' ID(EXPIRE1) ACCESS(ALTER)
CONNECT USER1 GROUP(EXPIRE1) REVOKE(12/04/01)
Chapter 6. Database migration 71
In the above example, USER1 is granted ALTER access to SYS1.LINKLIB because he
is connected to the group EXPIRE1. His connection to that group will be revoked on
12/04/01, and with it, his access to SYS1.LINKLIB.
6.3.8 More data set considerations
Some general observations on converting data set rules are provided in the this
section.
6.3.8.1 Discrete versus generic profiles
CA-Top Secret TSSPARM has a parameter for ADSP. RACF has the same option in the
systems options. In both cases, it indicates that a data set is to have the protect
bit set in the DSCB. In RACF, this is called a
discrete data set profile
. Discrete
means it covers only this specific data set on this specific volume/unit
combination and the DSCB protect flag is set. When such a data set is opened,
RACF will search for a discrete profile. If no such profile is found, it will look for a
generic profile that could cover the request. To help administration, use generic
profiles whenever reasonable. When one generic profile can cover many data
sets, this will also improve system performance. However, using too many
fully-qualified generic profiles can hurt both performance and administration.
Even if the data set has no generic characters and is fully qualified in CA-Top
Secret, that is, it has single quotes around the name, it should be generated as a
RACF fully qualified generic in most cases. To ensure a data set is generic,
include the word GENERIC or the abbreviation G on the ADDSD command.
In CA-Top Secret
XA DATASET = ‘SYS1.LINKLIB’ OWNER(DEPT1)
ACCESS = READ
XA DATASET = SYS1.PARM OWNER(DEPT1)
ACCESS = READ
In RACF
ADDSD SYS1.LINKLIB OWNER(DEPT1) UACC(NONE) GENERIC
ADDSD SYS1.PARM*.** OWNER(DEPT1) UACC(NONE) G
NOTE: CA-Top Secret will ignore the DSCB protect bit if it is set and the TSSPARM
specifies ADSP(NO). RACF always checks the discrete profiles, DSCB bit on, first. If it
is possible that any data sets were created with the DSCB protect bit set, you
should run the TSSPROT utility to find and reset the bits before conversion to RACF.
6.3.8.2 Erase-On-Scratch (EOS)
EOS should be used for confidential data to ensure that residual data cannot be
accessed after deletion. Residual data is a potential security exposure for
confidential data. In CA-Top Secret, EOS is done on a system level, based on the
TSSPARM AUTOERASE and MODE options. In RACF it can be done on a data set level
and as such, it can be very selective and used without causing performance
problems.
72 CA-Top Secret to OS/390 Security Server Migration Guide
6.4 Converting resources
We use the term “resource rules” to indicate the definitions in CA-Top Secret that
describe what resources any particular ACID is allowed to access. Data set
resources are covered in the previous section. This section will concentrate on
the other resources.
Table 6. Resource rules and RACF equivalents
It is important to note that there are many alternatives you can use when
converting non-data set protection. The following examples are suggestions of
how you can convert your non-data set rules. There is usually no one "right
answer"when choosing an algorithm to use to convert each of the resource rules.
However, in order to determine the most accurate and appropriate conversion
algorithm for each resource rule, you should do the following:
1. Thoroughly understand what that rule protects in the CA-Top Secret
environment.
2. Determine how RACF accomplishes the same protection.
3. Determine what RACF command is used to create that protection.
You then can create the necessary algorithm to convert that particular resource
rule.
6.4.1 FACILITIES
A FACILITY in CA-Top Secret usually becomes an application in RACF. The APPL
general resource class is used by RACF to provide this type of protection. There
is not always a 1-to-1 correspondence between facilities and applications. Having
access to a FACILITY in CA-Top Secret often allows you access to more than one
application. Some applications that are defined as a FACILITY in CA-Top Secret,
such as BATCH and TSO, will not be protected by the APPL class in RACF unless
there is a product or application that requires it.
A suggested conversion approach is as follows:
1. Identify what you have defined as facilities in your CA-Top Secret environment.
2. Document what specific applications are covered by each FACILITY.
3. Determine what the VTAM ACBs are of these applications.
Resource rule Typical RACF equivalent
FACILITY CLASS(APPL)
XA OTRAN CLASS(TCICSTRN/GCICSTRN) or
user-defined CICS or IMS Class
XA VOLUME CLASS(FACILITY) $DASDI
XA ACID CLASS(SURROGAT)
XA TERMINAL CLASS(TERMINAL)
XA PROGRAM CLASS(PROGRAM)
XA IBMGROUP GROUP
XA user-defined CLASS(user-defined)
Chapter 6. Database migration 73
4. Determine other applications you may wish to protect that may not be listed in
your CA-Top Secret database.
5. Create RDEF APPL commands to define the applications to RACF.
6. Create PERMIT commands to allow access to the applications.
For example:
CA-Top Secret Facility statements:
ACCESSORID = PROF1
FACILITY = BATCH doesn't convert to an APPL in RACF.
FACILITY = CICSPROD allows access to CICS1, CICS2, CICS3.
In RACF, may become:
RDEF APPL CICS1 UACC(NONE)
RDEF APPL CICS2 UACC(NONE)
RDEF APPL CICS3 UACC(NONE)
PERMIT CICS1 CLASS(APPL) ID(PROF1) ACCESS(READ)
PERMIT CICS2 CLASS(APPL) ID(PROF1) ACCESS(READ)
PERMIT CICS3 CLASS(APPL) ID(PROF1) ACCESS(READ)
6.4.2 VOLUME
XA VOLUME is a very powerful rule in CA-Top Secret. CA-Top Secret checks
these rules before XA DATASET rules. Depending on how these rules are coded,
some users may be allowed access to data sets through the XA VOLUME rule
that they normally would be denied access to through the XA DATASET rule.
RACF does not have a facility that allows someone access to a data set that they
are not authorized to, because of some sort of "override"based on the volume the
data set is on. Protection of that type is better handled by DFSMS routines.
You can use the information from these XA VOLUME rules to create a very
limited type of volume protection in RACF. For example, the FACILITY class in
RACF can be used to determine who can allocate space on a volume when
creating data sets. An appropriate IGGPRE00 exit must be installed as well. For
example:
CA-Top Secret listing:
USER1 - XA VOLUME = SYS
ACCESS = UPDATE
USER2 - XA VOLUME = SYS002
ACCESS = UPDATE
RACF commands:
RDEF FACILITY $DASDI.SYS* UACC(NONE)
PERMIT $DASDI.SYS* CLASS(FACILITY) ID(USER1) ACCESS(UPDATE)
- USER1 can now allocate space on volumes starting with SYS
RDEF FACILITY $DASDI.SYS002 UACC(NONE)
PERMIT $DASDI.SYS002 CLASS(FACILITY) ID(USER2) ACCESS(UPDATE)
- USER2 can now allocate space on VOL002
Note that once you create $DASDI.SYS002, you have to add USER1 to the access list
as well, or you restrict the authority given to USER1 by the $DASDI.SYS* profile.
74 CA-Top Secret to OS/390 Security Server Migration Guide
Also, the DASDVOL class in RACF can be used to allow someone access to data
sets by volume instead of by checking data set profiles. However, access is
granted only when the user is performing a DASD maintenance function, such as
backing up a pack. Access is not granted if the user is trying to browse or update
the file.
For volume protection of BLP, RACF has the FACILITY class of ICHBLP to provide
the same function.
CA-Top Secret listing:
USER1 - XA VOLUME = TAPE
ACCESS = BLP,UPDATE
RACF commands:
RDEF FACILITY ICHBLP.TAPE UACC(NONE)
PERMIT ICHBLP.TAPE* CLASS(FACILITY) ID(USER1) ACCESS(UPDATE)
- USER1 can now use Bypass Label processing on volumes starting with TAPE
For volume protection of ALL or READ, special action, possibly an exit, will be
required to preserve the function.
6.4.3 OTRAN
Online transactions require special consideration and planning to translate.
Before you create the new online security definitions, you should be very familiar
with how RACF protection works with the individual products, particularly with
CICS, and what performance issues are involved when defining your transactions
to RACF.
For CICS, recommendations include:
Define your transactions to RACF in a manner that minimizes defining the
same transaction to multiple RACF profiles.
Only permit the transaction profiles to GROUPs, and not to individual USERs.
Connect USERs who have to use the transactions to the appropriate
GROUPs.
For example:
CA-Top Secret XA OTRAN statements:
ACCESSORID = PROF1
DEPT ACID = DPT1
XA OTRAN = CEMT
XA OTRAN = DC01
XA OTRAN = DC02
ACCESSORID = PROF2
DEPT ACID = DPT2
XA OTRAN = DC01
XA OTRAN = DC02
In RACF:
RDEF TCICSTRN CEMT UACC(NONE)
RDEF TCICSTRN DC01 UACC(NONE)
RDEF TCICSTRN DC02 UACC(NONE)
PERMIT CEMT CLASS(TCICSTRN) ID(PROF1) ACCESS(READ)
PERMIT DC01 CLASS(TCICSTRN) ID(PROF1,PROF2) ACCESS(READ)
PERMIT DC02 CLASS(TCICSTRN) ID(PROF1,PROF2) ACCESS(READ)
Chapter 6. Database migration 75
6.4.4 LCF AUTH/EXMP
LCF AUTH for transactions should be converted the same as described previously
for the OTRAN.IfthereisanOTRAN and an LCF AUTH for the transaction, the OTRAN is
the one to be converted.
LCF AUTH for other than transactions must be evaluated. Often the facility is a TSO
command which, if needed, can be converted to program protection for the
module which is called for the TSO command. Other facilities will probably
require new resource classes and/or exits to control.
LCF EXMP commands can add many users to the access list with ACCESS(NONE) due
to undercutting issues. Remember, each PROFILE is a RACF group on the access
list and the common way to prevent the group access from being used is to put
individuals on the access list. This method will work for transactions and program
protection. Other methods may be required for other facilities protected.
6.4.5 DB2
There are three areas in which control of DB2 resources can be protected. These
controls can be implemented in both CA-Top Secret and RACF, and are:
Control of access to DB2 subsystems
Control of access to DB2 Secondary Authorization IDs
Control of access to DB2 objects through the use of external security
6.4.5.1 Access to DB2 subsystems
Controlling access to the DB2 subsystem from different environments (e.g,
TSO,BATCH, CICS, or IMS) is accomplished by DB2 issuing an SAF call to see if
the user is allowed access to the sub-system using a specific environment. Since
this DB2 control is using SAF, conversion from CA-Top Secret is rather
straightforward.
In CA-Top Secret
ACCESSORID = USER1
XA DB2 = DSNR.DBPROD.BATCH
XA DB2 = DSNR.DBPROD.DIST
In RACF:
RDEF DSNR DBPROD.BATCH UACC(NONE) OWNER(... )
PERMIT DBPROD.BATCH -
CLASS(DSNR) ID(USER1) ACCESS(READ )
PRDEF DSNR DBPROD.DIST UACC(NONE) OWNER(... )
PERMIT DBPROD.DIST -
CLASS(DSNR) ID(USER1) ACCESS(READ )
6.4.5.2 Secondary authorization
An IBMGROUP in CA-Top Secret becomes a
group
in RACF. Each XA
IBMGROUP rule should be defined to RACF by using the ADDGROUP command. The
supgroup
of each IBMGROUP is the owner that is listed next to each XA
IBMGROUP rule. The users who have these resource rules in their ACIDs should
be connected to the corresponding groups in RACF. For example:
In CA-Top Secret
ACCESSORID = USER1
XA IBMGROUP= DB2GRP OWNER(DB2)
76 CA-Top Secret to OS/390 Security Server Migration Guide
In RACF:
ADDGROUP DB2GRP SUPGROUP(DB2)
CONNECT USER1 DB2GRP
Note that DB2GRP might be both a
profile
name and an IBMGROUP. This is
allowable in CA-Top Secret. However, RACF lets you use DB2GRP as a group or
a user, but not as both. If the same name was used as a PROFILE ACID, for
example, and a IBMGROUP, two groups with the same name would be created,
which is not allowed. The people on the connect list may not need both the
secondary group and the functional group. You may have to rename some of the
IBMGROUPs or some ACIDs as part of the conversion effort.
6.4.5.3 Controlling access to DB2 objects
A user can have access to DB2 objects, such as tables and plans. DB2 has it own
access control mechanism to control these objects, maintained through DB2
administration. Controls of these objects can also be implemented by using DB2
external security. CA-Top Secret has a CA-Top Secret Sub-system feature to
accomplish this;RACF provides this access control through the RACF/DB2
External Security Module.
Controlling access to DB2 objects using external security and it’s implementation
is different in CA-Top Secret and RACF. Some of the DB2 privileges in CA-Top
Secret’s external security sub-system do not directly translate on a 1-to-1 basis.
Conversion and careful attention to this will be needed to ensure these privileges
get mapped to the correct RACF classes.
6.4.6 TERMINAL
XA TERMINAL corresponds to the TERMINAL class in RACF. For example:
In CA-Top Secret:
ACCESSORID = USER1
XA TERMINAL= A11
In RACF:
RDEF TERMINAL A11 UACC(NONE) OWNER(owner)
PERMIT A11 CLASS(TERMINAL) ID(USER1) ACCESS(READ)
USER1 can now access the system through terminal A11. Terminal definitions in
RACF are for LUs and TCPIP definitions.
6.4.7 PROGRAM
RACF uses the PROGRAM class to define controlled programs and libraries. On the
data set profile the additional statement WHEN(PROGRAM(xxx)) results in a
Conditional Access List which is used to restrict access only through this
program.
Program protection requires the following:
The program must be defined to the PROGRAM class.
•Inthe
PROGRAM class, both library name and the program name are specified.
Optionally, the volume for the library may be specified.
Any aliases of the program being defined must also be included in the PROGRAM
class profile.
Chapter 6. Database migration 77
In addition, the PROGRAM class profile can specify PADCHK or NOPADCHK (PADCHK is
the default). PADCHK adds the following additional requirements:
All programs represented by the opening task’s PRB must be controlled in
class PROGRAM.
All programs that link to, load or call the program that opens the data set
must be controlled in class PROGRAM.
PADCHK may be difficult to establish and maintain and is therefore rarely used.
APROGRAM class definition will look like the example below. Define the program
PAYUPDT in library 'PROD.LOADLIB'tothePROGRAM class.
RDEFINE PROGRAM PAYUPDT -
ADDMEM('PROD.LOADLIB'/volser/NOPADCHK) UACC(READ)
6.4.8 XA ACID
XA ACID corresponds to the SURROGAT class in RACF. For example:
In CA-Top Secret:
ACCESSORID = USER1
XA ACID = USER2
In RACF:
RDEF SURROGAT USER2.SUBMIT UACC(NONE) OWNER(USER2)
PERMIT USER2.SUBMIT CLASS(SURROGAT) ID(USER1) ACCESS(READ)
USER1 can now submit jobs with USER=USER2. Typically, XA ACID rules convert in a
very straightforward manner.
6.4.9 User-defined resources
If you have created your own resources, either for a purchased product or for an
application, you have made changes to the TSSPARM to use an exiting (pre-defined)
facility or you have modified the Resource Descriptor Table (RDT) to create your
own resource name. RACF has an equivalent function which is the Class
Descriptor Table (CDT). The CDT contains the names of all known resources
classes for RACF. To use your defined resources or those defined to CA-Top
Secret that are not in the CDT, you must add them to the user portion of the CDT.
The access to these resources can be converted using the same methodology as
other resources. For example:
In CA-Top Secret:
ACCESSORID = USER1
XA MYDEFINE = MYDATA
ACCESS = READ
In RACF:
RDEF MYDEFINE MYDATA UACC(NONE) OWNER(DEPT1)
PERMIT MYDATA CLASS(MYDEFINE) ID(USER1) ACCESS(READ)
78 CA-Top Secret to OS/390 Security Server Migration Guide
6.5 Other considerations
This section discusses considerations for other resources not previously covered,
like Unix System Services.
6.5.1 OS/390 UNIX considerations
The UNIX group (the RACF group containing the GID) must be the current
connect group for the GID to take effect. With LIST of GROUPS CHECKING,
most people don’t change their group at logon. Therefore, for conversions,
change the default group of the users with OMVS segments to the DFLTGRP specified
in the USER ACID and connect the user to the appropriate department. An
example is:
ACCESSORID = $USER3 NAME = AARON AARDVARK
TYPE = USER SIZE = 768 BYTES
DEPT ACID = DEPT1 DEPARTMENT = DEPARTMENT ONE
DIV ACID = DIV1 DIVISION = DIVISION ONE
CREATED = 11/11/99 LAST MOD = 24/03/00 12:34
PROFILES = PROF1 PROF7
GROUPS = OMVSGRP
LAST USED = 25/03/00 13:26 CPU(CPU1) FAC(TSO ) COUNT(00645)
DFLTGRP = OMVSGRP
MYDEFINE = MYDATA
----------- SEGMENT OMVS
HOME = /
OMVSPGM = /bin/sh
UID = 0000009303
This would have been:
ADDUSER $USER3 DFLTGRP(DEPT1) OMVS(...
It will now change to:
ADDUSER $USER3 DFLTGRP(OMVSGRP) OWNER(OVMSGRP) OMVS(...
CO $USER3 GROUP(DEPT1) OWNER(DEPT1)
If the user is created by an automated process with all users, the user would only
need the following commands to change the default group:
CO $USER3 GROUP(OMVSGRP) OWNER(OMVSGRP)
ALTUSER $USER# DFLTGRP(OVMSGRP)
6.5.2 STCs
This section describes the conversion of started task (STC) authorization.
To get the currently defined procedures and users associated with them, you
would simply list them as shown below.
In CA-Top Secret
TSS LIST(STC)
Output
ACCESSORID = *STC* NAME = STARTED-TASKS
SIZE = 2816 BYTES
CREATED = 04/03/00 LAST MOD = 07/20/00 15:43
STC = *DEF* ACID = *BYPASS*
STC = APPC ACID = APPCTP
STC = ASCH ACID = APPCSCH
Chapter 6. Database migration 79
STC = ASCHINIT ACID = APPCINT
STC = BPXAS ACID = OMVS
STC = BPXOINIT ACID = OMVS
STC = CICSTEST ACID = CICSTST
STC = CICSPRDA ACID = CICSPRA
STC = CICSPRDB ACID = CICSPRB
STC = CICSPRDC ACID = CICSPRB
STC = DSNDBM1 ACID = DB2DBM1
STC = DSNMSTR ACID = DB2MSTR
STC = OMVS ACID = OMVS
STC = RMFGAT ACID = RMFGAT
STC = SPECIAL ACID = *BYPASS*
STC = TCPIP ACID = TCPIP
STC = VTAM ACID = NET
Note that there are some PROCs that use the same User ID as another PROC and
there are some that are unique to the PROC. This is the same as in RACF. There
may be more started tasks required in RACF than are currently defined in CA-Top
Secret because RACF is started sooner in the IPL process than CA-Top Secret
and can, therefore, protect more system functions.
RACF has two methods to support started tasks: Started Class and Started
Table. The recommended method is the started class. In both cases, RACF uses
a class or table to associate a userid and group name with a started procedure.
Normal access checking is performed for all started procedures using the
associated RACF userid and group name defined. It is very important to have the
user
and
group
definitions match in the class or table. If they do not, the entry will
not be used and the default or undefined user will be used for the started task.
You can indicate that selected started procedures are to be considered as TRUSTED
similar to the BYPASS option in CA-Top Secret. TRUSTED will allow access to data
sets without the user being on the access list.
The class or table may include a generic entry similar to the *DEF*entry in the
sample above. The generic entry will apply to all started tasks not defined in the
class or table. A sample Class entry and a sample Table entry are:
Sample STC Class entries
RDEF STARTED CICSPRDA.* OWNER(xxxx)
STDATA(USER(CICSPRDA) GROUP(STCGROUP) TRUSTED(NO)
RDEF STARTED *.* OWNER(xxxx)
STDATA(USER(=MEMBER) GROUP(STCGROUP) TRUSTED(YES)
Sample STC Table entries
DC CL8'CICSPRDA' STARTED PROC NAME
DC CL8'CICSPRDA' ASSIGNED USER
DC CL8'STCGROUP' ASSIGNED GROUP
DC XL8'0000000000000000' ATTRIBUTES
DC CL8'* ' STARTED PROC NAME
DC CL8'= ' ASSIGNED USER
DC CL8'STCGROUP' ASSIGNED GROUP
DC XL8'0400000000000000' ATTRIBUTES
80 CA-Top Secret to OS/390 Security Server Migration Guide
Refer to
SecureWay Security Server RACF System Programmers Guide,
SC28-1913 for a more detailed description.
6.6 Converting system-wide options
This section describes some of the system-wide security options for both CA-Top
Secret and RACF. These options determine how the security product is protecting
your system. A table is included to show the most direct mapping of some of the
CA-Top Secret global system options to RACF’s system-wide options.
6.6.1 Common system-wide security options
Table 7 contains the system-wide options common to both CA-Top Secret and
RACF.
Table 7. System-wide options common to CA-Top Secret and RACF
6.6.2 CPF
The Command Propagation Facility includes several statements in the TSSPARM
such as CPFNODES,CPFRCVUND,CPFTARGET, and CPFWAIT. RACF also can propagate
changes across systems using the RACF Remote Sharing Facility (RRSF).
6.6.3 Protection modes
Both products can be set to enforce default data set protection, that is, denial of
access to data sets not covered by a CA-Top Secret definition or a RACF profile.
When no CA-Top Secret rule is found for a data set, the TSSPARM MODE option will
decide what will happen. If MODE is set to FAIL, the data set must have a matching
rule set, otherwise access is denied. If the global RACF option
PROTECTALL(FAILURES) is set, RACF will require a matching profile for all accessed1
data sets. Without a profile match, access will be denied, so CA-Top Secret’s
MODE=FAIL and RACF’s PROTECTALL(FAILURES) will both require all data sets to be
protected.
CA-Top Secret RACF
ADSP ADSP/NOADSPa
a. Be sure to review 6.3.8.1, “Discrete versus generic profiles” on page 71.
AUTH(xxx,yyy) GRPLIST
AUTOERASE(NO) ERASE/NOERASE
MODE(...) PROTECTALL(...)/NOPROTECTALL
HPBPW(n) JES(EARLYVERIFY)) - required default
INACTIVE(nn) INACTIVE(nn)
NEWPW PASSWORD(...)b
b. See PASSWORD options below.
PWEXP(nn) PASSWORD(INTERVAL(nn))
TAPE TAPEDSN/NOTAPEDSN
TEMPDS(NO) TEMPDS
1Note that a Global Access Table entry can also allow access.
Chapter 6. Database migration 81
6.6.4 Passwords
Many of the password rules can be converted. Listed are some of the RACF
options. The PASSWORD parameter of Systems Options specifies the monitoring and
checking of passwords by indicating the following sub-operands.
HISTORY() - Specifies that 1 to 32 previous passwords are saved and
compared to a new password if specified.
INTERVAL() - Indicates the number of days that the current password is valid
(1 to 254). This value is used as a default for new users added with the
ADDUSER command and is also used as the upper limit for the INTERVAL
operand of the PASSWORD command.
REVOKE() - Indicates the number of invalid passwords that can be entered
before RACF revokes the user ID.
RULEn() - Specifies 1 to 8 individual password syntax rules. The rule
contains a length attribute and content keywords describing valid
passwords. For example:
RULE1(LENGTH(8) ALPHA(1:3) CONSONANT(4,8) NUMERIC(5:7))
You can use the ICHPWX01 exit to perform additional checks for password
rules, such as, the password cannot be equal to the user ID
6.6.5 RACF options
This section describes some additional RACF options that are highly
recommended when defining system-wide protection for your installation. The
following example specifies that all the current RACF options be displayed.
SETROPTS LIST
Additional RACF SETROPTS parameters can include:
NOADDCREATOR - specifies that if a user defines any new data set or general
resource profile, RACF does not place the profile creator's user ID on the
profile's access.
EGN - activates enhanced generic naming (EGN). This option allows you to
specify the generic character ** (in addition to the generic characters *and %).
GENCMD(*) - activates generic profile command processing for all classes and
needs to be reissued each time a new class is added.
GENERIC(*) - activates generic profile checking for all classes except grouping
classes and needs to be reissued each time a new class is added.
GRPLIST - specifies that authorization check processing is to perform
list-of-groups access checking for all system users. When you specify GRPLIST,
a user's authority to access or define a resource is not based only on the
authority of the user's current-connect group;access is based on the authority
of any group of which the user is a member.
JES(BATCHALLRACF) - specifies that JES is to test for the presence of a user ID
and password on the job statement or for propagated RACF identification
information for all batch jobs. If the test fails, JES is to fail the job.
PREFIX() - Enables protection of data sets with a single-qualifier data-set name
and specifies an HLQ to be prefixed to these data-set names during RACF
authorization processing. The prefix should be a defined group name and not
an existing HLQ.
82 CA-Top Secret to OS/390 Security Server Migration Guide
PROTECTALL() - Enables protect-all processing. All data sets that do not have a
RACF profile cannot be accessed, including data sets on DASD, GDG, and
catalogs. Tape data sets are also included if TAPEDSN is active. NOPROTECTALL
specifies that a user can create or access a data set that is not protected by a
profile.
The two operands used with PROTECTALL are:
FAILURES - Causes RACF to deny access to all data sets that are not
protected with a RACF profile.
WARNING - Causes RACF to allow access to data sets that are not protected
by a RACF profile and issue a warning to the user and security
administrator. This option should be used during initial conversion testing
to assist in setting up data set security protection.
The PROTECTALL parameter pertains only to data set protection. General
resources are covered only by their existing resource profiles with specified
access levels and an optional WARNING parameter. Note that default protection
of general resources can be controlled by “catch-all profiles, such as a profile
definition of ‘*’withUACC=NONE.
For more detailed information on RACFs system-wide options refer to the
SecureWay Security Server RACF Command Language Reference
, SC28-1919.
© Copyright IBM Corp. 2000 83
Chapter 7. Administration and maintenance
The administration of the security subsystem is an important factor when
selecting the subsystem, or when migrating to another one. In general, normal
OS/390 users see only the effects of the security system, and very seldom issue
commands directly to it. Security administrators, however, frequently issue
commands to the security subsystem, and the structure (and convenience) of this
process is important to them.
7.1 The administrative interface
RACF administration consists of several different categories of tasks:
1. Routine, day-to-day functions, such as adding users, resetting passwords,
adding resource protection profiles, and so forth.
2. Higher-level administration, such as adding new SPECIAL,GROUP SPECIAL,
OPERATIONS users, setting AUDIT controls, and so forth.
3. Setting global RACF controls.
4. Maintaining the database, in the sense of purging unwanted entries, detecting
unwanted situations, monitoring the correctness of the security policy
reflected by the database, and so forth.
5. Monitoring the audit records written by RACF.
6. Maintaining the database, in the sense of backups and reorganization,
monitoring performance, and so forth.
RACF commands are normally used for the first three tasks in this list. There are
a number of ways to enter RACF commands, and these are discussed in the
following sections.
There are many ways to address the fourth task, database quality maintenance.
Using the RACF SEARCH command or the IRRRID00 utility is a starting point, and
may be all that is required. In more demanding cases, you might need to write or
obtain an application to address this area.
The fifth task, monitoring audit records, involves listing selected SMF records.
The RACF report writer (no longer actively maintained by IBM) is an easy starting
point. There are many SMF reporting programs, including the SMF Unload utility
that is part of RACF, which can be used with DB2 or DFSORT’s ICETOOL.
The sixth task, physical care of the database, involves several utilities supplied
with RACF, and also involves normal OS/390 tuning activities.
84 CA-Top Secret to OS/390 Security Server Migration Guide
7.2 Commands
CA-Top Secret and RACF both have their own command sets. In each case, ISPF
panels are available to ease the use of the commands, but the underlying line
commands are central to understanding the use of the product. Both products
have extensive documentation. Refer to
SecureWay Security Server RACF
Command Language Reference
, SC28-1919, for an explanation of all RACF
commands and syntax.
RACF commands may be entered in a number of ways:
RACF commands from the TSO command line
ISPF panels (provided with RACF)
Batch jobs (which issue the same commands as under TSO)
Application programs (or third-party products) that issue RACF commands
RACF commands from OS/390 operator consoles
Most commonly, TSO line commands and the ISPF panels are used for
day-to-day administration, and batch jobs are useful for bulk updates.
RACF commands issued from an OS/390 operator’s console are very useful in
critical situations, but are not intended for routine administration. The operator
must have performed a logon function (password authentication) before entering
RACF commands. (An exception exists for the operator command that switches to
the backup RACF database;an operator logon is not needed in order to issue this
command.)
Both products have many commands, and many of these are used only by the
security administrator or systems programmers. Only a small part of the full
command sets is used daily by other administrators, help desk personnel, and
end users.
RACF has four general types of database entities (profiles): User, Group,
Dataset, and General Resources. Each of these types has associated commands
to add, modify, delete, and list profiles. The following table lists the basic
commands for these operations. The table shows, for example, that the
ALTGROUP command would be used to alter a group profile.
Table 8. RACF commands to add, modify, delete and list resources
This table is quite simplistic and is not intended to convey any of the ramifications
of the indicated functions. More detailed information on the functionality of the
RACF commands can be found in Chapter 3, “RACF overview” on page 19. For
complete definitions and the syntax of the commands, refer to
SecureWay
Security Server RACF Command Language Reference,
SC28-1919
.
User Group Dataset General
resource
Add ADDUSER ADDGROUP ADDSD RDEFINE
Modify ALTUSER ALTGROUP ALTDSD RALTER
Delete DELUSER DELGROUP DELDSD RDELETE
List LISTUSER LISTGRP LISTDSD RLIST
Chapter 7. Administration and maintenance 85
The various privilege levels of RACF commands are described in detail in
previous chapters. A very brief summary, related to the use of RACF commands,
may be helpful here:
Someone with the SPECIAL privilege can issue any RACF command, except
those restricted to auditors. (A SPECIAL user can grant himself the AUDITOR
privilege, and then issue those commands.) This level is usually restricted to a
few security administrators. The SPECIAL user typically issues global RACF
commands, constructs important generic data set profiles, defines groups,
and delegates Group-SPECIAL authority.
Someone with a Group-SPECIAL privilege can issue RACF commands that affect
only a designated group, or its subgroups. A group may own many subgroups,
providing many ways to structure and delegate authority. Distributed security
administrators typically have Group-SPECIAL authority for their areas. Help desk
personnel may have Group-SPECIAL authority.
The owner of a profile can issue several RACF commands that affect only that
profile. In practice, this means that the owner of a data set profile can control
which users (and at what level) can access data sets protected by that profile.
The primary command involved is PERMIT.
In the PROTECTALL environment, a RACF profile will already exist for a user’s HLQ
(created when the user ID was added to RACF). A user can grant permission to
other users to access his files. The PERMIT command is used for this, and this may
be the only RACF command that typical users issue. In a well-designed
environment, with appropriate use of generic data set profiles, most users will
never need to issue PERMIT commands.
RACF commands can be issued from OS/390 operator consoles. This should not
be regarded as a routine interface for RACF administration, but it can be very
useful in an emergency situation. A profile class, OPERCMDS,isusedtocontrol
which operators can issue which RACF commands. Operators are required to log
onto the OS/390 operator console before they can issue RACF commands.
Once the basic command structure is understood, using RACF commands
instead of CA-Top Secret commands should not present any problems. The more
important migration issues are the organizational processes that occur before any
commands are issued.
In practice, CA-Top Secret and RACF commands are usually issued from the
TSO command line (more experienced administrators) or from ISPF panels. In
both cases, a good understanding of the security policy in use, and the use of
consistent naming conventions and group conventions, is key to understanding
and using the security administrative commands. In both cases, commands can
be batched by using the PGM=IKJEFT01 method of running TSO functions in batch
jobs.
86 CA-Top Secret to OS/390 Security Server Migration Guide
7.3 RACF utilities
Several utilities are provided with RACF. These are normally used in batch jobs,
and address some of the tasks previously listed. These utilities are:
IRRUT100 This program reads the RACF database, and can search for
specified entries. While reading, it checks the correctness of
internal index records and other pointers.
IRRUT200 This program will simply copy the RACF database, checking
major structural items as it copies. However, it observes all RACF
interlocks for update activities that occur while the copy is in
progress. This ensures a logically consistent copy. IEBGENER can
be used to copy a RACF database, but it does not observe such
interlocks and, if there are RACF updates during the copy, it may
not produce a complete copy.
IRRUT400 This program also copies the RACF database, but it reorganizes it
at the same time. It can split the database into multiple data sets
(for performance) or merging multiple data sets back into one.
IRRUT400 can rebuild internal index records, and generally corrects
small structural errors.
IRRADU00 This program unloads the security relevant SMF records into
sequential records. It is readable by a person, and can be used as
input to external programs.
IRRDBU00 This program unloads the RACF database into sequential
records, with fields specified in EBCDIC characters. It is readable
by a person, and can be used as input to external programs. For
example, some installations load this data into DB2 and perform
what if searches there.
IRRRID00 This program searches an unloaded RACF database for user IDs
and groups that are about to be removed from the installation.
You can specify the user ID or group that will replace these
departing user IDs and groups.
7.4 Security reports
Reports are important for security administration, in order to enable tracking and
monitoring of events and status of the security environment established, and to
uncover changes that could lower or change the expected security level. The
problem is to collect and get the correct data to meet the objectives. Too many
organizations collect too much data, without having any plan or strategy for its
use.
There are two levels of reporting for OS/390 security subsystems. One level
reflects the contents of the security database, and describes what is protected
and how it is protected. This is called
status monitoring
. The other level reflects
the security events that occurred during a particular period;for example, which
users logged onto the system, or what attempted security violations were
detected. This is called
event monitoring
.
Chapter 7. Administration and maintenance 87
For both CA-Top Secret and RACF, event monitoring is centered around SMF
records. There are many programs and products available for listing SMF
records.
The usefulness of event monitoring depends on what is monitored;that is, what
causes an SMF record to be written?CA-Top Secret and RACF have options to
control which events cause an SMF record to be written. RACF has an orderly
structure of auditing controls for this purpose. Controls exist at both individual
profile levels and at the global level. Since a profile can be used to protect a
single data set, or to protect a large number of data sets (with similar higher-level
qualifiers), auditing controls can be selective.
RACF controls can be set to write SMF records on either access failures (where
data set access was prevented by RACF), or on access successes (where data
set access was permitted by RACF). In general, reporting of successful accesses
is not desired, partly because the volume of SMF records would be too large.
However, successful access reporting may be appropriate for a carefully selected
set of application data sets. Access failure events are typically used to create an
SMF record, and a basic part of the security administrator’s duties is to review
these records.1
RACF can also log (to SMF) changes to the RACF database itself, and records
are created indicating changes to user profiles with any of the high-level
authorities, such as SPECIAL, should always be reviewed. Some of the key global
controls of RACF, related to auditing, are:
SAUDIT is used to log all commands that need a SPECIAL user privilege. This is
used to review activities by these privileged users. It can also be used to
recreate profiles and commands from SMF data in an emergency.
OPERAUDIT is used to log all data accesses a user with the OPERATIONS privilege
is granted, due to this privilege. Access through normal access rights are not
logged.
Use both SAUDIT and OPERAUDIT to enable auditing of privileged users and their
activities.
CMDVIOL is used to switch on/off RACF command reporting;CMDVIOL will record
all attempts to use RACF commands outside a user’s authority.
LOGOPTIONS are used to specify logging options for different resource classes,
from no logging to full logging. These can be used to globally force logging of
resources in one class to avoid having to specify the AUDIT option on each
profile.
GLOBALAUDIT can be specified by someone with the AUDITOR privilege. This
generates audit data without requiring that specific profiles be selected for
auditing.
In addition to these global and class options, each resource profile can have its
own audit requirements defined through the AUDIT option, from no logging to full
logging. This setting will not lower the logging requirement set by the LOGOPTIONS
value for that class. All profiles have a default AUDIT setting;for example, for data
sets it is AUDIT(FAILURES).
1There are many different approaches to this. Some installations want to review every access failure, while others check only for
substantial patterns of access failures. An access failure is not a security failure;it is simply an indication that the security subsystem was
doing its job. In practice, reviewing every access failure tends to be impractical.
88 CA-Top Secret to OS/390 Security Server Migration Guide
In addition to the various logging options mentioned here, all invalid password
attempts are logged by default.
UAUDIT can be set on a user profile to cause all RACF activity for that particular
user to be logged. It is an effective way to trace all activities of a user, but must be
used with some restraint to avoid writing too many SMF records.
Status monitor involves listing control settings in the security database, and
monitoring changes to these controls. SMF records, written by RACF, are useful
for detecting changes, while static information must be extracted from the
database itself. Several tools are provided by RACF:
DSMON (Data Security Monitor) is a program for reporting on several security
settings, user privileges and protection status of important system data sets. It
should be run regularly to monitor any changes to any of these security areas.
The RACF ISPF panels offer a number of options to display various control
settings.
RACFRW (RACF Report Writer) is an ad hoc reporting program. The Report
Writer has been stabilized, so new functions will not be reported. The
traditional RACF functions such as data set and resource violations can be
reported.
•The
IRRDBU00 utility-produced flat file can be used in a number of ways:
through locally-written programs, by loading it into DB2 and executing
searches there, or by using any standard report-writing software.
•The
IRRADU00 utility-produced flat file can be used in a number of ways:
through locally-written programs, by loading it into DB2 and executing
searches there, or by using any standard report writing software.
•The
RACFICE reporting tool utilizes the ICETOOL function of DFSORT to produce
various reports using the output of IRRDBU00 or IRRADU00, or both.
The IBM Performance Reporter product can also be used for RACF reporting
and comes with 11 canned reports for RACF.
In summary, log and audit functions are an important part of an organization’s
security policy. The security policy should clearly define what is expected for
logging and audit, and how it will be used. This requires some skill and
experience, since a balance is needed between what is practical, the effects on
performance, the problems of generating too much data, and so forth.
Chapter 7. Administration and maintenance 89
7.5 Availability considerations
CA-Top Secret and RACF, when fully implemented and used, are both functions
critical to an OS/390 production environment. Their availability and recoverability
must therefore be carefully designed, planned and tested. Due to different
technical features and capabilities of the two products, recovery techniques and
strategies differ. Approaches to RACF recovery are discussed in the following
sections.
Figure 21. RACF primary and backup data sets
7.5.1 RACF active backup option
A unique recovery feature in RACF is the active backup data set option, the
commonly used option to maintain a software mirror image of the primary RACF
database.
While RACF performs all authentication and authorization checking against its
primary database, all updates are automatically duplicated onto the active backup
database. In case the primary database is lost, a switch to the backup database
can be performed without the need for an IPL or other recovery procedures.
7.5.1.1 RACF database backup
The initial setup of the RACF recovery environment requires defining the name of
the backup data set in the RACF Dataset Name Table ICHRDSNT and making a
copy of the primary database (while no updates are taking place). Good recovery
strategies also have provisions to periodically take additional backup copies
(independent of the active backup). We believe that the best tool to create such
copies is the RACF verify utility program IRRUT200;this program enqueues on the
input database for the duration of the copy process and has the additional
advantage that it provides an analysis of the database structure. The IRRUT200 list
output can be used to determine the degree to which the database is full and to
identify potential structural problems that need to be addressed.
7.5.1.2 RACF database recovery
When a problem with the primary RACF database is discovered, an RVARY SWITCH
command is issued on the system console or in a TSO session to initiate a switch
to the active backup database. This one now becomes the primary database and
the original primary is deactivated. The system continues to run with just a
OS/390
RACF
Primary
Active
Backup
Active
Copy
90 CA-Top Secret to OS/390 Security Server Migration Guide
primary database, and the creation and activation of a new backup database is
scheduled for a period of low activity.
To avoid false alarms, this switching capability is secured by a password under
the control of the central security administration;this feature can be used to
enforce procedures that require the involvement of security management in any
RACF status change.
7.5.2 Reorganizing the RACF database
Some organizations include periodic reorganizations of their RACF databases in
their backup and recovery plans. In a quiesced environment, use the RACF
split/merge utility IRRUT400 to create a “logical” copy of your RACF database
(specify one input and one output file). This process eliminates CI-like splits in
the database structure and profiles that have been logically deleted (no pointers
in the index structure), but may physically still be present.
7.6 RACF performance considerations
There can be a conflict between your ideal security policy and the performance
practicalities of the security subsystem. Controlling CICS transaction accesses is
an example of a function that can be torn between security needs and
performance needs. Extracting the best performance from the security subsystem
involves these areas:
Using global options that short-circuit the rest of the security monitor.
Using some type of cache in main storage.
Using special coding options in applications that result in an unusually fast
response by the security subsystem.
Using a good design for sharing the database file among multiple systems,
since the need for a shared security database is common.
Using normal DASD tuning techniques to improve I/O response.
Both CA-Top Secret and RACF provide options in all these categories. Some of
these are not simply performance options;they affect the policy design of the
security database and should be considered part of your high-level design.
Some of the key RACF features in this area include:
Global Authorization Check (GAC) - RACF uses this in-storage table to make
quick decisions about whether further RACF checking is needed.
RACLIST refers to the process of moving a complete RACF CLASS of profiles
into storage, for faster access.
In-storage buffers refer to the allocation, in main storage, of a given number of
buffers that are managed by RACF with a type of Least Recently Used (LRU)
purging technique.
RACF can take advantage of the Coupling Facility to further improve
performance
If not deflected by a Trusted or Privileged property, RACF checks the GAC when
beginning to process an access request. The GAC is an in-storage table owned
by RACF. It is copied into storage when RACF is started, and is static during
Chapter 7. Administration and maintenance 91
operation, unless updated by a security administrator. It is usually a very small
table. The most typical use is to grant permission to access (in any manner) a
data set with the same HLQ as the caller. That is, a user can work with his own
data sets (as identified by a matching HLQ) without any further checking by
RACF. The GAC can contain lists of exceptions to the general rules it sets,
causing the normal profiles to be checked for these exceptions.
This process can provide excellent performance. The exposure is that no other
RACF controls are checked. If, for example, the GAC gives all users READ access
to all SYS1 data sets, then no SYS1 data sets can have a general access level of
NONE because the profiles that try to establish this condition are not checked. The
use of a GAC entry bypassed them. The use of the GAC table is important for
performance, but the usage must flow from the overall security policy being
defined.
The installation can specify a certain amount of buffer space to be dedicated to a
RACF cache, known as
in-storage buffers
. This space is in protected common
storage. It is pagable, but for practical purposes can be regarded as fixed
because it is referenced frequently. The use of this cache is transparent to policy
design, and is a pure tuning function. (The cache is limited to RACF elements that
are normally read-only, or write-through cache data. The RACF database, on
disk, must always reflect current data to other OS/390 systems sharing the same
database.)
RACF can manage a
backup
database, in addition to its primary database.
Practically every installation elects to have a backup RACF database. We do not
consider deleting this to be a reasonable action. In addition to profile updates,
RACF writes statistical data in its database, for example, the date and time of a
users most recent TSO logon. There is an option to bypass updating the backup
database with statistical data. Many installations select this option. In the rare
event of a database failure, requiring use of the backup RACF database, some
statistical data will be missing. This is usually considered a reasonable tradeoff.
Customers can make use of OS/390’s virtual lookaside facility (VLF) to cache
ACEEs and information for OS/390 UNIX. If RACF finds information in VLF, it will
avoid I/O to the database.
RACF can use “split databases”, meaning the database can be divided into
multiple files, on multiple volumes. (The backup database can also be split.)
RACF still uses it as a single logical database. By placing parts of the database
on different volumes, different control units, and/or different channels, normal
DASD data set tuning techniques can be applied.
Splitting the RACF database is transparent to security policy decisions. RACF
offers a special high-performance interface, RACROUTE REQUEST=FASTAUTH, commonly
known as FASTAUTH. Programs must be specially coded to use it;it is not used by
automatic system calls that go through SAF. CICS is the major example that can
use FASTAUTH.TheFASTAUTH function references only in-storage tables (placed in
storage by the RACROUTE REQUEST=LIST function), providing major performance
benefits over standard authorization that involves disk database inquiries.
The IRRUT400 utility, supplied with RACF, can be used to reorganize the database.
Database performance may degrade slightly over time, as updates and changes
occur. The effect is usually fairly minor, unless very large databases are involved
92 CA-Top Secret to OS/390 Security Server Migration Guide
or many profiles have been added and deleted. A typical installation might use
this utility to reorganize the database every six months.
7.6.1 Performance of shared databases
Sharing a database, CA-Top Secret or RACF, among multiple OS/390 images has
become common. This has a number of interesting effects on performance
design, including:
The use of cache functions becomes more restricted, since the corresponding
disk record could be updated by another system, making the cached data
invalid.
Extensive use of RESERVE and RELEASE functions (disk locking commands) can
badly impact the performance of a shared disk.
The use of a disk API (access method) that is not optimized for shared system
usage can badly impact performance.
RACF uses a low-level, proprietary API for disk access. It does not use VSAM.
The RACF design is optimized for shared-system use and should automatically
provide a major performance boost compared with shared-VSAM usage.
The RACF use of cache (in-storage buffers) is based on a design that avoids
cache coherency problems in the presence of shared-system operation.
The elements of RACF operation that affect shared-system performance are all
automatic. There is no user tuning involved. The tuning items discussed are
effective in both single-system and multi-system environments.
The Coupling Facility allows OS/390 and other software to share data
concurrently among multiple systems in the sysplex with the goal of maintaining a
single system image. A sysplex with a Coupling Facility significantly changes the
way systems can share data.
Data sharing
is the ability of concurrent subsystems
or application programs to directly access and change the same data, while
maintaining system integrity. RACF can take advantage of the Coupling Facility in
the sysplex to provide security for the resources of all systems in a
comprehensive and centralized way. RACF allows you to use the Coupling
Facility and shared RACF data to help manage the security of resources for all
systems in a sysplex.
7.6.2 Migration issues
The complete PPT should be reviewed manually, as part of any migration effort.
Other performance elements, especially the GAC, should be created manually.
Performance elements that do not interact with policy design, such as in-storage
buffers and database splitting, can be managed independently from the migration
process itself. If the basic migration process, normally through the use of
specialized software tools, provides acceptable performance, then it may be
advisable to postpone tuning these elements until the end of the migration
project.
A CICS installation would certainly want to enable FASTAUTH checking for its own
applications or program products as part of the migration. This should provide a
substantial performance improvement, as well as integrate CICS usage into
normal RACF operation.
Chapter 7. Administration and maintenance 93
7.6.3 Summary
Tuning can make a major difference in security subsystem performance. RACF
offers a number of major tuning options. Some of these interact with the security
policy goals of the system, and this aspect must be considered in the overall
design of the RACF implementation. With reasonable designs, RACF can offer
significant performance improvements, especially for key areas such as CICS.
94 CA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 95
Appendix A. IBM migration services
IBM offers a number of migration services, including CA-Top Secret to RACF
migration assistance. For a migration project of this scope and magnitude, it is
advisable to secure the services of someone who has done migration projects
before. The skills needed for a migration are unique and probably will not be
needed by an organization after completion of the project. IBM’s Software
Migration Project Office (SMPO) offers migration services which can be tailored
to the client’s needs. The following is a brief overview of the migration services.
A.1 Mainframe system software
In the evolving world of client/server computing, many customers are redefining
the role of their mainframes, and re-evaluating their mainframe system software.
They are choosing products that not only perform well today, but that are capable
of participating in the evolving world of open systems and enterprise-wide
computing. They are choosing vendors who offer quality products and quality
support, and who offer flexible terms and conditions that allow the software to
change as the customer's requirements change. Increasingly, customers are
choosing IBM software as a base for their enterprise computing needs.
A.2 Migration services
Choosing the right product is one thing, but changing mission-critical software
can be another. To accomplish the migration with the least disruption to their
business, many customers seek expert assistance.
IBM's migration services are designed to minimize the time, risk, and total cost of
changing critical system software. By assisting many customers with such
migrations, IBM has developed skills, tools, and experience which can be used to
assure a successful migration. Our approach is to leverage IBM's experience and
tools, along with the customer's knowledge of their systems, to create a
cost-effective team. This team approach also allows a great deal of skills transfer
to take place naturally throughout the migration, so that when the migration is
complete, the customer's staff is able to manage the new environment
productively.
A.3 Conversion vs. migration
One important consideration when choosing migration services is the difference
between a conversion and a migration. A
conversion
refers to the translation of
the operational data from one format to another. A
migration
project is a much
broader effort, beginning with project assessment and planning, continuing with
installation and testing (including conversion activities and tools), and ending with
final cutover. Though the conversion phase is very important, it is only one piece
of a full migration project.
A.4 Migrations - no two are alike
Most customers have had their mainframe system software installed for some
time. Over that time, the software has evolved, and each customer has uniquely
96 CA-Top Secret to OS/390 Security Server Migration Guide
customized their software to better fit their needs. While this customization
makes the product more valuable, it also makes the migration more complex.
Complexity, along with the amount of skill, resource, and focus that each
customer is willing to dedicate to a migration effort, makes each migration unique.
As such, each customer will require a different amount of assistance, take a
different amount of time, and have a different total cost for completing the same
product migration.
A.5 Migration service offerings
IBM's migration service offerings have a flexible, modular structure to allow each
customer to choose the type and amount of service that is needed to meet that
customer's needs. While the details regarding specific product migrations differ
slightly, the general structure of IBM's migration service offerings is as described
in the following sections.
A.5.1 Migration assessment service
Performed by a migration specialist, this service assists the customer to assess
the time, effort, skill requirements, and feasibility of migrating from their current
environment. By analyzing reports and extracted data and by interviewing
technical staff and management, the migration specialist can create a
documented assessment report and review it with the client.
A.5.2 Database conversion service
IBM can bring customized conversion tools to bear on many of the product
migrations. Fixed priced offerings include the customization, usage, and support
of the conversion tools.
A.5.3 Migration consulting services
Migration specialists, experienced from other, similar migrations, are available to
provide guidance with a wide variety of migration activities. Typical uses of
migration consulting are:
Migration planning - leading a customer/IBM team to create a documented
migration plan, including detailed task list, target dates and people
assignments.
Technical analysis - analyzing the current implementation of the installed
product and offer alternative ways of implementing functions using the new
product.
Consulting services are typically billed on an hourly basis.
A.5.4 Migration perform services
IBM Global Services are available to perform many of the tasks required to
complete the migration.
Some of the services available are:
Product installation and customization
Implementation of new function
Exit design and/or coding
Appendix A. IBM migration services 97
Testing, test planning, and validation
Operations skills transfer
Project management
Perform services are typically billed on an hourly basis.
A.5.5 Learning Services
Through IBM Learning Services, a variety of education alternatives are offered.
Product classes, as well as migration classes, are available. Classes are
available through a per seat, or onsite private class arrangement.
A.6 Product migrations
IBM can assist in a wide variety of product migrations. IBM's Software Migration
Project Office specializes in MVS system software migrations including:
CA-ACF2 to RACF
•CA-TopSecrettoRACF
• CA-7andCA-11toOPC/ESA
Control-M and Control-R to OPC/ESA
Jobtrac and Runtrac to OPC/ESA
Zeke and ZebbtoOPC/ESA
CA-Scheduler to OPC/ESA
CA-Manager to OPC/ESA
• CA-1toDFSMSrmm
CA-DYNAM/TLMS to DFSMSrmm
CONTROL-T to DFSMSrmm
ZARA to DFSMSrmm
• MVS(OS)CatalogtoDFSMSrmm
CA-IDMS to DB2 Family
Adabas to DB2 Family
CA-DATACOM to DB2 Family
TOTAL to DB2 Family
Model204 to DB2 Family
VSAM to DB2 Family
CA-LIBRARIAN to ISPF/PDF SCLM
•PanvalettoISPF/PDFSCLM
CA-OPS/MVS II System Automation for OS/390 (SA OS/390)
Boole &Baggage Auto Operator to SA OS/390
Candle’s AF/Operator to SA OS/390
NetMaster to Tivoli NetView for OS/390
CA-Opera to SA OS/390
•CA-Zak to SA OS/390
CA-Netman to Tivoli Service Desk for OS/390
Remedy to Tivoli Service Desk for OS/390
Peregrine to Tivoli Service Desk for OS/390
Heat to Tivoli Service Desk for OS/390
SLR to Tivoli Decision Support for OS/390
CA-MICS to Tivoli Decision Support for OS/390
IT/Service Vision to Tivoli Decision Support for OS/390
MXG to Tivoli Decision Support for OS/390
CA-JARS to Tivoli Decision Support for OS/390
Komand to Tivoli Decision Support for OS/390
98 CA-Top Secret to OS/390 Security Server Migration Guide
CIMS to Tivoli Decision Support for OS/390
CA-NetSpy to NPM (NetView Performance Monitor)
• CA-TPXtoNVAS(NetViewAccessServices)
CA-MAI to NVAS (NetView Access Services)
CMF to RMF (Resource Measurement Facility)
Connect Direct to TDE (Tivoli Data Exchange)
CA-Sterling Netmaster TCP/IP (Manage) to NPM/IP (NetView
PerformanceMonitor for IP)
CA-DISPATCH to OnDemand
CA-VIEW/DELIVER to OnDemand
INFOPAK to OnDemand
A.7 Getting started
All security projects are high-risk, high-visibility projects. Managing and
controlling the levels of risk are integral parts of project planning, project
management, and testing methodologies. Good project planning insures that all
tasks, problems, and issues are documented and tracked to solution. Good
testing not only ensures that individual problems and issues are tested, it also
ensures the total environment is tested. Good project management ensures the
project plans and testing is adhered to. Without these elements, the risks are
high;with them, the risks can be controlled to acceptable levels.
For additional information, or to discuss how IBM's migration service offerings
can be tailored to fit your needs, contact your IBM Client Representative.
© Copyright IBM Corp. 2000 99
Appendix B. Security policy considerations
Various aspects of security policies have been addressed throughout this
document in the context of specific technical discussions. This appendix is
intended to consistently summarize policy implementation and enforcement in
RACF.
We address general policies such as complete RACF control over users and
resources, naming conventions and resource ownership;we also include
discussions of effective and efficient security administration policies and RACF
resource utilization.
We do not address mandatory access control policies because we have not
observed implementations of these policies in commercial environments.
B.1 User identification
The recommended policy requires that, except for an initial migration, all users
must be identified and verified by RACF;in other words, undefined users are not
permitted. RACF principally allows for undefined users for two reasons:
To support an initial migration to a secured environment, and
To ensure uninterrupted system availability
Techniques to prohibit undefined user IDs vary with the processing environments,
as outlined in the following sections.
B.1.1 Batch
SETROPTS BATCHALLRACF is a global RACF option that enforces the requirements for
all batch jobs to have a valid RACF user ID, either through coding USER=user ID
on the job statement or through propagation (inheritance).
B.1.2 TSO
To prohibit undefined TSO users, all user IDs defined in SYS1.UADS must also
be defined to RACF. The recommended implementation is to use RACF TSO
segments for all TSO users and to keep only a few emergency user IDs in
SYS1.UADS. In any case, procedures must be implemented to ensure that the
RACF database and whatever entries remain in SYS1.UADS are synchronized, and
that user IDs deleted from RACF are also removed from the SYS1.UADS data
set.
B.1.3 Started procedures (STC)
Started procedures are considered part of the computing environment that is
essential to the availability and functionality of the MVS system. IBM has
therefore implemented RACF STC support with focus on availability, i.e., with the
goal to allow rather than disrupt the start of procedures. Procedures will start with
an undefined user ID under the following conditions:
The STC user ID (either assigned specifically or through the generic entry in
the STC table) is not a RACF-defined user ID, or
The user ID is not connected to the group specified in the table
100 CA-Top Secret to OS/390 Security Server Migration Guide
Undefined user IDs for started procedures can be prohibited by coding a generic
entry containing a default ID such as */STCDEF/STCGRP and by ensuring that all
entries in the table are error-free.
User IDs that are assigned to started procedures should have the PROTECTED
attribute. Protected user IDs are user IDs that have both the NOPASSWORD and
NOOIDCARD attribute. Protected user IDs cannot be used to logon to the
system, and are protected from being revoked through incorrect password
attempts.
A started procedure can gain access to RACF-protected resources in the
following ways;
By the user ID or group name assigned, as for any other user of the system.
By having the privileged attribute, which allows the started procedure to pass
all authorization checking. No installation exits are called, no SMF records are
generated, and no statistics are updated. Use this option with extreme
caution.
By having the trusted attribute, which mean the same as privileged, except
that you can request an audit using the SETROPTS LOGOPTIONS command.
Policy enforcement for all environments can be complemented by monitoring
SMF audit trails and, if required, by coding a RACINIT exit terminating all
requests for establishing a RACF environment for the default user ID.
B.2 Resource protection
The recommended policy requires default protection;that is, the prohibition of
access to unprotected (undefined) resources. The techniques used in RACF to
implement such policy vary with the type of resource, as described in the
following sections.
B.2.1 Data sets
Default protection for data sets can be activated through SETROPTS
PROTECTALL(FAIL). When turned on, unprotected data sets can only be accessed
by system-level SPECIAL users. WARN mode is available to ease migration.
B.2.2 Transactions and other resources
Default protection over general resources can be achieved through a variety of
controls:
Program logic in resource managers calling RACF
Settings in the RACF CDT
Catch-all profiles with UACC=NONE and restrictive specific access
We recommend catch-all profiles because the logic applied by resource
managers may not always be known, and changing CDT entries for existing
resource classes may not be desirable.
Appendix B. Security policy considerations 101
B.3 Authentication
Policy to establish personal accountability must address user behavior as well as
strong technical authentication mechanisms. RACF standard user authentication
is based on user-selected passwords;another technique supported is RACF
passtickets.
B.3.1 Passwords
Two separate issues must be addressed for RACF passwords, the technique
through which passwords are secured when stored in the RACF database and
password quality controls.
The recommended standard for password protection is DES encryption. Starting
with RACF release 2.1, this is the default. For earlier releases, the RACF exit
ICHDEX01 must either be deleted or modified to select DES encryption instead of
password hashing.
Password quality controls are SETROPTS PASSWORD options, as listed below (together
with generally recommended settings):
rule1(length(6,8) alphanum(1,8) - minimum length 6, alphanumeric with a
least one character being numeric
interval(30) - expiration after 30 days
history(32) - remember 32 previous passwords
revoke(3) - revoke ID after 3 invalid password attempts
A related SETROPTS option is:
inactive(30) - revoke user ID after 30 days of inactivity
B.3.2 Passtickets
RACF offers advanced authentication through passtickets, which are generated
by specific products supporting this form of user authentication.
B.4 Naming conventions
Recommended policy is to establish and enforce adequate naming conventions
for all subjects and objects. The RACF support of such policy is discussed in the
following sections.
B.4.1 Data sets
Native RACF strictly enforces data set high-level-qualifier (HLQ) naming
conventions;in a PROTECTALL(FAIL) environment, only HLQs that match user IDs
or group names can be created or accessed. Naming convention tables and exits
can be used to transform other naming conventions to the RACF standard.
The enforcement of standards beyond the HLQ is possible but may not always be
practical because it limits the use of high-level generic dataset profiles (such as
HLQ.**).
102 CA-Top Secret to OS/390 Security Server Migration Guide
B.4.2 Other resources
The use of catch-all profiles helps enforce naming conventions for general
resources;generic profiles, if used, must be designed accordingly.
B.4.3 Users and groups
User IDs and group names are not controlled by RACF in a way that allows
enforcement of local naming standards.
B.5 Ownership
Recommended policy is to assign resource ownership to business managers
responsible for an application or business area. RACF practice suggests group
ownership of profiles and offers an approximation to policy, provided the group
structure reflects applications and business areas adequately and custodians are
properly assigned as group administrators.
B.6 Security administration
Recommended policy addresses many aspects of security administration;some
can be supported by RACF, as discussed in the following sections.
B.6.1 Structure
Security administration tasks are typically performed within the following
structures:
Central security administration
Group administration or functional delegation
Help desk
Mandatory central security administration uses the RACF system-level SPECIAL
attribute to define or alter all but a few profiles and options in RACF. To set or
change some specific audit-related settings requires the system-level AUDITOR
attribute.
Optional group administration in RACF is based on group-SPECIAL, which provides
authority within the scope of a group, or on a privilege called class authorization
(CLAUTH), or both. Most policy requirements for group administration can be met
by assigning group-SPECIAL and possibly CLAUTH, and by defining the scope of
authority (based on group ownership).
Typical help desk functions such as user ID RESUME and password RESET can
be implemented through the RACF FACILITY class, group-SPECIAL,or
organizations have chosen other (limited) solutions through special programs that
run authorized and use authorization schemes other than group-SPECIAL.
B.6.2 Effectiveness
Recommended policy requires security administration to be effective, i.e., to
minimize potential risks through errors and omissions, particularly in the area of
temporary access and authorization. Typical precautions are automatic expiration
dates on user IDs and permissions. RACF provides the direct ability to expire
Appendix B. Security policy considerations 103
user IDs automatically through coding REVOKE(date) in user definitions;for
permissions, expiration dates can be established indirectly through group
connections.
B.6.3 Efficiency
Recommended policy also requires security administration to be efficient, to
ensure that administration workload problems do not contribute to risks.
Efficient RACF administration uses two main elements: generic profiles, and
group authorization on access lists. The use of generic profiles reduces, in
comparison with discrete ones, the number of profiles to be defined and
maintained. Using groups instead of user IDs on access lists dramatically
simplifies the management of a changing user population.
B.7 Audit considerations
Recommended policy requires a reasonably complete audit trail and firm
procedures to monitor and review security events and status information.
B.7.1 Logging
RACF provides an audit trail of security-related events through SMF;the nature
and amount of information recorded is controlled by RACF options and profile
definitions as discussed below:
SETROPTS SAUDIT,OPERAUDIT CMDVIOL and INITSTATS are the recommended
standard settings, which include privileged user activities.
AUDIT(SUCCESS(UPDATE) FAILURE(READ)) is the recommended standard profile
option, unless specific reasons exist for different settings.
The RACF Global Table should not cover any resources for which an audit trail
is needed.
UAUDIT should be used rather carefully because, if used generously, it may
create a significant amount of noise records.
B.7.2 Event monitoring
Recommended policy requires regular event monitoring. We recommend putting
as much emphasis on success as on detected violations. RACF provides four
reporting options:
Data Security Monitor (DSMON) provides “canned” RACF database and
OS/390 auditing reports.
The RACF report writer allows for ad hoc violation reporting.
The database unload and SMF unload feature allows you to unload the RACF
database and violation records from SMF into flat files.
The RACFICE reporting tool includes over 30 sample reports, and uses the
DF/SORT ICETOOL report generator.
104 CA-Top Secret to OS/390 Security Server Migration Guide
B.7.3 Status review
Recommended policy requires periodic security status monitoring and full
security audits. The RACF DSMON utility provides basic event monitoring
capabilities. The RACF data unload utility converts SMF records into a format that
can be easily processed by a relational database or other tools. For detailed
information on RACF reporting tools, visit the RACF Web site.1For more detailed
monitoring, or for a full analysis, third-party tools should be considered.
B.8 Resource utilization
Recommended policy and common sense require that the security monitors
performance impact be minimal.
B.8.1 Performance options
RACF offers key performance options that should be used in order to comply with
policy:
Resident blocks in the RACF data set name table - recommended value 255
Global table entries for trivial access in class DATASET - recommended entry
&RACUID/ALTER
B.8.2 Potential performance impact
Performance impacts may be caused by the following RACF practices:
Extensive use of discrete profiles in class DATASET
Poor use of generic profiles, such as a huge number of profiles under one
HLQ
No global table in large TSO environments
1OS/390 Security Server Audit Tool and Report Application (SG24-4820)
© Copyright IBM Corp. 2000 105
Appendix C. Frequently asked questions
Q. When protecting an HLQ for a production application (when there is no user
with a corresponding user ID), when should I use a group name for the HLQ and
when should I simply create an artificial user ID?Why?
A. Defining a group is the normal approach and this is a normal use for group
definitions. We recommend using user IDs only for real users. (Some exceptions
exist;artificial user IDs might be used for started task control, for example.) There
is no strong technical reason for this recommendation;it is simply that using
groupids provides a more orderly way to manage access to application data sets.
Q. Can I prevent users from PERMITing access to files they own?How?
A. Yes. The most global way to do this is to remove access to the PERMIT
command. However, we recommend that you do not do this unless there is a
particular, pressing need. Experience has shown little need to hide the PERMIT
command.
Q. How can I control the number of PERMITs created by a user?Should I worry
about this?
A. Again, experience has shown that this is not normally a problem to worry
about.
Q. Do I need to reorganize the RACF database?Also the backup database?How
often?
A. The IRRUT400 utility can be used to reorganize the RACF database.
Experience has shown that this does not need to be done frequently. Some
installations never reorganize their database. Others do it every month or so.
Reorganizing every six months seems to be a medial position. The backup
database is subject to the same reorganization process.
Q. Can I make simple backups of the RACF database?(Without the complication
of using IDCAMS?)
A. IDCAMS is never needed with RACF. You can use the IRRUT200 utility
provided with RACF. You could use something as simple as IEBGENER, although
IEBGENER (or other similar utilities) will not interlock with RACF to provide a
self-consistent copy. IRRUT200 provides the proper interlocks (without effectively
stopping RACF) so that partly updated profiles will not be copied.
Q. Can I administer RACF from CICS?
A. This ability is not part of the basic RACF product. There are third-party tools
that provide this ability. Some installations have written their own tools, often
based on submitting a jobs from CICS (via an internal reader) that executes the
appropriate RACF commands. We do not recommend this approach unless you
have the skills to assure the security of design. Note that APPC interfaces can
also be used to schedule RACF administrative commands.
106 CA-Top Secret to OS/390 Security Server Migration Guide
Q. What authority does a help desk need?
A. A help desk, especially one that is related to a specific set of departments, is
often given access via the RACF Facility class parameter or GROUP SPECIAL
authority for those departments. This permits the help desk personnel to make
almost any RACF adjustments to users who are members of the groups
associated with these departments.
There is considerable debate over what authority is appropriate for help desk
operations. The trend is to give them less absolute authority, and more tools to
perform specific functions. This debate is more related to appropriate security
policy than to specific RACF functions.
Q. How do I add a segment to an existing user ID?For example, add CICS to a
TSO user?
A. The ALTUSER command provides this function.
Q. What do I need to do to share my RACF database between multiple OS/390
systems?
A. Nothing;this function is automatic. You need the appropriate shared-DASD
hardware, of course. If sysplex functions are available, a higher-performance
mode of sharing can be used.
A major difference between sysplex and a conventional large computer systems
is the improved growth potential and level of availability in a sysplex. The
Coupling Facility allows OS/390 and other software to share data concurrently
among multiple systems in the sysplex, with the goal of maintaining a single
system image.
Q. Someone gave me some interesting programs that use the RACF ICHEINTY set
of macros. Should I consider using these?
A. The ICHEINTY macro is the low-level interface to the RACF database. At this
level, RACF does not check updates for consistency. A poorly designed program
issuing these macros could destroy your database, or, worse, introduce subtle
errors that grow over time. We recommend not using this level of interface unless
you really trust the design of the program issuing the commands, or have a very
unusual requirement. There are helpful and trustworthy programs that use
ICHEINTY, but there is no easy way to determine if your programs are in this
trustworthy and useful group.
Q. I want to see my RACF database contents. The TSO commands and ISPF
panels only deal with a small number of elements at one time, and I cannot get an
overall picture of what is in the database. How can I do this?
A. You can use the RACF database unload utility. With it, you can see every
profile in the database, in a printable format. For anything larger than a trivial
database, this may not be useful for direct human viewing. It can be used as input
to other (locally written) programs, or be used to load DB2 or something similar.
The RACF SEARCH command can be used to find and display profiles. The
RACFICE reporting tool is available, which includes over 30 sample reports, and
uses the DF/SORT ICETOOL report generator.
Appendix C. Frequently asked questions 107
Q. Do I need to train all my users for RACF?
A. Probably not, especially if you have a well-designed group structure and
well-designed generic profiles. A relatively short note might be used to inform
users about any changes in logon processing.
Your help desk staff and your group administrators may require more education.
Q. Can I list the passwords of my users?I have SPECIAL authority.
A. RACF can store passwords in two forms: encrypted and hashed. The
encrypted form is the default. The hashed form can be recovered;IBM does not
provide details about how to do this, but there are many informal programs that
do it. We strongly recommend using the encrypted form. There is no way to list
the original passwords, once they have been encrypted.
Q. After I install RACF, can I run my OS/390 system without it?What if I make a
change that locks out users?
A. Once installed, you can run without RACF. This is a very special mode,
awkward to use, and suitable for only a single user on the system. In effect,
OS/390 issues a console message for every data set allocation, and the OS/390
operator must reply to each message in order for the user to log on and repair the
problem. In addition, the user ID used in this situation must be defined in
SYS1.UADS. This is so rarely used that many installations and systems
programmers have never experienced the situation.
108 CA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 109
Appendix D. Special notices
This publication is intended to help system programmers, security administrators,
and security officers, who are planning a migration from CA-Top Secret to IBM’s
SecureWay Security Server for OS/390. The information in this publication is not
intended as the specification of any programming interfaces that are provided by
SecureWay Security Server for OS/390. See the PUBLICATIONS section of the
IBM Programming Announcement for SecureWay Security Server for OS/390 for
more information about what publications are considered to be product
documentation.
References in this publication to IBM products, programs or services do not imply
that IBM intends to make these available in all countries in which IBM operates.
Any reference to an IBM product, program, or service is not intended to state or
imply that only IBM's product, program, or service may be used. Any functionally
equivalent program that does not infringe any of IBM's intellectual property rights
may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact IBM Corporation, Dept.
600A, Mail Drop 1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The information contained in this document has not been submitted to any formal
IBM test and is distributed AS IS. The use of this information or the
implementation of any of these techniques is a customer responsibility and
depends on the customer's ability to evaluate and integrate them into the
customer's operational environment. While each item may have been reviewed by
IBM for accuracy in a specific situation, there is no guarantee that the same or
similar results will be obtained elsewhere. Customers attempting to adapt these
techniques to their own environments do so at their own risk.
Any pointers in this publication to external Web sites are provided for
convenience only and do not in any manner serve as an endorsement of these
Web sites.
110 CA-Top Secret to OS/390 Security Server Migration Guide
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
The following terms are trademarks of other companies:
Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything.
Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli,
and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems
Inc., an IBM company, in the United States, other countries, or both. In Denmark,
Tivoli is a trademark licensed from Kjøbenhavns Sommer - Tivoli A/S.
C-bus is a trademark of Corollary, Inc. in the United States and/or other countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc. in the United States and/or other countries.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States and/or other countries.
PC Direct is a trademark of Ziff Communications Company in the United States
and/or other countries and is used by IBM Corporation under license.
ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel
Corporation in the United States and/or other countries.
UNIX is a registered trademark in the United States and other countries licensed
exclusively through The Open Group.
SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned
by SET Secure Electronic Transaction LLC.
Other company, product, and service names may be trademarks or service marks
of others.
IBM
AT
CICS
Current
DFSMSrmm
Netfinity
RACF
RS/6000
SecureWay
System/390
400
Approach
Notes
Redbooks Logo
AS/400
C/MVS
CT
DB2
DFSORT
OS/390
RMF
S/390
SP
VTAM
Lotus
Lotus Notes
Redbooks
© Copyright IBM Corp. 2000 111
Appendix E. Related publications
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this redbook.
E.1 IBM Redbooks collections
Redbooks are also available on the following CD-ROMs. Click the CD-ROMs
button at ibm.com/redbooks for information about all the CD-ROMs offered,
updates and formats.
E.2 Other resources
These publications are also relevant as further information sources:
SecureWay Security Server RACF System Programmer's Guide,
SC28-1913
SecureWay Security Server RACF Security Administrator's Guide,
SC28-1915
SecureWay Security Server RACF Security Auditors Guide,
SC28-1916
SecureWay Security Server RACF Command Language Reference,
SC28-1919
CD-ROM Title Collection Kit
Number
IBM System/390 Redbooks Collection SK2T-2177
IBM Networking Redbooks Collection SK2T-6022
IBM Transaction Processing and Data Management Redbooks Collection SK2T-8038
IBM Lotus Redbooks Collection SK2T-8039
Tivoli Redbooks Collection SK2T-8044
IBM AS/400 Redbooks Collection SK2T-2849
IBM Netfinity Hardware and Software Redbooks Collection SK2T-8046
IBM RS/6000 Redbooks Collection SK2T-8043
IBM Application Development Redbooks Collection SK2T-8037
IBM Enterprise Storage and Systems Management Solutions SK3T-3694
112 CA-Top Secret to OS/390 Security Server Migration Guide
© Copyright IBM Corp. 2000 113
How to get IBM Redbooks
This section explains how both customers and IBM employees can find out about IBM Redbooks, redpieces, and
CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
Redbooks Web Site ibm.com/redbooks
Search for, view, download, or order hardcopy/CD-ROM Redbooks from the Redbooks Web site. Also read
redpieces and download additional materials (code samples or diskette/CD-ROM images) from this Redbooks
site.
Redpieces are Redbooks in progress; not all Redbooks become redpieces and sometimes just a few chapters will
be published this way. The intent is to get the information out much quicker than the formal publishing process
allows.
E-mail Orders
Send orders by e-mail including information from the IBM Redbooks fax order form to:
Telephone Orders
Fax Orders
This information was current at the time of publication, but is continually subject to change. The latest information
may be found at the Redbooks Web site.
In United States or Canada
Outside North America
e-mail address
pubscan@us.ibm.com
Contact information is in the How to Ordersection at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
United States (toll free)
Canada (toll free)
Outside North America
1-800-879-2755
1-800-IBM-4YOU
Country coordinator phone number is in the How to Ordersection at
this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
United States (toll free)
Canada
Outside North America
1-800-445-9269
1-403-267-4455
Fax phone number is in the How to Ordersection at this site:
http://www.elink.ibmlink.ibm.com/pbl/pbl
IBM employees may register for information on workshops, residencies, and Redbooks by accessing the IBM
Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials
repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical
professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for
redbook, residency, and workshop announcements.
IBM Intranet for Employees
114 CA-Top Secret to OS/390 Security Server Migration Guide
IBM Redbooks fax order form
Please send me the following:
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
Title Order Number Quantity
First name Last name
Company
Address
City Postal code
Telephone number Telefax number VAT number
Invoice to customer number
Country
Credit card number
Credit card expiration date SignatureCard issued to
© Copyright IBM Corp. 2000 115
Abbreviations and acronyms
ACB Access Control Block
ACEE ACessor Environment
Element
ACID ACcessor IDentifier
APPC Advanced
Program-to-Program
Communications
API Application Programming
Interface
CBIPO Custom-Built Installation
Process Offering
CDSA Common Data Security
Architecture
CDT Class Descriptor Table
CICS Customer Information Control
System
CLAUTH CLass AUTHorization
CLISTS Command Lists
CMDF Commercial Data Masking
Facility
CPU Central Processing Unit
DASD Data Access Storage Device
DB2 Database/2
DCE Distributed Computing
Environment ,component of
SecureWay Security Server
for OS/390
DDN Data Definition Name
DES Data Encryption Standard
DFDSS Data Facility/Data Storage
System
DFP Data Facility Product
DFSMS Data
Facility/System-Managed
Storagey
DLF Data Lookaside Facility
DNS Domain Name Services
DSMON Data Security Monitor
EOS Erase On Scratch
FTP File Transfer Protocol
GAC Global Access Checking
GID UNIX Group IDentifier
GRS General Resources
HFS Hierarchical File System
HLQ High Level Qualifier
ICB Inventory Control Block
IBM International Business
Machines Corporation
IMS Information Management
System
IPL Initial Program Load
IPSec Information Protocol Security
ISPF/PDF Interactive System
Productivity Facility/Program
Development Facilityi
ISV Independent Software Vendor
ITSO International Technical
Support Organization
JCL Job Control Language
JES Job Entry Subsystem
LDAP Lightweight Directory Access
Protocol, component of
SecureWay Security Server
for OS/390
LPA Link Pack Area
MVS Multiple Virtual Storage
NAT Network Address Translation
NDS Novell Directory Services
NJE Network Job Entry
OCEP Open Cryptographic
Enhanced Plug-ins,
component of SecureWay
Security Server for OS/390
OMVS Open Edition for MVS
OVM Open Edition for VM
PADS Program Access to Data Sets
PCICC PCI Cryptographic
Coprocessor
PGM Program
PKI Public Key Infrastructure
PL/I Programming Language/1
RACF Resource Access Control
Facility, component of
SecureWay Security Server
for OS/390
RJE Remote Job Entry
RJP Remote Job Process
116 CA-Top Secret to OS/390 Security Server Migration Guide
RRSF RACF Remote Sharing
Facility
SA Security Association
SAF System Authorization Facility
SDSF System Data Spool Facility
SMF System Management
Facilities
SMPO Software Migration Project
Office
SMS Storage Management
Subsystem
SNA Systems Network Architecture
SPT Started Procedures Table
STC Started Task Control
SYSRES System-resident pack
TME Tivoli Management
Environment
TMP Terminal Monitor Program
TSO Time Sharing Option
UACC Universal ACCess authority
UADS User Attribute Data Set
UID User IDentifier
USS UNIX System Services
VM Virtual Machinge
VOL Volume
VPN Virtual Private Network
VSAM Virtual System Access
Method
VTAM Virtual Telecommunications
Access Method
© Copyright IBM Corp. 2000 117
Index
A
ACCESS 66
ACID 33,66
ACIDS 54
list 56
ACTION 69
ADDGROUP 54
ADDSD 65
ADDUSER 54
Administration and Maintenance 83
Administrative Interface 83
Availability Considerations 89
Commands 84
RACF Performance Considerations 90
RACF Utilities 86
Security Reports 86
administrative 54
Administrative Groups 54
ALL Record 36,69
Analyze the current security environment 45
Application Project Leaders 43
Assess 40
B
Backout plan 48
C
CA-Top Secret
Access Authority
ALL 37
CONTROL 37
CREATE 37
FETCH 37
READ 37
SCRATCH 37
UPDATE 37
WRITE 37
Database Files
Audit/Tracking File 38
Backup File 38
Parameter File 38
Recovery File 38
Security File 38
Modes of Operation
DORMANT 33
FAIL 33
IMPL 33
WARN 33
CA-Top Secret Overview 33
CA-Top Secret Environment 36
ALL Record 36
CA-Top Secret Database Files 38
Personnel 36
Resource Rule 37
CA-Top Secret Security Philosophy 33
CA-Top Secret Subsystem Interfaces 38
CICS 38
DB2 38
IMS 38
TSO 38
CDSA 17
CDT 26,77
CICS 1
Class Descriptor Table 26,77
CMOS Cryptographic Coprocessor 18
Common Data Security Architecture 17
CONNECT 35,55
conversion 95
Conversion Programmer 43
Convert 40
Convert the security database 47
Coupling Facility 3
Customize RACF 46
D
DASD 41
Data set protection
Defining 65
Database Migration 51
Conversion Methodology 51
Migration Considerations 51
Converting ACIDs 52
Converting PROFILE ACIDs 55
Converting Security Administrator ACIDs 58
Converting User ACIDs 57
Converting Zone, Division and Department ACIDs
54
Listing the CA-Top Secret ACIDs 54
Other CA-Top Secret User ACID Parameters 62
PASSWORD 60
Reviewing and Defining ACIDs to RACF 54
User/Group Migration Issues 53
Converting Data Sets 62
Data Control Groups and the RACF High-level
Qualifier 65
Data Set Access 66
Defining Data Set Protection in RACF 65
More Data Set Considerations 71
Other Migration Issues 69
Overview 64
Protection Based on User vs Resource 63
Undercutting Considerations 67
Converting Resources 72
DB2 75
FACILITIES 72
LCF AUTH/EXMP 75
OTRAN 74
PROGRAM 76
TERMINAL 76
User Defined Resources 77
VOLUME 73
XA ACID 77
Converting System-Wide Options 80
118 CA-Top Secret to OS/390 Security Server Migration Guide
Common System-wide Security Options 80
CPF 80
Passwords 81
Protection Modes 80
RACF Options 81
Other Considerations 78
Data-Set Name Table 19
Dataset profiles 65
DB2 1
DB2 cascading revoke 6
DCA 36
DCE 13,14
Departments 54
DFSMS 1
Digital Certificate 2
Divisions 54
DSMON 4,103
E
Education 43
requirements 43
F
FACILITY 38,72
Financial Benefits of the Security Server
Identifying Monetary Savings Based on Product Price
3
Identifying Productivity Savings 3
Frequently Asked Questions 105
FTP 14
G
Generic characters 65
Group 24
GROUPING CLASS 26
GROUPS 23
Default group 23
definition 24
scope 25
H
Hardware Environment 41
High-level qualifier 46,65
I
IBM Migration Services 95
Conversion vs. Migration 95
Getting Started 98
Mainframe System Software 95
Migration Service Offerings 96
Database Conversion Service 96
Learning Services 97
Migration Assessment Service 96
Migration Consulting Services 96
Migration Perform Services 96
Migration Services 95
Migrations - No Two Alike 95
Product Migrations 97
IBM migration services 95
ICETOOL 5
ICHRDSNT 19,20
Identify project team 45
Install RACF 46
Integration testing 48
Interface 21,30
IPL 19,47
operator replies 20
IPsec 2
IRR@XACS 7
IRRUT100 86
IRRUT200 86,105
IRRUT400 105
K
Kerberos 1,13,16
L
LDAP 2
Lightweight Directory Access Protocol 2,15
LSCA 36
M
MERGE,ALLMERGE 69
MERGE,ALLOVER 68
migration 95
migration service offerings 96
migration services 95
MSCA 36
MVS System Programmer 43
N
Naming conventions 46
NAT 14
NDS 3
Network Authentication and Privacy Service 16
Novell Directory Services 3
O
OCEP 1,17
OCSF 17
Online System Programmers 43
Open Cryptographic Enhanced Plug-ins 17
Open Cryptographic Service Facility 17
OPERATIONS 62
OS/390 Security Server
Firewall Technologies 1
Network AuthenticationandPrivacyService (Kerberos)
1
Open Cryptographic Enhanced Plug-ins 1
OS/390 DCE Security Server 1
OS/390 LDAP Server 1
RACF 1
OVERRIDE,ALLOVER 33,36,67
OVERRIDE,MERGE 33
119
P
PCI Cryptographic Coprocessor 18
PCICC 18
PERMIT 65
PKI 2
Planning 45
PPT 62
Preserve CA-Top Secret Databases 48
Profiles 22,35,55
CA-TOP SECRET 35,55
connect 23
dataset 25
discrete 25
general resource 25
generic profile 25
group 24
Owner 25
search order 26
user 23
Program Property Table 62
Project Leader 43
Project management 45
Project phases
Planning 44
Project Team 45
Public Key Infrastructure 2
R
RACF
Install 41
Install and Customize 46
RACF database 20,27
name by ICHRDSNT 20
name by operator replies 20
name in MSTRJCL 20
RACF group structure planning 46
RACF Information Flow 21
RACF Migration Project Overview 39
Building the migration project plan 44
Significant Project Tasks 45
Preparing for the migration project plan 39
Education 43
Personnel 42
Review the current CA-Top Secret environment 40
Resource scheduling 49
Summary 49
RACF Overview 19
Information Flow 20
Authorization Flow 22
Interfaces 30
Product Interfaces 30
RACF Exits 31
SAF Interface 31
Vocabulary 23
Commands 28
Owner 25
RACF Database 27
RACF Group 24
RACF Protected Resources 25
RACF System Wide-Options 27
RACF User 23
RACF Remote Sharing Facility 80
RACF Report Writer 4
RACF's Remote Sharing Facility 4
RACF/DB2 Security Administration Overview
Benefits Using RACF to Administer your DB2 Security
6
Financial Benefits 7
Migration Issues
Protection of DB2 resources via RACF 6
Product Benefits 7
RACFICE 5,103,106
RDT 77
Reporting Options
Data Security Monitor 4
RACF Database Unload 4
RACF Remove ID Utility 5
RACF Report Writer 4
RACFICE 5
SMF Unload 4
Resource Access Control Facility 11
Resource Descriptor Table 77
Review naming conventions 46
Review security procedures 46
RRSF 4,80
RULE 37
S
SAF 21,22,31
SCA 36
SecureWay Security Server for OS/390 11
Introduction into the SecureWay Security Server for
OS/390 11
DCE Security Server 13
LDAP Server 15
Network Authentication and Privacy Service (Ker-
beros) 16
OS/390 Firewall Technologies 14
OS/390 Open Cryptographic Services Facility 17
Resource Access Control Facility (RACF) 11
SecureWay Branding 11
Security Administrator 42,58
Defining to RACF 59,61
SPECIAL attribute 59,61
Security Policy Considerations 99
Audit Considerations 103
Event Monitoring 103
Logging 103
Status Review 104
Authentication 101
Passtickets 101
Passwords 101
Naming Conventions 101
Data Sets 101
Other Resources 102
Users and Groups 102
Ownership 102
Resource Protection 100
Data Sets 100
120 CA-Top Secret to OS/390 Security Server Migration Guide
Transactions and Other Resources 100
Resource Utilization 104
Performance Options 104
Potential Performance Impact 104
Security Administration 102
Effectiveness 102
Efficiency 103
Structure 102
User Identification 99
Batch 99
Started Procedures (STC) 99
TSO 99
Security procedures 46
SMPO 95
SOCKS 14
Software Migration Project Office 95
Started tasks 78
SURROGAT 77
SYSRES 41
System environment 41
T
Test environment 46
Test system
determine requirements 41
Testing 47
The Value of the SecureWay Security Server for OS/390 1
Overview of the Security Server 1
Business Benefits of the Security Server 1
Financial Benefits of the Security Server 3
RACF Administrative Highlights 3
RACF Administrative Enhancements 3
RACF/DB2 Security Administration Overview 5
RACF Market Penetration 8
U
Unit testing 47
UNIX System Services 3
Unknown RefID_g001
Data control 65
functional 35,55
Unknown RefID_s006
Review 41
UNTIL function 70
User 23
attributes 23
profile 23
Users 57
Converting 57
Defining to RACF 58
V
VCA 36
Virtual Private Network 2
VLF 91
VPN 14
X
XA ACID 77
XA DATASET 33,64
XA Facility 37
XA IBMGROUP 75
XA otran 37
XA terminal 37
XA VOLUME 73
Z
ZCA 36
© Copyright IBM Corp. 2000 121
IBM Redbooks review
Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook
"made the difference" in a task or problem you encountered. Using one of the following methods, please review the
Redbook, addressing value, subject matter, structure, depth and quality as appropriate.
Use the online Contact us review redbook form found at ibm.com/redbooks
Fax this form to: USA International Access Code + 1 914 432 8264
Send your comments in an Internet note to redbook@us.ibm.com
Document Number
Redbook Title
SG24-5677-00
CA-Top Secret to OS/390 Security Server Migration Guide
Review
What other subjects would you
like to see IBM Redbooks
address?
Please rate your overall
satisfaction:
O Very Good O Good O Average O Poor
Please identify yourself as
belonging to one of the following
groups:
OCustomer
O Business Partner
O Solution Developer
O IBM, Lotus or Tivoli Employee
O None of the above
Your email address:
The data you provide here may be
used to provide you with information
from IBM or our business partners
about our products, services or
activities.
O Please do not use the information collected here for future marketing or
promotional contacts or other communications beyond the scope of this
transaction.
Questions about IBM’s privacy
policy?
The following link explains how we protect your personal information.
ibm.com/privacy/yourprivacy/
(0.2spine)
0.17<->0.473
90<->249 pages
CA-Top Secret to OS/390 Security Server Migration Guide CA-Top Secret to OS/390 Security Server Migration Guide
®
SG24-5677-00 ISBN 0738418919
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:
ibm.com/redbooks
CA-Topsecret to
OS/390 Security Server
Migration Guide
Product design
similarities and
differences
Planning the
migration
Conversion
methodologies
CA-Top Secret and the OS/390 Security Server are both
sophisticated products. In some areas their designs are similar,
and in other areas the designs are very different. Planning a
migration from CA-Top Secret to the RACF element of the OS/390
Security Server, without unduly disrupting an OS/390 production
environment, requires considerable planning and understanding.
With proper planning, and perhaps with specially skilled people
to assist in certain areas, the migration can usually be
accomplished in an orderly way.
Understanding the higher-level issues and differences between
the two products is an important starting point. This redbook is
intended to assist in this area.

Navigation menu