Application Security-Pre and Post Upgrade Steps (MDG on S/4 Using RISE Methodology)

Recently one of the customers upgraded their MDG environment from ECC On-Prem to S/4 Hana Private Cloud using SAP RISE methodology. This blog post will try to cover various application Security Steps, Best Practice’s, Do’s, and Don’ts during such an upgrade.

Technical details of the upgrade are as follows:

 Introduction of RISE with SAP:

RISE with SAP helps companies to get started with cloud SAP solutions. RISE with SAP draws inspiration from those ideas and presents itself in a set of “ones,” defined as:

One offer: bundled products for a single price

One contract: ability to manage SLA, operations, and issue management without signing contracts for each.

RISE offering will result into reduced cost for the customer both on the PRODUCTS front as well as in terms of user licensing. RISE with SAP provides access to a lot of services that pertain to areas of lifecycle management, analytics, support.

MDG upgrade can be a bit different and deceptive vis-à-vis other SAP product upgrades. From an application security standpoint, the core reason for this in my experience is the usage of webdynpro applications and not transaction codes. We might end up adding authorization objects manually in the roles which is against the core philosophy of SAP’s role maintenance strategy.  Let’s dig deep into the pre and post upgrade steps and nuances from an application security perspective which a security architect must follow during the upgrade journey.

Pre-Upgrade Steps:

1)Plan: It is imperative to have a comprehensive upgrade plan in place with security tasks   very clearly articulated and tagged to precise timelines. The plan should also comprise of key stages of the SDLC lifecycle. Viz Design, Implementation, Testing, Cut-Over, Go-Live & Hyper-Care.

2)Testing: Maximum emphasis should be given to this step. Since the roles will be modified it becomes extremely important that the roles go through unit testing, a detailed integration testing and user acceptance testing. A detailed testing plan must be in place before the upgrade.

3)Back Up: Before we start executing the post upgrade steps using tcode SU25 – Upgrade Tool for Profile Generator we need to take back up of the following critical tables:

a) USOBT & USOBT_C

b) USOBX & USOBX_C

c) AGR_1250

d) AGR_1251

e) AGR_1252

f) AGR_DEFINE

4) Sandbox Environment: It would be better to upgrade an Sandbox environment first so that not only the Security team but all other teams involved would get a feel and hang of all the activities involved and this would help in planning the entire project. As far as Security is concerned SU25 steps could at times be very time consuming subjective to the number of roles in the system and the number of roles being affected due to the newer version. Hence performing the steps in Sandbox gives an added advantage to the Security architect to meticulously plan the different steps which are part of the upgrade.

5) Change Management or Transport Methodology: Another very critical aspect of an upgrade is change management or transport strategy. If the upgrade is on the existing maintenance or production landscape, then we need not worry much from a security perspective but if in case the maintenance landscape is a non-upgraded one and we are building a new system altogether with a copy of existing system we must be extremely vary about the content of each role. We must ensure that each and every role is in sync across the landscape and also changes are appropriately retrofitted in the upgraded environment in a timely manner. Normally, security teams prefer doing manual retrofits as compared to auto – retrofits which other teams (Functional/ Development) prefer i.e directly move the transport from one system to another. But in case of Security such an action could be disastrous if in case proper due diligence is missing. Our one transport request can comprise of multiple Security roles and authorizations hence most of the implementors prefer manual retrofit instead of an auto-retrofit.

6) Last but not the least extract the list of transaction codes/webdynpro applications/reports which are currently being used in the Production environment but users and are part of the roles. This data would be useful to reconcile the changes and compare pre and post upgrade SU24 mapping.

Post-Upgrade Steps:

There is a lot of material already available regarding SU25 steps in the public forum and even within the transaction in form of information but here I am trying to articulate based on my experience:

Once the technical upgrade is completed and the system is handed over to us by the BASIS team, we need to start performing the steps mentioned in the transaction code SU25 – Upgrade tool for profile generator.

Step 1:

This step will populate and fill the customer tables USOBX_C and USOBT_C (SU24 Tcode) from Std. tables USOBX and USOBT (SU22 tcode). This step is performed only one is a system’s lifetime i.e., during installation. Need not execute this step after an upgrade of the existing system. Standard tables would remain as is.

