Conversion from CA Top Secret (TSS) to RACF
This offering includes 5 deliverables: review of the present TSS security system, preparation of a migration plan, actual conversion, RACF administration and reporting.post-conversion testing and tuning. If the client has more than one LPAR to convert (for example, TEST and PROD) then all 5 deliverables are needed separately for each LPAR.
Deliverable One: Review of present TSS Security System
During the years, depending on their security policy and business needs, each institution has added various IBM and 3rd party subsystems and products resulting in quite distinct TSS implementations. Therefore, the Review (mostly examination of the TSSCFILE and interviews with main stakeholders) serves as a base for a unique conversion proposal.
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. In most cases, each vendor’s product documentation will have
published RACF installation instructions and these should be reviewed. We
Identify all vendor product features you are using for which RACF does not
have an equivalent function for, then we determine alternative ways of providing
the same protection using RACF functions. Also, we will check your OS/390
base product code for any security-related usermods, accounting exits, JES2
exits, and so forth.
1.2 Decide on how to
convert the security database
Our choice is a combination of:
• Leasing a conversion tool.
• Wrap RACF commands around specific output from TSS, master catalog,
whenever tool is not enough.
• Propose new group structure.
• Manual adjustments.
1.3 Analyze the current
system environment
We will complete a comprehensive, detailed review of any products, programs,
or interfaces that perform security functions. We may have to modify program
code or write program code or exits. To analyze your current system environment,
we start by listing all hardware and software products you have installed.
For each 3rd party product that has a security interface, we define entries
in the Class Definition Table (ICHRRCDE) and Router Table (ICHRFR01).
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. We
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.
1.5 Assemble a conversion
team
After the Review is complete, a conversion team including our consultants
and client's personnel (representatives from systems programming, security
and application programming) is assembled with an appointed project manager.
We work hard to convince the client that some changes are inevitable by explaining
their benefits.
1.6 Knowledge transfer
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. During
all stages of the project we help your staff to gain RACF skills and to understand
the nitty-gritty details of how and why things are set up.
Deliverable Two: Prepare Conversion 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.
2.1 Install RACF
We install RACF, typically on a brand new test system apart from the production
system that contains CA-Top Secret.
2.2 Prepare Conversion
Programs
In this phase, we examine the conversion programs to be used to convert the
CA-Top Secret to RACF. These programs should be customized based on your specific
requirements.
2.3 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. For example,
CA-Top Secret allows the use of generic characters for masking of high-level
qualifiers, while RACF does not.
2.4 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.
2.5 RACF group structure
planning
This is a very important part of the database conversion. Our methodology
allows us to build a RACF group structure which is manageable, well-designed,
and meets your specific needs. For example, we propose our proven implementation
of RACF default groups based on type of user: employee, contractor, machine
user etc. Also we can implement access groups based on job-role concept.
2.6 Convert the security database
In this phase, we run our conversion programs to convert the CA-Top Secret
database to RACF commands. Through repetitive executions of the tool against
the CA-Top Secret database, we are able to build a functionally equivalent
RACF database. Final testing should verify the integrity of the user ID and
resource profile definitions.
2.7 Testing
A typical RACF testing sequence, or “cycle”, might be:
• Create a RACF database to match the CA-Top Secret database.
• IPL the test system with RACF.
• 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.
2.8 Production Cutover
Before migrating RACF to production, you probably want to test RACF with the
full production system.
Successful migrations freeze all changes to CA-Top Secret shortly before the
cutover weekend.
Deliverable Three: Actual TSS to RACF conversion
This task comprises the actual database migration of CA-Top Secret to IBM’s RACF.
3.1 TSS database clean-up
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.
A fairly clean input database at the beginning of the migration will help
produce a higher quality result.
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
are the replacement of "+" symbol in HLQs for datasets and removal
of partial strings for similar datasets from TSS PROFILES.
3.2 Create RACF test
system
The RACF database is practically empty, we use userid IBMUSER to run a skeleton
set of RACF commands to activate selected options of SETROPTS, corresponding
to equivalent options from TSSPARM together with profiles in class STARTED
for a core of system address spaces and started tasks. Also several TSO userids
having SPECIAL will be created. Once RACF is up and running we propose names
for primary and backup RACF databases, prepare the ICHRDSNT module and SYS1.RACF.PARMLIB
dataset and use IRRUT200 to allocate your new RACF databases.
3.3 Review TSSCFILE
The TSSCFILE is the input to our conversion tool together with information
extracted from Master catalog with LISTCAT ALL. We will make sure that any
new HLQs specifically needed are accounted for by creating corresponding groups
and dataset profiles with the attribute of WARNING. We will eximine TSSCFILE
for completeness (for example it may not have info about logonprocs for TSO
users) and take notice to update our tools with the missing info. In case
our group methodology is accepted by the client we will feed the structure
to the conversion tool.
3.4 Automated database
conversion
The conversion consists of jobs comprising RACF commands run in the following
order:
ADDGROUP defines all RACF
groups
ADDUSER defines all userids
ALTUSER changes to userids (revoke, special attributes)
CONNECT fills groups with users
ADDSD define dataset profiles
RDEFINE defines all general resources. Grouping profiles are created later.
GROUP PERMIT place groups on access lists
USER PERMIT place userids on access lists
The results in the following areas will be carefully examined:
Dataset profiles: all
having one and the same HLQ for "undercutting" (higher RACF access).
Class STARTED: note all profiles running as trusted. Replace with specific
access.
Converted OTRAN and PPT to RACF CICS classes.
Review changes to CICS regions JCL for proper keywords (XTRAN XCMD etc) and
preset terminal security
Converted TSS FACILITY to RACF APPL class.
Converted TSS BLP to profile ICHBLP in class FACILITY.
Converted powerfull attributes SPECIAL OPERATIONS AUDITOR and their group
equivalents.
Converted TSS FACILITY TSO to TSO userids.
Review procedure for password import.
Converted DB2 to profiles in RACF classes MDSNxx and DSNADM. RACF does not
protect DB2 commands (they should be protected by internal DB2 security).
Deliverable Four: Administration, Reporting and Documentation
We will provide comprehensive review and changes to Administration procedures, changes to SMF collect procedure and a new documentation for client RACF administrators .
4.1 RACFAdministration
This task comprises: changes to security administration due to converting
to RACF, update of security request forms, proposal of 3rd party tool (Consul,
VRA etc). Changes and/or replacement for client decentralized security administration
will be provided (simplified RACF panels etc).
4.2 RACF Reporting
TSS has its own log, while RACF uses SMF. We will advise how to replace existing
TSS reporting with equivalent tools: ICETOOL reporting, DB2 queries on output
from flat datasets for RACF database and SMF record 80, Consul CARLA queries.
4.3 Documentation
We will deliver a comprehensive document consisting of description of all
implemeted RACF controls with recommendations how to create new groups, userids,
profiles for started tasks, CICS transactions etc. Suggestions for future
improvements are also included.
Deliverable Five: Post-conversion Testing and Tuning
This task must be performed as a joint effort of the conversion team and teams of testers from all client areas.
5.1 Acceptance testing
without end-users
For this task we will prepare and support the converted system for initial
verification and pre-acceptance tests by client security staff. If required,
this will include weekend support. This testing is not to include end-users
or production work. If required, during this task, the consultant(s) will
provide knowledge transfer and/or informal training on the new environment
to client security staff.
5.2 Acceptance testing with end-users
We will prepare and support the converted system for end-user testing and
verification. This end-user test is not to include production work. We will
provide onsite support including weekends for this task. No end-user training
is expected.
5.3 Production cutover
We will prepare and support the converted system for the final production
cutover. If required, this will include weekend work. Following the production
cutover, we will provide close support and monitoring of the new environment.
This will include onsite support during normal business hours and 24-hour
on-call support throughout the follow-up period. Client staff will be required
to attend the production activation.