OSS and Release Notes
Review all security-related OSS and Release notes related to upgrades and to the release you’ll be upgrading to, prior to the upgrade. It’s useful to review these before you define your workplan, in case you have to cater for any unforeseen issues or changes.
Workplan
Given the amount of work and number of steps involved in the security upgrade, it is recommended that a detailed Workplan is defined at the startup of the upgrade project. Key milestones from the security workplan should be integrated and tracked as part of the overall Upgrade Plan.
Clear ownership of activities, including conversion of Report Trees, needs to be established. This function is often perform by the Development team.
Naming conventions and standard procedures should be established before the manual profiles are reconstructed as activity groups. Each team member should know how the new activity groups should be named to ensure consistency. Other standard practices for the construction of the activity groups should include:
· Transactions are added via the Menu tab and not by manipulating s_tcode.
· Ideally, no end users should have access to SE38, SA38, SE16 nor SE17.
Remember to keep Internal Audit involved where decisions need to be made regarding the segregation of job functions or changes to current authorizations are requested or brought in with new authorization objects / defaults.
Enough resources should be allocated to the security upgrade process as each activity group and profile will require work to some degree or the other. It is important that key users and functional resources are involved in testing the activity groups and that this effort is catered for in the Upgrade Project plan. Clear ownership of each activity group should be established not only for testing purposes, but also for ongoing support and approval of changes. Ideally, the ownership and approval of changes should reside with different resources (i.e. the person requesting the addition of a transaction or authorization should not be the same person responsible for approving the request).
The security team should also establish testing objectives (whether each transaction being used in Production should be tested, whether each activity group should be tested with a representative ID, etc.).
A detailed test plan should then be established based on the approach, to ensure each person responsible for testing knows what s/he should be testing, what the objective(s) of the test is and how to report the status of each test. Both positive (user can do his/her job functions) and negative (user can’t perform any unauthorized functions) testing should be performed.
The Reverse Business Engineering (RBE) tool is very useful in identifying which transactions are actually being using in Production. This can assist with focusing on which transactions to test.
The importance of testing all used transactions individually and as part of role-testing cannot be stressed enough. TEST,TEST,TEST!
Every menu option, button, icon and available functions for all critical transactions need to be checked and tested. There are some instances where icons are grayed out or don’t even appear for certain users, due to limited authorizations. The only way these type of issues can be identified, is through thorough testing.
Due to the number of users potentially impacted by issues / changes to a single activity group, a perception can quickly be created that the security upgrade was unsuccessful or the cause of many post GoLive issues.
It is therefore recommended that an issues log is established to track and ensure resolution of issues. The log should ideally also contain a description of the resolution, to aid with similar problems on other activity groups.
This log will be helpful during the entire upgrade process, especially where more than one resource is working the same set of activity groups, so set it up at the beginning of upgrade project! You can also use this for a ‘lessons learnt’ document for the next upgrade.
The security upgrade forms an integral part of the overall upgrade given the sensitivity and frustration security issues could cause. It is important that key milestones for the security upgrade are tracked and reported on to ensure a smooth and on-time cutover.
The detailed cutover plan differs from the overall security workplan, in that the detailed plan outlines the exact steps to be taken during each system’s upgrade itself. This should include:
· Transport request numbers,
· Download of security tables prior to the upgrade, especially UST12, USOBT_C and USOBX_C,
· A backup and restore plan, (e.g. temporary group of activity groups for critical functions),
· The relinking of user master records, with details on any CATT scripts, etc. that might be used,
· User comparison, etc.
The security team needs to ensure that enough time is allocated for each action item and that this time is built into the overall cutover plan. The project manager is usually expected to give an indication to end users and key stakeholders as to when the Productive system will be unavailable during its cutover to the new release. This downtime should thus incorporate time required to perform user master comparisons, unlocking of ID’s and all other action items.
The SAP_NEW profile can temporarily be assigned to project team members to provide interim access to the new authorization objects. This provides the security team the opportunity to convert and adjust the IS team’s activity groups. It also eliminates frustration on the functional team’s side when configuring and testing new transactions, etc.
Some support team members (e.g. Help Desk members responsible for reset of user passwords, etc.) might require training and/or documentation on the changed screens of SU01, etc.
It is recommended that a basic Navigation & Settings training module is created for all SAP users and should cover the use of Favorites, etc.
The security team should also review Profile Generator in detail, as several new functions have been added (e.g. download/upload of activity groups, etc.). Remember to review all the different icons, menu options and settings on the authorizations tab, etc.
Lastly, if your company / project does use HR as related to security (activity groups and users assigned to positions / jobs), ensure that you become acquainted with the new enjoy transactions, e.g. PPOMW.
A new function with SU53 is the ability to display another user’s SU53 results. (Click on the ‘other user’ button and enter the person’s SAP ID).
Remember to establish a support roster, including after hours for critical batch processes, to ensure security-related issues are resolved in a timely fashion.
Dumps should be checked regularly (Objects s_rfc and s_c_funct like making appearances in dumps) for any authorizations-related issues. Transaction ST22 can be used to review dumps for that day and the previous day.
Avoid transporting activity groups at peak times, as the generation of activity groups can cause momentarily loss of authorizations. It’s recommended that a roster for activity group transport and mass user comparison be reviewed with the project manager prior to the upgrade. Exceptions should be handled on an individual basis and the potential impact identified, based on number and type of users, batch jobs in progress, etc.
And, don’t forget to keep on tracking all issues and documenting the resolutions for future reference.
