Security of Tables Previous Functionality Securing direct table access (both display and update) is a constant area of concern

n for auditors and the business. Within SAP there are various transactions that allow you to display and edit tables. These transactions include the following: SE16 SE16N SE17 SM30 SM31 SM34 Data Browser General Table Display General Table Display Call View Maintenance Call View Maintenance Like SM30 Viewcluster maintenance call

Controlling which tables a user could access was not very granular. SAP security delivered authorization object S_TABU_DIS which would allow you to assign access to users based on table authorization group. This is a flag that is attached to the table using transaction SE54 (maintained in table TDDAT). This basically allowed a customer to secure access to GROUPS of tables. This table authorization group was only 4 digits long so it did not provide the flexibility to create authorization groups for individual tables. What this meant is that access could only be controlled at this group level, and not the individual table level. This left gaps in the ability to secure tables to a level required for appropriate control. An example is below. The two tables below are both assigned to the SS table authorization group. The first table, T000 is considered a highly sensitive table and access to this table needs to be strictly controlled. However, the other table T100, is a master data table and users do need the ability to update it. T000 Change View Clients T100 Message Maintenance The problem stems from the fact if you provide access to a user that needs to update table T100, they automatically get the ability to edit table T000 as well.

Summary of new Functionality: With SAP note 1481950, customers have the option to implement a complementary security concept related to table level security. Basically, a new authorization object (permission) called S_TABU_NAM is being offered. This note was released on September 13, 2010 and is only relevant to Basis versions 7.0 and higher. This functionality is not delivered in lower basis levels.

This functionality enhancement is described in detail in SAP notes 1522661, 1516880, 1503975, 1500054 and 1434284. Please review SAP note 1434284 in detail as a good overview.

Example of How New Functionality Works: Below is a real-world example of how this new security works. First of all, the previous use of S_TABU_DIS is unchanged, even after implementation of S_TABU_NAM. If a customer creates a role that has access to a certain table authorization group, the user can edit all tables in this authorization group regardless of what S_TABU_NAM values they have. In this example, the role was created to have access to table authorization group SS. This user does NOT have authorization object S_TABU_NAM.

This user can edit table T000 and table T100 as shown below:

A second user was created that only has S_TABU_NAM and does not have any access to S_TABU_DIS. The user is only given access to table T000 per this role.

This user can edit table T000.

However, the user can NOT edit table T100. This effectively shows how you can now restrict access to certain specific tables without having to give access to all tables in a certain authorization group.

If a user has both S_TABU_DIS and S_TABU_NAM, S_TABU_DIS always overwrites. In the example below, the user has S_TABU_DIS for SS authorization group, but S_TABU_NAM is restricted to table T000.

The user can edit both tables T000 and T100. Basically, the first check is always for S_TABU_DIS and if the user has the necessary authorization, S_TABU_NAM is not checked.

Impact to Risk Analysis and Remediation: Because table maintenance and security is very critical to GRC customers, this change was evaluated in detail and the following pages provide guidance on how customers who implement this new authorization object can leverage existing Risk Analysis and Remediation (RAR) rule architect capability to evaluate this security concept. Implementing this concept in RAR is not entirely straightforward as the security logic behind S_TABU_NAM is different than with other authorization objects. Specifically, its because theres an OR relationship between S_TABU_DIS and S_TABU_NAM, that the structure of the rules has to be a bit different than normal rules. SAP note 1434284 explains the security concept in detail. 1. Basically, the first check will always be for S_TABU_DIS. If the user has the necessary table authorization group, then they can edit/view the table. 2. HOWEVER, if this auth check fails and theyve implemented SAP note 1516880 to activate S_TABU_NAM, then if the customer has S_TABU_NAM with the required table name, theyll be able to edit/view the table.

PLEASE NOTE The following is an example only. What tables are considered critical are unique to every customer. SAP will not provide a listing of critical tables or rules. Its up to each customer to identify which tables they consider critical and then build the rules as appropriate. The below data is used to demonstrate how the RAR rules should be structured when S_TABU_NAM is implemented. Customer has enabled the S_TABU_NAM concept. Specifically the customer is concerned with table T000 which allows them to configure client settings. They want to identify any user who has access to change this table. This table is part of the SS authorization group. They have various users that have various security combinations as per below. All of these users CAN edit table T000. 1. SM30_1 SM30 S_TABU_DIS ACTVT = 02 DICBERCLS = SS 2. SM30_2 SM30 S_TABU_NAM ACTVT = 02 TABNAME = T000 3. SM30_3 SM30 S_TABU_DIS ACTVT = 02 DICBERCLS = SS S_TABU_NAM ACTVT = 02 TABNAME = T000 In addition, they have the user below who cannot edit table T000. This is just to demonstrate that RAR reports are accurate: 1. SM30_4 SM30 S_TABU_NAM ACTVT = 02 TABNAME = T100

