Maintenance takes the form of updates to the CA Top Secret Security File, as well as maintenance to the CA Top Secret software itself. It is important that your maintenance procedures are in place before receiving the first request.
If you have chosen a gradual approach to security implementation (implementing functional areas and facilities one at a time), maintenance will become a requirement before the implementation is completed.
As your environment changes you are required to revise your security definitions to reflect these changes. Determine that the changes to security definitions are both necessary and legitimate. Have a CA Top Secret Security File maintenance procedure which lets you ensure that the requested revisions are correct and authorized.
If the organization is small, and the security administration staff can easily identify and control all users and resources, then the central administrators might be able to verify the requests for changes.
If the organization is large, it is difficult for the central staff to know all users and resources. They will have to depend on other individuals to verify change requests. In large organizations, or even in small ones, it is recommended that the representatives of the functional area that owns the resource(s) be responsible for verifying the necessity and accuracy of change requests. Requests should be made in writing with the proper authorization.
Many installations design security maintenance request forms that are completed by the appropriate functional area and are approved by the appropriate functional authority. The forms are submitted to the appropriate administrator for revision of the Security File. The forms are then filed as a permanent record of the request. These forms should contain all of the information necessary for the revision, including effective date, resource name and level of access required, user or profile name, and expiration date if the request is for temporary access.
Be sure that your maintenance activity follows your original Security File design. Be careful that your profile structure is not compromised by numerous requests for update to user ACID records. Review each request to ensure that the request falls in the appropriate place in the Security File. It is possible that the requestor is unfamiliar with the structure and has requested an update for an inappropriate ACID. You might have to review the request with the requestor and modify the request before the update is actually made to the Security File.
Your CA Top Secret Security File maintenance procedure should be designed for quick response. If quick response is not practical, then the turnaround time for requests should be communicated and understood by all user areas so that they can effectively plan for timely Security File revisions. Emergency procedures should be available for immediate response when required.
The ability of a central security administration staff to respond quickly to maintenance requests can determine whether you choose to decentralize CA Top Secret security maintenance. If certain areas require more timely response than is possible at the central level, you might choose to decentralize maintenance for those areas.
CA Top Secret works through the z/OS Standard Security Interface and is rarely impacted by z/OS maintenance. If you receive early releases or special releases of z/OS maintenance which revise these interfaces, take care in applying and testing this maintenance with CA Top Secret. Testing procedures for operating system software changes and upgrades should always include a verification of basic security system functions as part of the plan.
Ensure that maintenance to interfaces of other vendor products still function properly with CA Top Secret.
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|