Step2: This step has 4 sub-steps (2a, 2b, 2c & 2d). Combined this step is called as

Postprocess settings after upgrading to a higher release.

2a) Automatic Comparison with SU22 Data

In this step, SAP would compare and adjust transaction codes to auth object mapping automatically and the scope would include transaction codes for which the SU24 mapping has not been changed by the customer.  For example:

Tcode: STMS_IMPORT – TMS Import Queue.

In the non-upgraded environment this tcode used to check following Auth Objects:

In the upgraded environment this tcode check following Auth Objects:

So, no more check on Auth Objects S_BTCH_ADM, S_RFC, S_DEVELOP so that means complexity reduces and the roles would be lighter in the upgraded environment. Since this was not changed by the customer automatic adjustment will happen in Step 2A. If this would have been manually changed or adjusted by the customer it would have been considered in step 2B.

Step 2B: Modification Comparison with SU22 Data

In this step, the system would give you an insight about the tcodes/webdynpros for which SU24 mapping has changed and even in the current environment the client had changed the default SU24 mapping for those tcodes. It would be the client prerogative to adopt new SU24 mappings or continue with the existing ones and only maintain / change subjective to the testing. This step could become time consuming depending on the list of tcodes that are being shown and the approach that the upgrade security team is taking. Most of the customers prefer to keep the existing mapping and do no change to SAP std. They decide to change depending on the testing results.

Step 2C: Roles to be checked

Most critical and important step as part of the Security post upgrade tasks. This step will give a list of all the roles both SAP Std and Custom which have been affected due to steps 2A and 2B. It is imperative for the Security architect to maintain each customized role and generate the profiles. If this is not done roles will not functional as per the requirement and security would be in a mess and hence maintenance of custom roles that appear in Step 2C is mandatory.

In this case there 2 options:

1. a) Merge Mode
2. b) Non-Merge mode or Deactivate Merge Mode or Manual Maintenance.

Again, most of the clients prefer Manual maintenance, so the security architect would go into every role and deactivate the newly added auth objects and only maintain them based on the authorization testing results. But just a word of caution, there would be defaults which would get automatically adjusted without the security architect even being aware, so appropriate due diligence is expected from the security architect in this step.

Hence it is better to compare roles between non-upgraded and upgraded environment to streamline and highlight the delta authorizations.

Step 2D: Search for obsolete applications

This step would give an insight into obsolete transaction codes and its affect on roles. It would give you a holistic view about which tcode be replaced in which role and which tcode would be deleted or does not exist or is obsolete in the upgraded environment. Security architect will have to adjust the menu and generate the profile of those affected corresponding roles.

Step 3: Transport the customer tables.

In most upgrades, this step is the final step. Security practitioner need not run all these steps in the non-development systems. This step will primarily capture all changes in Steps 2A & 2B in a Transport Request. Step 3 & 4 would be covered by transporting the roles that we will modify. Hence all the steps have to be performed only in the DEV environment.

In conclusion Best Practises as part of an upgrade are as follows:

1) Backup of custom tables (USOBX_C & USOBT_C) prior to upgrade. Segregate the    transactions in use in production roles.

2) Take the dump of the same tables after executing Step 2A and 2B in SU25 post upgrade.

3) VLOOKUP between these tables prior and post upgrade to find out the delta in authorization mapping.

4) Adjust the roles accordingly as per business requirement and testing results.

5) Make sure to have a robust security testing strategy in place.

6) Ensure to retrofit roles from the maintenance landscape (If and only If the upgrade is in a different landscape viz N+1 environment).

7)Make sure due to retrofit none of the post upgrade changes are overwritten and before the actual transport from DEV is done compare the roles with the production version.

8)Post transport do check for the authorization profile status. Profiles should have the current version.

9) Equal emphasis to be given to maintenance of both Business and IT Support Roles.

10) Maintain comprehensive documentation for every role which has been modified due to upgrade.

Hope this blog post helps SAP Security Practitioners who plan to work on upgrades.

Best Regards,

Suyog.