In order to identify users that can edit table T000 using transaction SM30, you will need to create TWO different functions. One will have S_TABU_DIS and one will have S_TABU_NAM. First, you can create a function that references S_TABU_DIS. Create a function and add the transaction in question. You can add multiple transactions if wanted, we are just demonstrating with one.

This will automatically bring in the authorization objects relevant for SM30. VERY IMPORTANT in this area, only enable S_TABU_DIS. If S_TABU_NAM also comes in, leave it inactive. In this example, the table in question is table T000 which is in authorization group (DICBERCLS) SS. Therefore, the permissions are set up as per below:

Next, you must create ANOTHER function with the exact same actions.

In this function, we want S_TABU_NAM to be active. Do not activate S_TABU_DIS in this function. Go to the permission tab. It may be that S_TABU_NAM does not default. If that is the case, click on the pencil icon next to the action.

You can manually add authorization object S_TABU_NAM. You can only add one field at a time, so start with the ACTVT (activity field).

Once this is added, expand the permission. Right now, this only has ACTVT. We need to add field TABLE to this as well. Click on the + sign underneath S_TABU_NAM.

This will add a new row where you can enter the table name that you want RAR to evaluate. Save this function.

After the function is created, you must create the related risks. Again, youll have to create TWO risks, one that has the function with S_TABU_DIS and one that has the function with S_TABU_NAM. In this example, were just creating a critical action risk. However, you can create a segregation of duties risk for this as well so that this function conflicts with another function. Below is the risk created for the first function. The name of the risk should indicate for which transaction and table it relates to as well as whether its S_TABU_NAM or S_TABU_DIS.

Create the second risk the same way, but refer to the second function created.

After these rules are generated, you can run a report on the users to identify which users have ability to change table T000 either via access to S_TABU_DIS or S_TABU_NAM. Below is an example report based on our test data:

Below are the results. This shows that RAR will correctly report the users based on the level of access they have. Note that user SM30_3 is reported twice. Technically, they are able to change table T000 because they have S_TABU_DIS, regardless of S_TABU_NAM. However, in order to correctly report all of the other users, this is the way the rules must be structured. Note that SM30_4 does not show any risks because this user only has access to table T100. So this shows that RAR is correctly reporting both positive and negative results.

Delivered Ruleset: In the current ruleset (updated as of Q2 2010), there are 187 transactions that have a permission check on S_TABU_DIS. This listing is attached here:

s_tabu_dis_in_rule s_currently....

Based on information in SAP note 1434284, the new S_TABU_NAM concept only applies to the generic table display transactions of SE16, SE16N, SE17, SM30, SM31, and SM34, and generic function modules such as RFC_READ_TABLE. The S_TABU_DIS checks for other transactions and programs are hardcoded in and can NOT be replaced with S_TABU_NAM. What this means is the majority of transactions in our rules that check for S_TABU_DIS will remain as is. These transactions will continue to require S_TABU_DIS permission and if the permission check fails, the user cannot execute the transaction, regardless of what S_TABU_NAM authorizations they have. This means, its really only the rules for the transactions below that need to be assessed: SE16 SE16N SE17 SM30 SM31 SM34

Right now, these transactions are in functions BS03 - Basis Table Maintenance, BS16 - Basis Configuration Actions and BS17 - Basis Critical Actions. In our rules, we only include EDITING of tables as critical. We do not get into the criticality of display of tables because this is customer specific. A table one customer thinks is critical to display, another customer will think is not. So at the base level, our rules are really only concerned about editing of tables. Below are the settings currently for these transactions in our rules: SE16 S_TABU_DIS ACTVT 01-02 S_TABU_DIS ACTVT 01-02

SE16N

SE17 Not currently in rules this is strictly display only and you cannot edit. Because our rules only care about editing of tables, not display, its not in the rules. SM30 S_TABU_DIS ACTVT 02 S_TABU_DIS ACTVT 02

SM31

SM34 Not currently in rules. This is view and maintain cluster maintenance. Does not appear to be actual table maintenance.

Plan for Updating Default Ruleset The next scheduled ruleset update is Q2 2011. As part of this ruleset update, we will be adding one new function that will include the transactions below with S_TABU_NAM activated. SE16 SE16N SM30 SM31 This new function will be set to conflict with the other functions that these transactions are already a part of. If a customer has NOT implementing SAP note 1481950, this change wont impact them at all because no users will have S_TABU_NAM. For customers that have implemented this note, it will be important to adjust the TABLE name in this function as needed to identify the critical tables that each customer cares about. Again, SAP will not deliver the listing of any tables. The function we deliver will only have ACTVT 02 enabled. The exact tables to be analyzed will have to be updated by each customer.