Summary

As an overall strategy in organizing for RACF® implementation, the implementation team should strive for a policy of security by evolution, rather than revolution. Wherever transparency can be used, it should be. In some cases, you must actively solicit management support.

You should examine organizational structures to establish the most efficient profile ownership structures, educate users with the level of information they need to perform their assigned functions, and prepare guidelines for the various administrators.

Finally, you and the implementation team should prepare an implementation plan to guide the work of the team. Table 1 provides a checklist for the implementation team to use while preparing the implementation plan. Note that this checklist represents only a starting point; it is not meant to be exhaustive.

Table 1. Checklist for implementation team activities
Item	Comments
Objectives	What are the installation's security objectives? Over what time frame are they to be achieved? Is the position of management clear on all objectives? Is the statement of security policy clear and complete for all objectives?
Protection	What resource classes are to be protected? What resources within these classes are to be protected? Can protection be phased in? Which resources must be protected, and when?
Naming conventions	What installation data set or general resource naming conventions already exist? Are changes necessary? Does implementing RACF provide an opportunity to enforce naming conventions? If so, can they be enforced across the entire installation or only over a subset of the installation? Immediately or eventually?
Organization	Can the definition of RACF groups (and their associated users) be mapped to the existing organizational structure? What changes to the organizational structure, if any, are necessary? How is RACF to be controlled and administered? Which functions are to be retained centrally? Which functions are to be delegated, wholly or in part? Which users should have what RACF attributes?
User and group names	What names are to be established for groups and user IDs? Which groups and users are to be defined to RACF? Which user verification technique is to be used?
Transparency	Try to make RACF transparent to your users wherever possible. Which resources can be protected by generic profiles? Which resources require discrete profiles? Which users and groups should be placed in the access lists, and with what access authorities? What deviations from strict user accountability are to be allowed, and for how long?
RACF tailoring	Which RACF exits are to be used, if any, and under what conditions?
Authorizations	What authorizations are required for the program properties table (PPT), APF libraries, and similar items?
Recovery	What recovery procedures must be established?
Violation procedures	What security procedures for logging, reporting, and auditing must be established?
Subsystems	What are the security requirements for IMS™, CICS®, and other subsystems?
Storage Management Subsystem (SMS)	Is your data managed by SMS? If it is, what is required for your SMS constructs, application IDs, and data set owners?
Test plan	What is the plan for testing the RACF implementation?
Education	What is the plan for preparing user documentation and other educational material? Should there be a newsletter for most users and more detailed education for group administrators?
Install RACF	What RACF options are to be used? What is the plan for installing RACF?
Monitor	After beginning to define groups, users, generic profiles, and data for a pilot group, how will progress against your implementation plan be monitored? What procedures will be established to ensure that future applications receive the appropriate security considerations?